How to Audit Patch and Vulnerability Management

The vulnerability management dashboard shows 41,000 open findings and a downward trend, and the IT director presents it as progress. It is not evidence of anything. The number counts every finding on every scanned asset at every severity, most of it noise; the trend reflects a scanner reconfiguration; and the assets that matter, the internet-facing application servers, the domain controllers, the plant systems running an operating system its vendor stopped supporting three years ago, may not be in the scan at all. Meanwhile a vulnerability that appeared on the government’s catalog of actively exploited flaws two hundred days ago is still open on a server that faces the internet, and no one has noticed, because the dashboard does not have a column for that.

This guide is the method for auditing patch and vulnerability management as a program: the objective and the frameworks that define it, including NIST SP 800-40 Revision 4, the CISA Known Exploited Vulnerabilities catalog and PCI DSS, the asset-inventory reconciliation that has to come first because you cannot patch what you cannot see, scanning coverage and cadence, risk-based prioritization and the service-level matrix that turns it into deadlines, the metrics that measure outcome and the ones that only look like they do, exception governance and the unpatchable, emergency patching, the evidence to request, a twelve-test program, and a worked example at Brightwater Foods, a food manufacturer whose co-sourced audit found nine actively exploited vulnerabilities open for up to two hundred and ten days and fourteen plant systems on an operating system past its end of support. It sits within the cybersecurity program audit as the core of the protect function, and beside the change management guide, because every patch is a change.

In this guide

The objective, and the two programs inside it
You cannot patch what you cannot see: the inventory reconciliation
Scanning coverage and cadence
The handoff: from finding to ticket to patch to verification
Risk-based prioritization and the service-level matrix
Metrics that matter, and vanity metrics
Reporting to the board: the four numbers
Exception governance and the unpatchable
Emergency patching: the zero-day and the catalog addition
Cloud, containers and SaaS: where patching changes shape
The evidence to request
The twelve-test program
Worked example: Brightwater Foods and the plant systems nobody scanned
Common mistakes

The objective, and the two programs inside it

The objective is that known weaknesses in the organization’s technology are found, prioritized by the risk they actually pose, and fixed or mitigated within a time the organization has decided it can tolerate, with the decisions and the exceptions visible to the people accountable for the risk. Two programs deliver it and are often run by different teams. Vulnerability management finds and prioritizes: asset discovery, scanning, threat intelligence, scoring, reporting. Patch management fixes: acquiring, testing, deploying and verifying vendor updates and configuration changes, on a schedule and in emergencies. The audit covers both and, above all, the handoff between them, which is where findings that were identified go to wait.

The frameworks converge on the same expectations. NIST SP 800-40 Revision 4, published in April 2022, reframes patching as preventive maintenance, a cost of doing business rather than a security project, and recommends an enterprise strategy that plans for routine, emergency and exceptional cases including assets that cannot be patched. The NIST Cybersecurity Framework 2.0 places vulnerability identification in the identify function and software maintenance in the protect function. ISO/IEC 27001:2022 carries the requirement as Annex A control 8.8, management of technical vulnerabilities. CIS Control 7 is continuous vulnerability management. PCI DSS version 4.0.1 requires critical and high-security patches to be installed within one month of release and vulnerability scans at least quarterly and after significant changes. And since November 2021 the CISA Known Exploited Vulnerabilities catalog, established under Binding Operational Directive 22-01, has given every organization a short, authoritative list of the vulnerabilities attackers are actually using, with inclusion requiring a CVE identifier, reliable evidence of exploitation in the wild, and a clear remediation action; the directive binds federal civilian agencies to remediation deadlines and CISA strongly recommends that every organization prioritize catalog entries. Scoring has moved too: CVSS version 4.0, released by FIRST in November 2023, and the Exploit Prediction Scoring System, which estimates the probability of exploitation, are the current inputs to prioritization alongside the catalog.

Source	What it requires or provides	Use in the audit
NIST SP 800-40 Rev. 4 (April 2022)	Enterprise patch management planning; patching as preventive maintenance; routine, emergency and exceptional cases	The structure for evaluating the program’s strategy and its handling of the unpatchable
NIST CSF 2.0 (2024)	Identify: vulnerabilities in assets are identified and recorded; Protect: software and hardware maintained; Detect: continuous monitoring	Mapping for organizations using the CSF; ties to the program audit
ISO/IEC 27001:2022 Annex A 8.8	Information about technical vulnerabilities obtained, exposure evaluated, measures taken	Certification evidence; internal audit results of certified organizations
CIS Controls v8, Control 7	Continuous vulnerability management with safeguards for process, scanning and remediation	Practical safeguard checklist
PCI DSS v4.0.1	Critical and high-security patches within one month of release (6.3.3); internal and external scans at least quarterly and after significant changes (11.3)	Binding deadlines for cardholder data environments; a benchmark elsewhere
CISA Known Exploited Vulnerabilities catalog (BOD 22-01, November 2021)	Authoritative list of exploited vulnerabilities with remediation due dates for federal agencies; recommended for all	The exposure list every organization should reconcile its findings to
CVSS v4.0 (November 2023) and EPSS	Severity scoring; exploitation probability	Inputs to the prioritization test; neither alone is a priority

You cannot patch what you cannot see: the inventory reconciliation

Every metric the program reports is a percentage of the assets it knows about, and the assets it does not know about are, by selection, the ones nobody is patching. The first substantive test is therefore a reconciliation of the asset inventory against every other source that sees assets: the scanner’s discovered hosts, the directory’s computer objects, the endpoint management platform’s enrolled devices, the cloud providers’ resource lists, the network’s address leases and switch tables, and the operational technology inventory if there is one. The differences are the audit’s first population: assets the scanner has never seen, assets in the directory that no management platform knows, cloud instances nobody registered, and plant or building systems that live on the corporate network and appear in no inventory at all. The IT audit plan should already hold the reconciled universe; where it does not, this reconciliation builds it. The table lists the sources and what each reveals.

Source	What it sees	What the difference to the inventory reveals
Vulnerability scanner discovery	Hosts responding on scanned ranges	Assets scanned but not in the inventory (unknown assets); inventory assets never scanned (coverage gap)
Directory computer objects	Domain-joined machines, with last logon	Stale objects; machines in the directory that no management tool covers
Endpoint and server management platforms	Enrolled devices and their patch status	Devices outside management; patch status unknown
Cloud provider resource lists	Every instance, container host, managed service, across all accounts	Unregistered accounts; instances outside the scanner’s scope
Network address and switch data	Everything that has talked on the network	Devices in no other source: printers, cameras, plant controllers, contractor laptops
Operational technology inventory	Controllers, HMIs, historians, MES servers	Usually the largest gap; often unsupported operating systems
Software bill of materials and container registries	Components inside applications and images	Library vulnerabilities invisible to host scanning

Scanning coverage and cadence

With the universe established, coverage is a computed number: the proportion of in-scope assets scanned with credentials within the last cycle. Each word matters. Credentialed or agent-based scans see installed software and missing patches; unauthenticated scans see only what a network attacker sees, which understates internal exposure badly. The cycle should match the program’s own policy, weekly or continuous for most environments, with PCI’s quarterly minimum as a floor rather than a target, and a scan after every significant change. Coverage is reported by asset class and by criticality, because an overall figure of 92 percent can conceal that the 8 percent unscanned includes every domain controller. The audit tests coverage by re-computing it from the scanner’s own asset list against the reconciled universe, tests cadence from the scan schedule and run history, tests scan health from the failure and authentication-error logs the scanner keeps, and confirms that web applications, cloud configurations and container images are covered by the tools built for them rather than assumed to be covered by host scanning. External penetration tests supplement scanning; they do not replace it, and their findings should appear in the same remediation queue with the same clocks.

The handoff: from finding to ticket to patch to verification

Findings are identified by the security team and fixed by the infrastructure, application and cloud teams, and the space between them is where remediation dies. A finding that has no owner is nobody’s job; a finding whose ticket was raised against the wrong team bounces for weeks; a finding whose ticket was closed when the patch was scheduled rather than when the re-scan confirmed it is counted as fixed and is not. The program needs four things at the handoff, and the audit tests each: every asset in the universe has a named remediation owner, so that every finding inherits one; findings above a class threshold generate tickets automatically with the deadline from the matrix, rather than depending on someone reading a report; ticket closure requires evidence of verification, ideally an automated re-scan result attached to the ticket; and findings that miss their deadline escalate to the asset’s business owner rather than aging silently in the queue. The test is a trace: take forty findings across classes, follow each from detection to ticket to deployment record to verification, and time each step. The pattern that emerges, findings waiting days for a ticket, tickets waiting weeks for a maintenance window, closures without verification, is the program’s real cycle time, and it is usually several multiples of the deadline in the matrix.

Risk-based prioritization and the service-level matrix

A program that treats every critical-severity finding as equally urgent will fix none of them on time, because there are thousands. Prioritization combines three things: how bad the vulnerability is (the CVSS base score), how likely it is to be exploited (presence on the CISA catalog, EPSS probability, vendor and threat intelligence), and how exposed and important the asset is (internet-facing, holding sensitive data, supporting a critical process, reachable from user networks). The output is a small set of remediation classes with a deadline each, written into policy as a service-level matrix, and the audit tests three things about it: that the matrix exists and is risk-based rather than severity-only, that findings are actually assigned to the classes the matrix defines, and that the deadlines are met, measured from the date the finding was first detected rather than the date it was ticketed. The table is a workable matrix; the numbers are illustrative and an organization’s own matrix should be defended by reference to its exposure and its regulators, with PCI’s one month for critical and high patches and the CISA catalog deadlines as external anchors.

Class	Criteria	Remediation deadline from detection	Verification
Emergency	On the CISA catalog, or actively exploited per credible intelligence, on any internet-facing or critical asset; or a vendor emergency advisory for a widely deployed product	Mitigate within 48 hours; patch within 7 days; emergency change procedure	Re-scan or configuration check within 24 hours of the fix
Critical	CVSS critical, or high with high exploitation probability, on internet-facing or critical assets	15 days	Re-scan in the next cycle
High	CVSS critical or high on internal assets; catalog entries on isolated assets	30 days (PCI: one month for critical and high in the cardholder environment)	Re-scan in the next cycle
Medium	CVSS medium, or low-probability highs on low-exposure assets	90 days, aligned to routine maintenance windows	Quarterly reporting
Low	CVSS low; informational	Next scheduled upgrade; may be accepted	Annual review
Exception	Any finding that cannot meet its deadline	Documented risk acceptance with compensating control and expiry, per the exception section below	Re-review at expiry

Metrics that matter, and vanity metrics

The metrics that measure the program are all about time, coverage and the things that are not fixed; the metrics that decorate dashboards are all about volume. The audit computes the first set from the scanner and ticketing data and reports them, with the vanity metrics named as such, because the organization’s leadership has usually been receiving the wrong ones for years. The table gives both sets. Two habits make the computation reliable: measure remediation time from first detection to verified closure, not from ticket creation to ticket closure, and compute distributions rather than averages, because the tail of findings open for a year is the exposure and an average hides it.

Metric	Type	What it tells you	How to compute
Scan coverage by asset class and criticality	Outcome	Whether the program can see what matters	Credentialed scans in the last cycle divided by the reconciled universe
Catalog exposure: count and age of open CISA-catalog vulnerabilities	Outcome	Exposure to known active exploitation; the number the board should see	Open findings cross-referenced to the catalog; days since detection
Remediation time by class (median and 90th percentile)	Outcome	Whether the deadlines are real	Detection to verified closure per finding
Deadline compliance by class	Outcome	Proportion fixed within the matrix	Closed within deadline divided by all findings in class
Aging distribution of open findings	Outcome	The tail	Open findings by class and days open, in bands
Exceptions: count, age, expired, without compensating controls	Outcome	How much risk is being accepted and whether anyone still knows	Exception register analysis
End-of-support assets	Outcome	Unpatchable exposure	Inventory versus vendor support dates
Patch deployment success and rollback rate	Process	Whether the patching machinery works	Deployment platform reports
Total open findings	Vanity	Nothing; dominated by low-severity noise	Do not report without stratification
Findings closed per month	Vanity	Activity, not exposure	Report only alongside aging
Mean time to remediate, all severities	Vanity	An average across incomparable classes	Replace with per-class distributions

Reporting to the board: the four numbers

Boards and audit committees receive vulnerability data more often than any other security metric and understand it less, because they are given the volume figures. Four numbers, reported quarterly with a trend and a target, tell a board what it needs to know. The first is catalog exposure: how many actively exploited vulnerabilities are open on the estate, on what kinds of assets, and how old the oldest is; the target is zero beyond the emergency deadline, and a board that sees a nine and a two-hundred-day age understands immediately. The second is coverage: the proportion of the reconciled universe under credentialed scanning, by criticality, with the unscanned classes named. The third is deadline compliance by class, with the tail: the proportion of critical and high findings fixed within the matrix, and the count open beyond ninety days. The fourth is accepted risk: the number of exceptions and end-of-support systems, their age, and whether the compensating controls have been verified. The audit committee deck template has a place for a security slide, and these four numbers are that slide; internal audit’s role is to compute them independently once a year and compare them with what management reported, which is the reconciliation the worked example below turned on.

Exception governance and the unpatchable

Some findings cannot be fixed on time: the patch breaks the application, the vendor has not issued one, the system is past its end of support, the plant controller cannot be taken down until the annual shutdown. The program’s quality shows in how it handles these. An exception is a documented risk acceptance by the business owner of the asset, not by the IT team that wants the ticket closed; it states the compensating control that reduces the exposure meanwhile, network isolation, a web application firewall rule, enhanced monitoring, removal of the vulnerable feature; it has an expiry date and a re-review; and it is counted and reported. The audit tests the register for those attributes and for the pattern that defeats them, the perpetual exception renewed annually without anyone re-examining whether the compensating control still exists. End-of-support systems get their own treatment: an inventory with dates, a plan for each (upgrade, replace, isolate, retire), and, for operational technology that will run unsupported for years, segmentation from the corporate network with monitored, tightly controlled access, which is where the cybersecurity program audit and this one meet. NIST SP 800-40’s exceptional-case planning is the reference: the question is not whether the asset is patched but whether the organization has decided, on the record, what to do instead.

Emergency patching: the zero-day and the catalog addition

Routine patching runs on a calendar; emergency patching runs on a trigger, and the audit tests that the trigger exists and that the organization has responded to it recently. The triggers are additions to the CISA catalog, vendor emergency advisories, credible intelligence of active exploitation, and the organization’s own incident response finding a vulnerability being used against it. The process has four steps with times against them: assess applicability and exposure (which assets, are they reachable) within hours; mitigate where a patch is not yet available or cannot be applied immediately; patch through the emergency change procedure, which the change management guide describes, with after-the-fact approval and review; and verify by re-scan. The evidence is the record of the last several emergency events: when the advisory appeared, when the organization assessed it, what it found, what it did and when, and the emergency change tickets. An organization that cannot produce that record for the widely exploited vulnerabilities of the past year, and there are always several, either did not respond or did not record it, and either is the finding.

Cloud, containers and SaaS: where patching changes shape

Three parts of a modern estate do not patch the way servers do, and an audit built on the server model misreads them. In cloud infrastructure, managed services are patched by the provider under the shared responsibility model, but virtual machines, container hosts and the software inside them remain the customer’s, and the provider’s patch-management services only work for the instances enrolled in them; the test is enrollment coverage and the patch-compliance reports those services produce, reconciled to the cloud resource list. In containerized and immutable environments, nobody patches a running system; the image is rebuilt with updated components and redeployed, so the controls move to the image pipeline: base images from approved sources, scanning of images in the registry before deployment, a policy that blocks deployment of images with findings above a threshold, and a rebuild cadence so that long-running workloads do not drift months behind their images. The audit tests the registry scanning results, the admission policy and the age of deployed images, and treats an environment with a scanning gate but no rebuild cadence as one that patches nothing. For SaaS, the vendor patches its platform and the customer’s evidence is the vendor’s SOC 2 report under criteria CC7 and CC8, read with the SOC 2 review method; the customer’s own exposure is the browser, the integration and the identity layer, all of which are in its own program. Application dependencies cut across all three: the libraries inside custom software are found by software composition analysis rather than host scanning, and an organization that scans hosts diligently while shipping applications built on vulnerable components has covered half its exposure.

The evidence to request

The domain is data-rich, and the audit’s evidence is mostly extracts, each of which is information produced by the entity and handled under the IPE method: the auditor observes the extraction or re-runs it, records the parameters, and reconciles the counts. The table lists the artifacts, their source and the completeness check for each. The scanner export is the one to be most careful with, because scanner consoles filter by default and an export of “open findings on active assets” excludes the decommissioned assets that are still on the network and the findings someone marked as accepted.

Artifact	Source	Completeness check	Used for
Asset inventory	CMDB or inventory tool	Reconciliation to scanner, directory, management platforms, cloud, network	Universe; coverage
Scanner configuration and schedules	Scanner console	Ranges and credentials compared with the universe; run history	Coverage; cadence
Scan results export, unfiltered	Scanner database or API	Row count against console totals; includes accepted and inactive	Metrics; aging; catalog cross-reference
Service-level policy and matrix	Policy documents	Version and approval	Classification and deadline tests
Remediation tickets	Ticketing system	Linked to findings; dates	Handoff and timing
Patch deployment records	Endpoint and server management platforms; cloud patch services	Deployment success by device; failures	Patch execution; verification
Exception register	GRC tool or register	All accepted findings in the scanner appear in the register	Exception governance
End-of-support list	Inventory with vendor dates	Vendor lifecycle data applied to the universe	Unpatchable exposure
Emergency response records	Change tickets, incident records, communications	Cross-reference to catalog additions and advisories in the period	Emergency patching
Penetration test reports	External testers	Findings traced into the remediation queue	Independent view; queue integration

The twelve-test program

The program below is analytics-heavy by design: most tests are computed over full populations from the extracts above rather than sampled, which makes the audit both stronger and faster than a sample-based one. Where a sample is needed, patch deployments for instance, the standard sizes apply. The work program guide covers layout.

#	Test	Population	Evidence	What a failure looks like
1	Reconcile the asset inventory to every discovery source	All sources	Reconciliation with dispositions	Unknown assets; whole classes (OT, cloud) absent
2	Compute credentialed scan coverage by class and criticality	Reconciled universe	Scanner asset list and last-scan dates	Critical assets unscanned; unauthenticated only
3	Test scan cadence and health	Scan schedules and run history	Schedule; failures; authentication errors	Scans failing silently; cadence below policy
4	Evaluate the service-level matrix for risk basis and approval	Policy	Matrix; approval; alignment to PCI and catalog deadlines	Severity-only; no deadlines; undocumented
5	Test classification of findings against the matrix	Sample of 40 findings across classes	Finding attributes versus class assigned	Catalog entries classed as routine; exposure ignored
6	Compute remediation time and deadline compliance by class	All findings closed in the period	Detection and verified-closure dates	Compliance below policy; long tails
7	Compute the aging distribution and the catalog exposure	All open findings	Days open by class; catalog cross-reference	Catalog entries open beyond deadline on exposed assets
8	Test the exception register	All exceptions	Owner, compensating control, expiry, re-review; reconciliation to scanner-accepted findings	Perpetual exceptions; IT self-approval; accepted findings not in register
9	Test end-of-support handling	All assets past support	Plan per asset; segmentation and monitoring evidence for those isolated	Unsupported systems on the corporate network with no plan
10	Test emergency patching for the period’s major advisories	Catalog additions and vendor emergencies affecting the estate	Assessment, mitigation, emergency change and re-scan records with times	No record; weeks to respond
11	Test patch deployment and verification	Sample of 25 deployments	Deployment records; re-scan confirming closure; rollback handling	Tickets closed without verification; failed deployments unaddressed
12	Evaluate reporting to management and the board	Reports in the period	Metrics reported versus the outcome set	Volume metrics only; catalog exposure never reported

Worked example: Brightwater Foods and the plant systems nobody scanned

Brightwater Foods is a 180-million-dollar food manufacturer with 600 staff across three plants and a head office, and a co-sourced internal audit function in which a small in-house team directs a specialist firm. Its FY26 plan included a 160-hour vulnerability and patch management audit, performed by the co-source firm’s IT auditor under the in-house audit manager, with the IT infrastructure lead as the main contact. Brightwater’s IT team reported monthly to the executive committee a single vulnerability number and its trend, both improving.

The reconciliation set the audit’s direction. The vulnerability scanner knew 1,210 assets; the directory, the endpoint platform, the cloud subscription and the network switch data together produced 1,480, and the difference of 270 was concentrated in the plants: manufacturing execution servers, historian databases, line controllers’ engineering workstations and label printers, most on a flat network shared with the office. Fourteen plant systems ran a server operating system whose vendor support had ended in 2023. Credentialed scan coverage of the reconciled universe was 74 percent overall and 31 percent for the plant segment. Against the CISA catalog, nine open findings on scanned assets were listed as actively exploited, on assets including the remote-access gateway the plants’ vendors used, the oldest open for 210 days; against the company’s own policy of 30 days for critical findings, deadline compliance was 41 percent, and the aging distribution showed 380 critical and high findings open beyond 90 days. The exception register held 63 entries, none with an expiry date, 41 approved by the IT team itself. Emergency patching for the year’s most widely exploited gateway vulnerability had taken 26 days from the advisory to the patch, with no record of an interim mitigation.

Measure	Reported by IT	Computed by the audit
Asset universe	1,210 (scanner)	1,480 reconciled; 270 unknown to the scanner, mostly plant systems
Credentialed scan coverage	Not reported	74 percent overall; 31 percent for the plant segment
End-of-support systems	Not reported	14 plant servers on an operating system unsupported since 2023, on a flat network
Open findings	41,000, trending down	380 critical and high open beyond 90 days; 9 CISA catalog entries open, oldest 210 days, including the vendor remote-access gateway
Deadline compliance, critical class	Not reported	41 percent
Exceptions	Not reported	63, none with expiry, 41 approved by IT
Emergency response	Not reported	26 days advisory to patch for the year’s major gateway vulnerability; no interim mitigation

The report carried two High findings, catalog-listed vulnerabilities open on exposed assets and plant systems outside scanning and support on a shared network, and three Medium, deadline compliance and aging, exception governance, and emergency response. The recommendations were sequenced by exposure: patch the nine catalog entries within the week and mitigate the gateway immediately; segment the plant network with monitored access and enroll the plant systems in scanning; rewrite the matrix with an emergency class tied to the catalog and business-owner approval and expiry for exceptions; and replace the executive committee’s single number with the outcome metrics, starting with catalog exposure. The in-house audit manager’s cover note observed that the improving trend the committee had watched for a year had been produced by a scanner reconfiguration that removed the plant ranges from the scope, which was the root cause of most of the report and the reason the reconciliation is the first test.

Common mistakes

Starting from the scanner’s asset list. Reconcile the universe first; the unscanned assets are the finding.
Accepting overall coverage. Compute it by class and criticality with credentialed scans only.
Auditing severity instead of risk. Test that the matrix and the classification use exploitation evidence and exposure, not CVSS alone.
Ignoring the catalog. Cross-reference open findings to the CISA catalog and report the count and age; it is the number that matters most.
Measuring from ticket to ticket. Remediation time runs from detection to verified closure.
Reporting averages. Distributions and tails; the year-old finding is the exposure.
Letting IT approve its own exceptions. Business-owner acceptance, compensating control, expiry, re-review.
Treating unsupported systems as someone else’s problem. Inventory, plan, isolate, monitor.
Not testing emergency response. Pull the record for the year’s major advisories and time it.
Presenting volume to the board. Catalog exposure, coverage, deadline compliance, aging and exceptions are the report.

Comments

Leave a Reply Cancel reply

Dark Towers by David Enrich: Summary and Lessons for Auditors

Blind Spots by Bazerman and Tenbrunsel: Summary and Lessons for Auditors

Black Box Thinking by Matthew Syed: Summary and Lessons for Auditors

The Field Desk Series