When should organisations prioritise PBAC over per-system rules?

Prioritise PBAC when the same NHI must be governed across multiple clouds, applications or platforms and inconsistent local rules are creating control drift. Central policy is most useful when the main problem is fragmentation, but it only works if policy ownership and change control are disciplined.

When PBAC is the better control model

PBAC becomes the stronger choice when the organisation needs one policy decision layer to govern the same NHI across many systems, rather than relying on each platform to interpret access differently. That shift matters most when permissions are changing often, the environment is hybrid, or teams need a consistent way to express conditions such as environment, purpose, risk or workflow state.

Per-system rules can work in a single product boundary, but they tend to fragment as soon as the same workload or service credential is reused elsewhere. PBAC helps reduce that duplication by moving the decision logic into policy, which makes it easier to keep access intent consistent while allowing different enforcement points to apply the same rule set.

A useful way to think about the choice is whether the organisation is managing access as isolated local configuration or as a shared governance problem. If each application team is inventing its own exceptions, the access model is already drifting away from the business intent. PBAC is designed to pull that intent back into one place, provided the policy model is actually owned and maintained as a governed control plane.

Why per-system rules stop scaling

Per-system rules usually fail because they encode decisions in too many places, creating inconsistency, blind spots and hard-to-audit exceptions. That problem becomes visible when the same NHI has different rights in different clouds, different app teams apply different naming conventions, or a temporary exception in one place quietly becomes permanent somewhere else.

This is where a central authorisation model is useful: it turns access from a set of local settings into a policy problem that can be reviewed, tested and changed consistently. NHIMG’s IAM and IGA Basics is a helpful reference point for the broader governance distinction between access assignment, entitlement review and policy-driven control.

PBAC also gives security teams a better chance of spotting when policy drift is creating risk. A local rule that seems harmless in one platform can become excessive privilege when copied into another environment, and the organisation may not notice until an audit, an incident or a failed access review exposes the gap.

What to get right before centralising policy

PBAC only improves control when the policy layer is clear enough to govern and simple enough to operate. If policy ownership is ambiguous, or if teams can make ad hoc changes without review, centralisation just moves inconsistency from the application layer into the policy layer.

The most important design question is whether the policy expresses a stable business rule or merely re-creates a system-specific exception in a more complex form. PBAC works best when the rule is something the organisation genuinely wants to apply consistently, such as environment segregation, purpose limitation, approval state or workload trust conditions. It is a poor fit when every system needs a one-off exception that no common rule can reasonably represent.

For teams comparing policy options, Authorisation Models Guide is useful for understanding where PBAC sits relative to RBAC, ABAC and related models. If the access decision depends on context rather than just a static role, PBAC is usually the cleaner governance layer.

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 is used to reduce access scope across systems.
	IA-5 — Authenticator Management	PBAC decisions often depend on governed credentials and trust inputs.
Recommendation — Apply AC-6 to keep policy decisions aligned with least privilege. Use IA-5 to govern credentials that feed policy-based access decisions.
ISO/IEC 27001:2022	A.5.15 — Access control	PBAC centralises access decisions under a governed access-control model.
	A.8.5 — Secure authentication	Policy decisions rely on reliable authentication signals before authorisation.
Recommendation — Define and enforce central access-control rules through A.5.15. Verify authentication strength before allowing policy-driven access.
CSA Cloud Controls Matrix	IAM — Identity & Access Management	PBAC is a cloud access-governance pattern across services and platforms.
Recommendation — Use IAM controls to centralise access policy across cloud platforms.

Practitioner Guidance

What to prioritise: Move to PBAC first where the same access rule must be applied across multiple enforcement points and local exceptions are already causing drift. Keep per-system rules only where the application truly has a narrow, self-contained access boundary.

What to verify: Confirm that policy ownership, approval, testing and rollback are defined before consolidation. If no team can explain who may change policy, how it is reviewed, and how conflicts are resolved, the model is not ready for centralisation.

Common mistake: Treating PBAC as a syntax change rather than a governance change. The control improves consistency only when teams also standardise how exceptions are requested, approved and retired.

Practitioner takeaway: Choose PBAC when the main risk is inconsistent access intent across systems, but only if the organisation is prepared to run policy as a managed control, not a loose configuration layer.