Who should own identity decisions when business and IT priorities conflict?

Why This Matters for Security Teams

Identity ownership disputes are not just governance debates. They determine who can approve access, who is accountable when privileges expand, and whether access stays aligned to the service being delivered. When business leaders own the outcome but IT owns the mechanism, both sides must stay engaged or the process drifts toward convenience. That drift is how exceptions become normal and controls lose force.

This is especially visible in NHI programs, where service accounts, API keys, and automation often outgrow their original purpose. NHIMG’s Ultimate Guide to NHIs highlights that 97% of NHIs carry excessive privileges and only 5.7% of organisations have full visibility into their service accounts, which makes ownership clarity a control issue, not a paperwork issue. The NIST Cybersecurity Framework 2.0 reinforces that governance and accountability must be explicit, especially where access decisions affect business resilience.

In practice, many security teams only discover ownership gaps after an overprivileged account has already been used in production or a review cycle has stalled because no one could approve the change.

How It Works in Practice

The cleanest operating model separates decision ownership from control ownership. The business service owner owns the risk outcome because that person understands the service, the customer impact, and the tolerance for delay or access. IAM and IT own the policy mechanics, enforcement, and technical execution because they control the identity platform, provisioning workflow, and audit trail.

That split works best when it is codified in a RACI or service ownership register. For each identity change, teams should be able to answer: who requested it, who approved it, who implemented it, and who is accountable if the access outlives the business need. For NHIs, that means mapping every service account, workload credential, or API key to a named service owner and a named technical custodian. NHIMG’s Top 10 NHI Issues is useful here because it shows how weak ownership quickly becomes a rotation, vaulting, and offboarding problem.

• Business owns the justification for access and the acceptable business risk.
• IAM defines policy, review cadence, and approval thresholds.
• IT or platform teams execute provisioning, rotation, and revocation.
• Security validates that exceptions are time-bound and visible.

Current guidance suggests aligning these roles with the service lifecycle, not with organisational hierarchy, because identity decisions tied to the wrong owner tend to survive long after the business need has changed. NIST CSF 2.0’s emphasis on governance supports this approach, but there is no universal standard for ownership matrices yet. The operational test is simple: if no business owner can explain why the access exists, the access is already drifting out of control.

These controls tend to break down in matrixed organisations with shared platforms and outsourced operations because approval paths become slow, ambiguous, and easy to bypass.

Common Variations and Edge Cases

Tighter ownership controls often increase approval overhead, so organisations have to balance speed against accountability. That tradeoff is real in product teams, DevOps pipelines, and shared service environments where one identity may support multiple applications or regions.

For shared NHIs, the best practice is evolving toward primary and secondary owners, with the business owner carrying outcome responsibility and the platform team carrying operational continuity. In outsourced or managed-service scenarios, the external provider may execute changes, but the internal service owner should still approve the access scope and accept the residual risk. Where access is ephemeral or machine-generated, approval can be pre-authorised through policy, but ownership still needs to exist at the service level.

NHIMG’s 52 NHI Breaches Analysis shows that breach patterns often repeat when responsibility is diffuse and no one is accountable for rotation or revocation. That is why ownership should be reviewed whenever a service changes purpose, enters a new third-party dependency, or gains privileged automation. The business owns the “why,” IT owns the “how,” and security verifies that both stay aligned.

Related resources from NHI Mgmt Group

• Who should own identity drift when access no longer matches business need?
• Who should own access decisions in a business-driven IGA model?
• Who should own release decisions for kernel-backed identity controls?
• Who should own access decisions when service management and IAM are connected?