The Problem
Patch management doesn’t generate much excitement. It’s not a strategic initiative, it doesn’t show up in board presentations, and it’s rarely the focus of a vendor sales pitch. It is, however, one of the most consistently scrutinized controls in IT examinations — and one of the most common pathways for breaches at institutions that experience them.
The challenge isn’t that institutions don’t patch. Most do, eventually. The challenge is that “eventually” isn’t a patch management program. Examiners want to see documented timelines, prioritization based on risk, evidence that patching is happening on schedule, and a process for handling the systems that can’t be patched on the standard cycle.
Why It Matters More Than Ever
Threat actors actively monitor public vulnerability disclosures. The time between a CVE being published and exploitation attempts beginning has compressed dramatically over the past several years — in some cases measured in days, not weeks. A patch management program built around monthly cycles with no urgency tier for critical vulnerabilities is operating on a timeline that no longer matches the threat environment.
CISA’s Known Exploited Vulnerabilities (KEV) catalog, which tracks vulnerabilities with confirmed in-the-wild exploitation, has grown substantially since its launch. Many of the vulnerabilities on that list are not obscure zero-days — they are well-known, long-disclosed weaknesses in common enterprise software. The institutions that get hit are frequently running unpatched versions of systems they knew were vulnerable.
What Examiners Expect
A Written Patch Management Policy
The policy should define what systems are in scope, who is responsible for patching, how patches are prioritized (typically by severity rating — Critical, High, Medium, Low), and the target timeframes for each tier. A common framework is: Critical vulnerabilities patched within 72 hours to 7 days; High within 30 days; Medium within 90 days. Examiners will compare your actual patching activity against whatever timelines your policy establishes.
A Current Asset Inventory
You cannot patch what you don’t know exists. Examiners frequently find that institutions have systems — older workstations, network equipment, point-of-sale terminals, branch servers — that aren’t included in the patch management scope because they were never formally inventoried. A complete asset inventory is the prerequisite to a complete patching program.
Evidence of Ongoing Patching Activity
Examiners will ask for patch scan reports or patch management platform exports showing current vulnerability status across your environment. They want to see not just that patches were applied, but when they were applied relative to release date, and what the current state of outstanding vulnerabilities looks like. A clean report is the goal, but an honest report with a clear remediation plan for outstanding items is far better than a report that doesn’t reflect reality.
A Process for Exceptions
Some systems can’t be patched on the standard cycle. Legacy systems with limited vendor support, systems requiring vendor involvement to patch safely, or systems where patching would disrupt critical operations all create legitimate exceptions. Examiners don’t expect zero exceptions — they expect a documented exception process: who approved the exception, what compensating controls are in place, and when the exception will be resolved or reassessed.
End-of-Life System Management
Operating systems and applications that have reached end-of-life receive no further security patches from the vendor. Running EOL software is a significant finding. Examiners will specifically ask about EOL systems, and they expect either a documented migration plan with a target date or an accepted risk decision with compensating controls. Neither is a permanent answer — but having a plan is far better than having none.
Building a Defensible Program
If your patch management program needs structure, start with these four elements:
- Get a vulnerability scanner in place. You cannot manage what you cannot measure. A basic authenticated vulnerability scan of your environment will give you a current-state baseline and is the foundation for everything else. Many MSPs include this capability, and standalone tools are available at accessible price points for smaller institutions.
- Define your tiers and timelines in writing. Document your severity-based patching timelines in a policy that is reviewed and approved by management. Once the timelines are in writing, they become your standard — and your patching activity will be evaluated against them.
- Build a patching calendar. Regular patch cycles — weekly for critical systems, monthly for everything else — are easier to sustain than ad-hoc patching. A calendar also makes it easier to demonstrate program activity to examiners.
- Document exceptions formally. Create a simple exception log: system name, reason for exception, compensating controls, approved by, and target resolution date. Review it quarterly and close exceptions as systems are updated or migrated.
Practical Checklist
- Written patch management policy defining scope, ownership, severity tiers, and patching timelines
- Complete asset inventory covering all systems in the patching scope
- Vulnerability scanning conducted on a documented schedule with results retained
- Patching activity documented with dates applied and comparison to policy timelines
- Formal exception process with documented approvals and compensating controls for delayed patches
- End-of-life systems inventoried with migration plans or accepted-risk decisions on file
- Critical vulnerability patches applied within policy-defined timeframes (tracked and verifiable)
- Patch management status reported to management on a regular basis