Record exceptions in version controlled code, aimed at one named rule and one resource, with an owner and an end date in the same change. That keeps them reviewable and countable. An exception granted in a chat thread is invisible to the pipeline and to the next auditor.
Why code beats chat
When a team asks to bypass a check, the quick answer is a message saying "fine, skip it". Weeks later nobody remembers who agreed, why, or whether it still applies. An exception expressed as a reviewed change fixes that. It has an author, a reviewer, a date and a diff.
How Conftest models exceptions
Conftest, a tool for testing structured configuration against Rego policies, has a built in concept. Its documentation says exceptions are written in Rego and specify when a given deny or violation rule does not apply. Inputs matched by an exception are exempted from the rules the exception names. Those rules are matched by name, where a rule called deny_foo can be exempted by naming foo.
Two details from the docs matter for design:
- If you give an empty string as the rule name, the exception matches all rules named deny or violation. That is a broad exemption, so use it with care.
- The docs recommend using identifiers in rule names so exceptions can be targeted. A rule called deny_root_user is easier to exempt narrowly than an unnamed deny.
Conftest also reports exceptions as a separate tally in its output, so a run shows how many checks were skipped alongside passes and failures. That number is worth tracking.
A pattern that scales
- Name every rule. Use a short identifier in each rule name.
- Keep exceptions in their own file. One file per policy set, so a reviewer sees them together.
- Record the metadata. An owner, a ticket or reason, and an expiry date, in a comment or a data file.
- Expire them. A scheduled check that fails when an exception is past its end date forces a decision.
- Review the list. Read the whole file monthly. Remove what is no longer needed.
| Field | Example |
|---|---|
| Rule | root_user |
| Resource | payments-api deployment |
| Owner | Payments team lead |
| Reason | Vendor image requires root, fix tracked |
| Expires | A date within the next quarter |
What an exception should never be
An exception is not a fix. If the same rule is excepted by many teams, the rule or the road needs to change. Treat a growing exception file as feedback on the policy.
Also decide who may approve exceptions, and put that in your CODEOWNERS or review rules so the approval is enforced, not assumed.
Where Safeguard fits
Safeguard offers policies, gates and compliance evidence automation, which can help you keep the approvals and reasons behind decisions together for audits. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Should exceptions have an end date?
Yes. Without one, temporary becomes permanent. An expiry forces a recheck.
Is it fine to exempt a whole repository?
Rarely. Prefer the narrowest scope that solves the problem: one rule on one resource.
Sources
Last reviewed: 19 October 2026.
