Yes. Authorisation is part of identity governance because it determines how access is granted, reviewed, and explained across systems. PBAC gives IAM and IGA teams a shared decision model that can support least privilege, auditability, and change control without pushing every rule into each application.
Why identity governance should include PBAC
PBAC belongs in identity governance when it is the mechanism that determines who can do what, under which conditions, and how that decision is reviewed over time. In practice, that makes PBAC a governance control as much as an application control. It gives teams a consistent way to express policy, reduce one-off entitlements, and keep access decisions explainable across systems.
That matters because identity governance is not only about account provisioning. It also has to describe, review, and change access decisions in a way auditors, approvers, and administrators can understand. PBAC helps when IAM and IGA basics are being translated into real operating practice, especially where authorisation rules need to stay consistent across multiple applications.
PBAC is most useful when access rules are too dynamic for static role design alone, but still need central oversight. A policy model can express context such as resource type, sensitivity, environment, time, or user purpose without forcing every rule into every application. That makes it a governance-friendly way to support access review, entitlement explanation, and change control.
How PBAC fits alongside RBAC, ABAC, and entitlement review
PBAC does not replace every other access model. It usually sits above or alongside RBAC and ABAC, turning scattered rules into an explicit decision layer. IAM teams should treat it as part of governance when policies are the authoritative source for access decisions, and when role changes, attribute changes, or policy changes must be reviewed as governed access changes rather than app-by-app exceptions.
That is why policy-based access control is especially relevant to authorisation models: it helps teams compare where roles are sufficient, where attributes add precision, and where policy-driven decisions improve consistency. In a governance program, the useful question is not “Which model wins?” but “Which model gives the cleanest control point for review, audit, and least privilege?”
PBAC also changes how access review works. Instead of reviewing hundreds of isolated permissions, teams can review the policy inputs, policy exceptions, and the scope of any policy engine. That is often easier to govern than individual entitlements, but only if the policy set is well owned, versioned, and tied to clear business justification.
What changes for IAM teams when PBAC becomes part of governance
Once PBAC is treated as governance, IAM teams have to own more than implementation. They need policy ownership, policy change control, policy recertification, and evidence that access outcomes still match intent after business or system changes. Without that, PBAC becomes a hidden decision layer that is technically elegant but hard to explain.
That is where lifecycle and review discipline matter. Access reviews and certification work better when policy decisions can be traced back to business purpose, approver intent, and current conditions. If a policy grants access because a user is in a certain function, environment, or approval state, governance must be able to prove that those conditions were valid at the time of access.
Teams should also watch for policy sprawl. PBAC can improve least privilege, but only if the policy set stays intelligible. If policies become too numerous, too nested, or too dependent on undocumented exceptions, governance quality drops and the system becomes harder to attest, harder to troubleshoot, and easier to bypass through informal approvals.
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 CSA Cloud Controls Matrix 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 | PBAC helps enforce least-privilege access decisions through policy. |
| AC-2 — Account Management | PBAC must be governed through account and entitlement lifecycle oversight. | |
| AC-3 — Access Enforcement | PBAC is a policy-driven access enforcement mechanism. | |
| Recommendation — Use AC-6 to bound policy decisions so access stays minimally sufficient. Tie PBAC decisions to AC-2 reviews, provisioning, and revocation workflows. Implement AC-3 so policy decisions are enforced consistently at access time. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | PBAC is an access control method that fits access governance oversight. |
| A.8.5 — Secure authentication | PBAC decisions depend on trustworthy identity signals and access assertions. | |
| Recommendation — Use A.5.15 to define, review, and maintain policy-based access rules. Apply A.8.5 so the identity signals feeding policy decisions are reliable. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | PBAC is part of cloud IAM governance and access decisioning. |
| Recommendation — Use IAM to govern policy-based access decisions across cloud services. | ||
Practitioner Guidance
What to prioritise: Treat PBAC as an identity governance control when it governs persistent access decisions, not merely as an application implementation detail. The first ownership question is who approves policy changes, who reviews policy exceptions, and who can explain an access grant months later.
What to verify: Confirm that policy definitions are version-controlled, reviewable, and mapped to business justification rather than embedded only in application code. If a rule cannot be reviewed outside the application, it is usually too opaque to serve as a durable governance control.
Common mistake: Teams often centralise policy logic but fail to centralise accountability. That creates the illusion of governance while leaving review, exception handling, and evidence collection fragmented across product teams.
Practitioner takeaway: PBAC belongs in identity governance when it becomes a controlled, reviewable decision model for access, not just a technical policy engine. The governance test is whether the access decision can be explained, recertified, and changed without losing control of the entitlement path.
Related resources from NHI Mgmt Group
- Should IAM teams treat GenAI as part of access governance?
- How should security teams implement policy based access control in existing IAM programmes?
- How should security teams implement policy-based access control in existing IAM environments?
- Should identity teams treat proofing as part of access governance?