You own a standard: every service must use the shared auth library, every database must be encrypted at rest, every deploy must go through the paved pipeline. Sooner or later a team asks to skip it, usually for a good reason and always under a deadline. Say no every time and your standard becomes something teams route around. Say yes in a chat thread and two years later you have forty undocumented exceptions, nobody remembers why, and the standard means nothing. This post gives you a small exception process that keeps standards credible: a one-page request, approval that scales with risk, a hard expiry date, and a register you actually review.
Why exceptions are where standards live or die
Any standard that matters will meet cases it doesn't fit. A vendor appliance can't run your agent. A legacy service will be retired in six months and isn't worth migrating. A research prototype needs a library you haven't approved yet. The PTMS study guide puts it plainly: standards "need enforcement mechanisms and ways to request exceptions." Without the second half, enforcement turns into conflict.
The common failure modes:
- No path at all. Teams that can't ask for an exception stop asking. They comply on paper and diverge in practice, and you lose sight of where your real risk is.
- Exceptions by chat. A senior specialist says "fine, go ahead" in a message. There's no record, no owner, no end date. The exception becomes permanent by default.
- Exceptions with no expiry. "Approved" is treated as final. The reason for the exception went away a year ago; the exception didn't.
- Everything goes to one person. The standard's owner approves every request personally, becomes a bottleneck, and starts approving things unread to keep up.
- Exceptions as a quiet signal nobody reads. When many teams ask for the same exception, the standard is probably wrong. If nobody looks at the pattern, you never find out.
A one-page exception request
Keep the request short enough that filling it in takes fifteen minutes, but complete enough that someone outside the team can judge it. A template:
Exception request: <short name> ID: EX-<number>
Standard: <which standard, which clause>
Requesting team / owner: <a named person, not a team alias>
What we won't do
The specific requirement we're not meeting, and where
(which services, repos, environments).
Why
The reason compliance isn't possible or isn't worth it now.
"We're busy" is not a reason; "the vendor appliance can't
run the agent" is.
Risk
What could go wrong because of this gap, how likely it is,
and what the worst realistic outcome looks like.
Compensating controls
What we'll do instead to reduce that risk
(extra monitoring, network isolation, manual review...).
Exit plan
How and when we'll come into compliance, or retire the
thing that can't comply.
Expiry date: <no more than the maximum for this risk tier>
Approver: <name> Decision: approved / approved with
conditions / declined Date: <date>
Three fields carry most of the weight. Compensating controls turn a request to skip a rule into a proposal for a different way to manage the same risk. Exit plan forces the team to say how the exception ends. Expiry date makes sure someone looks again.
If your organization already writes architecture decision records, the format will feel familiar. Michael Nygard's original 2011 proposal for ADRs recorded context, decision and consequences; an exception request is the same idea applied to a deliberate departure from a standard.
Approval that scales with risk
Not every exception needs the same scrutiny. Sort them into tiers by what could go wrong, and set the approver and the maximum duration per tier. A hypothetical example for a security standard:
| Tier | Example | Approver | Max duration | Compensating controls |
|---|---|---|---|---|
| Low | Internal tool with no customer data uses an older logging library | Team's engineering manager, recorded in the register | 12 months | Optional |
| Medium | Customer-facing service delays moving to the shared auth library | Standard owner or a delegate from the specialist team | 6 months | Required |
| High | Production database holding personal data runs without encryption at rest during a migration | Head of the specialist area plus the accountable business owner | 90 days | Required and verified before approval |
| Not allowed | Disabling audit logging on payment systems | Nobody; no exception path | n/a | n/a |
A few rules make the tiers work:
- Publish the tiers with the standard. Teams should be able to tell which tier they're in before they ask.
- Push low-risk decisions down. If the specialist team approves every low-risk exception, it becomes the bottleneck and the high-risk ones get less attention.
- Put the business owner on high-risk approvals. Accepting serious risk is a business decision. A specialist can advise on it, but shouldn't sign for it alone.
- Name what's never allowed. A short list of non-negotiables makes the rest of the process more flexible, not less, because people trust that the hard lines are real.
- Set a response time. Something like two working days for low and medium tiers. A slow exception process gets bypassed just as surely as a missing one.
Expiry is the whole point
An exception without an end date is just a second, undocumented standard. Every exception gets an expiry date no later than its tier's maximum, and when it arrives there are only three outcomes:
- Closed. The team is now compliant, or the thing that couldn't comply was retired.
- Renewed. The team submits a fresh request with an updated exit plan. Renewal is a new decision, judged as if it were the first, not a formality. A useful question for the approver: knowing what we know now, would we approve this from scratch?
- Escalated. No renewal was requested, or the exit plan has slipped twice. It goes to the next tier's approver.
Expiry silently passing is not an outcome. Someone has to notice, which is what the register is for.
A register you actually review
Keep every exception in one place: a spreadsheet, a ticket queue or a table in your internal portal. The format matters less than these fields:
| Field | Why it matters |
|---|---|
| ID and short name | So people can refer to it |
| Standard and clause | So you can group exceptions by rule |
| Owner (a person) | Teams reorganize; someone must be accountable |
| Tier | Drives approver and review frequency |
| Approved on / expires on | The basis for every follow-up |
| Compensating controls | So audits and incident reviews can check them |
| Status | Open, renewed, closed, escalated |
Then review it on a fixed rhythm. Monthly works for most specialist teams, and takes about 30 minutes if the register is kept up:
- Expiring in the next 30 days. Nudge owners now, not on the day.
- Expired and still open. Escalate each one. This list should be empty most months.
- Clusters. Count open exceptions per standard and clause. Five or more teams asking for the same exception is evidence, not disobedience.
- Renewals. Anything renewed twice gets a direct conversation with the owning team's manager about the exit plan.
Report the totals upward each quarter: open exceptions by tier, how many expired without action, and how many closed. Those three numbers tell leadership more about the real state of your standards than any compliance percentage.
Read exceptions as feedback on the standard
The most valuable thing an exception process produces isn't permission; it's information about where your standard doesn't fit reality. When a cluster appears, ask which of these is true:
- The standard is wrong for a whole class of systems. Change the standard, perhaps with a variant for that class.
- The standard is right but too expensive to meet. That's a platform problem. If the paved path were easier, fewer teams would need to step off it. Team Topologies' idea of the thinnest viable platform is a useful check: is the smallest thing that would make compliance easy something your team could build?
- The standard is right and teams don't understand it. Fix the documentation and the examples, not the rule.
- The teams are wrong. Sometimes it really is this. But reach that conclusion last, not first.
Be careful about how you measure success here. If you set a target such as "fewer than ten open exceptions", Goodhart's law applies: teams stop filing requests and comply on paper instead, and you lose exactly the visibility the process was meant to give you. A healthy register has exceptions in it. What you want is that they're recorded, owned, bounded and actually closing.
Common objections
"This is bureaucracy." For low-risk exceptions it should be a fifteen-minute form and a manager's approval. If it takes longer, shrink the template for that tier. The heavy process belongs only where the risk is.
"Teams will abuse it." Some will file requests to avoid work. The exit plan and the expiry date handle that: an exception with no credible exit plan is declined or gets a short expiry, and repeated renewals become visible in the register.
"We'll set this up after the standard is adopted." Launch them together. The first week a standard is enforced is when exception requests arrive, and the habits you set then stick.
Your first step
Pick the one standard your team owns that most often causes friction. This week, write down every exception to it you know of, including the ones granted in chat, with an owner and a reason for each. Give each one an expiry date no more than six months out, and put a 30-minute register review in the calendar for next month. If the list is longer than you expected, that's your answer to whether you need the process. Building governance like this is part of the specialized practice development area in the PTMS study guide, and it pairs well with the decision discipline in research bets that end in a decision.