Exception Management: The Framework Every Other Playbook Ignores

Every Zero Trust programme creates exceptions in its first month. The legacy HR system can’t do MFA. The contractor needs access from outside the corporate network. The CEO’s travel pattern trips conditional access every second Tuesday. Without a formal exception lifecycle, those exceptions quietly become permanent bypasses, and the programme’s security posture erodes one legitimate-sounding request at a time. Microsoft’s research on access control rollouts shows proper RBAC + exception management moves compliance from 65% to 95% within 12 months — and shows what happens when either half is missing.

This is an Operations chapter of the 90-Day Zero Trust Playbook. It is the cross-cutting process that keeps Phase 1, 2, and 3 controls from being silently hollowed out.

Key Takeaways

• Proper RBAC plus formal exception management takes compliance from ~65% to ~95% in 12 months; without it, programmes stall in the 60s (Microsoft Tech Community)
• Exceptions should have a hard maximum duration — 90 days is the ISC² GRC guidance, longer for documented structural cases
• Exception management maps directly onto ISO 27001 A.5.15 / A.8.2 and SOC 2 CC6 controls — Drata’s cross-framework analysis puts ISO 27001 and SOC 2 overlap at 40–85%, so one exception process satisfies both auditors
• The anti-pattern is making renewal easier than the initial request. Reverse this: require remediation-progress evidence to renew
• Steering-committee-level metrics (total count, age distribution, exception-to-policy ratio, trend) are the early warning that the programme is drifting

The Six-Step Lifecycle

1 — Request. Formal submission with three required fields: the policy being excepted, the business justification, and the compensating control that mitigates the added risk. “Because it’s urgent” is not a justification; “because the quarterly close runs through a system that can’t do MFA, and we are on a Q4 replacement roadmap” is. Without the third field (compensating control), the request bounces automatically.

2 — Risk assessment. Security team scores the request on likelihood × impact of the exception being exploited. Low-risk exceptions (a contractor MFA grace period) go to a single-approver fast path. High-risk exceptions (a T0 system on an isolated VLAN because it can’t do modern auth) require steering-committee review.

3 — Approval. Documented, in the exception register, with the specific policy waived, the scope, the compensating controls, and the expiry date. Approver is always the CISO or a pre-delegated authority with the same accountability. Informal Slack approvals do not count.

4 — Monitoring. Every exception is tagged in the systems it affects — the identity provider, the network policy, the change-management ticket. Monitoring the tagged exception is not optional; it is how you know whether the compensating control is actually working.

5 — Expiry. Every exception has an expiry date at approval time. Default 90 days (ISC² GRC guidance), longer only for documented structural cases where a shorter clock would force unsafe workarounds. Expiry is automatic. No silent renewals.

6 — Review. Quarterly steering-committee review of the full exception register. Not a dashboard — an actual review where exceptions still open past the original expiry are either re-approved with fresh justification or closed.

The Anti-Pattern

The failure mode is always the same shape:

1. Exception requests come in through informal channels (Slack DMs, email to the CISO).
2. Approval is verbal or lightly documented.
3. Expiry is “we’ll revisit it.”
4. Six months in, nobody knows how many exceptions are active.
5. A year in, the exception list is longer than the policy list, and “Zero Trust” is functionally “policy with holes where it matters.”

The corrective: treat exception management as a process with a product owner, a system of record, and steering-committee visibility. It costs roughly 0.25–0.5 FTE of programme manager time and is the cheapest insurance you will buy.

Making Renewal Harder Than the Initial Request

This is the single most important design decision. Most organisations accidentally do the opposite: the initial request requires a full assessment, and renewal is “re-approve this existing exception.” That asymmetry is what turns 90-day exceptions into permanent bypasses.

Invert it. Initial request is bureaucratic but straightforward. Renewal requires evidence of remediation progress: how close is the legacy system to being wrapped? When does the contractor’s project end? Has the compensating control been tested in the last quarter? No progress, no renewal.

The governance backing for this lives in Governance Structure for Zero Trust Programmes — the steering committee has to be willing to close an exception even when the system owner protests. That is its job.

ISO 27001 and SOC 2 Alignment

Exception management is not purely a Zero Trust concern. It is a mandatory control in ISO 27001 (A.5.15, A.8.2), SOC 2 (CC6 series), HITRUST, and effectively every enterprise compliance framework. Drata’s cross-framework analysis shows ISO 27001 and SOC 2 overlap at 40–85% depending on scope, which means a single exception register, properly maintained, satisfies multiple audits.

Build the register with the auditor in mind. Fields required by ISO 27001 A.5.15 (access control review) map 1:1 onto what your steering committee needs anyway: who approved, when, for how long, what compensating controls, when last reviewed.

The Four Metrics Worth Reporting Up

• Total active exception count — the headline number. Trend matters more than absolute.
• Age distribution — how many have been open >90 days, >180, >365. If the >180 bucket is growing, the process is failing.
• Exception-to-policy ratio — number of active exceptions per policy. A single policy with 40 active exceptions is not a policy; it is a wish.
• Trend direction quarter-over-quarter — up, down, or flat. Flat is acceptable in a mature programme; monotonically up is a warning.

These four, in a single page, are what the steering committee reviews every quarter. They are also exactly what the board cares about when cybersecurity is on the agenda (see Measurement Dashboard).

What the Playbook Artifact Delivers

By the end of this chapter, you should have:

• An exception register — not a spreadsheet, a system of record integrated with your identity provider and change-management tool
• A documented request-assess-approve-monitor-expire-review process with owners at each step
• Automatic expiry with no silent renewals; renewal requires fresh remediation-progress evidence
• Quarterly steering-committee review on the agenda, with the four metrics reported every time
• Audit-ready documentation that satisfies ISO 27001 A.5.15 / SOC 2 CC6 without additional work

Return to the 90-Day Playbook hub for the remaining operations chapters.