An override log should record who overrode the gate, when, which finding or check, which artifact, why, who approved, and when the exception expires. Keep it append-only and linked to the release ID. If you cannot answer those questions later, the override is not evidence of control.
Why the log matters
Every gate gets overridden eventually. That is not the failure. The failure is an override that leaves no trace, or one that cannot be explained six months later. Auditors tend to test exceptions directly because they show how a control behaves under pressure.
NIST SP 800-53 control CM-3 asks for documented configuration change decisions, retained records and monitoring and review of change control activities. An override log serves all three.
Fields to capture
| Field | Why |
|---|---|
| Release ID and artifact digest | Ties the override to a specific build |
| Gate and rule that failed | Shows what was bypassed |
| Finding IDs and severity | Shows what risk was accepted |
| Requested by | Accountability |
| Approved by | Separation of duties |
| Reason | The reasoning an auditor will ask about |
| Compensating control | What reduced the risk |
| Timestamp and expiry | When it happened and when it ends |
| Outcome of follow-up | Closes the loop |
How to keep it trustworthy
- Write entries automatically from the pipeline, not by hand.
- Make the log append-only. Corrections are new entries that reference the old.
- Send a copy to a separate system, so a pipeline admin cannot quietly edit history.
- Require a reason field that is not empty, and reject placeholder text such as "n/a".
- Include emergency overrides, even those made by administrators.
Review it
A log nobody reads is just storage. Each month, look at:
- Count of overrides by team and by rule.
- Overrides without an expiry, or past it.
- Repeat overrides for the same finding.
- Overrides approved by the person who requested them.
A rule that is overridden often is telling you something. Either it is too strict, the fix path is too slow, or a team needs support.
Who else uses the log
Beyond audits, the log helps incident response. If a shipped release is later exploited through an accepted finding, the log shows who accepted what, on which evidence. That is useful for learning, not blame, provided the reasoning was recorded honestly at the time.
Quick check
Should administrators be able to override without a record?
No. Administrator overrides are exactly the ones an auditor wants to see.
How long should the log be kept?
Match your policy retention for change records. Write the period down.
Sources
Safeguard offers policies, gates and compliance evidence automation, and a free scan is available at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.