A vulnerability exception should identify who accepts a delayed fix, how long that decision remains valid, and what evidence will end the exception. The expiry date limits the approval period. The exit test defines the result the team must demonstrate before closing the record.
Those are different jobs. A calendar reminder can bring an unresolved vulnerability back to someone's attention. The record still needs evidence about the system's condition.
For security leaders, the useful question is whether an exception still describes the environment they approved. Has the asset's exposure changed? Does the temporary control still work? Is the promised replacement actually funded?
This article proposes a practical way to answer those questions: treat each exception as a decision with a limited scope, conditions for continuing, and a verifiable route out.
What does a vulnerability exception approve?
Here, a vulnerability exception means an approved, temporary departure from a remediation requirement for a genuine finding. It records a decision about remaining risk. It does not change the technical condition of the affected system.
Keep false positives separate. Evidence that a finding does not apply is a correction to the finding, not a reason to accept a vulnerability that does exist.
An exception may be justified by a dependency that cannot yet be replaced, an unavailable vendor fix, or a change whose immediate operational impact needs assessment. Explain the constraint precisely enough for someone outside the delivery team to challenge it.
“Business-critical application” is insufficient. Which function would fail? What test established that concern? Who can resolve the dependency, and what work is scheduled?
NIST's Cybersecurity Framework 2.0 places changes and exceptions within risk assessment. Its ID.RA-07 outcome calls for their risk impact to be assessed and for the decisions to be recorded and tracked. The framework does not prescribe the expiry-and-exit model proposed here. Source: NIST CSF 2.0.
For wider context on deployment constraints, see patch management risks. An exception record should capture the specific constraint affecting this decision, rather than copy a general list of patching difficulties.
An expiry date ends the approval period
Set the expiry date when the exception is approved. Choose a date that reflects the exposure, the expected duration of the constraint, and the organization's applicable requirements. Avoid assigning every exception the same convenient quarter-end date.
Work backward from that expiry to schedule the review. The owner needs enough time to gather evidence and obtain a decision before the approval lapses.
Keep the scheduled review date separate from the expiry date. The review starts the next decision; expiry ends the current authorization.
GitLab's published security policy exception process offers a concrete example: it reviews exceptions as expiration approaches and requires a new approved request for an extension. That is GitLab's process, not a universal regulatory deadline. Source: GitLab's exception process.
Define the response to expiry in advance. It may require escalation, an emergency change decision, or a previously approved restriction. Do not let a ticket timer silently shut down a critical service or remove a protective control.
If the expiry passes without a decision, report the exception as expired and unresolved. Leaving the status as “approved” conceals a governance failure.
Write the exit test before granting the exception
An exit test is the evidence required to show that the departure from the remediation requirement is no longer needed. Specify it while the people approving the exception are still discussing the actual risk.
“Close after the upgrade project” is too loose. The project may finish while some affected systems remain unchanged.
A useful exit test names the scope, the condition to demonstrate, the evidence source, and the person who will review it. Different resolution routes need different evidence:
• A software update needs evidence that the applicable fixed version is running on the affected assets.
• A configuration correction needs evidence that the vulnerable condition has been removed, where that correction is a valid remedy.
• Removing a component needs evidence that it is no longer present or available through the affected service.
• Retiring a system needs confirmation that it has left service. A missing scan result is not sufficient.
NIST's enterprise patch-management guidance includes verifying installation in the patching process. The exit-test recommendation extends that evidence discipline to the exception decision; it does not imply that every resolution requires a patch. Source: NIST SP 800-40 Rev. 4.
Where a compensating control only reduces exploitability, document that narrower result. Approval of the remaining risk can coexist with verified mitigation. Keep the underlying vulnerability visible while it remains present.
What should the exception record contain?
Keep the decision and its supporting evidence together. The following is a proposed working template, not a compliance checklist.
Scope deserves particular care. If an exception refers to a changing asset group, retain the membership approved at the time and define how additions will be assessed. A newly added production server should not inherit an old decision simply because it matches a group label.
Identify who is authorized to accept risk, even when another person implements the fix. The delivery team can describe the constraint and propose treatment. Acceptance belongs with the authority designated by the organization.
Reopen the decision when its assumptions change
Expiry is the latest scheduled decision point, not a promise that the original assessment remains valid until then.
Specify the changes that require earlier review. Examples include credible reports of exploitation, newly reachable services, a failed compensating control, a material change in business use, or loss of the telemetry used to verify protection.
NIST CSF 2.0's ID.RA-05 connects threat, vulnerability, likelihood, and impact information to risk prioritization. Reassessing an exception when those inputs change is an operational application of that principle. Source: NIST CSF 2.0.
Make the trigger actionable. Identify who receives it, who reassesses the decision, and which approved response process applies. “Monitor closely” leaves all three unanswered.
Also distinguish failure from uncertainty. If a control check fails, investigate the failure. If the check cannot run because the asset is unreachable, report verification as unknown. Neither result supports carrying forward an unqualified “control effective” status.
Keep renewals attached to the original exposure
A renewal should preserve the original finding date, previous decisions, and cumulative time under exception. Moving the expiry date must not erase the history.
Ask what changed since the last approval. Did the owner complete the promised dependency test? Did the supplier provide a supported fix? Was the replacement delayed because of a technical constraint or because nobody funded it?
These answers belong in the decision record. Repeated renewal for the same unfunded dependency should reach the people who can allocate resources or accept a different operating model.
For related background on organizational delays, see what slows critical vulnerability patching. This review has a narrower purpose: deciding whether the current exception remains justified.
Track original exposure age and renewal count alongside the next expiry. Show overdue decisions and stale control evidence separately. These measures help leadership distinguish a temporary obstacle from an unresolved investment decision. They are management indicators, not proof that the environment is secure.
A worked example: replacing an unsupported reporting service
Consider a hypothetical internal reporting service running an unsupported component. Its business owner has approved a replacement project. The security team has validated a specific network restriction as an interim measure for the relevant exposure.
The exception names the affected servers, the permitted access path, the restriction's test evidence, and the replacement owner. It records the residual risk the authorized approver accepted.
Its exit test requires evidence that the affected component has been removed from every scoped server or that those servers have been formally retired. The reviewer must reconcile that result against the approved asset list.
During the project, most servers move to the replacement. One remains in use because a finance workflow still depends on it.
Closing the whole exception would misrepresent the result. Record the completed assets with their closure evidence and retain a linked, narrower exception for the remaining server. Preserve the original exposure date and renewal history.
If the remaining server becomes accessible through a new integration, the scope and assumptions have changed. Reassess that decision before relying on the old network-control evidence.
This example illustrates the governance method. It does not claim that a network restriction is an adequate mitigation for every unsupported component.
Keep approval status separate from technical status
An exception can be approved while the vulnerability remains open. A mitigation can be verified while permanent resolution is still pending. A record can expire while the underlying control continues to function.
Reporting should preserve those distinctions.
For each exception, show the decision status, the current technical condition, and the latest evidence date. A single green status should not stand in for all three.
This gives a security leader a useful basis for intervention: which decisions need renewal, which controls need checking, and which assets have met their exit criteria. It also gives the delivery team a clear definition of the work still owed.
Frequently asked questions
How long should a vulnerability exception remain valid?
Set its duration from the specific exposure, the constraint delaying remediation, and applicable organizational requirements. Avoid a universal default that ignores those conditions. Set an explicit expiry date and review it earlier if the assumptions supporting approval change.
Can a compensating control close a vulnerability exception?
A compensating control can support continued risk acceptance, but it does not automatically satisfy the exit test. If it only reduces exploitability while the vulnerability remains, retain that distinction. Close the exception only when evidence demonstrates that the approved exit criteria have been met.
What happens when only some affected assets meet the exit test?
Record closure evidence for those assets and retain a linked exception for the unresolved remainder. Preserve the original exposure date and decision history. Check that the narrower scope still has an accountable owner, valid approval, and current evidence for any continuing controls.
Should renewing an exception reset its age?
No. In the approach proposed here, renewal changes the approval period, not the original exposure date. Retain earlier decisions and cumulative time under exception so reviewers can distinguish a short-term constraint from a repeatedly deferred remediation decision.
Review five exceptions before the next renewal meeting
Choose five of your oldest active vulnerability exceptions. For each one, identify the original exposure date, current scope, authorized approver, expiry date, and exit test.
Then ask the owner to show the most recent evidence that the continuing conditions still hold.
Where an answer is missing, assign the decision or verification work needed to obtain it. Keep unresolved items visible until that work is complete.
The result should be five defensible decisions: close with evidence, continue under freshly approved conditions, or escalate for a different response. That is a more useful outcome than five new dates.
.webp)
%20Signals%20a%20New%20Era%20of%20Supply%20Chain%20Risk.webp)
.webp)
