Risk-Based Patching: How to Defend It to an Auditor

This article is general risk-management guidance, not legal, audit, or compliance advice. Confirm every control decision with your QSA, auditor, or counsel. Some links to vendor tools may be affiliate links; that never changes what we recommend.

Why this matters right now

Every modern vulnerability framework is pushing teams away from patching everything and toward patching by risk. On June 10, 2026, CISA issued Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk, which reprioritizes remediation around public exposure, Known Exploited Vulnerability status, exploit automation, and technical impact. FedRAMP has committed to requiring BOD 26-04-aligned detection and reporting rules by December 7, 2026. The private-sector frameworks that auditors test against — PCI DSS, SOC 2, and the NIST guidance underneath both — have allowed risk-based prioritization for years.

That creates a trap. Teams hear “prioritize by risk” and start deferring high-CVSS vulnerabilities that score low on exploitation probability. Then an auditor asks the question that decides the finding: you left a CVSS 9.8 unpatched for ninety days, so show me why that was reasonable. If your answer is a shrug or a Slack thread, you have a control gap, regardless of whether the deferral was technically correct. This is a change-management and evidence problem, not a scanning problem. Here is how to build the record before the auditor asks.

What the frameworks actually permit

Risk-based deferral is allowed, but each framework fences it differently. The PCI DSS v4.0.1 standard is the strictest on timing. Requirement 6.3.1 tells you to identify and rank vulnerabilities using industry-recognized sources and your own impact assessment, and Requirement 6.3.3 sets a hard clock: critical and high-severity patches must be installed within one month of release, with everything else on a documented schedule you define. PCI lets you risk-rank the lower tier, but the critical/high one-month deadline is not something EPSS can talk you out of.

SOC 2 is looser on timing and stricter on process. Common Criteria 7.1 requires you to monitor system components for new vulnerabilities as an ongoing activity, and auditors reviewing CC7.1 want dated evidence: scan and test dates, scope, the findings themselves, and the remediation decisions attached to each. There is no fixed calendar deadline in the Trust Services Criteria, which means your own documented SLA becomes the standard you are audited against.

CISA BOD 26-04 is risk-based by design for federal civilian agencies, replacing the flat KEV clock with tiered deadlines driven by its four variables. We covered the directive’s mechanics for change advisory boards in our piece on BOD 26-04 risk-based remediation deadlines. Underneath all of this sits NIST SP 800-40 Revision 4, the enterprise patch-management guide both private frameworks lean on, which states plainly that “patching is one of several ways to respond to risks from software vulnerabilities.”

The four risk responses an auditor recognizes

The single most useful move for defensibility is to stop framing a deferral as “not patching” and start framing it as a chosen risk response. NIST SP 800-40 Rev. 4 names four, and an auditor recognizes all four as legitimate:

Accept — rely on existing controls or judge the impact low enough that no action is needed.
Mitigate — reduce the risk by patching, disabling the vulnerable feature, upgrading, or adding compensating controls such as segmentation and firewalls.
Transfer — share the consequence, for example by moving to a SaaS version where the vendor patches, or via cybersecurity insurance.
Avoid — eliminate the attack surface entirely by uninstalling or decommissioning the asset.

When you defer a Critical CVSS, you are almost always choosing “accept with compensating controls” or “mitigate by a non-patch route.” Documenting it in those terms, with the control that offsets the risk, is what turns a gap into a decision. NIST is explicit that this is the goal: “assessing the risk the vulnerability poses to your organization, choosing which form of risk response (or combination of forms) to use, and deciding how to implement the risk response.”

Where EPSS helps, and where it will sink you

Exploitation probability is the evidence teams most want to cite and most often misuse. The FIRST EPSS documentation is careful about what the score is: “a calibrated probability: the estimated likelihood that exploitation activity for a given vulnerability will be observed across EPSS data partners in the next 30 days.” It is explicitly “not a severity score and not a complete risk score.” The EPSS FAQ goes further — EPSS “does not measure how much damage successful exploitation would cause, or whether it affects your environment,” and ignores compensating controls entirely.

So a low EPSS score alone does not defend a deferral, because it says nothing about your blast radius. Two failure modes will draw a finding. First, treating EPSS as a risk score rather than one input, with no asset-context layer on top. Second, forgetting that probabilities compound. FIRST’s own math shows that for a set of 100 vulnerabilities each scoring 0.05, the probability that at least one is exploited within 30 days is roughly 99.4%. A backlog of “individually low-risk” deferrals is not collectively low-risk. There is also an aging trap: FIRST notes that vulnerabilities older than two years are exploited at roughly five times the rate of ones less than a month old, so a deferral that looked safe in month one gets riskier the longer it sits in the backlog untouched.

The evidence package that survives an audit

Framework language is consistent about one thing: the process has to be documented and consistently applied. NIST warns against “overly simplistic metrics, such as counting the number of vulnerabilities that the entire organization had and what percentage of them were patched,” because they are “not actionable.” What an auditor wants attached to every risk-based deferral is a small, dated record:

The vulnerability identifier and the affected assets, tied to their CMDB importance tier.
The inputs you used: CVSS for severity, EPSS or KEV for exploitation signal, and your own asset-criticality rating.
The risk response you chose, named in NIST’s terms, with the compensating control if you accepted or transferred.
The approver and the date, ideally the change advisory board record.
The review date, because a deferral is a decision with an expiry, not a permanent state.

If a vulnerability is on the CISA Known Exploited Vulnerabilities catalog, treat it as a fix-first item and do not defer it on an EPSS argument — NIST itself flags the KEV catalog as “a list of vulnerabilities that are considered particularly important for organizations to mitigate,” and every framework treats confirmed exploitation as the strongest signal there is. Our free change risk score tool produces the kind of asset-context-weighted output that belongs in field two of that record.

How the four frameworks compare on deferral

We mapped the four frameworks against the three questions that decide whether a risk-based deferral is defensible: does the framework permit it, does it require a documented method, and does it impose a hard calendar deadline you cannot risk-rank around?

The pattern is clear. Every framework permits or actively expects a documented risk-ranking method, so the method is table stakes. The variable is the clock. PCI DSS 4.0 and BOD 26-04 both impose hard calendar deadlines on the top tier that no probability score overrides; SOC 2 and NIST leave the timing to the SLA you write and then hold you to it. None of the four names a weakness worth ignoring: PCI’s one-month critical clock is rigid even when your asset context says otherwise, SOC 2’s lack of a fixed deadline means a sloppy internal SLA becomes your audit standard, BOD 26-04 applies cleanly only to federal scope, and NIST 800-40 is guidance with no enforcement teeth of its own.

What to do about it

Write the risk-ranking method down before you use it. A one-page policy naming your inputs (CVSS, EPSS, KEV, asset criticality) and how they combine is the document auditors ask for first.
Map your SLAs to the strictest framework you are subject to. If you take card payments, the PCI one-month critical clock governs; do not let a looser SOC 2 SLA lull you.
Never defer a KEV entry on an EPSS argument. Confirmed exploitation outranks probability. Route KEV items to an emergency-change fast lane instead.
Attach a dated risk-response record to every deferral, naming the NIST response type and the compensating control.
Add asset context to the exploitation score, so a low-EPSS vulnerability on a Tier 0 system is not auto-deferred. Score it with the change risk score tool.
Set a review date on every deferral and re-check it, because the aging effect makes yesterday’s safe deferral riskier over time.
Report the backlog as compound risk, not a patch percentage, so leadership sees the “at least one exploited” probability rather than a comforting count.

Frequently asked questions

Can you defend not patching a Critical CVSS to an auditor? Yes, if the decision came from a documented, consistently applied risk-ranking process with dated evidence and a compensating-control record. PCI DSS, SOC 2, and BOD 26-04 all permit risk-based prioritization, but require a defined method (NIST SP 800-40 Rev. 4). The failing answer is deferring without being able to show why.

Does a low EPSS score justify deferring a patch? Not on its own. FIRST states EPSS is a probability of exploitation in the next 30 days, “not a complete risk score,” and it ignores your environment and compensating controls (FIRST EPSS FAQ). A low EPSS score must be combined with asset criticality before it can support a deferral.

Does PCI DSS allow risk-based patch prioritization? Partly. PCI DSS 4.0 Requirement 6.3.1 requires you to risk-rank vulnerabilities, but Requirement 6.3.3 sets a hard one-month deadline for critical and high-severity patches (PCI DSS v4.0.1). You can risk-rank the lower tier on a documented schedule, but the critical/high clock is fixed.

What does SOC 2 CC7.1 require for vulnerability management? CC7.1 requires ongoing monitoring of system components for new vulnerabilities, and auditors want dated evidence of scans, scope, findings, and remediation decisions. There is no fixed calendar deadline, so your own documented SLA becomes the standard you are audited against.

How should we document a decision not to patch? Record the vulnerability and affected assets with their CMDB tier, the inputs used, the NIST risk-response type chosen, the compensating control, the approver and date, and a review date. A deferral is a dated decision with an expiry, not a permanent state (NIST SP 800-40 Rev. 4).

Should a KEV-listed CVE ever be deferred on risk grounds? No. A CVE on the CISA KEV catalog has confirmed exploitation, the strongest signal any framework recognizes. Route them to an emergency-change fast lane rather than deferring them.

Why is a backlog of low-risk deferrals still a problem? Because probabilities compound. FIRST’s math shows that for 100 vulnerabilities each scoring 0.05 EPSS, the chance at least one is exploited within 30 days is about 99.4% (FIRST — Using EPSS). Report the backlog as compound probability, not a patch percentage.

For the full set of GRC and compliance workflows we cover, see the compliance pillar.

Sources

#risk-based-patching #compliance #audit #pci-dss #soc-2 #epss

Published August 18, 2026.