A vulnerability risk exception process is a documented workflow that lets security teams formally accept, track, and expire risk on vulnerabilities that can't be remediated on the standard timeline — without letting "we'll fix it later" turn into permanent risk. The process only works if it has an owner, an expiration date, and compensating controls attached to every exception; skip any one of those three and the exception list becomes a graveyard of forgotten risk.
- A vulnerability risk exception process needs four gates: request, risk scoring, approval, and expiration — skipping expiration is the most common failure in 2026 audits.
- Route Critical (CVSS 9.0-10.0) findings through a security leader, not a single engineer, before granting an exception.
- Every exception needs a compensating control on file, or it's just risk acceptance with extra paperwork.
- Brinqa's exposure management platform ties exception records to live asset and threat data so expired exceptions surface automatically.
Why this matters
Most vulnerability management programs generate exception requests faster than they can process them — a scanner flags a finding on a legacy server, the app owner says the fix breaks a dependency, and the ticket sits open. Without a formal exception process, that ticket either gets ignored (an audit finding waiting to happen) or gets closed without real review (risk acceptance nobody signed off on).
Auditors reviewing SOC 2, ISO 27001, or FedRAMP evidence in 2026 specifically ask for exception records: who approved it, what compensating control is in place, and when it expires. A vulnerability risk exception process that can't answer those three questions on demand is a process in name only.
How do you build a vulnerability risk exception process?
Build the process around four gates: request, risk scoring, approval, and expiration. Each gate needs an owner and a deadline, or exceptions pile up without anyone accountable for closing them out.
- Standardize the request form. Require the asset, the CVE or finding ID, the business justification, and the proposed compensating control before a request enters the queue. Requests without a justification get bounced automatically.
- Score the risk, not just the severity. A CVSS 9.2 finding on an internet-facing asset with no compensating control is a different conversation than the same CVE on an isolated internal test box. Layer in exploit data — EPSS scores run from 0 to 1 and estimate real-world exploitation probability — before anyone approves anything.
- Route approval by severity tier. Low and Medium findings (CVSS 0.1-6.9) can go through a team lead. High and Critical findings (CVSS 7.0-10.0) need sign-off from a security manager or CISO, full stop.
- Attach a compensating control. Network segmentation, WAF rules, disabled services — the exception record names the control, it doesn't gesture at one.
- Set an expiration date at approval time, not later. 30, 60, or 90 days depending on severity; the date goes on the record the moment the exception is granted.
- Automate the expiration review. When the date hits, the finding either gets remediated, re-scored, or re-approved — it never just falls off the list silently.
| Gate | Owner | Typical trigger |
|---|---|---|
| Request | Asset or app owner | Fix breaks a dependency or requires downtime |
| Risk scoring | Security analyst | CVSS, EPSS and asset exposure reviewed together |
| Approval | Security lead or CISO, by severity | Sign-off recorded with justification |
| Expiration | Automated tracking system | Date hits, finding re-enters the queue |
Teams running this in spreadsheets lose gate four almost every time — the expiration date gets set, then nobody checks it. A risk-based vulnerability management approach ties the exception record to live vulnerability data, so an expired exception resurfaces as an open finding instead of disappearing.
Why exception approval requirements vary
Not every finding deserves the same approval chain. The factors that should change who signs off:
- Asset exposure — internet-facing systems get stricter review than internal-only assets.
- Severity and exploitability — a Critical CVSS score paired with a high EPSS probability skips fast-track approval entirely.
- Compliance scope — findings on systems in scope for SOC 2 or HIPAA need documented sign-off, not a verbal okay.
- Data sensitivity — systems holding regulated or customer data get shorter exception windows.
- Compensating control strength — network isolation justifies a longer window than monitoring alone.
- History of the asset — repeat exception requests on the same CVE family signal a remediation gap, not a one-off exception.
Automate exception tracking end to end
See how Brinqa ties exception records to live vulnerability and asset data.
How long should a vulnerability exception last?
Exception windows scale with severity: shorter for Critical and High findings, longer for Low and Medium. There is no universal number in 2026 regulatory guidance, but the window should always be shorter than the time it takes an attacker to find and exploit an unpatched internet-facing asset — which is why Critical findings on public systems rarely earn exceptions past 30 days.
Set the date at approval, review it automatically, and never extend an exception without a fresh risk score. That single rule separates a working exception program from a backlog with better formatting.
Does an exception need a compensating control to be valid?
Yes. An exception without a documented compensating control is risk acceptance wearing an exception label, and most auditors flag the distinction directly. The control has to be named specifically — which firewall rule, which segmentation policy — rather than described generically as "monitoring in place."
What's the difference between a risk exception and a false positive?
A risk exception accepts real, confirmed risk for a defined period with a compensating control attached. A false positive means the finding itself is wrong and gets closed, not exceptioned. Confusing the two is how exception lists fill up with findings that should have been dismissed at triage.
Teams building this alongside a formal framework usually map it to audit controls first — see how to align vulnerability management with SOC 2 for the evidence side of the same workflow. The remediation-side counterpart is clear SLAs by severity, so exceptions stay the deviation rather than the default: how to set vulnerability remediation SLAs by severity.
“An exception without an expiration date isn't an exception. It's permanent risk with a ticket number.”
FAQ
What is a vulnerability risk exception process?
A vulnerability risk exception process is a documented workflow for formally accepting, tracking, and expiring risk on vulnerabilities that can't be remediated on schedule. It requires a request, a risk score, approval by the right authority, and a set expiration date.
How long should a vulnerability exception last?
Exception windows scale with severity, running shorter for Critical and High findings (CVSS 7.0-10.0) and longer for Low and Medium. The expiration date is set at approval time, never added afterward.
Who should approve a risk exception?
Low and Medium severity exceptions can go through a team lead, but High and Critical findings need sign-off from a security manager or CISO. Internet-facing assets route through the stricter chain regardless of severity.
What's the difference between a risk exception and a false positive?
A risk exception accepts confirmed real risk for a defined period with a compensating control in place, while a false positive means the finding is inaccurate and gets closed outright. Mixing the two into one queue is a common audit finding.
Does a vulnerability exception need compensating controls?
Yes, an exception without a named compensating control is undocumented risk acceptance, and most compliance frameworks flag that gap. The control has to be specific, like a segmentation rule or a WAF policy, not a general statement about monitoring.
How do you track vulnerability exceptions at scale?
At scale, exceptions belong in a system tied to real-time asset and vulnerability data rather than a spreadsheet, so expired exceptions automatically resurface as open findings. Manual tracking is the most common reason exception programs fail compliance review.
What happens when an exception expires?
When an exception expires, the finding re-enters the active remediation queue unless it is explicitly re-scored and re-approved with new justification. Letting an exception silently lapse is the most common audit finding in vulnerability programs.
Is risk acceptance the same as a vulnerability exception?
Risk acceptance and a vulnerability exception overlap but are not identical: risk acceptance is a standing decision, while an exception is time-bound with a defined expiration and review cycle. Programs that use the terms interchangeably end up with permanent risk they never revisit.
One last thing
The exception process fails at the same gate almost every time: expiration. Teams in 2026 are good at building request forms and approval chains, but almost nobody automates the review that fires when the clock runs out — so the exception list quietly becomes a permanent risk acceptance list with better paperwork. Tie exception expiration to live vulnerability data instead of a calendar reminder and that leak closes. Brinqa's exposure management platform is built for exactly that handoff between exception records and active findings.
