A risk acceptance ticket should record the finding, why it is not being fixed now, what limits the risk in the meantime, who approved it, when it expires, and what would trigger an earlier review. Without an expiry and an approver, an acceptance is just a forgotten finding.
The field list
| Field | Content | Why |
|---|---|---|
| Finding link | Advisory id, component, location | Ties the decision to the issue |
| Reason | Why not fixing now, in plain words | Makes the decision reviewable |
| Exposure note | Reachable or not, internet facing or internal | Shows the risk is understood |
| Compensating controls | What reduces the risk meanwhile | Evidence of care |
| Approver | A named person with authority | Accountability |
| Requester | Who asked | Traceability |
| Decision date | When approved | Starts the clock |
| Expiry date | When it must be reviewed | Prevents permanence |
| Review triggers | New exploit evidence, a fix becoming available, a change in exposure | Brings it back early |
| Fix plan | What would let you close it | Keeps an exit |
Write the reason like a decision, not an excuse
Weak: "Low priority." Better: "The vulnerable function is not called by our code and the service is internal only. A fix needs a major upgrade that we will schedule in the next quarter."
The better version is specific, checkable and honest about the gap.
Link the evidence
If you claim a function is not reachable, link the analysis or note the date and method. Reachability is evidence, not a guarantee, so say when it was checked. See can reachability analysis justify a risk acceptance.
Automate the boring parts
- Create the ticket from a template with the fields required.
- Block approval if the expiry date is empty or too far out under your policy.
- Send a reminder before expiry.
- On expiry, move the ticket back to triage automatically.
- Keep the history of who changed what, which supports audits.
What auditors tend to look at
They usually sample accepted items and ask who approved them and whether the dates were respected. A complete set of fields answers both questions without a meeting.
Quick check
Who should approve a risk acceptance?
Someone with authority over the affected system and the business risk, named in the ticket. It should not be the person who wrote the code alone.
What happens at expiry?
The ticket returns to triage for a fresh decision, either a fix, a renewed acceptance with new reasoning, or closure.
Safeguard offers reachability analysis and compliance and evidence automation, and a free scan is available at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
