An exception clause should say who may request a deviation, who may approve it, what the request must contain, the longest term allowed, how renewals work, and how emergencies are handled. Short and specific beats long and vague. Auditors read the clause, then test whether you follow it.
Below is a structure with sample wording you can adapt. It is engineering guidance, not legal advice, and your own counsel or auditor should review the final text.
The six parts
| Part | What the clause should settle |
|---|---|
| Eligibility | Who may request, and that requests are per finding and per asset |
| Approval | Role of the approver, independence from the requester, backup |
| Content | Mandatory fields in every request |
| Term | Maximum duration, by severity if you wish |
| Renewal | Fresh review, no automatic extension |
| Emergency | Fast path with after-the-fact review in a set number of days |
Sample wording
Eligibility. "Any employee may request an exception to the vulnerability remediation timelines in this policy. Each request covers one finding on one asset."
Approval. "Exceptions are approved by the Security Lead, or a named deputy. No one may approve an exception they requested or for code they own."
Content. "A request states the finding, the affected asset and version, the reason remediation is not possible within the policy timeline, any other controls that reduce the risk, a proposed end date, and a named owner."
Term. "An exception expires no later than 90 days after approval. Exceptions for findings listed in the CISA Known Exploited Vulnerabilities Catalog require approval from the Security Lead and an executive and expire no later than 30 days after approval."
Renewal. "An exception is not renewed automatically. A renewal request is reviewed as a new request and must state what changed."
Emergency. "When a release must proceed before approval can be obtained, the Security Lead may grant a temporary exception of up to 7 days, which must be reviewed in full within 5 business days."
Choices to make on purpose
The numbers above are examples. Pick values you can meet. A 30 day limit that you routinely miss is worse for an audit than a 90 day limit you always honor. Also decide whether you tier terms by severity, and write it down either way.
Avoid these phrasings
"As appropriate" and "when necessary" give an auditor nothing to test. Replace each with a role, a number, or a field. Likewise, avoid promising controls you do not run, such as "all exceptions are reviewed monthly" if reviews are quarterly.
Link the clause to the register
End the clause with where the records live: "Approved exceptions are recorded in the exception register, which is available to auditors on request." That sentence points at the evidence and gives you a reason to keep the register complete.
Test the wording
Hand the clause to a new engineer and ask them to file a request using only the clause. Wherever they get stuck, the text is unclear. Fix it, then date the revision.
Where Safeguard fits
Safeguard policies and gates let you encode the term limits and scope rules from the clause as enforceable rules, so the written policy and the tooling agree.
Try it yourself
Click through it at your own pace, or open it full screen. See how policy statements map to framework controls, then check where your clause would provide evidence.
Quick check
How long should an exception clause be?
A paragraph or a short list per part. If it takes a page of prose, readers will not apply it.
Should the clause set one maximum term for all severities?
Either works. One term is simpler. Tiered terms fit risk better. Choose one you can follow and state it.
Sources
Last reviewed: 19 October 2026.
