The Patch Management Audit: 14 questions to ask before the next CVE drops
Patch management problems can remain hidden until an incident exposes them. By then, the question shifts from how do we fix this? to how do we explain this?
This audit helps surface those gaps before that conversation happens. Work through each question with the people who own the answers. A no or we don’t know is useful information. It tells you where to investigate and what needs attention.
Inventory and visibility
1. Do you maintain an up-to-date inventory of devices accessing your network, including unmanaged and BYOD endpoints?
If your answer is a spreadsheet updated quarterly, you may be working from a historical picture. Devices missing from your inventory might still receive updates, but your team cannot reliably verify their patch status. Know which devices you manage, which you only monitor, and who is responsible for the rest.
2. Does your inventory cover third-party and open-source software across managed endpoints, alongside operating systems?
An inventory that only tracks OS updates leaves application vulnerabilities out of view. Include browsers, productivity tools, developer utilities, and other installed software. Embedded components need attention too: A vulnerable library inside an application may not appear as a separately installed product.
3. Do you know which systems are internet-facing, and can you distinguish them from internal-only systems?
Prioritisation depends on exposure. All else being equal, a vulnerability reachable from the internet warrants greater urgency than the same flaw on an isolated system. If you cannot identify that exposure, an important part of your prioritization is guesswork.
4. Are cloud instances, virtual machines, and containers included in your vulnerability remediation scope, with clear ownership?
Short-lived infrastructure can slip past processes built for long-lived devices. For containers and immutable infrastructure, remediation may mean rebuilding an image and redeploying it rather than patching a running workload. Know what your team owns and what the cloud or service provider handles. Attacker scanners do not make exceptions for unclear responsibilities.
Process and SLAs
5. Do you have defined remediation deadlines based on risk, and are you measuring against them?
We patch as soon as possible is not an SLA. Set targets using exploitation evidence, exposure, business criticality, and severity. For example, your organization might require an actively exploited vulnerability on an internet-facing critical system to be addressed within 72 hours. That is an internal target, not a universal benchmark. Define when the clock starts and how exceptions are escalated.
6. Can you deploy an emergency patch or mitigation outside your standard maintenance window?
When an actively exploited vulnerability surfaces on a Thursday afternoon, waiting until Tuesday may leave an unacceptable exposure. If no patch exists, the response may require a vendor-recommended workaround, restricted access or temporary service isolation. Approvals still matter, but the emergency process needs named decision-makers and a clear turnaround time. Find out how long it actually takes.
7. Are patch exceptions formally documented, time-bounded and reviewed?
Every program has systems that cannot be patched on schedule. Record the reason, affected assets, accountable owner, compensating controls, and next review date. An exception granted two years ago and never revisited may have become a permanent exposure without anyone explicitly accepting that decision.
8. Do your agreements with third-party vendors and managed service providers define patching responsibilities and timelines?
If a vendor manages systems on your behalf, your internal SLA does not automatically bind them. Agree on remediation deadlines, emergency notification, exceptions, and evidence of completion. If the contract leaves those responsibilities unclear, that is a gap worth closing.
Prioritization
9. Are you using CISA’s Known Exploited Vulnerabilities catalogue alongside severity and asset context?
CVSS base scores describe intrinsic severity. The KEV catalogue adds evidence that a vulnerability has been exploited in the wild. A high-rated KEV may deserve attention ahead of a critical-rated vulnerability with no exploitation evidence, depending on exposure and business impact. Use those signals together. If your team has not reviewed relevant KEV updates recently, check them now.
10. Do you track whether vulnerabilities in your environment are associated with active threat actors or ransomware activity?
Severity and KEV status tell you part of the story. Evidence that a ransomware group is exploiting a vulnerability affecting your systems can increase the urgency, especially if its activity is relevant to your sector. Endpoint Central’s documented risk-scoring inputs include active exploitation, threat-actor interest and ransomware-affiliate activity, alongside factors such as EPSS and remediation availability. The purpose is to bring more of that context into prioritization.
11. Do you have a documented risk-management process for legacy systems and OT environments that cannot follow standard patch timelines?
These systems can have operational, safety, or vendor-support constraints that require a different approach. Record those constraints, assign an owner and assess suitable compensating controls. Where no supported fix exists, include a replacement, upgrade, or isolation plan where feasible. A system should not disappear from the risk register because patching it is difficult.
Testing and verification
12. Do you verify remediation after deployment, including required reboots and failed or offline devices?
A successful deployment status is useful evidence, but it should not be your only check. Confirm that the expected update or fixed version is present and that required reboots have completed. Use appropriate follow-up scans or checks to identify remaining exposure. Investigate devices that failed, stayed offline or returned incomplete results.
13. Does patch testing have a defined, risk-based time limit and an emergency route?
Testing is necessary. It can also become an indefinite holding area. Use representative systems and clear criteria for approving, pausing or rolling back a deployment. If a patch sits in staging for two weeks, the team should be able to explain why that delay is justified and how exposure is being managed in the meantime.
14. Do you periodically reconcile vulnerability findings with patch records across your in-scope environment?
Post-deployment checks confirm individual changes. Periodic reconciliation looks for wider gaps: assets missing from the patch tool, stale scan results, unsupported software, and vulnerabilities that remain open despite apparently successful deployments. Investigate discrepancies rather than assuming either tool is always right. Track each unresolved finding to an owner.
Reviewing your results
Count your yes answers.
12 to 14: Your programme is mature. Focus on the gaps you found and verify that documentation matches practice.
8 to 11: Solid foundations with identifiable gaps. Prioritise questions 5, 6, and 9 first; those tend to have the highest risk impact.
Below 8: Material exposure. Start with inventory (questions 1 to 4), because everything else depends on knowing what you have.
A we don’t know counts as a no. The goal of this audit is not a score. It is an honest picture of where your programme stands before the next CVE makes that picture visible to someone else.
References