A security exception request should state what rule is being waived, why it cannot be met now, what limits the risk in the meantime, who owns it, who approved it, and when it expires. An exception without an expiry date is not an exception. It is a permanent policy change nobody decided.
Why exceptions need structure
Every pipeline gate eventually meets a case it should not block: a vendor library with no patch, a legacy service due for retirement, a finding the tool gets wrong. If there is no clean path for those, developers build their own. A short, fast, written process keeps the exceptions visible and the gate respected.
The fields
| Field | What to write |
|---|---|
| Rule or control | The exact policy or gate being waived |
| Scope | Which repository, service or component, and which versions |
| Reason | Why it cannot be met now, in plain words |
| Risk | What could happen, who would be affected, how likely |
| Compensating controls | What reduces the risk while the exception stands |
| Owner | One named person who will close it |
| Approver | The person with authority to accept the risk |
| Expiry | A calendar date, ideally 30 to 90 days out |
| Exit plan | The specific change that ends the exception |
| Evidence | Links to the finding, ticket and any test result |
Two example answers
Weak: "Library X has a known vulnerability. We will fix it later."
Better: "The image parsing library in the upload service has a published flaw with no fixed release. The vulnerable function is only reachable through the admin import page. Compensating control: the page is limited to the internal network and logged. Owner: the upload team lead. Expires 15 January. Exit: replace the library in the next planned refactor."
The second answer can be reviewed in a minute and checked in a month.
Who approves
Match the approver to the risk. A low severity warning in an internal tool can be accepted by the engineering manager. A reachable or exploited flaw in a customer facing service should go to someone who answers for the business risk, with the security team consulted. Write the thresholds down so people do not guess.
The review routine
Exceptions only work if someone looks at them again.
- Keep all exceptions in one register, searchable by owner and expiry.
- Send a reminder to the owner two weeks before expiry.
- On the expiry date, the gate starts failing again unless a renewal is approved.
- Allow at most one renewal without senior sign-off.
- Review the register monthly: how many are open, how many are past due, which rules are waived most often.
A rule that is waived over and over is telling you something. Either the rule is wrong, or the tool is, or the team needs help.
What not to do
Do not accept exceptions by chat message. Do not let the requester approve their own. Do not grant "forever" because the review feels like a chore. Do not hide exceptions from auditors, who often ask to see exactly this register.
Quick check
How long should an exception last?
Short enough that the reason is still true when it expires. Thirty to ninety days is a common starting point, with a firm date and a named exit.
Is a false positive an exception?
Usually it is better handled as a suppression with a recorded reason, which ideally also feeds back into tuning the rule. Use the exception process for real risks you are choosing to carry.
Safeguard offers policies, gates and guardrails, plus compliance and evidence automation for audit preparation. A free scan is a quick way to see which findings you would be deciding about.
Last reviewed: 19 October 2026.
