When you decide not to fix a security risk, write a short record: what the risk is, who accepted it and why, what limits the damage meanwhile, and the date you will review it. One paragraph plus a few fields. An undocumented deferral is just an oversight.
Why write it down
Every team defers something. The difference between a managed risk and a forgotten one is a record. It shows a buyer or auditor that you decided on purpose, and it reminds you to look again. Without a review date, deferrals quietly become permanent.
The record
Keep it to these fields.
| Field | What to put |
|---|---|
| Risk | One sentence in plain words |
| Affected | The service, data or system |
| Why not fixing now | Cost, dependency, timing, or low likelihood |
| Limiting measures | Controls that reduce exposure meanwhile |
| Accepted by | A named person with authority over the system |
| Date and review date | When accepted, when to look again |
| Exit condition | What would make us fix it sooner |
An example in prose
"Our internal reporting tool runs on an older framework version that no longer gets fixes. We are not upgrading this quarter because the team is shipping a customer deadline. The tool is reachable only through the company network and requires single sign on. Accepted by the engineering lead on the date above. Review next quarter, or sooner if the tool is exposed to the internet or handles customer data."
That paragraph names the risk, the reason, the limits and the trigger.
Who may accept
The person who owns the system and the business consequence, not the person who found the issue. In a small team that is usually the engineering lead or a founder. A security champion can recommend, but should not accept alone on behalf of the business.
Rules of thumb
Set a short review window for high impact items and a longer one for minor ones. Never accept a risk indefinitely. Do not accept a risk you do not understand, because you cannot describe its limits. If the exit condition happens, such as the service becoming public, the acceptance is void.
Where to keep records
A single table or a folder of markdown files is enough. If you already keep a risk register, this is a row with extra fields. If you keep a decision log, it is an entry.
Common mistakes
Writing "accepted" with no reason. No owner. No review date. Copying a record forward each quarter without rethinking it. Accepting a risk because the fix is boring.
Review day
On the review date, read the record aloud and ask three questions. Has anything in the limiting measures changed? Has the exit condition happened? Is the fix cheaper or more urgent now? Then either close the record because the fix shipped, renew it with a new date and a fresh sentence of reasoning, or escalate it. Renewing without rethinking is the most common failure.
Where Safeguard fits
Safeguard can cover the dependency side of this work: SBOM and dependency scanning, reachability analysis to show which findings are actually exposed, and policies and gates for pull requests. A free scan is at gold.safeguard.sh/scan.
Quick check
Is a risk acceptance the same as ignoring a finding?
No. Ignoring leaves no trace. Acceptance records the reason, the limits and a date to revisit.
Does this count as legal advice?
No. It is a practical engineering habit. Ask counsel about contractual or regulatory duties.
Last reviewed: 19 October 2026.
