Safeguard
Security Guides•

Vulnerability risk acceptance: quick answers to common questions

Short answers on vulnerability risk acceptance: what it is, who approves, how long, what to record and when not to use it, with links to detail.

Safeguard Security Team
3 min read

Vulnerability risk acceptance is a documented decision, made by someone with authority, to leave a known vulnerability unfixed for a limited time, with compensating controls and a review date. It is not ignoring the finding. The finding stays visible and the decision can be reversed.

The short answers

What is the difference between risk acceptance and an exception? Acceptance is the decision to live with a specific risk. An exception is the approved departure from a policy, such as a patch deadline. Most cases involve both. See the terms explained.

Who should approve? Someone who owns the business risk, not the requester. Higher risk and more exposure should go higher up. Read the approval ladder.

How long should it last? As short as the real fix plan allows, with an enforced end date. Longer terms suit low risk, short terms suit exposed and serious findings. See how long an exception should last.

What must the record contain? The finding, asset and version, reason, impact, compensating controls, approver, end date and a link to evidence. What to put in a request has a checklist.

Does a compensating control have to be tested? Yes. Describe the attack path it blocks, try to get past it, and save the result. See how to prove it works.

When should it end early? On new exploitation evidence, a change in exposure, a failed control or a cheap fix. See revocation triggers.

Is it the same as a VEX not_affected statement? No. VEX says the flaw cannot be exploited. Acceptance says it can, and you chose to accept that. See the comparison.

Where should it be stored? In the system that evaluates the finding, linked to a ticket and your risk register. See where exceptions live.

When not to use it

Do not use acceptance for a finding that is simply wrong. Document a false positive with evidence. Do not use it when a tested fix is ready and cheap to merge. Do not use it as a standing way to meet a deadline you keep missing.

A minimal process

  1. Triage the finding with context, not just the score.
  2. Try to fix or mitigate first.
  3. If not possible now, request an exception with controls and an end date.
  4. A separate approver decides.
  5. The system enforces the end date and reopens the finding.
  6. Review the register and its metrics each month.

Where Safeguard fits

Safeguard provides vulnerability scanning with reachability analysis, policies and gates, and compliance and evidence automation, and you can try a free scan to see current findings.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how findings move through statuses from open to resolved.

Quick check

Can I accept a vulnerability forever?

You should not. Even low-risk items deserve a review date, because assets, exposure and exploit activity change.

Does accepting a risk mean we skip the fix?

Only for now. The record should name the fix plan or the condition that ends the exception.

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.