Patch Exceptions and Risk Acceptance Without the Spreadsheet

Every vulnerability program eventually hits a finding that will not close on schedule. The patch breaks a vendor-certified configuration, the host cannot take a reboot window, or the fix requires an end-of-life replacement that is not funded yet. At that point you need a patch exception process: a documented, time-boxed, approved decision to accept risk instead of remediating immediately. Without one, exceptions live in email threads and spreadsheets, auditors cannot trace who approved what, and “temporary” exceptions quietly become permanent.

Legitimate Reasons a System Cannot Be Patched

Not every missed SLA deserves an exception. Before a request goes anywhere, filter for reasons that actually hold up under review.

• Vendor support constraints. The application vendor has not certified the patch and will void the support contract if you apply it out of band. This is common with SCADA/ICS controllers, medical device middleware, and some ERP modules.
• Uptime and change-window scarcity. A clustered database or a payment gateway with a contractual four-nines SLA may only accept changes in a quarterly window. A critical CVE does not always justify breaking that window unilaterally.
• End-of-life or end-of-support software. No patch exists. The only real fixes are migration or replacement, both of which take longer than any patch SLA. The exception here is really a migration project with an interim risk acceptance attached to it.
• Patch regression risk. The vendor’s own release notes or your test environment show the patch breaks a dependency. This needs a rollback plan and a retest date, not an indefinite waiver.
• Licensing or architectural blockers. The fix requires a paid upgrade tier, a new OS version incompatible with other installed software, or a code change in an application no longer actively maintained by any team.

Reasons that should not qualify on their own: “we did not get to it,” “the ticket was assigned to the wrong team,” or “the business owner did not respond.” Those are process failures, not risk decisions, and routing them through an exception workflow just launders missed SLAs into accepted risk. If your vulnerability lifecycle tracking cannot tell the difference between an SLA breach and an approved exception, every metric downstream of it is unreliable.

Who Can Accept the Risk, and for How Long

Risk acceptance authority should scale with severity, not with whoever is available to click approve. A workable model ties approver seniority to CVSS or your internal risk score, and caps duration accordingly.

Two details matter more than the exact numbers. First, the system owner alone should never be sufficient for critical or high findings, because they are the party with the least incentive to say no to their own uptime. Second, “known exploited” findings, meaning anything present on CISA’s KEV catalog or with confirmed in-the-wild activity, should never route through the standard exception ladder at all. Cap those at a hard maximum, commonly 7 to 15 days, regardless of who is asking, and require compensating controls as a precondition rather than an afterthought.

Whoever approves also needs to see what they are approving: the specific finding, the affected asset, the CVSS and exploit-maturity data, and the compensating controls proposed, not a generic “approve exception request #4471” line. If the approval screen in your ticketing tool does not surface that context, the approver is rubber-stamping a memo, not evaluating risk.

Compensating Controls Required Before an Exception Is Granted

An exception without a compensating control is just an acknowledgment that the risk exists. Auditors under ISO 27001 Annex A.8.8, PCI DSS Requirement 6.3, and SOC 2 CC7.1 all expect to see specific mitigating actions tied to each acceptance, not a blanket statement that “risk was accepted by management.” Reasonable compensating controls, matched to the exposure:

• Network segmentation or ACL tightening. Restrict inbound access to the vulnerable service to a named jump host or VPN range, verified with a firewall rule review, not just a request ticket saying it was done.
• WAF or IPS virtual patching. For a web application vulnerability, deploy a signature or custom rule that blocks the specific exploit pattern (for example a ModSecurity rule matching the CVE’s known payload structure) while the underlying code fix is pending.
• EDR/behavioral monitoring on the affected host. Add the specific process, port, or file path to a watchlist so any exploitation attempt generates an alert routed to the SOC, not just a log entry nobody reviews.
• Service or feature disablement. If the vulnerable functionality is not business-critical, disable it (an unused module, a legacy API endpoint, an SMBv1 fallback) rather than accepting risk on a feature nobody uses.
• Credential and privilege reduction. Rotate any credentials the vulnerable service can access, and drop it to the minimum privilege level, so a successful exploit has a smaller blast radius.

Each control needs an owner and a verification step, not just a description in a text field. This is where a lot of exception processes quietly fail: the mitigation is written down at approval time but nobody checks six weeks later whether the firewall rule is still in place. Platforms that automate this phase, such as SITEY, re-test the specific finding and the compensating control together on the same retest cycle, instead of trusting a change ticket’s closure status as proof the mitigation is real.

Expiry, Review Cycles and Automatic Re-Opening

An exception with no expiry date is a permanent risk acceptance wearing a temporary label. Every exception record needs three dates: the grant date, the expiry date, and the next review date, and the review date should always fall before expiry, not on it. A 30-day high-severity exception with a review on day 25 gives the owner five days to either close the finding, request a documented renewal, or escalate, rather than discovering on day 31 that the exception silently lapsed.

What should happen automatically at expiry, without a human remembering to act:

1. The finding’s status reverts from “risk accepted” to “open” in the vulnerability register, and it re-enters the standard SLA clock.
2. The original approver and the system owner both receive a notification, not just the person who filed the original request.
3. If a renewal was requested, it requires the same approval level as the original grant. Renewals do not get to route through a lower-tier approver just because “it was already approved once.”
4. If the renewal count for that severity tier has been exhausted (see the table above), the finding escalates automatically to the next approval level up, forcing a conversation about remediation funding or architecture change instead of another rubber stamp.

This is also where compensating controls need a re-check, not just the finding record. A firewall rule or WAF signature drifts: someone opens the port back up during a later change, or a rule gets removed during a device migration. Re-verifying the control at each review cycle, not just at grant time, is what separates an exception process that holds up in an audit from one that is a document trail with no substance behind it.

Reporting Open Exceptions as a Standing Risk Register Item

Open exceptions belong on the same risk register as any other accepted business risk, reviewed by the same governance body that reviews budget and vendor risk, not buried inside a security team’s internal tracker. At minimum, a quarterly report to that body should show:

• Total open exceptions by severity, with a trend line against the prior quarter.
• Exceptions past their review date with no action taken, flagged distinctly from ones on schedule.
• Exceptions on assets that fall in scope for an upcoming audit (PCI, SOC 2, KVKK, BDDK) so the compliance team is not surprised mid-audit.
• Concentration risk: five separate exceptions on the same host or the same application tell a different story than five exceptions spread across unrelated systems.

Auditors reviewing an ISO 27001 or SOC 2 program specifically ask for evidence that risk acceptances are reviewed at a defined interval and that someone with authority signed off, not just that a ticket exists. A compliance mapping view that ties each open exception to the specific control it affects turns that request from a scramble through old emails into a query. Pairing the exception register with your approval gate history gives the auditor the full chain: who requested, who approved, what mitigated it, and when it was reviewed.

The same register also protects the security team internally. When an exception-related incident does occur, the register is the record showing the decision was made deliberately, with a named owner, a time limit, and a compensating control, rather than being an oversight. That distinction matters both for post-incident review and for the next budget conversation about why some remediation work needs to be funded ahead of the next audit cycle. Centralizing exception tracking inside the same system that runs patch management also removes the translation step between “what the scanner found” and “what risk was formally accepted,” which is usually where the paper trail breaks down first.

About SITEY

SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.