Join our Newsletter — 33% off our NHI Course

Who should be accountable for converged identity governance across security and IT teams?

Accountability should sit with a clear business owner, usually within identity, security, or infrastructure leadership, with IT operations responsible for implementation. Converged governance only works when one team owns policy, another executes control changes, and audit or risk functions verify outcomes. Shared accountability without a single owner usually weakens follow through and creates control drift.

Why This Matters for Security Teams

converged identity governance fails when security and IT both think the other side owns the final decision. Identity policy, access review, credential lifecycle, and exception handling all touch operational systems, but accountability cannot be split across two queues without creating drift. The practical question is not who “helps” govern identities, but who is answerable when access is excessive, stale, or not revoked on time.

This is especially visible in NHI programs, where service accounts, API keys, and automation identities outnumber human users and create a much larger control surface. NHIMG’s Ultimate Guide to NHIs notes that 90% of IT leaders say proper NHI management is essential to zero trust, yet 71% of NHIs are not rotated within recommended time frames. That gap usually reflects unclear ownership more than lack of tools.

For broader governance context, current guidance from NIST Cybersecurity Framework 2.0 emphasizes governance and accountability as management functions, not optional coordination. In practice, many security teams encounter control drift only after an audit finding, a leaked secret, or an orphaned account has already exposed the weakness.

How It Works in Practice

The most effective model is a single accountable owner for policy and risk acceptance, usually in identity, security, or infrastructure leadership, with IT operations executing the changes and maintaining the platforms. That owner sets standards for provisioning, approvals, recertification, secret rotation, offboarding, and exception handling. IT then carries out the technical work in IAM, PAM, directory services, vaults, and ticketing workflows.

For NHI governance, the owner should also define how service accounts and automation identities are classified, reviewed, and retired. NHIMG’s Lifecycle Processes for Managing NHIs is useful here because lifecycle ownership is where many programs fail. The accountable function should require evidence that credentials are inventoried, rotated, and revoked, while audit or risk validates the outcome rather than performing the work itself.

  • Policy owner: defines standards, approves exceptions, and accepts residual risk.
  • IT operations: implements joiner-mover-leaver flows, rotation, and deprovisioning.
  • Security or audit: tests control effectiveness, samples exceptions, and reports drift.
  • Business system owners: confirm access need for the application or workload.

Use NIST SP 800-53 Rev. 5 Security and Privacy Controls as the control baseline and map ownership to specific control families so reviews do not become informal discussions. This guidance breaks down in highly federated environments where cloud platforms, product teams, and regional IT groups each control different parts of the identity stack without a single delegated decision-maker.

Common Variations and Edge Cases

Tighter accountability often increases coordination overhead, requiring organisations to balance clear ownership against local autonomy and delivery speed. That tradeoff is real, especially in mergers, shared services, and product-led engineering environments where identity tooling is fragmented.

There is no universal standard for this yet, but current guidance suggests the accountable owner should sit as close as possible to enterprise identity governance, not as a committee chair. Committees can advise, but they rarely close gaps on their own. If security owns the policy and IT owns implementation, then both teams need a formal RACI that defines who approves exceptions, who tracks remediation, and who escalates overdue actions.

Edge cases appear when privileged access, cloud platform engineering, and NHI governance overlap. In those cases, a single owner still matters, but execution may be delegated to separate operational teams. NHIMG’s Ultimate Guide to NHIs and Top 10 NHI Issues both reflect the same pattern: when ownership is split, secrets linger, reviews stall, and nobody is clearly accountable for the final risk state. The model works best when one named executive owns the outcome and the rest of the organisation is measured against it.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST CSF 2.0 GV.OC Governance outcomes require a named owner and clear accountability.
NIST SP 800-63 AAL Identity assurance depends on lifecycle controls and defined responsibility.
NIST AI RMF GOVERN AI risk governance requires explicit ownership, oversight, and escalation paths.
NIST Zero Trust (SP 800-207) PL.1 Zero Trust requires policy-driven identity decisions with accountable administration.
OWASP Non-Human Identity Top 10 NHI-01 NHI governance fails without ownership of lifecycle, rotation, and revocation.

Assign one executive owner for identity governance and measure security and IT against that accountable outcome.