PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties

PR.AA-05 requires you to formally define access permissions and entitlements in policy, then run an end-to-end access lifecycle (request, approval, provisioning, enforcement, and review) that proves least privilege and separation of duties in practice. Operationalize it by standardizing role definitions, enforcing approvals and technical controls, and producing recurring access review evidence.

Key takeaways:

• Write policy that defines who can grant access, how least privilege is applied, and where separation of duties (SoD) is mandatory ¹.
• Run a controlled access lifecycle with traceable approvals, automated provisioning where possible, and hard enforcement through IAM and system controls ¹.
• Perform periodic access reviews and remediate exceptions with documented outcomes you can show to auditors ².

PR.AA-05: access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties requirement is an access governance control. Auditors interpret it as “show me the rules, show me the machinery that enforces the rules, and show me proof the rules were followed and re-checked.” The fastest path to compliance is to treat access as a lifecycle with clear decision points: who requests, who approves, who provisions, what prevents toxic combinations of access, and how you confirm access still makes sense after people change roles or projects.

For a Compliance Officer, CCO, or GRC lead, the operational challenge is less about writing the “least privilege” sentence and more about making it real across identity providers, SaaS apps, infrastructure, databases, and privileged tools. The control fails most often where access is granted “temporarily” and never removed, where service accounts are unmanaged, or where the same person can request, approve, and implement changes that affect money, data, or security.

This page gives requirement-level implementation guidance tied to NIST CSF 2.0 and focuses on producing durable evidence: policies, role/entitlement models, approval records, access review outputs, exception handling, and remediation proof ¹.

Regulatory text

NIST CSF 2.0 PR.AA-05 excerpt: “Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties” ¹.

Operator interpretation: what you must do

• Defined in a policy: You need written rules that define access concepts (permissions/entitlements/authorizations), who can approve and grant them, and how least privilege and SoD are applied ¹.
• Managed: Access changes must follow a repeatable process (joiner/mover/leaver; requests; approvals; provisioning; deprovisioning) with assigned owners and records.
• Enforced: Controls can’t be “paper only.” Access must be technically restricted via IAM, groups/roles, conditional access, PAM, and system-level controls.
• Reviewed: You must periodically validate that users and accounts still have appropriate access, and you must remove or re-justify access that no longer fits the user’s role ².
• Least privilege + SoD: Users get only what they need, and critical duties are split so one person cannot complete a sensitive action end-to-end without independent checks.

Plain-English interpretation (what PR.AA-05 expects)

You are expected to prevent “access sprawl” by designing access so it is:

1. Intentional (defined roles and entitlements),
2. Controlled (approved and provisioned through authorized paths),
3. Constrained (least privilege; SoD barriers; privileged access is limited),
4. Re-checked (recurring access reviews with remediation).

A clean way to phrase the success criteria for PR.AA-05 in an exam:

• “We can show policy, role definitions, approval workflows, and periodic access review evidence for in-scope systems, including how we prevent toxic access combinations.”

Who it applies to

Entities: Any organization operating a cybersecurity program and using NIST CSF 2.0 as a framework or mapped requirement set ¹.

Operational context (where the control must work):

• Corporate IAM (SSO/IdP), directories, HRIS feeds, and MFA/conditional access.
• Cloud consoles, infrastructure management, CI/CD, and secrets systems.
• Databases and data platforms with sensitive or regulated data.
• Financial and operational systems where SoD matters (billing, refunds, purchasing, payroll-like processes).
• Third-party hosted applications where you still own access governance, even if the third party hosts the platform.

What you actually need to do (step-by-step)

1) Define the access governance policy (make it auditable)

Minimum contents you should include:

• Scope: systems, environments, identities (employees, contractors, service accounts).
• Roles and entitlements: how roles are created, who owns them, and naming standards.
• Approvals: who approves what (manager, system owner, data owner), and escalation rules.
• Least privilege rules: default deny, time-bounded privileged access, justification requirements.
• Separation of duties rules: identify “cannot be same person” combinations (examples below).
• Reviews: how often you review access, who performs reviews, required remediation timelines (state these as internal requirements, not as external facts).
• Exceptions: risk acceptance process, expiry dates, compensating controls, and re-approval cadence. Tie the policy to the requirement language so a reviewer can see PR.AA-05 coverage ¹.

2) Build an entitlement model that matches reality

Create an inventory for in-scope systems:

• System name, owner, authentication method (SSO/local), role types, privileged roles, and provisioning method. Then define access at two layers:
• Business roles (Job functions: AP Clerk, HR Analyst, DevOps On-Call).
• Technical entitlements (groups, IAM roles, database grants, admin flags). Map business roles to technical entitlements. This becomes your access catalog.

3) Implement a controlled request and approval workflow

For each access request, require:

• Requester identity and target system/role.
• Business justification tied to a ticket or work item.
• Approver(s): manager plus system/data owner for sensitive access.
• SoD check: confirm the request doesn’t create a toxic combination. Practical SoD examples to encode:
• Cannot both create and approve payments.
• Cannot both deploy code to production and approve the change (or require independent approval).
• Cannot both administer IAM and approve own privileged access.

4) Enforce technically (close the “policy gap”)

Common enforcement controls:

• Centralize auth with SSO and strong authentication.
• Use role-based access control (RBAC) and groups over direct user permissions.
• Use privileged access management (PAM) for admin roles: time-bound elevation, session logging where supported.
• Remove shared accounts; where impossible, wrap with compensating controls (strong authentication, logging, check-out processes).
• Restrict service accounts: no interactive login, scoped permissions, secrets rotation process.

5) Run access reviews that produce usable evidence

Set up reviews by risk:

• Privileged access (admins, root, superusers).
• High-impact systems (finance, sensitive data repositories).
• High-risk identity types (contractors, service accounts). Mechanics:
• Generate current access lists from systems of record.
• Reviewer attests: keep/remove/change; documents justification for keeps.
• Track remediation tickets and closure proof (screenshots, exported reports, change records).
• Record exceptions with expiry and compensating controls. This is where many teams fail PR.AA-05: they “do a review” but can’t prove remediation was completed.

6) Operationalize monitoring and change control

• Detect out-of-band grants (manual admin console changes) via logs or periodic delta reports.
• Require that role changes go through the same approvals as individual access grants.
• Tie mover/leaver processes to HR events so access is removed quickly when roles change.

7) Assign ownership and recurring evidence collection

Name:

• Policy owner (typically Security/GRC).
• Control owner (IAM/PAM owner).
• System owners (accountable for access decisions).
• Access review owners (who runs and who attests). A practical control design is “map PR.AA-05 to policy, procedure, control owner, and recurring evidence collection” ¹.

Required evidence and artifacts to retain

Keep evidence in a way that supports sampling (auditors rarely want everything).

• Access control policy with version history and approvals.
• Role/entitlement catalog (role definitions, owners, risk tiering).
• SoD matrix (toxic combinations, systems covered, detection method).
• Access request tickets with approvals and justification.
• Provisioning/deprovisioning records (IdP logs, HRIS-triggered events, admin console exports).
• Privileged access records (PAM reports, elevation approvals).
• Access review packages: reviewer list, extracts reviewed, decisions, remediation tickets, closure evidence.
• Exception register: rationale, compensating controls, expiry, approver, review outcomes.

Daydream can reduce evidence churn by mapping PR.AA-05 directly to your policy/procedure owners and scheduling recurring evidence pulls so your access reviews and approvals stay audit-ready without ad hoc scramble ².

Common exam/audit questions and hangups

1. “Show me least privilege.” Expect requests for role definitions, permission diffs, and examples where access was denied or reduced.
2. “Who can grant access?” Auditors look for clear approver roles and proof the workflow enforces them.
3. “How do you prevent someone from approving their own access?” You need technical or process controls that block self-approval and document exceptions.
4. “Prove reviews are effective.” They will sample a completed review and ask for remediation closure evidence, not just a sign-off.
5. “What about service accounts?” Examiners often ask because unmanaged service accounts bypass normal joiner/mover/leaver controls.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Policy says SoD, systems don’t enforce it. Fix by implementing SoD checks in the access workflow and adding detective controls (reporting) where preventive controls are not supported.
• Mistake: RBAC exists only in the IdP, not in the application. Fix by aligning app roles with IdP groups and disabling local accounts where feasible.
• Mistake: Access reviews are “checkbox” attestations. Fix by requiring reviewers to provide justification for privileged access and by tracking remediation to closure with tickets.
• Mistake: Exceptions never expire. Fix by putting expiry dates on exceptions and forcing re-approval with documented compensating controls.
• Mistake: Contractors and third-party admins are outside the process. Fix by treating third-party identities as first-class identities: unique IDs, scoped access, and review inclusion.

Enforcement context and risk implications

No PR.AA-05-specific public enforcement cases were provided in the source catalog, so this page does not list cases. Practically, PR.AA-05 maps to high-frequency incident patterns: unauthorized access, fraud enabled by poor SoD, and material control failures where privileged access is not governed. Your risk story to leadership should be concrete: access sprawl increases the blast radius of compromised credentials and increases the chance of undetected internal misuse.

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Publish or update access control policy with explicit least privilege and SoD requirements ¹.
• Identify in-scope systems and owners; build the first system access inventory.
• Stand up an access request workflow for privileged access if you don’t have one.
• Start an exception register with expiry and approvals.

Days 31–60 (implement control paths and evidence)

• Build the role/entitlement catalog for highest-risk systems first.
• Configure approvals: manager + system/data owner for sensitive access.
• Implement PAM or time-bounded admin elevation where possible.
• Run the first formal access review for privileged roles; remediate and retain closure evidence.

Days 61–90 (scale and make it repeatable)

• Expand access reviews to additional systems and non-privileged sensitive roles.
• Add SoD checks to workflows (manual checklist at minimum; automated where supported).
• Implement monitoring for out-of-band access changes and periodic reconciliation.
• Convert ad hoc evidence collection into a recurring calendar with owners and storage locations; Daydream can track control ownership and recurring evidence requests so reviews happen on schedule ².

Frequently Asked Questions

What counts as an “entitlement” for PR.AA-05?

Any permission that changes what a user or account can do: group membership, IAM role assignment, application role, database grant, or admin flag. Treat them consistently in policy and track who approved and who provisioned them ¹.

How do we prove least privilege without a perfect role model?

Start with privileged and high-impact systems, document current roles, and show a reduction path: approvals, time-bounding, and periodic reviews with removals. Auditors accept maturity if the control is operating and the scope is expanding predictably.

What if a system can’t enforce separation of duties?

Document the limitation, implement a compensating control (independent review, logging review, or workflow-based approvals), and record exceptions with expiry. Then include that system in periodic access reviews with extra scrutiny.

Do service accounts need access reviews?

Yes. Service accounts often hold broad permissions and bypass normal HR-driven deprovisioning. Inventory them, assign an owner, scope permissions, and review them like privileged access.

How should third-party administrators be handled?

Give third-party personnel unique identities, time-bound access, and approvals by your system owner. Include them in access reviews and terminate access at contract end or when work completes.

What evidence do auditors ask for most often?

A completed access review package with remediation closure, plus a sample of access requests showing approvals and provisioning logs. Keep everything tied to system owners and dates so sampling is painless.

Footnotes

1. NIST CSWP 29

2. NIST CSF 1.1 to 2.0 Core Transition Changes