How should IAM teams operationalise identity governance across multiple business units?

Why This Matters for Security Teams

identity governance across multiple business units fails when each unit treats access as a local exception rather than a shared control. The result is duplicated roles, inconsistent approvals, stale entitlements, and audit evidence that cannot be reconciled across systems. NIST’s Cybersecurity Framework 2.0 frames governance as an enterprise capability, not a project, which is the right lens for IAM operating models. NHI Management Group’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives makes the same point for machine identities: controls only hold when they are measurable, owned, and repeatable.

The practical challenge is that business-unit autonomy often creates “shadow governance,” where local teams approve access using different thresholds, recertification cadences, and evidence standards. That makes it hard to prove least privilege or show that access changes were reviewed in time. In practice, many security teams encounter governance drift only after an audit finding, a failed recertification, or an incident review, rather than through intentional control design.

How It Works in Practice

Effective multi-business-unit governance starts with a common operating model and a shared control backbone. The IAM team defines the minimum enterprise standards, while each business unit supplies the business context needed to approve, reject, or review access. That usually means separating policy from execution: central teams own the governance rules, and local owners validate role fit, exception handling, and risk acceptance.

For business units, the workflow should be consistent even if the underlying systems differ. Access requests, role mining, recertification, and evidence capture should all feed a common record so that the enterprise can answer who approved what, when, and why. This aligns with the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, which treats identity governance as a lifecycle rather than a point-in-time review. For broader governance structure, the NIST Cybersecurity Framework 2.0 supports tying access control to measurable outcomes and continuous oversight.

• Define a single ownership model for roles, access approvals, and recertification per business unit.
• Standardise evidence requirements so audit trails are comparable across units and applications.
• Use role mining and access analytics to identify duplicates, toxic combinations, and stale entitlements.
• Route exceptions through a documented risk acceptance path with expiry dates.
• Track service-level metrics for review completion, remediation time, and control exceptions.

Where this works best, the governance model is embedded into service delivery, not managed as a separate annual exercise. These controls tend to break down when business units operate with incompatible HR, ERP, or identity data models because role definitions and approval chains cannot be normalised cleanly.

Common Variations and Edge Cases

Tighter governance often increases coordination overhead, requiring organisations to balance auditability against business-unit speed. That tradeoff becomes more visible in federated organisations, mergers, or regions with different legal and privacy requirements. Current guidance suggests central standards should remain fixed, while local implementation can vary when law, operating model, or application architecture demands it.

Edge cases usually appear when one business unit manages highly regulated systems while another manages low-risk internal tools, or when a managed service provider handles day-to-day operations but the company retains accountability. In those scenarios, the control objective does not change: approvals still need a business owner, reviews still need a cadence, and evidence still needs to be retrievable. NHIMG’s Top 10 NHI Issues is a useful reminder that governance gaps often show up first in lifecycle failures, not in the access request itself. The same lesson is visible in the 52 NHI Breaches Analysis, where weak ownership and poor lifecycle discipline repeatedly amplify impact.

There is no universal standard for how much local variation is acceptable, but best practice is to keep the governance workflow uniform and constrain exceptions to documented, time-bound cases.

Related resources from NHI Mgmt Group

• How should IAM teams reduce identity sprawl across disconnected tools?
• How should security teams make NHI best practices usable across the business?
• How should IAM teams handle identity attributes that live across multiple apps?
• How can IAM teams preserve governance when they centralise multiple identity functions?