Series 2, July 7, 2026

Exceptions

2 minute read, by Becky Sandberg

The graphic that went with this post on LinkedIn, summarizing Exceptions

Exceptions are often treated as administrative tasks. In identity, they are something more useful. They are signals.

There are two kinds. Filed Exceptions are the formal artifact. They are documented, approved, time-bound, with compensating controls and a named owner. Undocumented deviations are everything else. The configuration that drifts from policy. The "I had approval" with no traceable approver. The workaround that quietly becomes how things work.

I asked an application admin once why a configuration did not match our standard. They said they had approval to do it differently. No one could name who gave it, and there was no Exception on file. Maybe an auditor accepted the explanation. Maybe the system owner did not know the official path. Either way, the deviation had quietly become the design.

Filed Exceptions are honest. They tell the truth about where the model bends. Someone reviews them, sets an end date, can revoke them. The dangerous ones are the deviations nobody filed.

Both reveal where the operating model is weak. The weakness shows up in governance, lifecycle, access design, or technology.

This is why the relationship with GRC, Compliance, or whoever owns the formal Exception process matters. IAM owns the standard, so IAM has to be at the table for review, approval, remediation planning, and closure. Not as an auditor. As the trusted advisor for application admins and owners trying to meet the standard. GRC and auditors test controls. IAM owns the standards those controls were drawn from. Without IAM at the table, the Exception process is checking control language while the standard itself continues to drift. IAM also has to surface the deviations that never made it into the process, because those are the ones drifting into design.

Start by getting clear on:

Which Exceptions are filed, aging, and repeating

Which deviations exist without an Exception on file

Which ones are tied to privileged access or lifecycle gaps

Which ones exist because the standard path is too hard to use

Which ones affect nonhuman identities or AI agents

Whether IAM is at the table as a trusted advisor

Measure:

  • Filed Exception volume, age, and repeat rate
  • Configurations that drift from standard without Exception
  • Privileged access deviations
  • Lifecycle-related deviations
  • Deviations affecting nonhuman or AI identities

The goal is not to eliminate every exception. The goal is to keep them visible and stop letting them become design.

❓ Which deviation in your environment never made it into the Exception process?

Put it to work. The free toolkit turns ideas like this into templates, a five-minute assessment, and a first move you can finish.

Open the free toolkit