Security & Compliance
What Is Patch Management? A Guide
What patch management means, why unpatched software causes breaches, the six-step process, patch rings, SLAs by severity, and how to run it without breaking production.
Most breaches do not use a clever zero-day. They use a vulnerability that was fixed months ago on a machine nobody updated. Patch management is the discipline that closes that gap on purpose instead of by luck.
Definition
What is patch management?
Patch management is the process of identifying, testing, deploying and verifying software updates across every device an organisation runs — operating systems, applications, drivers and firmware.
It is a security control first and a maintenance task second. When a vendor publishes a patch, they also effectively publish the existence of the vulnerability — and attackers reverse-engineer patches to build exploits within days.
NIST SP 800-40 Rev. 4, the standard reference for enterprise patch management, frames it the same way from the planning side: patching is preventive maintenance for organisational risk, and the goal is a boring, repeatable routine — not a heroic scramble every time an advisory lands. The organisations that patch well are not the ones with the most staff; they are the ones where the cycle runs the same way every month.
Patch management is one part of the wider discipline of vulnerability assessment and vulnerability management: assessment finds and prioritises weaknesses of every kind, and patching is the remediation you apply when a vendor fix exists.
Why patch management matters
Patch management matters because known, fixed vulnerabilities remain one of the cheapest and most common ways into an organisation — the exploit is public, the target list is scannable, and the only defence is having applied the fix first.
- Over 11,000 new CVEs were published in the first quarter of 2026 alone, tracked in the National Vulnerability Database — the volume is beyond manual tracking
- Exploits for high-profile vulnerabilities frequently appear within days of the patch
- Unpatched software is one of the most common root causes in breach investigations
- Compliance frameworks require it explicitly: PCI DSS, ISO 27001 Annex A 8.8, SOC 2, HIPAA and NIS2
- Patch status is one of the fastest audit questions to fail if you cannot produce evidence
Process
The 6-step patch management process
The process is a loop, not a project: inventory what you have, detect what is missing, prioritise by real risk, test on a small group, deploy in stages, and verify with evidence. Every mature patch programme — whether it runs on SCCM, a cloud agent or a script — is some version of these six steps.
Step 1: Inventory
You cannot patch what you do not know about. The starting point is a live list of every device and the software on it — not a spreadsheet from last quarter. The machines that hurt you are precisely the ones missing from the list: the laptop that never comes to the office, the server someone stood up outside the process, the appliance nobody owns.
Agent-based inventory keeps this current automatically; devices report what they run every time they check in, wherever they are. If your asset register and your patch tool share one record per device, gaps become visible instead of silent.
Step 2: Detect
Scan every device for missing patches and map each gap to known CVEs and a severity. Detection should be continuous or at least daily — a weekly scan means your compliance picture is up to seven days stale, which matters when exploits appear within days of a patch release.
Detection must cover third-party applications, not just the operating system. Browsers, PDF readers, Java runtimes and collaboration tools are patched on their own schedules and heavily targeted; an OS-only view routinely misses the riskiest gaps on the machine.
Step 3: Prioritise
Patch by risk, not by release date. Anything on CISA's Known Exploited Vulnerabilities catalogue jumps the queue regardless of CVSS score, because it is being used in real attacks right now. After that, weigh severity against exposure: a medium-severity flaw on an internet-facing server usually outranks a critical one on an isolated lab machine.
This is where a defined severity-to-SLA mapping (below) earns its keep: it turns prioritisation from a nightly argument into a lookup.
Step 4: Test
Deploy to a small pilot ring first — a group tolerant of disruption and close enough to IT to report problems clearly. The purpose is not to validate the patch in general (the vendor did that); it is to catch the patch that breaks your specific line-of-business application, your VPN client or your printer driver.
Keep the pilot window short and defined — one to three days for workstation patches — so testing does not become the excuse for indefinite delay.
Step 5: Deploy
Roll out in rings on a schedule, inside maintenance windows, with a rollback plan. Deployment is where user trust is won or lost: patch outside business hours, give users a bounded ability to postpone a reboot, and never let a forced restart interrupt a presentation twice.
For servers, deploy inside agreed maintenance windows, stagger cluster nodes so one is always up, and know before you start how you would roll back — uninstall the update, restore a snapshot, or fail over — if the patch misbehaves.
Step 6: Verify
Confirm the patch actually applied and the device rebooted if the fix requires it — an installed-but-not-rebooted patch is often not active, and it is the most common form of false confidence in patch reporting.
Record the evidence per device and per CVE: what was deployed, when, to which machines, with what result. This is exactly what an auditor asks for, and it is also how you catch the five percent of installs that silently fail every cycle and would otherwise fall further behind each month.
Patch rings: how to deploy without breaking production
A patch ring is simply a group of machines that receives updates at a different time. A typical structure is: Ring 0 — IT team's own devices (day 0); Ring 1 — a pilot group of tolerant users (day 2); Ring 2 — general workforce (day 7); Ring 3 — servers and critical systems (day 14, in a maintenance window).
Promotion between rings should be a gate, not a calendar entry alone: move to the next ring when the previous one shows an acceptable success rate and no open incidents traced to the update. If Ring 1 turns up a broken application, the cycle pauses for everyone behind it — which is the entire point.
Build the pilot ring deliberately. A pilot made only of IT's identical laptops will never catch the driver conflict that appears on the finance team's older hardware; spread Ring 1 across departments, device models and hardware ages.
This structure costs you a few days of exposure on the last ring but prevents the far more expensive outcome: one bad patch taking down every machine simultaneously. Keep a small, documented exceptions group for devices that genuinely cannot follow the standard schedule — each with a named owner and a review date, so the exception list shrinks instead of quietly growing.
Patch SLAs by severity
A patch SLA is a written commitment: vulnerabilities of a given severity are remediated within a defined number of days. Set the targets by severity and exposure, put them in the patch policy, and report against them — without a defined SLA, "we patch regularly" is not an answer an auditor accepts.
- Critical / actively exploited (CISA KEV) — within 24 to 72 hours
- High — within 7 to 14 days
- Medium — within 30 days
- Low — next scheduled maintenance cycle
- Track the SLA from detection to verified install, not to "deployment started" — the clock an attacker cares about ends when the fix is active
Common patch management failure modes
Most patch programmes fail the same few ways, and almost all of them are process gaps rather than tooling gaps. If your compliance number has been stuck at the same percentage for months, one of these is usually why.
- Patching only the OS and ignoring third-party applications — browsers, PDF readers and Java are heavily targeted, and OS-native tools often cannot see them at all
- No inventory, so laptops that are rarely online silently fall years behind — roaming devices are the most under-patched group in most organisations
- Treating reboot-required as done — an installed patch that never rebooted is often not active, and dashboards that count installs rather than active fixes overstate your posture
- No verification step, so failures are discovered during the next audit rather than the next day
- Manual tracking in spreadsheets, which stops scaling at about thirty machines
- No rollback plan, so the first bad patch turns into an all-hands outage instead of a contained Ring 1 incident
- SLAs that exist on paper but are never reported against, which is indistinguishable from having none
Infronest
Conclusion
Infronest's Patch Management module scans for missing patches across Windows and Linux, deploys them in rings on a schedule, and reports compliance — using a single lightweight agent, inside the same workspace as your asset register, monitoring and helpdesk, so a missing patch on a known asset can become a tracked ticket automatically.
If you are still choosing tooling, our patch management tools comparison walks through WSUS, Intune, ManageEngine, Automox, Action1 and the automation options side by side.
Start a 14-day free trial at infronest.com — no credit card required.
Frequently Asked Questions
- What is patch management in simple terms?
- It is the organised process of keeping software up to date across every device you own — finding which updates are missing, deciding what to install first, testing, deploying and then proving it worked.
- How often should you patch?
- Continuously detect, and deploy on a defined schedule with severity-based SLAs: critical or actively exploited vulnerabilities within 24 to 72 hours, high within 7 to 14 days, medium within 30 days. Most organisations anchor the workstation cycle to the monthly vendor release rhythm and patch servers in scheduled maintenance windows.
- What is the difference between patch management and vulnerability management?
- Vulnerability management is the broader discipline of finding, prioritising and tracking all security weaknesses — including those with no patch, such as misconfigurations. Patch management is the specific process of deploying vendor updates. Patching is one of the remediations vulnerability management drives.
- What are patch rings and why use them?
- A patch ring is a group of machines that receives updates at a staggered time — IT first, a pilot group next, the general fleet after, servers last inside maintenance windows. Rings mean a bad patch damages twenty devices instead of two thousand, at the cost of a few days' extra exposure on the final ring.
- What is a good patch management SLA?
- A common baseline: critical or actively exploited vulnerabilities remediated within 24 to 72 hours, high severity within 7 to 14 days, medium within 30 days, and low in the next maintenance cycle. Measure from detection to verified install, and put the targets in a written policy you report against.
- Is Windows Update enough for patch management?
- Not for an organisation. Windows Update patches one machine with no central visibility, no ring control, no third-party application coverage and no compliance evidence. Patch management adds central targeting, staged rollout, verification and the reporting an auditor will ask for.
- What should a patch management policy include?
- Scope (which devices and software), roles and owners, severity-based SLAs, the ring structure and testing approach, maintenance windows and reboot rules, the exception process with named owners and review dates, and how compliance is measured and evidenced. NIST SP 800-40 Rev. 4 is the reference most auditors recognise.
- Why do patches fail to install?
- The usual causes are a pending reboot blocking the next install, insufficient disk space, a device offline during its deployment window, a dependency or servicing-stack update missing, or an interrupted download. This is why verification is a distinct step: a few percent of installs fail every cycle, and without a retry-and-report loop those machines fall further behind each month.