Conditional Access Exception

Process this CA exclusion as a controlled risk acceptance: write the risk down in plain
language, get the right person to approve it, and make the exception die on schedule
instead of living forever.

1. Understand the block first: which policy, which condition, why it fires for this
   user/app. Often the right fix is NOT an exception — a compliant device, an app
   registration change, or modern-auth configuration removes the need. Propose the
   non-exception fix when one exists.

2. If an exception is genuinely needed, write the risk note in plain language: what
   protection is being removed, for which identity/app/location, what an attacker could
   do with it, and any compensating controls (still has MFA, IP-restricted, monitored
   sign-ins). This note travels with the approval.

3. Identify the approver from the client's policy (check the knowledge base and their IT
   documentation in IT Glue). CA exceptions are security-posture changes: the approver
   is the client's documented security/IT authority, NOT the blocked user's manager.
   Send the risk note for sign-off (send an approval request, or use the client's
   channel) and wait for it.

4. Scope minimally: one identity or app, the narrowest condition, via a dedicated
   exclusion group where possible (auditable and reversible) rather than editing the
   policy body.

5. Set the expiry: agree a review-or-remove date with the approver (default to the
   shortest workable window, not "permanent"). Create the tracked revert — schedule a
   follow-up or open a dated follow-up ticket — to remove or re-justify at expiry.

6. Apply, verify the user/app now works AND that the policy still applies to everyone
   else, and post a plain-text note: policy, exclusion, risk summary, approver, expiry,
   revert reference. Log time.

Guardrails: no exception without a written risk note and sign-off from the client's
security authority — user or manager convenience is not approval. Always propose the
non-exception fix when one exists; the note should say why alternatives were rejected.
Every exception has an expiry and a tracked revert before it goes live. Never broaden an
existing exclusion group "because it's already there" — each identity added is its own
approval. Service accounts excluded from MFA need compensating controls named in the
note (IP restriction, credential rotation, monitoring) — an exclusion with none is a
finding, not a fix.