How do compliance teams justify leaving some vulnerabilities unpatched?

What Makes a Patch Exception Defensible

A compliance team can justify deferring a vulnerability when it can show the issue was not reachable in the specific product, deployment, or use case, and that the exception was consciously approved rather than left to drift. That shifts the decision from informal tolerance to a documented, reviewable risk acceptance with clear ownership and an expiry date.

Unreachable does not mean “ignore it.” It means the team has evidence that the vulnerable path cannot be exercised in the current environment, such as missing exposure, disabled functionality, compensating isolation, or an affected component that is not actually used. The stronger the evidence trail, the easier it is to explain why immediate remediation was deferred.

A defensible exception also records the business reason for delay, the approver, the scope of the exception, and the date it must be revisited. That prevents the same vulnerability from being rediscovered as an orphaned technical debt item with no owner or review cycle.

How Teams Prove the Risk Is Contained

The practical test is whether the vulnerable condition can be reached in the real operating context. Teams usually validate exposure by checking asset inventory, deployed features, network paths, authentication paths, version usage, configuration state, and whether compensating controls actually block the vulnerable action.

That evidence should be specific enough to survive scrutiny. A generic statement that “we are not using that feature” is weak unless it is backed by configuration proof, architecture review, or operational telemetry. When a vulnerability is only partially relevant, the exception should describe the exact boundary of exposure instead of treating the whole product as safe.

For internally approved deferrals, the record should show who owns the residual risk and what event will trigger reconsideration, such as a configuration change, product upgrade, new integration, or threat intelligence update. A good exception process ties the decision to a future control point, not just a one-time signoff.

What Auditors and Stakeholders Expect to See

Auditors are usually looking for three things: evidence, accountability, and timeliness. Evidence proves the issue was not reachable in the stated context. Accountability shows a named owner accepted the exception. Timeliness shows the team did not convert a temporary deferral into an indefinite waiver.

That is why exception records need to be easy to trace back to the affected system, the specific vulnerability, the compensating rationale, and the review date. If the documentation only states that remediation was postponed, it may be treated as an unmanaged weakness rather than a controlled exception.

When the vulnerability is widely exploited or appears in a formal exploited list, the burden of justification becomes much higher. Current guidance from the CISA Known Exploited Vulnerabilities Catalog and emergency response guidance in the Zero-Day and Exploited Vulnerabilities Guide both reinforce the need to treat active exploitation as a different class of decision from ordinary backlog management.

Risk and Threat Considerations

Deferring a vulnerability becomes risky when the “not reachable” assumption is wrong, incomplete, or no longer true after a configuration change, feature rollout, or new integration. The main exposure is not only the flaw itself, but the possibility that teams lose track of why it was deferred and continue operating with an unreviewed exception.

Failure mechanism: A vulnerability is assumed to be unreachable based on stale inventory, incomplete testing, or a compensating control that no longer works, so the exception outlives the condition that justified it.

Impact: The organisation can end up with an exploitable weakness in production, poor audit defensibility, and no clear owner to force reassessment when the risk environment changes.

Practitioner Guidance

What to verify: Before approving a deferral, verify the exact deployment path, affected feature set, and compensating control, not just the product name. If the vulnerable code path is reachable in any live environment, treat the issue as exposed until proven otherwise.

Decision rule: If the team cannot produce evidence of non-reachability and a named reviewer who accepted the exception, do not frame the item as a controlled deferral. Escalate it as an open remediation or a higher-risk exception that needs tighter review.

What good looks like: A complete exception file should let another practitioner understand why remediation was delayed, who accepted the risk, when it must be revisited, and what evidence supports the decision without re-investigating the original issue from scratch.

Practitioner takeaway: The goal is not to make every deferral look safe, but to make every deferral explicit, evidence-based, time-bound, and owned.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities for SOC 2 compliance?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?