An unpatched vulnerability past its deadline is either a documented, owned and time-limited risk decision, or it is an audit finding waiting to happen. Auditors and regulators routinely ask for evidence that missed remediation deadlines were approved by someone with authority, that compensating controls were in place and verified, and that the exception expired. This template gives [Organisation] a ready-to-use procedure and request form for vulnerability risk acceptance: when an exception is allowed, who may approve it at each risk level, which compensating controls are acceptable, how expiry and renewal work, and what goes in the register. It is written for vulnerability management leads, risk managers, system owners and internal audit. For setting the deadlines themselves, see the Remediation SLAs and Vulnerability Exceptions Guide.
How to use this template
- Adopt it under the vulnerability management policy as the only route by which a remediation deadline may be missed. See the Patch Management Policy Template.
- Replace the bracketed values ([Organisation], approver titles, maximum durations, SLA tiers) with your own and get them approved by the risk committee.
- Keep the form in section 7.2 in your ticketing or GRC tool so that each exception has an ID, a workflow, an approval record and an automatic expiry reminder.
- Use it for configuration findings too only if they come from a vulnerability scanner; hardening baseline deviations follow the Hardening Exceptions and Compensating Controls Template.
1. Scope and triggers
1.1 This procedure applies to every vulnerability finding on [Organisation] assets and services, including operating systems, applications, firmware, container images, cloud services, code dependencies and supplier-managed systems where [Organisation] carries the risk.
1.2 An exception request is required when any of the following is true:
- Deadline will be missed: the finding cannot be remediated within its SLA tier (for example [Critical: 7 days; High: 30 days; Medium: 90 days]).
- No fix exists: the vendor has no patch, or the product is end of life.
- Fix is unsafe: the patch breaks a business service, a certified configuration (for example a medical or OT system) or a vendor support contract.
- Finding is disputed: the owner believes the finding is a false positive or not exploitable in context. A disputed finding is closed only with evidence reviewed by the vulnerability management team; it is not an exception.
1.3 NIST SP 800-40 Rev. 4 frames the four risk responses as accept, mitigate, transfer or share, and avoid, and notes that patching or upgrading is the only response that removes a vulnerability without removing functionality. An exception is therefore always a temporary acceptance or mitigation decision, never a closure.
1.4 Not eligible for exception without [CISO] approval and a maximum of [14] days: vulnerabilities listed in the CISA Known Exploited Vulnerabilities catalogue on internet-facing assets, and any vulnerability with evidence of exploitation against [Organisation]. See the CISA KEV Catalogue Guide.
2. Roles and contacts
| Role | Named lead | Responsibility |
|---|---|---|
| Requester (system or service owner) | [Name] | Raises the request, proposes compensating controls and a remediation plan |
| Vulnerability management lead | [Name] | Validates the finding, rates the residual risk, checks controls |
| Security architect | [Name] | Approves compensating control designs |
| Risk owner (approver) | Per section 2.1 | Accepts the residual risk in writing and is accountable if it materialises |
| Internal audit | [Name] | Samples exceptions for evidence and expiry compliance |
2.1 Approval authority by residual risk:
| Residual risk | Approver | Maximum duration | Renewals allowed |
|---|---|---|---|
| Critical | [CISO] and [business executive owning the service] | [30] days | [1], with risk committee notification |
| High | [CISO or deputy] and [service owner's director] | [90] days | [2] |
| Medium | [Head of IT or engineering for the service] | [180] days | [2] |
| Low | [Vulnerability management lead] | [365] days | Reviewed annually |
2.2 The requester cannot approve their own exception, and the approver must be senior enough to own the business impact if the vulnerability is exploited.
3. Detection and triage
3.1 The vulnerability management lead confirms within [3] working days:
- The finding is valid and the affected asset list is complete (scanner output, CVE, version, asset IDs).
- Exploitation context: CISA KEV listing, EPSS probability, public exploit availability, and the CVSS base score. See the EPSS Guide and the SSVC Guide.
- Exposure: internet-facing, internal, isolated; data and identities reachable from the asset, including service accounts and stored credentials.
- Inherent risk rating using [Organisation]'s risk matrix, then residual risk after the proposed compensating controls.
3.2 Worked example (fictional). A remote code execution flaw in a reporting server's web component has a vendor fix, but the fix requires a database upgrade that the supplier will not certify for [60] days. The server is internal only, but it holds a service account with read access to the finance data warehouse. Inherent risk: high. Proposed controls: block the vulnerable web port from all subnets except the two reporting gateways, add a WAF rule for the CVE, rotate the service account password and reduce it to read access on two schemas, and add a SIEM rule for new child processes of the web service. Residual risk: medium. Route: [Head of IT] approval, [60] days, remediation plan tied to the supplier's certified release. If the CVE is later added to the KEV catalogue, the exception is revoked and escalated under 6.4.
3.3 Identity check. Many exceptions are rated low because the asset seems unimportant, while the credentials stored on it are not. Before rating, list service accounts, API keys and cached administrator credentials on the asset; an attacker who exploits the flaw inherits them. See the Service Account Inventory Template.
3.4 Decision (vulnerability management lead): route to the approver in 2.1, return to the requester for stronger controls, or reject and escalate the SLA breach.
4. Containment
4.1 No exception is approved without at least one verified compensating control that reduces likelihood or impact for the specific vulnerability. Generic statements such as "the server has antivirus" are not accepted.
| Compensating control | Reduces | Evidence required |
|---|---|---|
| Network isolation or micro-segmentation of the asset | Reachability | Firewall rule IDs, a connectivity test from an untrusted segment |
| Disable the vulnerable feature, service or port | Attack surface | Configuration export, rescan showing the service closed |
| Virtual patching (WAF or IPS signature for the CVE) | Exploitability over the network | Rule ID, blocking mode, test result |
| Restrict access to administrators through a PAM jump host | Who can reach the flaw | Access policy and session logs |
| Rotate and scope credentials stored on or used by the asset | Impact if compromised | Rotation record, reduced permissions |
| Targeted detection rule for exploitation attempts | Time to detect | Rule ID in SIEM, alert routing test |
4.2 SP 800-40 Rev. 4 recommends an approved set of mitigation methods for unpatchable assets, reviewed in advance by security architects. Maintain that list at [location] and prefer controls from it. See the Virtual Patching and Compensating Controls Guide.
5. Eradication
5.1 Every exception carries a remediation plan: the fix (patch, upgrade, replacement or decommission), the target date, the owner, and any dependency such as a vendor release or change freeze.
5.2 Where no fix will ever exist (end-of-life products), the plan is replacement or decommission, with a funded project reference. SP 800-40 Rev. 4 advises periodically re-evaluating alternatives to patching for unpatchable assets.
6. Recovery
6.1 On expiry the GRC tool reopens the finding as an SLA breach and notifies the approver [14] days before and on the expiry date. There is no silent extension.
6.2 Renewal requires a new request with updated evidence that the compensating controls are still in place, the reason the remediation plan slipped, and approval at one level higher than the original after the first renewal.
6.3 Closure happens only after a rescan confirms the vulnerability is gone. Compensating controls added for the exception (temporary firewall rules, emergency mitigations) are then reviewed and removed or made permanent, as SP 800-40 Rev. 4 advises for emergency mitigations.
6.4 Revocation: the vulnerability management lead may revoke an exception early if the vulnerability is added to the KEV catalogue, exploitation is observed, or a compensating control fails.
7. Communication and notification
7.1 Register. All exceptions are held in one register (the exception register, linked to the risk register). See the Risk Register Template.
7.2 Exception request form (all fields mandatory):
| Field | Content |
|---|---|
| Exception ID | [VEX-YYYY-NNN] |
| Finding | CVE or scanner plugin ID, title, CVSS, KEV status, EPSS |
| Assets | Asset IDs, environment, internet-facing yes or no, data classification |
| Reason | Deadline missed, no fix, fix unsafe; with evidence (vendor statement, failed test) |
| Compensating controls | Each control with its evidence reference (section 4) |
| Residual risk | Critical, high, medium or low, with rationale |
| Remediation plan | Action, owner, target date |
| Start and expiry dates | Expiry within the maximum in 2.1 |
| Approval | Approver name, title, date, and the statement: "I accept the residual risk described above until the expiry date." |
| Renewal history | Previous exception IDs |
7.3 Reporting. Monthly to [security steering group]: open exceptions by residual risk and age, exceptions expiring in the next 30 days, renewals, and breaches of this procedure. Quarterly to [risk committee]: critical and high exceptions, and repeat renewals.
8. Post-incident review
8.1 If an incident exploits a vulnerability under exception, review whether the compensating controls worked, whether the residual risk was rated correctly and whether the approver had the right information.
8.2 Review the whole register every [quarter] to confirm each exception is still needed and its controls are still in place. SP 800-40 Rev. 4 calls for closely tracking and regularly reviewing all exceptions, and notes that assets with similar long-term exceptions may need their own maintenance plan.
8.3 Track: number of open exceptions by residual risk; median exception age; percentage expired without renewal or closure (target 0%); percentage renewed more than once; and percentage of sampled exceptions with complete control evidence.
Implementation guidance
- Set the authority matrix first (2.1) and have it approved by the risk committee, so that approvers know they are accountable.
- Configure the workflow in the GRC or ticketing tool with mandatory fields, automatic expiry, reminders and a link to the scanner finding so closure can be verified automatically.
- Migrate existing exceptions: every current "risk accepted" status in the scanner gets a request under this procedure within [60] days or is reopened.
- Map to frameworks for audit: NIST CSF 2.0 ID.RA-06 (risk responses chosen, tracked and communicated) and GV.RM-04; NIST SP 800-53 Rev. 5 RA-7 Risk Response, CA-5 Plan of Action and Milestones and RA-5 Vulnerability Monitoring and Scanning; CIS Controls v8.1 Safeguard 7.2 (remediation process); ISO/IEC 27001:2022 Annex A 8.8 Management of technical vulnerabilities.
- Audit a sample of [10] exceptions each quarter against section 7.2 evidence requirements.
Common failure patterns to avoid: scanner "accepted risk" flags with no approver or expiry; exceptions approved by the same team that owns the system; compensating controls that are claimed but never tested; renewals that simply copy the last request; and exceptions on internet-facing systems for flaws later added to the KEV catalogue that nobody revisits.
Related NHI Mgmt Group resources: Remediation SLAs and Vulnerability Exceptions Guide · Security Exceptions and Risk Acceptance Guide · Risk-Based Vulnerability Management Guide · CIS Control 7 Continuous Vulnerability Management Guide