Who should own AI governance across identity and data controls?

Why This Matters for Security Teams

AI governance across identity and data controls is not a policy exercise that can be handed to one function and forgotten. Identity teams see entitlements and authentication, data teams see classification and movement, and security operations sees alerts and incident patterns. When those views are separated, the organisation cannot answer a basic question fast enough: who approved access, what data was exposed, and whether the same control failed in more than one place?

This gap shows up quickly in non-human identity programs. NHIMG research on the State of Non-Human Identity Security found that only 1.5 out of 10 organisations are highly confident in securing NHIs, which is a clear signal that ownership and execution are still fragmented. The same pattern appears in broader governance guidance from the NIST Cybersecurity Framework 2.0 and the NIST AI Risk Management Framework, both of which assume coordinated accountability across technical domains. In practice, many security teams encounter ownership disputes only after a policy exception, data exposure, or token misuse has already occurred, rather than through intentional design.

How It Works in Practice

Effective ownership starts with a cross-functional control model, not a single approver. Identity and access management should own authentication, service accounts, privileged access, and workload identity. Data security should own classification, masking, retention, and controls that prevent sensitive material from being moved into unsafe contexts. Security operations should own monitoring, detection, incident triage, and reconstruction. Governance then sits above those layers to define policy, resolve exceptions, and measure whether the controls actually work together.

For NHI programs, the strongest operating model is usually a joint one. Teams should map every non-human identity to a business service, a data domain, and an owner for runtime decisions. That means the owner is not just the product manager for the AI feature, but the group that can enforce lifecycle processes for managing NHIs and respond when those identities are used outside expected boundaries. It also means governance must span policy design and evidence collection, including what was accessed, by whom or by what agent, and whether data controls triggered as intended.

• Define one accountable owner for each control plane: identity, data, and monitoring.
• Use shared policy baselines so exceptions are not managed differently in each silo.
• Require joint review for high-risk workflows involving secrets, sensitive data, or autonomous agents.
• Document handoffs so incident response can reconstruct the chain of custody.

NHIMG’s Ultimate Guide to NHIs and regulatory and audit perspectives make the same operational point: governance only works when it is tied to enforceable controls, not committee language. These controls tend to break down in highly distributed environments with multiple cloud platforms, unmanaged service accounts, and shadow AI workflows because no single team can see the full identity-to-data path.

Common Variations and Edge Cases

Tighter ownership often increases coordination overhead, requiring organisations to balance clear accountability against speed of delivery. That tradeoff is especially visible when development teams deploy AI features quickly and assume the platform team will absorb governance tasks later.

There is no universal standard for this yet, but current guidance suggests separating policy ownership from operational enforcement. The governance function should define minimum requirements, while IAM, data protection, and SOC teams each own their controls and reporting. For large enterprises, this may be formalised through a federated model with a central council and local control owners; for smaller organisations, a single security leader may coordinate the three domains, but still cannot own all technical execution alone.

Edge cases matter. Shared service accounts, vendor-managed integrations, and autonomous agents often blur responsibility because one team provisions access, another approves data use, and a third monitors outcomes. In those cases, ownership should follow the control that can actually stop misuse. If the failure is credential exposure, the identity owner is accountable. If the failure is sensitive data leakage, the data security owner is accountable. If the failure is missed detection, security operations must own the gap and the evidence trail. NHIMG’s Top 10 NHI Issues remains a useful reference for those recurring failure modes, alongside the enterprise risk framing in the NIST AI 600-1 Generative AI Profile.

Related resources from NHI Mgmt Group

• What do identity teams get wrong about data governance in AI platforms?
• Who should own governance for workload identity in AI systems?
• Who should own DLP decisions when data, identity, and AI workflows overlap?
• Who should own AI agent governance in an enterprise identity programme?