Patch management is the routine of finding, prioritising, testing and installing updates (patches) for the software your business relies on, from website plugins to server operating systems. Most patches fix bugs or security flaws that have already been made public. Once a flaw is public, attackers can look for systems that have not been updated yet, so the gap between a fix being released and you installing it matters.
For a small or medium-sized business, the hard part is rarely the update itself. Problems usually come from not knowing what needs updating, who is responsible, or whether an update will break something.
What needs patching
A typical business website or web app depends on more layers than the code you paid for:
- Operating systems on servers, virtual machines and staff computers.
- Server software such as web servers, databases, PHP, Node.js or .NET runtimes.
- Platforms and CMSs, for example WordPress, Magento or other e-commerce and content systems.
- Plugins, themes and extensions added to those platforms.
- Libraries and dependencies used inside custom code, often pulled in automatically by package managers.
- Network and security devices such as firewalls, routers and VPN appliances, which have firmware of their own.
- Cloud and hosted services, where the provider patches some layers and you remain responsible for others.
A practical patch management routine
1. Keep an inventory
You cannot patch what you do not know you have. Keep a simple list of systems, the software and versions they run, who maintains each one, and where they are hosted. Include plugins and major libraries, not just servers.
2. Watch for updates and advisories
Subscribe to security announcements from the vendors and projects you use, and check update notices in your CMS or hosting control panel. If your developer or support provider tracks this, confirm it.
3. Prioritise by risk
Not every update is urgent. Severity ratings such as CVSS scores help, but two other questions often matter more: is the flaw being actively exploited, and is the affected system reachable from the internet? CISA's Known Exploited Vulnerabilities (KEV) catalog, published by the US Cybersecurity and Infrastructure Security Agency, lists flaws with evidence of real-world exploitation and is a useful signal for what to move to the front of the queue. A critical flaw on a public website usually comes before a minor fix on an internal tool.
4. Test before production
Apply updates to a staging environment first, then check the key flows that matter to the business, such as login, checkout, booking and forms. Regression testing, manual or automated, helps confirm that existing features still work after the update.
5. Schedule a maintenance window
Agree regular times for routine updates when traffic is low, and tell staff or customers if the site may be briefly unavailable. Keep a faster path for urgent security fixes, as these may not be able to wait for the next scheduled window.
6. Plan rollback
Before updating, take a backup or snapshot and know how to restore it. Record the previous version numbers so a problematic update can be reversed quickly.
7. Verify and record
After the update, confirm the new version is running and the site behaves normally. Website monitoring can catch errors or downtime that appear afterwards. Log what was updated, when and by whom.
End-of-life software
Every product version eventually reaches end of life, after which the vendor stops releasing security fixes. Running end-of-life software means new flaws will not be fixed at all. Track support dates for your operating systems, runtimes and platforms, and plan upgrades well before they expire. Large version jumps often need development work, which is one way technical debt builds up when updates are postponed.
Who is responsible?
Responsibility for patching is often unclear, especially when a website was built by one vendor and hosted by another. Write down who handles each layer: hosting provider, developer, internal IT or a support partner. A software support SLA can state which updates are included, how quickly urgent security patches are applied and how testing is handled. If nothing is written down, assume nobody is doing it.
A web application firewall can reduce exposure while a fix is being tested, but it does not replace the update. technine.io's Managed Support and SLA service covers ongoing security patching and dependency updates as part of routine maintenance.
Frequently asked questions
How often should we apply patches?
Many teams run routine updates on a regular schedule, such as monthly, and handle urgent security fixes as soon as they can be tested. The right frequency depends on how exposed and how critical each system is.
Should we turn on automatic updates?
Automatic updates suit some components, such as minor security releases for well-supported software. For business-critical websites and custom systems, updates are usually safer when tested first, because an untested update can quietly break a plugin or integration.
Is a managed hosting plan enough?
It depends on the plan. Hosting providers often patch the server and operating system, but not your CMS, plugins or custom code. Check exactly which layers are covered.
What if an update breaks the site?
Roll back to the backup or previous version, then investigate on staging. If the update was a security fix, look for a temporary mitigation, such as a firewall rule or disabling the affected feature, until a working update is ready.