Should organisations separate governance from IAM or keep them together?

Why governance should be separated from IAM, but not detached from it

Governance and IAM solve different problems. IAM enforces access at the point of login, token issuance, or policy evaluation; governance asks whether that access should exist in the first place, and whether it still makes sense across business context, risk, and ownership. Keeping them as one function usually collapses review, provisioning, and approval into a single operating bottleneck.

The cleaner model is separation with a control handoff: IAM remains the enforcement layer, while governance becomes the decision layer that can see across applications, cloud services, and privileged pathways. That separation matters most when the estate is distributed, because local admin choices and app-specific permissions quickly outgrow a single team’s ability to validate them manually.

When organisations treat governance as a distinct function, they can review access by role, entitlement, criticality, and exception pattern rather than by whatever IAM system happens to administer a specific account. That is the difference between automated issuance and defensible access oversight.

What breaks when governance is absorbed into IAM

Conflating the two usually creates three failure modes. First, the IAM team becomes the de facto policy owner, even though it may not own the business context needed to approve access. Second, access reviews become retrospective and checkbox-driven, because the same workflow that provisions access is also expected to judge whether it is justified. Third, governance loses visibility into exceptions, orphaned access, and privilege drift across systems that do not share one control plane.

This is why mature programmes often separate workflow from enforcement, then connect them through common data about ownership, entitlements, systems, and risk. A governance decision should be able to trigger or revoke IAM actions, but it should not be trapped inside the same operational queue as routine identity administration. NHIMG’s Identity Security Programme Guide is useful here because it frames the operating model, RACI, and roadmap choices that sit above the tooling layer.

In practice, this also prevents access review fatigue. If reviewers only see usernames and groups, they miss whether a permission is business-critical, temporary, inherited, or excessive relative to the actual job function. Governance is the place where those distinctions are meant to be visible.

How to split responsibilities without creating a control gap

The design principle is simple: IAM should answer “who can authenticate and what enforcement should occur now?”, while governance should answer “who should have what access, under what conditions, and for how long?”. That means governance owns policy, approvals, recertification, and exception handling; IAM owns provisioning, authentication, session enforcement, and revocation execution.

For teams managing service accounts, workloads, or other machine credentials, the same split still applies. Lifecycle and review belong to governance, while credential issuance and access enforcement belong to IAM. NHIMG’s NHI Lifecycle Management Guide is relevant because lifecycle controls only work when ownership, rotation, and offboarding are governed separately from runtime access.

Where the access model is broad or cloud-heavy, governance also needs a view of effective privilege, not just assigned roles. NHIMG’s Cloud PAM and CIEM Guide is a good fit for that point because it shows why entitlement review and just-in-time privilege decisions are governance problems even when IAM performs the technical enforcement.

Risk and Threat Considerations

When governance is fused into IAM, organisations tend to miss privilege drift, delayed offboarding, and approvals that no longer reflect business need. That creates a direct exposure path for overprivileged users, stale service accounts, and exceptions that persist long after the original justification has expired.

Failure mechanism: The same team or workflow is asked to both provision access quickly and independently challenge whether the access is still appropriate, so review quality decays as volume grows.

Impact: Excess access becomes normalised, audit evidence weakens, and a compromise can spread further because the organisation has no clean separation between issuance and oversight.

Practitioner Guidance

What to prioritise: Start by defining which decisions are governance decisions, which are IAM execution decisions, and which are exception decisions. If a control requires business context, ownership validation, or recertification, it belongs in governance even if IAM will carry out the change.

What to verify: Check that every high-risk entitlement has a named owner, an expiry or review point, and a clear revocation path. If you cannot produce those three artifacts quickly, the organisation does not yet have a real separation of duties between governance and enforcement.

Common mistake: Treating access reviews as a feature of the IAM tool rather than a governance discipline. Tools can automate the workflow, but they cannot substitute for policy ownership or accountable review.

Practitioner takeaway: Keep IAM as the enforcement engine and governance as the decision authority, because scale comes from separating who grants access from who justifies it.

Related resources from NHI Mgmt Group

• What is the difference between human IAM controls and NHI governance?
• What does the 144:1 NHI-to-human ratio mean for IAM governance programmes?
• Should organisations prioritise external exposure or internal credential governance first?
• How do organisations keep AI governance from becoming a separate silo?