A minimum viable exception process is one page that says who may approve a deviation from your vulnerability policy, what the request must contain, how long it lasts, and where the list is kept. Five fields, one named approver, a hard expiry, and one place to look.
Small teams skip this because it feels like bureaucracy. Then a buyer or auditor asks how you handle a finding you chose not to fix, and the honest answer is a Slack thread from March. A short written process fixes that without slowing anyone down.
The five fields
Every request carries the same five things.
| Field | What goes in it |
|---|---|
| What | The finding or CVE, and the exact component and version |
| Where | The specific service or repository, not "everywhere" |
| Why | The reason you are not fixing it now, in two sentences |
| What else reduces risk | Any control that limits exposure, or "none" |
| Until when | A calendar date, ideally within 90 days |
If a request cannot fill in "why" in two sentences, it is not ready.
One approver, one backup
At ten people, a committee is theater. Name one approver, usually the engineering lead or whoever owns security, and one backup for vacations. The requester cannot approve their own request. If the founder is the only senior engineer, the founder approves and a second person signs as reviewer. That second signature is what an auditor looks for.
The steps
- The engineer opens a ticket using a template with the five fields.
- The approver reads it within two business days and answers yes, no, or "fix instead".
- If yes, the ticket gets an expiry date and a label such as
security-exception. - The scanner or tracker is told about it, so the finding shows as accepted until the date, not as new noise.
- On the expiry date, the owner either fixes the issue or asks for a renewal that gets a fresh review.
Keep one list. A saved ticket filter on the label is enough. The point is that a stranger can find every active exception in under a minute.
What to leave out for now
You do not need a risk committee, a scoring formula, or a 12-page policy. Add those when volume demands them. NIST SP 800-30 describes risk response as a decision senior leaders make from assessed risk, and a written approval from a named person is the small-company version of that idea.
Where Safeguard fits
Safeguard policies and gates can treat an approved exception as a time-limited rule, and its SBOM and dependency scanning shows which services carry the component you are waiving. A spreadsheet works too, if you keep it current.
Quick check
Can the CTO approve their own exception?
Avoid it. If there is no one else, record a second reviewer, even an outside advisor, so that approval and request come from different people.
How long should a first exception last?
Pick a date you can defend, commonly 30 to 90 days. Short expiries keep the list honest.
Sources
Last reviewed: 19 October 2026.
