Skip to content
IT White GloveFractional CIO & IT decision advisory
Build a decision brief
Menu

Decision guide · Identity and access governance

MFA is a control. Deciding who can waive it is governance.

Every organization collects a policy, an exception, and a story about why the exception still exists. Identity governance is the decision about who owns that story going forward.

Frame the exception question

Access policy without an owner becomes whatever is convenient this week.

MFA, single sign-on, and Conditional Access are usually rolled out as a project. Someone picks the tool, sets the initial rules, and moves on. What happens next - a legacy application needs a bypass, a senior executive wants a waiver, a contractor keeps standing access weeks after the contract ends - rarely has an owner at all.

Each exception is granted for a specific, defensible reason in the moment. None of them are revisited as a set. Eighteen months later, the actual policy is not the one written down; it is the accumulated pile of exceptions nobody has re-tested.

Identity governance separates the tool decision from the ownership decision: who can approve an exception, who reviews standing access on a schedule, and what should trigger a policy change - independent of which platform enforces it.

Boundary

This is a governance and decision-rights lens on identity policy. Selecting or configuring an identity platform, and day-to-day access administration, remain separately scoped technical work.

Decision roles

Four jobs a working access policy actually needs.

Approve

Grant or deny an exception

A named role weighs risk against business need - not IT convenience or executive pressure alone.

Review

Confirm standing access still fits

A defined cadence catches access nobody remembers granting before it gets tested.

Enforce

Apply the policy consistently

An exception without a record quietly becomes the new unwritten policy for everyone else.

Escalate

Raise what the policy doesn't cover

A new application or workforce change tests the policy before anyone has updated it.

Ownership lenses

Six questions before the next exception is granted.

  • Exception ownershipWho can actually approve a Conditional Access or MFA bypass, and is it written down?
  • Standing-access reviewHow often is access compared against current role and need, rather than assumed correct?
  • Privileged account countHow many accounts hold elevated rights, and can each one be explained today?
  • Contractor & third-party accessDoes access expire with the engagement, or does someone have to remember to remove it?
  • Legacy application fitWhich systems can't support modern policy, and what compensating control covers them?
  • Escalation triggerWhat event - a new app, an incident, an audit - should force a policy review?

Working process

Decide the exception rules before the next one is requested.

  1. Inventory the identity surface

    MFA coverage, SSO scope, and every standing exception currently in place, listed rather than assumed.

  2. Name exception authority

    One accountable role for approving a waiver, with the reasoning recorded at the time.

  3. Set a review cadence

    A scheduled pass over privileged accounts, guest access, and open exceptions - not an annual afterthought.

  4. Decide the escalation trigger

    Agree what event forces the policy itself to be revisited, rather than patched with one more exception.

Most identity policy lives inside the same tenant this ownership decision covers

Guest access to Teams and SharePoint content is often the exception this decision has to cover

Hypothetical pattern

A Conditional Access exception with no expiry date

A legacy finance application gets a permanent Conditional Access bypass three years ago because it couldn't support modern authentication at the time. The exception is never re-tested - not because anyone decided it was still necessary, but because no one owns checking. The useful decision was never "allow or deny"; it was naming who revisits that answer, and when.

See how this connects to onboarding and offboarding

Next step

Bring the exception nobody has revisited since it was granted.

A focused brief can turn an informal waiver into a named approval authority, a review cadence, and a clear escalation trigger.

Build the exception brief

IT White Glove · Fractional CIO & IT decision advisory

Get IT decisions made, and made to stick.

contact@itwhiteglove.com

IT White Glove is an independent IT provider. Microsoft and Microsoft 365 are trademarks of the Microsoft group of companies.

Related brands share common ownership and are operated by the same team.