Identity governance should own policy, role design, access certification, exception handling, and audit evidence. Identity management should own provisioning, authentication, directory updates, and routine access maintenance. Separating the two helps teams see whether they have only operational control or also defensible oversight. The test is whether each control can be assigned to one clear owner and measured independently.
Identity governance and identity management solve different problems
Identity governance answers who should have access, why they should have it, and how you prove it remains justified. Identity management answers how accounts, credentials, directories, and access changes are created and maintained. If those responsibilities are blurred, teams often optimise for speed in the operational plane while leaving policy, review, and accountability too diffuse to defend.
That separation is easiest to understand when you treat governance as the decision and evidence layer, and management as the execution layer. Governance defines the rules for roles, approvals, certification, exceptions, and auditability; management carries out provisioning, authentication, updates, and routine maintenance. The two work together, but they should not be owned as the same operational bucket.
For a practical reference point, IAM and IGA Basics lays out the split between access administration and access oversight, while Ultimate Guide to NHIs, Regulatory and Audit Perspectives shows why audit trails and governance obligations sit on the oversight side of the line.
Where the boundary becomes visible in day-to-day operations
The clearest boundary is not organisational chart language, it is work product. Governance produces policy decisions such as role models, certification campaigns, separation-of-duties rules, and exception approvals. Management produces operational outcomes such as a provisioned account, a rotated credential, a directory sync, or a disabled user.
This distinction matters because the same team can easily become both the requester and the approver if the boundary is not explicit. When that happens, access may still be granted correctly, but the organisation loses independent challenge, traceable evidence, and a clean way to show whether access was authorised for business reasons or merely executed by the platform.
That is why role design and review processes belong with governance, not with the provisioning queue. Role Mining and Role Design Guide is useful for understanding how roles become a governed entitlement structure, and Access Reviews and Certification Guide is the natural companion when the control objective is review and recertification rather than ticket handling.
How to separate ownership without breaking the control plane
A good split is to define governance as the owner of policy, risk acceptance, control design, and attestation, while identity management owns system administration, lifecycle workflows, and connector reliability. That means governance can ask whether a role is still justified, and management can answer whether the account was actually created, updated, or removed as intended.
The test is whether the control can be measured independently. A governance control should produce evidence such as approval records, review completion, exception ageing, or role rationalisation outcomes. A management control should produce operational evidence such as provisioning latency, account state accuracy, authentication success, or deprovisioning completion. If one measure is hiding the other, the boundary is too loose.
For implementation detail, Joiner-Mover-Leaver Guide shows the management side of lifecycle execution, while IGA Buyer’s Guide is helpful when you need to separate governance workflows from operational connectors and provisioning logic.
Risk and Threat Considerations
When governance and management are not separated, the main risk is that operational efficiency masks weak accountability. A team can keep accounts flowing while role design drifts, exceptions pile up, and access reviews become rubber-stamped because the people operating the system also control the evidence trail.
Failure mechanism: The organisation merges approval, execution, and verification into one process owner, so excessive access, stale entitlements, and unchallenged exceptions persist even when provisioning itself appears to work.
Impact: Over time, that creates privilege creep, weak audit defensibility, slower exception remediation, and a higher chance that an access decision cannot be explained or independently validated after the fact.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Separates lifecycle administration from access governance decisions. |
| AC-6 — Least Privilege | Role design and exception handling directly shape excess access risk. | |
| AU-2 — Event Logging | Governance needs auditable evidence distinct from operational system activity. | |
| Recommendation — Assign account lifecycle execution to identity management and keep access decisions under governed review. Use least privilege to keep access decisions independent from routine provisioning. Retain review and approval evidence separately from provisioning logs. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Defines access policy and control expectations that governance should own. |
| A.5.18 — Access rights | Access rights must be allocated, reviewed, and removed under clear oversight. | |
| Recommendation — Set access rules centrally and let management execute them. Review and revoke access rights through a governed process, not ad hoc administration. | ||
Practitioner Guidance
What to verify: Check that governance can approve, review, or revoke access without also operating the provisioning system. If the same team owns both the policy decision and the system of record, the separation is only nominal.
What good looks like: Governance owns the rules, the exceptions, and the evidence; management owns the workflow, directory state, and technical completion. Each side should have its own success measures and its own escalation path.
Common mistake: Treating identity management as the entire control surface because it is easier to automate. Automation improves execution, but it does not replace independent oversight or role accountability.
Practitioner takeaway: Separate the decision to grant or retain access from the act of making it happen, then measure both layers independently so operational control never substitutes for governance.
Related resources from NHI Mgmt Group
- Should organisations separate identity governance and SaaS management workspaces in a single platform?
- What is the difference between attack surface management and NHI governance?
- Why is it important to integrate identity and data governance?
- Should organisations prioritise external exposure or internal credential governance first?