.png)
Every segregation of duties program eventually meets a conflict it can't remove. A controller covering two roles during a departure. A five-person finance team where full separation isn't staffable. The exemption is the right answer in these moments, and it's also where most SoD programs quietly fall apart. Not because exceptions exist, but because they never end.
No SoD program survives contact with a real org chart without exceptions.
The real design question is what happens to each exception after it's granted. An expiry date on every exemption is the single choice that separates controls that hold up in an audit from controls that quietly rot.
In this piece, we make the case for that discipline and lay out the six properties a real exemption model needs.
Exemptions Are a Feature, Not a Failure
Let's get one thing out of the way first: needing exemptions doesn't mean your segregation of duties program is weak. It means your SoD program has met reality.
Perfect separation assumes headcount that most teams don't have. The textbook model, where the person who creates a vendor never approves a payment to that vendor, and the person who provisions access never reviews it, requires enough people to spread those duties across. Smaller teams, teams mid-reorganization, and teams covering a sudden departure all hit situations where one person legitimately needs both sides of a conflict for a while.
The exemption exists for exactly this. It's a documented, deliberate decision to carry a segregation of duties risk for a defined stretch, made by someone with the authority to accept it. That's not control erosion. That's how controls are supposed to bend without breaking.
The erosion starts one step later, in how the exemption is allowed to behave after it's granted.
The Failure Mode: Exceptions That Outlive Their Reasons
Here's the pattern that plays out in most organizations. A conflict fires. The access is legitimate, so someone grants an exception, usually with a one-line justification typed into a free-text field. The violation goes quiet. Everyone moves on.
And then nothing else ever happens.
The controller who needed dual roles "during the transition" still holds both eighteen months later, because the transition ended but the exception didn't. The justification that made sense in March is unverifiable in November, because the person who wrote it left in July. Multiply this across a few dozen conflicts and a few years, and the exemption list becomes something worse than a gap in the control. It becomes a parallel policy: one no leader authored, no process reviews, and no one can defend when asked.
The problem was never the exception. The problem is that the exception had no clock on it. An exemption without an expiry date isn't a temporary risk acceptance. It's a permanent hole with paperwork.
Auditors know this pattern well, which is why the exemption list is one of the first places a SOX audit digs. A control with a clean violation history and a bloated, undated exception list isn't a passing control. It's a control that's been routed around, with the routing helpfully documented.
What a Disciplined Exemption Model Looks Like
The fix isn't cultural. You will not solve this by asking people to remember to re-review exceptions, because re-reviewing exceptions is precisely the kind of work that loses to everything else on the calendar, every time. The fix has to live in the mechanism: the exemption system itself should make permanence impossible.
That translates into six specific properties.
Every exemption carries a mandatory duration. Not an optional end date, not a "review by" suggestion. A required duration, entered at grant time, after which the exemption stops existing. If the system allows an exemption to be created without an expiry, the system allows permanent exceptions, and permanent exceptions are what you'll get.
Expiry reopens the violation automatically. This is the piece most homegrown processes miss. An expiry date in a spreadsheet is a reminder; an expiry date in the SoD engine is an event. When the duration lapses, the violation should return to open status on its own, forcing a fresh decision: is this conflict still justified, or has the situation that justified it ended? No one has to remember anything. The re-review is baked in.
The exemption itself has a lifecycle, not just a flag. A real exemption record moves through states of its own: active while it suppresses the violation, expired when the clock runs out, revoked when someone ends it early. Both terminal states reopen the linked violation; the only difference is whether time or a human pulled the trigger. That record, with its state history intact, is what turns an exception from a soft spot into evidence.
Every exemption carries a required reason. A justification field that can be left blank will be left blank. The reason is what makes the exemption defensible later, to an auditor, to a successor, to yourself in a year. It should be impossible to grant an exception without stating why.
Exemption durations have a policy-level ceiling. Individual grantors shouldn't decide the maximum. The policy owner sets a cap, say 30 or 90 days depending on the conflict's risk level, and every exemption under that policy stays within it. This keeps a well-meaning admin from granting a two-year exception to make a recurring annoyance go away.
Only specific roles can grant them. Exemption authority is risk-acceptance authority, and risk acceptance belongs to people accountable for the control, not to whoever happens to be looking at the violation. Narrow the set of roles that can grant, and the exemption list stays something leadership actually authored.
This is the model Zluri's SoD engine implements natively:
- Off by default on every policy, in Monitor and Enforce mode alike, and deliberately enabled with a maximum duration
- Duration and written reason required at grant time, within the policy's cap
- Automatic reopening: expiry flips the record to Expired, early revocation flips it to Revoked, and either way the violation reopens immediately
- Grant authority restricted to admin-level roles, regardless of who's assigned to work the violation itself
There is no configuration in which an indefinite exemption is possible, which is exactly the point.
Time-Bound Exemptions Change the Conversation With Auditors
There's a second-order benefit here that's easy to miss, and it shows up in the audit room.
An undated exception list puts you on the defensive. Every entry is a question you have to answer from memory or from archaeology: why does this exist, who approved it, is it still needed, when will it end? The honest answer to most of those questions, months or years later, is "we're not sure," and auditors hear that answer for what it is.
A time-bound exemption list flips the posture entirely, because every exception carries four things an auditor can verify:
- A stated reason
- A named grantor
- A defined end date
- A system-enforced re-review when that date arrives
The exception list stops being evidence of control erosion and becomes evidence of control operation: here are the risks we knowingly accepted, here's who accepted them, here's when each acceptance expires, and here's the mechanism that guarantees we'll look again. You're no longer explaining gaps. You're demonstrating governance.
The same records also compound over time. When every exemption grant, expiry, and revocation is logged, you can answer the question auditors actually care about, which is not "do exceptions exist" but "does anything ever escape review permanently." With a mandatory-duration model, the answer is provably no.
Where the records live matters too. In Zluri, exemptions surface in one dedicated view across every policy, each carrying its status, reason, grantor, and expiry date, alongside a per-policy view for investigation. When an auditor asks for the exception register, it's a filter and an export, not a quarter of archaeology across spreadsheets and email threads.
Running Exemptions Well: Three Decisions Worth Making Deliberately
Mechanism handles the enforcement, but a few judgment calls still belong to you, and they're worth making explicitly rather than by default.
Decide which policies allow exemptions at all. Not every conflict deserves an exception path. A policy covering payment creation and payment approval in your ERP might reasonably allow 30-day exemptions for coverage situations. A policy covering production database admin access alongside audit log deletion probably shouldn't allow exemptions under any circumstances, because there's no coverage scenario that justifies that combination. Keeping exemptions off by default, and enabling them policy by policy, turns this into a conscious decision instead of an ambient one. And where exemptions are allowed, under what cap, and who grants them belongs in your written SoD policy and procedure, not in tribal knowledge.
Scale the duration cap to the conflict's risk. A high-risk toxic combination might warrant a 15-day maximum, enough to cover a handover, short enough that it can't become furniture. A lower-risk conflict might reasonably allow 90 days. The cap is a statement about how long you're willing to live with that specific risk, so it should vary with the risk.
Treat repeated re-exemption as a signal, not a routine. When the same identity's violation reopens and gets re-exempted three cycles in a row, the exemption process is working exactly as designed, and it's telling you something: this isn't a temporary situation. It's a staffing or process problem wearing an exemption as a costume. The right response at that point is redesigning the roles, not a fourth exemption. The reopen mechanism is what surfaces this pattern; without it, the third and fourth cycles never happen because the first exemption never ended.
The mechanics underneath all of this, how an exempted violation behaves, what happens at expiry, how early revocation works, and where every state change lands for audit evidence, run through Zluri's own state machine. We've walked through all of it in our guide to the violation lifecycle in Zluri.
Frequently Asked Questions
Aren't mandatory expiry dates just bureaucratic overhead for small teams?
The opposite, in practice. Small teams are exactly where conflicts are most often legitimate and where no one has bandwidth to manually track exception reviews. A mandatory duration with automatic reopening does the tracking for you. The overhead of entering a duration at grant time is seconds; the overhead of an auditor unwinding five years of undated exceptions is weeks.
What's a reasonable maximum exemption duration?
It depends on the conflict's risk, which is why the cap should be set per policy rather than globally. Common patterns: 15 to 30 days for high-risk financial conflicts (long enough for a handover, short enough to force resolution), 60 to 90 days for lower-risk combinations. If you find yourself wanting a cap longer than a quarter, the situation probably calls for redesigning the roles rather than exempting the conflict.
What should happen when an exemption expires but the business need still exists?
The violation reopens, someone with grant authority reviews it fresh, and if the need genuinely persists, they grant a new exemption with a new reason and a new duration. That re-decision is the entire point. And if the same conflict needs re-exempting repeatedly, treat it as evidence that the underlying role design needs fixing, not as a process to streamline.
Who should be allowed to grant SoD exemptions?
Roles accountable for the control itself, typically admin-level or policy-owner roles, and deliberately not the assignees working individual violations. Granting an exemption is accepting a risk on the organization's behalf, and that authority should be narrow enough that the exception list reflects decisions leadership would recognize and defend.
Does exempting a violation remove it from audit evidence?
No, and it shouldn't. A well-built SoD engine logs the exemption grant, the reason, the grantor, the expiry, and any early revocation as part of the violation's permanent record. Exempted violations are some of the most valuable audit evidence you have, because they demonstrate the control kept operating even when the answer was "accept the risk for now."
