Who is accountable for policy governance when IGA and ABAC are deployed together?

Accountability should sit with the organisation operating both control planes, not with either system alone. Identity governance teams typically own attribute stewardship, workflow approval, and policy oversight, while application and platform owners own enforcement and local exceptions. Clear ownership is essential so access decisions, policy updates, and audit evidence remain traceable across both layers.

Why This Matters for Security Teams

When IGA and ABAC are deployed together, the technical question is usually simple, but the governance question is not. IGA controls who can request or inherit access, while ABAC evaluates conditions at decision time. If accountability is split too loosely, policy drift, conflicting exceptions, and incomplete audit trails follow. NIST CSF 2.0 emphasises governance as a distinct function, which is exactly where this shared model must be anchored: one operating model, two control planes, one accountable owner.

That distinction matters because ABAC often appears to solve access problems that IGA was never meant to enforce in real time. The more dynamic the environment, the more likely teams are to discover that policy ownership, attribute quality, and enforcement logic have drifted apart. NHIMG’s Top 10 NHI Issues highlights how quickly weak lifecycle control becomes an operational risk, especially when approvals, entitlements, and runtime decisions are owned by different groups. In practice, many security teams encounter accountability gaps only after a policy exception has already been used in production.

How It Works in Practice

The cleanest model is to assign governance ownership to the organisation operating both layers, then divide responsibilities by function. IGA teams normally own identity lifecycle policy, attribute stewardship, approval workflows, recertification, and audit evidence. Platform or application owners usually own enforcement points, local policy logic, and any exception handling that is specific to their systems. Security architecture defines the common policy model, while risk and compliance define the approval boundaries. NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev. 5 Security and Privacy Controls both support this kind of explicit governance and accountability structure.

In practice, teams should define:

• a policy owner who approves the ABAC ruleset and material changes;
• an attribute owner for each authoritative data source used in decisions;
• an enforcement owner for each application, gateway, or policy engine;
• a review cadence for stale attributes, overbroad rules, and exceptions;
• an audit trail that links access request, attribute state, policy decision, and final enforcement outcome.

For non-human identities, this becomes even more important because service accounts, workloads, and agents often rely on rapidly changing context. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is a useful reference for tying lifecycle control to governance responsibility. The operational rule is straightforward: IGA governs who may qualify for access, ABAC governs whether access is allowed now, and neither can be allowed to “own” the full decision in isolation. These controls tend to break down when attributes are sourced from unmanaged systems because policy decisions become non-reproducible under audit.

Common Variations and Edge Cases

Tighter policy governance often increases coordination overhead, requiring organisations to balance decision speed against accountability and traceability. That tradeoff becomes visible in shared-platform environments, where a central IGA team may define enterprise rules but a product team needs local ABAC exceptions to keep services running. Current guidance suggests that the exception process should still be centrally governed, even when the enforcement point is local, because otherwise policy drift becomes normalised.

There is no universal standard for this yet, but best practice is evolving toward a single policy authority with delegated enforcement. That matters most where multiple IAM tools, cloud policy engines, and application-layer ABAC rules overlap. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is relevant here because auditors will usually ask who approved the policy, who changed the attribute source, and who can prove the runtime decision was consistent with the approved model. In mixed environments, that answer should not depend on which system returned the final allow or deny.

Related resources from NHI Mgmt Group

• What makes agentic AI an NHI governance issue?
• What is the difference between attack surface management and NHI governance?
• Why is it important to integrate identity and data governance?
• Why is NHI governance critical in the age of AI attacks?