Who should own identity governance architecture across IAM and compliance teams?

Why This Matters for Security Teams

identity governance ownership is not just an org chart question. It determines who sets policy, who approves exceptions, who can evidence control performance, and who is accountable when privileged access drifts outside approved boundaries. When IAM, compliance, and security operations each own a fragment, control evidence tends to fragment with them, which makes reviews slower and remediation less reliable. NIST Cybersecurity Framework 2.0 stresses that governance must be coordinated across the enterprise, not bolted onto access management after the fact.

For non-human identities, the stakes are higher because scale and churn outpace manual oversight. NHI Management Group notes that NHIs outnumber human identities by 25x to 50x in modern enterprises, and 68% of organisations do not know how to fully address NHI risks. That combination makes split ownership especially dangerous: one team may provision access, another may review it, and a third may discover the gaps only during audit. In practice, many security teams encounter control failures only after secrets have already been exposed or an access review has missed a service account.

For broader context, see the Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0.

How It Works in Practice

The most effective operating model is a combined identity governance function with clear authority over policy, workflow, and measurement, while IAM engineering and compliance remain embedded partners. That function should own the architecture patterns for joiner-mover-leaver flows, privileged access review cadence, exception handling, and evidence collection. IAM engineering then implements the technical controls, and compliance defines retention, audit, and attestations requirements. This avoids the common failure mode where each team optimises its own deliverable but no one owns the end-to-end result.

For NHI and agentic workloads, the governance layer should also define what “approved identity” means in technical terms. Current guidance suggests that workload identity, short-lived credentials, and policy-driven approvals are more defensible than static shared secrets, especially where service accounts and automation spans cloud, CI/CD, and third-party integrations. The 52 NHI Breaches Analysis is useful here because it illustrates how recurring compromise patterns often trace back to weak ownership of lifecycle controls rather than a single broken tool. The practical model is simple: one governance owner defines required control outcomes, IAM builds enforcement, and compliance validates whether evidence matches the policy.

• Define one policy owner for identity lifecycle, access approvals, and exception governance.
• Assign IAM engineering to enforce controls in systems, not to interpret audit requirements.
• Assign compliance to test evidence quality and control consistency, not to run access operations.
• Track metrics for provisioning timeliness, review completion, secret rotation, and orphaned identities.

Where this guidance breaks down is in heavily federated environments with separate M&A, regional, or business-unit IAM stacks, because overlapping control planes make a single operating model hard to enforce without executive mandate.

Common Variations and Edge Cases

Tighter governance ownership often increases coordination overhead, requiring organisations to balance control consistency against local autonomy. That tradeoff is real in regulated groups, multi-cloud estates, and enterprises with separate platform teams, where one central function can become a bottleneck if it is also expected to execute every approval.

Best practice is evolving, but current guidance suggests that the central owner should govern the model while delegated teams execute within guardrails. For example, a platform team may own service account creation, but the governance function still defines naming standards, approval thresholds, review evidence, and revocation triggers. This is especially important for NHI-heavy environments, where Top 10 NHI Issues highlights recurring failures such as excess privilege, weak rotation, and poor visibility. NIST CSF 2.0 can help here, but there is no universal standard for exactly how to split execution between IAM and compliance teams.

The cleanest exception is when compliance is legally required to approve certain controls, such as regulated attestations or segregation-of-duties checks. Even then, compliance should validate and challenge the model rather than own the operational workflow. In practice, ownership works best when the governance function can enforce standards across human and non-human identities without negotiating every control on a case-by-case basis.

Related resources from NHI Mgmt Group

• Who should own identity governance across security and compliance teams?
• Who should own AI agent governance when identity and access are shared across teams?
• Who should own AI agent compliance across security and IAM teams?
• Who should own access ticket governance across IT and IAM teams?