The Exception With No Clock Attached
Somebody can't get past two-factor. Maybe their phone died, maybe the contractor's org doesn't support the authenticator app, maybe it's 6pm on a Friday and the deploy is blocked behind a login nobody can complete. An admin opens the console, finds the policy, carves out a group or an OU, and turns enforcement off for that one slice of the directory. The ticket note says "temporary, revisit end of month." The login goes through. The deploy ships.
End of month comes and goes. Nobody revisits it. Eighteen months later the exception shows up in an access review as a surprise, the kind where the person reading the report has to go find whoever's still around from the original incident and ask why a chunk of the org has been running without the control everyone assumes is universal. The answer is never a cover-up. It's always some version of: it worked, so nobody thought about it again.
The easy explanation is neglect, somebody forgot. But neglect implies the task was sitting on a list and got skipped. This isn't that. The task was never on a list. Creating the exception was a response to a problem that hurt right now, in the moment, with a person on the other end of it waiting. Reverting the exception has no equivalent moment. There's no instant where the absence of the fix starts to hurt again, because the fix, by definition, removed the hurt. The thing that would motivate the reversal is the exact thing the exception was built to make go away.
That's the asymmetry, and it's not about diligence. Creating an exception is one motivated action by one person solving one problem they can feel. Reverting it requires someone, at some later and entirely arbitrary date, to feel an urgency that already expired on the day it was granted. Nobody attaches that urgency to a calendar because urgency isn't the kind of thing you can schedule. You can schedule a date. You can't schedule a feeling. And a feeling is what actually got the original fix shipped in twenty minutes instead of twenty days.
So the exception doesn't rot because someone dropped the ball. It rots because the system only has a mechanism for the pain that creates rules, not for the absence of pain that would unmake them. A ticket with a due date looks like it solves this, but a due date is a note to a future self who has to manufacture concern from scratch, with none of the context that made the original urgency real. By the time the date arrives, the login works fine, the deploy shipped months ago, and the only thing left is a line item asking someone to go inconvenience a group of people who aren't currently inconvenienced. That's a hard sell against a backlog full of things that are.
The fix people reach for is a review cadence, quarterly audits, expiring the exception outright and forcing a renewal request. Those work exactly as well as the review actually treats "nobody asked to renew this" as evidence the exception should die, rather than treating silence as tacit approval and rubber-stamping the renewal because nobody wants to be the one who breaks something that's been fine for a year. An expiration date only does anything if expiry defaults to off. If it defaults to on, you've just added a second place for the asymmetry to hide.
The honest fix is to attach the revert to something that already has its own urgency, not to manufacture a new one. Tie the exception to the departure of the contractor, the resolution of the vendor issue, the replacement of the broken phone, something with a natural endpoint that somebody is already tracking for other reasons. Anything that needs its own fresh motivation to undo, years after the motivation that created it has burned off, is going to outlive its reason. Not because anyone decided it should. Because nobody decided it shouldn't, and deciding is the part that needs a reason to happen at all.
The switch got flipped by a problem that was loud enough to get someone's attention. It waits now for a problem that already left the building.