The best model is a shared accountability structure where IAM or security owns the control framework, development understands implementation impact, and business owners validate policy intent. This arrangement keeps authorization close to the systems it protects while preserving governance. It also reduces the gap between policy design, testing, and operational enforcement.
Why policy ownership in ABAC should be shared, not centralised in one team
ABAC policy decisions work best when the policy authority is shared across security, engineering, and the business. Security or IAM should define the control model and guardrails, engineering should make the rules executable in the platform, and business owners should approve the intent and exceptions. That split prevents policy from becoming either too technical to govern or too abstract to enforce.
In practice, the owner of the policy engine is not the same as the owner of policy meaning. Security owns the standards for attributes, conditions, and exception handling; application teams translate those standards into code or configuration; business owners decide whether the access outcome matches the operational need. This separation matters most when policies affect production access, data sensitivity, or cross-system entitlements.
DevSecOps makes that division more important because policy changes move quickly and can affect release velocity, incident response, and auditability. A policy that is technically correct but not understood by the business is likely to be overridden later. A policy that is business-approved but not implementable will drift into workarounds. Shared accountability is the mechanism that keeps those failure modes aligned.
Where ABAC policy decisions actually belong in the delivery chain
Policy decisions should be made as close to the protected resource as possible, but not in isolation from governance. The practical pattern is to define attributes and decision logic centrally, then apply them locally in the application, API, or policy enforcement layer. That keeps authorization decisions consistent while allowing each product team to account for its own data model, user flows, and operational constraints.
For DevSecOps teams, the most useful split is between policy design, policy implementation, and policy approval. Design belongs with security and IAM because they can keep the model consistent across applications. Implementation belongs with developers and platform engineers because they understand the runtime context. Approval belongs with the business because they can confirm whether a policy reflects real-world entitlements, not just system convenience. You can review IAM and IGA Basics for the broader ownership pattern behind access governance, and Authorisation Models Guide for how ABAC fits alongside RBAC, ReBAC, and policy-based access control.
When the policy boundary is defined this way, teams can test decisions before deployment and preserve traceability after release. That is especially important in environments where policy-as-code is part of the delivery pipeline, because a small attribute change can alter access across many services at once.
What goes wrong when one group owns ABAC policy end to end
If security writes the rules alone, the policy may be governable but not operationally realistic. If engineering owns everything, the policy may be fast but lack clear business intent. If the business owns everything without technical validation, the policy may not account for attribute quality, data freshness, or enforcement limits. Shared ownership reduces all three problems by forcing each team to contribute the piece it understands best.
That model also supports stronger evidence during review. Business owners can confirm the entitlement intent, security can validate the control logic, and engineering can show how the rule behaves in test and production. For a broader view of how policy logic should remain testable and consistent across people and systems, see the IAM and IGA Basics resource and the Authorisation Models Guide.
In other words, the question is not who gets the final say in every case. The better question is which group owns the control, which group owns the meaning, and which group owns the implementation. ABAC fails when those responsibilities are blurred.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | ABAC policy decisions are a least-privilege control problem. |
| AC-3 — Access Enforcement | ABAC is implemented through enforced authorization decisions at runtime. | |
| AC-5 — Separation of Duties | Shared ABAC ownership depends on separating policy design, approval, and implementation. | |
| Recommendation — Apply AC-6 to keep attribute-driven access decisions tightly scoped to business need. Use AC-3 to enforce attribute-based decisions consistently at the point of access. Use AC-5 to split policy authoring, approval, and deployment responsibilities. | ||
| OWASP ASVS | V8 — Authorization | ABAC is an authorization model and needs verifiable access-control behavior. |
| Recommendation — Verify V8 to ensure authorization rules match intended access outcomes. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | ABAC policy ownership is part of access control governance in an ISMS. |
| Recommendation — Apply A.5.15 to define access control ownership and review authority. | ||
Practitioner Guidance
What to prioritise: Define one policy owner for governance, one for implementation, and one for business approval. If all three roles sit with the same team, expect slow drift toward either overblocking or unmanaged exceptions.
What to verify: Make sure every ABAC rule has a named business owner, a technical owner, and a test case that proves the decision matches the intended access outcome. If a policy cannot be explained in business terms and executed in code, it is not ready for production.
Common mistake: Treating ABAC as a security-only control. That usually produces rules that are technically elegant but operationally fragile, because the people closest to the workflow never validated the intent.
Practitioner takeaway: ABAC policy decisions should be shared across governance, implementation, and business intent, but the control must still be owned as a system, not as a committee.
