Should organisations centralise identity governance even when local offices need flexibility?

How central governance preserves flexibility without fragmenting control

Centralising identity governance does not mean every office must use identical workflows for every access request. It means the organisation defines one control model for provisioning, approvals, reviews, revocation, and evidence, then allows local offices to operate inside that model where business need justifies variation. That preserves agility without letting exceptions become separate security standards.

A practical way to think about this is that central governance owns the rules, the accountabilities, and the evidence, while local teams supply the context. The result is usually faster exception handling, clearer audit trails, and less debate about which office’s process is authoritative.

For the underlying governance model, teams often start with IAM and IGA Basics, which frames how access decisions, reviews, and entitlement management fit together across people and machines.

Where local flexibility belongs, and where it should stop

Local flexibility is most defensible at the edge of the process: role justification, business approver selection, regional compliance add-ons, and timing windows that reflect operating hours or local regulation. It is far less defensible in the control spine itself, such as inconsistent joiner-mover-leaver steps, different revocation thresholds, or office-specific definitions of what counts as acceptable evidence.

When the same entitlement can be approved under different rules in different locations, the organisation loses comparability. That makes access review quality uneven and weakens the ability to show that the same control objective was met everywhere.

Good operating models also define how exceptions are handled across the enterprise. IGA Buyer's Guide is useful here because platform selection should support configurable workflows without creating policy drift between offices.

Why decentralised exceptions become a governance problem

The main failure mode is not local adaptation itself, but local adaptation without a common control boundary. Over time, one office may add its own approval chain, another may skip periodic certification, and a third may retain access longer than policy allows. That creates inconsistent security posture even when each office believes it is being pragmatic.

This is also where accountability breaks down. If access, device control, and compliance evidence are handled differently in different locations, it becomes harder to prove who owns the decision, who approved the exception, and whether the exception expired when it should have.

Those risks are amplified when roles and entitlements are already complex. A common role design and review discipline helps the centre compare like with like, instead of trying to reconcile incompatible local practices. The Role Mining and Role Design Guide supports that central comparison by showing how to keep role models manageable across different business units.

Risk and Threat Considerations

When identity governance is fragmented, the organisation usually accumulates three risks at once: privilege creep, weak revocation, and unreliable audit evidence. Local offices may not intend to create exposure, but inconsistent approval and review practices can leave excessive access in place long after it should have been removed.

Failure mechanism: Separate local processes create different approval standards, review cadences, and evidence formats, so controls no longer behave consistently across the enterprise. That increases the chance that an exception becomes a permanent access path or that a compliance review misses a weak office-specific practice.

Impact: The organisation gets uneven control quality, higher audit friction, and a larger blast radius when access is misused or an entitlement is left active. In practice, that can also make remediation slower because no one can easily tell which local exception is legitimate and which is simply unmanaged drift.

Where the issue is access governance rather than a single access review, teams often need a common treatment for exceptions and conflicts. Segregation of Duties (SoD) Guide is relevant because it shows how central policy can still accommodate mitigations without letting local offices rewrite control intent.

Practitioner Guidance

What to prioritise: Define the enterprise control model first, then document the small set of local variations that are explicitly allowed. If a local process cannot produce the same minimum evidence as the global process, it should be treated as a policy exception, not a local preference.

What to verify: Verify that every office uses the same baseline for provisioning, recertification, revocation, and exception expiry. The key test is whether a central reviewer can compare one office to another without translating between different rule sets or evidence formats.

Practitioner takeaway: Central governance works when it standardises decisions and evidence, while local flexibility is limited to approved context, not control design. If the exception cannot be measured, reviewed, and revoked under the same enterprise model, it is already outside governance.

Related resources from NHI Mgmt Group

• Why is it important to integrate identity and data governance?
• Should organisations prioritise external exposure or internal credential governance first?
• How can organisations avoid the flexibility trap in non-human identity governance?
• How should organisations balance export flexibility with identity governance requirements?