Home / Knowledge hub / Patch management
Knowledge hub
Patch management
The routine of tracking, testing and rolling out updates across your systems.
What it means
Patch management is the routine of finding out which updates exist for the software you run, deciding which matter, testing them, installing them and checking that they worked. A patch is a small update from the maker that fixes a flaw, and sometimes a bug that is not a security matter.
It covers more than operating systems. Libraries your app depends on, container images, databases, routers and the tools your team uses all need updates. The hard part is rarely installing one patch. It is knowing what you run and doing the work on time, every month.
Why it matters
Many breaches use flaws for which a fix already existed. The attacker did not need anything new, only a system that nobody had updated. Once a patch is public, anyone can compare it with the old version and work out what was fixed, which shortens the time before attempts begin.
The opposite risk is real as well. A patch pushed without testing can stop a payment flow or break a login. A good routine is quick for urgent fixes and calm for the rest, and it leaves a record that an auditor can read.
How it shows up
NIST SP 800-40 Rev. 4 treats it as routine maintenance with a plan for emergencies. Keep an asset inventory, rank updates by exploitation and exposure (see risk-based prioritisation), test in a copy, roll out in stages, and keep a way to roll back. Set target times for each priority.
Where it goes wrong is usually boring. A server nobody remembers, a library pinned to an old version, a container image never rebuilt, or a vendor product that cannot be patched without downtime nobody will approve. When a patch cannot be applied, record why and add a compensating control with a date to review.
Questions people ask
Patch management, answered
What is the difference between patching and updating?
A patch usually fixes a specific flaw or bug. An update may also add features or change behaviour. In practice the words are used loosely.
What matters is that security fixes reach your systems quickly.
How fast should we patch?
It depends on exploitation and exposure. Flaws known to be exploited, on systems reachable from the internet, should be fixed in days. Others can follow a monthly cycle.
CISA gives federal agencies fixed deadlines for flaws in its known exploited catalogue, which is a useful benchmark.
Does patching cover our own code?
Fixing a flaw in your code is a fix or release rather than a patch from a vendor, but the same discipline applies: find, test, ship, verify.
A closed-loop retest confirms the fix worked.
What if we cannot patch?
Isolate the system, restrict who can reach it, add a filter in front, or replace it. Write down the reason and set a review date.
Leaving the gap undocumented is the worst option.
Should patches be automatic?
For low-risk systems and endpoints, often yes. For production services that serve customers, staged rollouts with testing are safer.
Automatic does not mean unwatched. Check that updates actually installed.
Sources
Where this comes from
Related
Terms that sit next to this one
Patching
Applying the fixes that vendors and maintainers publish.
Vulnerability management
The loop of finding, prioritising, fixing and checking the fix held.
Asset inventory
A current list of the systems, apps and data you are responsible for.
Virtual patching
Blocking an exploit with a filter while the real fix is still being built.
End-of-life software
Software its maker no longer supports, so new flaws stay unfixed.
Did the patch actually close it?
After a fix ships, we re-run the exact exploit against the new code, so you know it closed rather than assume. A fresh scan is not the same check. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.