A vulnerability exception process should start as one line in a shared note and grow as headcount rises. Small teams need a reason and a date. Mid-size teams add an owner and an approver. Large organizations add a compensating control field, tiered approval, and automatic expiry.
Why exceptions deserve a process
Every team accepts some risk. The danger is not the acceptance. It is that nobody remembers it. An exception without an expiry is a permanent dismissal in disguise, and a pile of permanent dismissals is how backlogs turn into audit findings.
A good process is cheap to use, so people use it instead of quietly ignoring alerts.
The process by team size
| Size | Minimum record | Who approves | Review |
|---|---|---|---|
| 1 to 5 | Alert, reason, review date | The person doing the work | Monthly glance |
| 6 to 25 | Plus owner team | The weekly triage owner | At each expiry |
| 26 to 200 | Plus compensating control | Team lead for low impact, security for high | Expiry opens a task |
| 200 plus | Plus approver and business unit | Tiered, with a review board for the highest | Automatic reopen on expiry |
These bands are a suggested starting point. Adapt them to your own risk appetite.
Four fields that matter most
- Reason. Specific enough that a stranger could judge it. "Not reachable: function never called in our code" beats "low risk".
- Owner. A named team that will re-check it.
- Expiry. A date, usually a quarter at most for anything reachable.
- Compensating control. What reduces the risk in the meantime, such as a network restriction or a disabled feature.
Use platform features that already exist
Most platforms support dismissal reasons. GitHub's documentation shows that auto-dismissed alerts keep a distinct close reason, that dismissed alerts can be filtered, and that they can be auto-reopened if the alert metadata changes, for example when a dependency moves from development to production scope. Automatic dismissal activity is included in webhooks, REST and GraphQL APIs, and the audit log. That supports an audit of your own exceptions without building new tooling.
When an exception should not be granted
Some findings should not be accepted casually. A vulnerability listed in CISA's Known Exploited Vulnerabilities catalog and present in a production, reachable path deserves a fix or a strong mitigation, not a waiver. CISA strongly recommends all organizations prioritize remediation of those entries. If a waiver is unavoidable, require senior approval and a short expiry.
Common failure modes
- Rubber stamping. If approvers never say no, the process is theater. Track the approval rate.
- No reopen. Expired exceptions that do nothing are worse than none.
- Sprawl across tools. Keep one register, even if it is a spreadsheet at first.
For how dismissal and snooze can be done safely, see auto-dismiss and snooze with an expiry.
Try it yourself
Click through it at your own pace, or open it full screen. Look at where a finding's status and reason are recorded.
Safeguard's policies and evidence automation can keep the register and the audit trail together, and the free scan at gold.safeguard.sh/scan is a way to see a first set of findings.
Quick check
How long should an exception last?
Short enough that it gets looked at again. For reachable issues, many teams choose a quarter at most. Pick a rule and apply it consistently.
Who should approve exceptions for a solo developer?
The developer, with a written reason and an expiry. A trusted peer review once a year is a useful check.
Sources
- GitHub Docs, Dependabot auto-triage rules
- CISA, Reducing the Significant Risk of Known Exploited Vulnerabilities
Last reviewed: 19 October 2026.
