What PR.AA-05 access permissions and least privilege require
PR.AA-05 asks an organization to define access permissions, entitlements and authorizations in policy, then manage, enforce and review them under least privilege and separation of duties. If an auditor, customer questionnaire or contract asks how you control who can do what, PR.AA-05 is the Subcategory that expects a written rule, a working enforcement point and proof that someone checks the result on a schedule. In NIST CSF 2.0 it sits in the PROTECT Function under the Identity Management, Authentication, and Access Control (PR.AA) Category. It takes over CSF 1.1 PR.AC-4 under a new identifier and absorbs parts of CSF 1.1 PR.AC-1 and PR.AC-3, so teams that mapped the older identifiers will need to re-point their evidence.
The hard part is rarely writing the policy. Permissions accumulate when people change roles and nobody removes the old grants, role catalogs grow until no one can explain what a role allows, and access systems often have no named owner who must approve each entitlement. NIST's Implementation Examples for PR.AA-05 point at periodic review of logical and physical privileges, review on role change or departure, use of attributes such as location, time and endpoint health in authorization decisions, and review of separation of duties for critical functions. Confirm with your own identity and cloud teams which of these attributes your platforms can actually evaluate before you promise them in a policy.
For an assessment, prepare three artifacts: the permission model (roles, entitlements and who owns each), a sample of enforcement records showing the model is applied, and review records with reviewer names, decisions and dates. Open-source tools such as midPoint can run access certification campaigns in which designated reviewers keep, change or revoke each access item within a set timeframe, which produces that review trail. Ask any implementation partner to show how its scope covers the systems holding sensitive data, and ask your independent auditor which sample sizes and review intervals they expect before you set them.
Which systems, accounts and teams PR.AA-05 covers
PR.AA-05 applies wherever access permissions are granted, so its scope reaches well beyond the user directory. The cards below cover the systems, accounts and teams that usually fall inside it, and the scoping decisions that determine how much work the assessment will involve.
Identity sources and directories
Every place that holds or issues identities is a source of permissions, including the corporate directory, local directories on servers, and any separate identity provider. Decide which one is the authoritative source for each population of users. If two sources can both grant access, a reviewer has to check both, and a leaver removed in one but not the other keeps access. Confirm which source feeds each application and whether group membership flows one way only.
Applications and internal systems
Business applications, admin consoles and internal tools each hold their own roles or permission models. Inventory which ones enforce permissions locally and which delegate to a central identity provider through single sign-on. Applications that keep local accounts outside the central model need their own review cycle. Ask each system owner which roles exist, who assigns them and whether roles can be combined into broader rights.
SaaS entitlements and cloud roles
Scoping SaaS seats, administrator roles and cloud IAM roles is the decision that most often changes the size of the work. Including them means reviewing permissions inside platforms you do not operate, so the evidence depends on exports or vendor reports. Excluding them leaves a common route for access accumulation. Record the decision in writing, name the owner of each cloud account and confirm which exports each platform can produce.
Privileged and administrator accounts
Accounts that can change configurations, read sensitive data or grant access carry the most risk and usually need the shortest review cycle. Track administrator and break-glass accounts separately from standard user accounts so that their approvals, elevation paths and usage are visible. Confirm that each privileged role is assigned to a named person and that the reason for elevation is recorded.
Service and automation accounts
Service accounts, API keys and pipeline credentials often have broad rights, no named owner and no interactive login to disable when a project ends. Include them in the inventory, record the owning team for each, and check that their permissions match the single job they perform. Ask whether any shared credentials exist and whether they can be replaced with individually scoped ones.
Data stores and third-party access
Databases, file shares and backup repositories hold data whose access is controlled by permissions set outside the applications that use it. Vendors, contractors and managed service providers often receive access through their own accounts or through remote tools. Scope both: list the data stores that hold sensitive records and the external parties with accounts, then confirm who approves each grant and how it ends. Physical access points are a separate control, PR.AA-06, so keep them out of this review unless your scope says otherwise.
How an assessor tests access permissions and least privilege
This table sets out how an assessor typically tests each part of PR.AA-05, from the written access policy through enforcement, reviews, minimum-necessary privilege and separation of duties. Read each row as a test step with the evidence the assessor will ask for and the findings that most often cause a gap. The main takeaway is that a policy on paper does not pass the test unless the organization can show accounts and entitlements matching that policy on a given date.
| Test area | Evidence requested | Common findings |
|---|---|---|
| Policy definition | Written access control policy naming who approves access, how roles are defined and how permissions map to them, with version and approval history | Policy exists but does not cover service accounts, shared accounts or privileged access; roles are undefined |
| Enforcement sampling | Sample of user and service accounts with their entitlements, the approval record for each, and the directory or identity platform configuration that grants them | Accounts granted outside the approval workflow; direct permissions bypassing roles; approvals missing or dated after access began |
| Periodic access review | Review schedule, completed review records showing reviewer, decision (keep, change or revoke) and the revocations carried out afterward | Reviews performed but never acted on; reviewers lack context; reviews skip privileged or inherited access |
| Role-change and departure review | Records of access changes tied to HR transfers and terminations, with dates compared to the effective change date | Movers keep prior-role access; leavers' accounts remain active or dormant; no link between HR events and access tickets |
| Stale and dormant accounts | Report of last sign-in or last use per account, with the owner and disposition for accounts inactive beyond the organization's own threshold | Unowned accounts; contractor accounts past contract end; test or migration accounts still enabled |
| Minimum-necessary privilege | Privileged role list, justification for each administrator grant, and evidence of time-limited or just-in-time elevation where used | Standing administrator rights with no owner; broad wildcard permissions; admin rights granted for convenience |
| Separation of duties for critical functions | Matrix of critical functions with conflicting combinations, and evidence that conflicts are blocked or compensated by a documented control | Same person can request, approve and execute payments or production changes; conflicts identified but not recorded as accepted risk |
| Attribute-based decisions | Documented attributes used in authorization (for example location, time or endpoint health), their configuration and test results showing denials when conditions are not met | Attributes defined in policy but not enforced in the platform; attribute sources not maintained or trusted |
How to implement PR.AA-05 in sequence
This sequence turns the PR.AA-05 outcome into working practice: an inventory of who holds what, a written permission policy with named owners, separation rules for critical functions, enforced least privilege, and recurring reviews that catch access accumulation after role changes and departures.
Inventory entitlements, roles and privileged access
The identity or IT team lists every account type in scope, including workforce users, service accounts and administrative access, and records the roles, groups and direct grants that give each identity its rights. Application owners confirm which entitlements exist in their systems, including local and physical access where it applies. Done means one inventory exists with each entitlement tied to a system, an identity source and a named business owner, and gaps such as shared or orphaned accounts are logged for follow-up.
Define the permission policy and owners
Leadership and the control owner write the access permission rules: who may request each role, who approves it, what minimum access each job function needs, and which privileged rights require extra approval. Each system and role gets a named owner accountable for approving and reviewing its permissions. Done means the policy is approved, owners are recorded in the inventory, and the approval path for a new or changed permission is documented and testable.
Map critical functions for separation of duties
Security, finance, development and operations leads identify functions where one person acting alone could cause material harm, such as creating and approving payments, or deploying code and approving its release. The team records which role combinations conflict and who must sign off on any exception. NIST's Implementation Examples for PR.AA-05 explicitly call for reviewing separation of duties for critical functions. Done means a conflict matrix exists, each conflict is either removed or covered by a documented compensating control, and the matrix is attached to the policy.
Enforce least privilege through roles and attributes
Engineers restrict each role to the minimum permissions in the policy and, where the platform supports it, add attribute conditions such as location, time window and endpoint health to authorization decisions. Privileged roles are limited to the systems and periods that need them. Done means test accounts for each role confirm that out-of-scope actions are denied, and the configuration is stored under version control so the enforced state can be shown to an assessor.
Set review cadence and change triggers
The control owner sets how often each role's members are reviewed and defines event triggers that force an immediate review, including role change, transfer, departure and a privilege escalation. The identity team wires these triggers into the joiner, mover and leaver workflow so that changes in the HR or directory source reach the access system. Done means the cadence and triggers are written into the policy and the workflow has been tested with a sample transfer and a sample departure.
Run the first access review and act on results
Each role owner receives the list of identities holding their role and the entitlements attached to it, then decides to keep, change or revoke each item. Revocations are executed in the source systems, not only in a report. Tools such as midPoint can route certification campaigns to designated reviewers within a set timeframe, which helps counter access accumulation. Done means every item has a recorded decision, revocations are verified in the target systems, and the reviewer sign-offs are retained as evidence.
Retain evidence for the assessor
The compliance lead collects the approved policy, the inventory, the conflict matrix, configuration exports, trigger test records and signed review results into one evidence set mapped to PR.AA-05. The organization owns this set and its accuracy. An independent assessor, not DeployOpen or any implementation partner, decides whether the evidence supports a conclusion. Done means the evidence set is indexed, dated and stored where the assessor can access it, and each later review cycle adds to it.
Where attribute-based decisions fit alongside roles
Role-based access control assigns permissions to a role, then assigns people to roles. For many systems this is the simplest way to show that access follows the job. It works well when job functions are stable, the number of roles stays manageable and the permissions attached to each role are narrow enough to justify on their own. The main cost is upfront role design and ongoing maintenance as duties change.
- Clear job mapping: Roles match distinct job functions that a manager can confirm without technical knowledge.
- Manageable role count: A small, documented role catalog is easier to review than hundreds of one-off grants.
- Simple evidence: Role definitions, assignment records and review sign-offs usually satisfy an assessor for low-variation access.
- Role creep risk: Without periodic review, users accumulate roles as they change jobs, which the PR.AA-05 Implementation Examples address through reviews on role change.
- Separation of duties: Conflicting roles must be identified explicitly, because a role model does not detect conflicts unless someone defines the rules.
Confirm with your own assessor whether your role catalog, assignment records and review cadence are enough for the systems in scope before adding more complexity.
Attribute-based decisions evaluate attributes of the user, resource, action and environment at the moment of access. PR.AA-05 names attributes such as location, time and endpoint health as inputs to authorization, so the decision can change when conditions change. This matters most where the same role would be unsafe from some locations, at some hours or on some devices. For example, an administrator role might be allowed from managed workstations on the corporate network but denied from an unmanaged personal device. This is an illustrative case, not a prescribed design.
- Sensitive data by location: Access to regulated data may depend on network range, country or a managed device.
- Time-bound elevation: Privileged access may be allowed only during approved change windows.
- Endpoint health: A device that fails posture checks may lose access to sensitive resources.
- Physical and logical linkage: The Implementation Examples also reference physical privileges, so badge or site attributes may belong in the same policy.
- Context that is hard to prove: Attributes that cannot be reliably sourced or logged weaken the decision and should not be relied on.
Before adding a context rule, confirm the attribute source, the logging of each decision and who approves the rule.
The cost of role-based models is mostly in role engineering and review, which recurs as the organization changes. Attribute-based models add policy design, attribute sourcing, integration with identity and device systems, and test cases for each rule. Effort rises with the number of attributes and the number of systems that must honor the same policy. No fee or duration is stated here because the scope of each environment drives the estimate.
- Policy design effort: Each attribute rule needs an owner, a rationale and a documented exception path.
- Integration effort: Identity providers and access gateways must supply attributes reliably, which may require connectors or configuration work.
- Test effort: Positive and negative test cases should show that access is granted and denied as written.
- Recurring maintenance: Attribute sources, device posture tools and policy rules change over time and need periodic retesting.
- Quote inputs: Ask for the list of systems in scope, the attributes to be used, the logging design and the test plan as separate line items.
Ask any implementation partner to show the scope and deliverables in writing before work starts, since most engagements are fixed-scope.
An assessor will want to see the policy, the mechanism that enforces it and the evidence that it operates. Role models are explained through role catalogs and assignment records. Attribute-based models require the rule set, the attribute sources, decision logs and test results showing that the rule behaves as documented. The explanation should be readable by someone who did not design the system.
- Written policy: Define which decisions use roles, which use attributes and why.
- Decision records: Logs should show the attributes evaluated and the outcome for sensitive resources.
- Test evidence: Keep results from tests that confirm denial when a device fails posture checks or access occurs outside the permitted window.
- Periodic review: Access certifications, such as those in midPoint, can show reviewers deciding whether to keep, change or revoke access items.
- Ownership: Name the owner of each attribute source and each rule.
Ask the assessor which evidence format they accept for attribute decisions before you build the logging.
Evidence that satisfies PR.AA-05 and how to keep it current
PR.AA-05 is outcome-based, so an assessor looks for records showing that permissions were defined, enforced and reviewed over time, not a single snapshot. The artifacts below connect policy to configuration to decisions, and each one needs a named owner and a refresh cadence so it is still accurate when someone asks for it.
Access control policy
The written policy states who approves access, how least privilege and separation of duties are applied, and how often permissions are reviewed. It is the baseline every other artifact is measured against. Check that it names an owner, carries a version and approval date, and covers both logical and physical privileges. Review it on a set schedule and after any major change to identity systems or org structure.
Entitlement and role inventories
An export of every account, group, role and application entitlement, with its source system and last-changed date. This is the population that reviews and sampling draw from, so an incomplete inventory undermines every later test. Schedule a recurring export from each directory, identity provider and key application, store the output with a timestamp, and reconcile record counts against the previous run to catch gaps.
Role definitions and privilege mapping
Role definitions state which entitlements each job function receives and which privileged actions require extra approval. They show the minimum necessary access the policy promises. Keep a change log for each role, record who approved each edit, and confirm that roles still match current job descriptions. Drift between the role catalog and actual assignments is one of the most common findings in access reviews.
Access review records
Each review campaign should record the reviewer, the items presented, the decision to keep, change or revoke, and the date of each decision. Designated reviewers deciding within a set timeframe is the pattern that counters access accumulation. Keep the completed campaign export, the reminders sent, and the evidence of any escalation for overdue items. Assessors test whether decisions were made, not only that a review happened.
Removal and revocation tickets
Tickets prove that access was removed when a role changed or a person left. Link each ticket to the triggering event, the revoked entitlements, the executor and the verification step. Compare departures from the HR feed against revocations on the same day, and report any account still active after its owner left. This artifact shows the review decisions were actually enforced.
Separation-of-duties matrix and exceptions
The matrix lists incompatible role combinations for critical functions, such as requesting and approving payments. Each approved exception needs a named business owner, a compensating control, an expiry date and a review date. Refresh the matrix when roles change and export the exception register on the same recurring schedule as the entitlement inventory, so every exception can be traced to a current approval.
What meeting PR.AA-05 costs in money and effort
This table compares the main cost components of meeting PR.AA-05, showing who is paid, whether each cost is one-time or recurring, and what drives it up or down. Use it to frame a quote request, since no price list applies and the figures depend on your own environment and written scope.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives the cost |
|---|---|---|---|
| Role model design | Internal architects and IAM owners, with an implementation partner if engaged | One-time, revisited on major role changes | Number of job functions, business units and roles that must be defined in policy |
| Entitlement cleanup | Internal application owners, with partner support for extraction and analysis | One-time, then reduced by periodic reviews | Accumulated access, number of applications and directories holding local accounts |
| Identity source integration | Implementation partner or internal platform team | One-time per source, plus upkeep when sources change | Number of identity sources, such as directories, HR systems and applications using local accounts |
| Separation-of-duties analysis | Internal risk and compliance staff, with technical support for conflict rules | One-time baseline, then recurring when roles change | Count of critical functions, such as payments, production changes and privileged administration |
| Access review campaigns | Designated reviewers in each business unit, plus the team that runs the campaign | Recurring, at the frequency your policy sets | Number of reviewers, access items per campaign and how much evidence each reviewer needs |
| Evidence upkeep | Internal compliance team, with partner support if automated exports are built | Recurring | Number of systems that must produce access records and how often evidence is pulled |
| Auditor sampling and walkthroughs | Independent auditor or assessor, billed under their own engagement terms | Recurring with each assessment cycle | Sample sizes the assessor selects and how quickly your team produces complete records |
| Testing of access controls | Internal testers or a security testing provider under a written scope | Recurring, or one-time for a targeted test | Number of applications in scope, privileged paths and whether testing covers role changes and departures |
| Software licenses for open-source identity tools | No license fee for the open-source components themselves; infrastructure and staff time still apply | Recurring infrastructure, optional support contracts | Hosting footprint and whether you buy vendor support for the chosen components |
Open-source tools that produce PR.AA-05 evidence
Three open-source platforms can each produce a different part of the evidence for PR.AA-05: midPoint runs access certification campaigns, authentik controls which applications accept sign-in and under what identity source, and FreeIPA centralizes accounts and single sign-on for Linux and UNIX hosts. midPoint is licensed under EUPL-1.2+, authentik under MIT and FreeIPA under GPL-3.0-or-later. Licensing affects how you may modify and redistribute the software, so have legal counsel review the terms that apply to your deployment before you build on any of them.
midPoint certification campaigns are the closest match to the review obligation in PR.AA-05. Designated reviewers decide within a set timeframe whether to keep, change or revoke access items such as role assignments, and the campaign outcome is recorded. Those decision records are what an assessor will ask to see, along with the reviewer list and the scope of each campaign. Confirm in your own environment that the campaign history, reviewer identities and revocation actions are retained in a form you can export, and that the reviews cover both logical and physical access if your policy requires it. Also confirm whether separation-of-duties conflicts can be flagged for review, since the supplied documentation describes reviews countering access accumulation but does not confirm a specific conflict-detection feature.
authentik and FreeIPA address the enforcement side. authentik acts as an identity provider through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so each application delegates sign-in to it, and access bindings can be reviewed as a single source for who may reach which application. FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC, which helps keep host-level accounts and group membership in one directory. Before you rely on either for evidence, test whether a removed group membership or deactivated account actually stops access in each connected application and host, and keep a dated export of those bindings for each review cycle.
Who owns PR.AA-05 and what can be outsourced
PR.AA-05 is a management outcome, so the organization keeps the decisions about who may access what. Implementation partners, auditors and the organization each hold a different part of the work, and the boundaries between them matter as much as the work itself.
Access policy and approvals
The organization owns the access policy that defines permissions, entitlements and authorizations, and its named owners approve who receives them. An implementation partner can draft the policy structure and approval workflow, but the approvers must be the organization's own managers and data owners. Check that the policy names an accountable owner for each system and role, and that approvals are recorded in a system the organization controls.
Role models and entitlement design
An implementation partner can design the role model, map job functions to entitlements and configure least-privilege defaults in the identity platform. The organization still validates that each role matches real job duties, since a role built from assumptions carries excess access into every account assigned to it. Ask for the role catalog as a documented deliverable, with owners and the systems each role touches.
Technical enforcement and configuration
Implementation work covers configuring identity providers, directory groups, policy engines and privileged access settings so that permissions are enforced by the systems rather than by convention. Partners can harden these configurations and document them, but production changes stay under the organization's change control. Confirm who holds administrative credentials to the platform after handover.
Access review campaigns and evidence
Periodic access reviews, and reviews triggered by role change or departure, produce much of the evidence an assessor asks for. A partner can set up review campaigns, reviewer assignments and export reports, but reviewers must be people the organization designates, and decisions to keep or revoke access belong to them. Retain the completed review records, not only the tooling configuration.
Separation of duties analysis
Reviewing separation of duties for critical functions is an analytical task that depends on knowledge of business processes. An implementation partner can build conflict rules and report on conflicting entitlements, while the organization decides which combinations are unacceptable and accepts any residual risk. Ask for the conflict rule set and the owner who signed off on each rule.
Independent testing and reporting
An independent auditor, assessor or certification body tests whether PR.AA-05 is operating, and only that party issues an assessment report or certificate. DeployOpen prepares systems, controls and evidence for that testing but does not issue audit reports, attestations or certifications, and it should not perform the audit of work it implemented. Confirm the auditor's independence from the implementation team before work begins.
How much effort does PR.AA-05 take and can we do it in-house?
What drives the effort and cost of meeting PR.AA-05?
The main driver is how many systems, applications, cloud accounts and physical areas hold access decisions that must be defined, enforced and reviewed. Effort rises with the number of roles, the number of exceptions to standard roles, how many systems lack central identity integration, and how much of the access history is undocumented. Cost components are staff time for policy and role design, engineering time for enforcement and logging, and recurring time for access reviews. NIST does not publish a price or effort estimate for PR.AA-05, so ask any provider to break its quote into these components before you compare numbers.
How long does it take to implement least privilege access?
No duration for this work is established in the sources available to this page, so treat any timeline as something to confirm in writing. The schedule usually depends on how many systems need role-based access, whether a central identity provider already exists, and how many access reviews must be completed before the first cycle is signed off. Ask for a phased plan that separates policy and role definition, enforcement on priority systems, and the first review cycle, with a named owner and a start and end date for each phase.
What does the work need from our internal team?
The work needs people who own business roles, people who administer identity and access systems, and a sponsor who can approve policy. Business owners must confirm which access each role needs, because least privilege cannot be designed by IT alone. Identity administrators must be able to change group memberships, application roles and directory settings. Security or compliance staff must define the review cadence and keep evidence. Expect the internal team to spend regular time in workshops and reviews, not only during initial setup.
Can we implement PR.AA-05 in-house without outside help?
Yes, an organization can implement PR.AA-05 with its own staff, because the organization owns its controls and the CSF does not require an outside party. The usual constraints are internal capacity and skills. In-house teams often need to cover role engineering, enforcement across several platforms and recurring reviews at the same time. Assess whether your identity administrators have time for this alongside daily operations, and whether someone can maintain the evidence trail. If the answer to either question is uncertain, consider a scoped engagement for the specific gaps.
When is outside help worth paying for on access permissions?
Outside help is worth considering when the access model spans many legacy systems, when identity tooling must be deployed or integrated, or when a customer or regulator asks for evidence that your team cannot produce quickly. An implementation partner such as DeployOpen can plan, implement, customize, integrate and document self-hosted open-source identity components inside your infrastructure, and can prepare access review evidence. It does not decide whether your access model is adequate, and it does not issue any report or certificate. Those judgments belong to your leadership and to an independent assessor where one is required.
What should a fixed-scope quote for PR.AA-05 include?
A fixed-scope quote should name the systems and identity sources in scope, the roles or entitlement types to be defined, the enforcement points to be configured, and the review cycles to be set up. It should list each deliverable, such as an access policy, a role catalog, configuration records, review templates and evidence packs, and state who approves each one. It should also state what the client must provide, such as system access, role owners and decision timeframes, and what is excluded. Timelines and fees should appear only once the scope is agreed in writing.
Which access review tools can help run recurring reviews?
Open-source identity governance tools can run access certification campaigns, in which designated reviewers decide whether to keep, change or revoke access items such as role assignments within a set timeframe. midPoint is one such platform, licensed under EUPL-1.2+, and its documentation describes how these campaigns counter access accumulation and support segregation of duties. Confirm with the vendor which features your version offers and whether they fit your identity sources. Tool selection changes effort, but the review decisions still require named owners.
What ongoing work continues after the first access review?
Least privilege is recurring work, because roles change, staff move and new applications appear. The ongoing costs are periodic reviews, reviews triggered by role changes or departures, updates to role catalogs, and maintenance of the evidence trail. NIST's implementation examples for PR.AA-05 describe periodic reviews of logical and physical privileges and reviews on role change or departure, so plan these as standing operations. Ask any provider whether support, upgrades and continuous testing are covered by a separate retainer.
Primary sources for PR.AA-05
Start with the primary source itself. The Core appendix of NIST CSWP 29 contains the official wording of PR.AA-05, which is the only text an assessor will treat as the Subcategory outcome. Read it alongside the framework's Organizational Profile and Tier guidance so that the access outcome is tied to your own current and target state rather than to a generic checklist. The Core is a short, stable document, so read the Subcategory as written and avoid paraphrasing it into a control requirement before you have checked the wording against the source. Confirm in the PDF that the Subcategory identifier and the Implementation Examples you plan to cite match the version your organization adopts.
The NIST CSF 2.0 Reference Tool export is the place to find the Implementation Examples and informative references for PR.AA-05 in machine-readable form. Export the rows for this Subcategory and build your evidence register from them: the four Implementation Examples describe periodic and role-change reviews, attribute-based decisions, minimum necessary privileges and separation of duties for critical functions. Each informative reference, including the SP 800-53 Rev. 5.2.0 access control controls and the ISO/IEC 27001:2022 Annex A entries, points to a different evidence set, so record which one your auditor or customer asks for. Treat the export as a working tool, since NIST updates informative references separately from the Core.
The CSF 1.1 to CSF 2.0 Core transition spreadsheet matters if your access controls were documented against the earlier framework. According to NIST's transition material, PR.AA-05 takes over CSF 1.1 PR.AC-4 under a new identifier and absorbs part or all of PR.AC-1 and PR.AC-3. Use the spreadsheet to find where your existing access review and permission evidence now sits, and to confirm that no CSF 1.1 access outcome has been dropped from your mapping. Organizations with a long history of role-based access documentation often find that the old identifiers appear in policies, tickets and audit reports, so update those references before the next assessment cycle. For small organizations, the NIST SP 1300 Small Business Quick-Start Guide (February 2024) cites PR.AA-05 when it suggests limiting access to sensitive information to employees who need it for their jobs. It is a practical starting point for a first access review, though it does not replace the Core or the Reference Tool for a full program.
How DeployOpen scopes and prepares PR.AA-05 evidence
DeployOpen helps organizations prepare the access permission model, enforcement points and review records that PR.AA-05 Access permissions and least privilege calls for. Work runs inside the client's own infrastructure on self-hosted open-source platforms, and the organization keeps ownership of its policies, decisions and controls.
How we scope
- Engagements are fixed-scope, with systems, roles, deliverables and timelines agreed in writing before work starts.
- The written scope lists which applications, directories, cloud accounts and physical access systems fall under PR.AA-05.
- Scope also names who approves access policy and who performs each periodic access review.
How we build
- We configure role-based and attribute-based access rules on self-hosted identity platforms within the client's environment.
- We set up access certification campaigns with named reviewers, decision deadlines and records of keep, change or revoke outcomes.
- We test least privilege and separation of duties rules for critical functions before the client relies on them.
How we hand over
- We document permission models, role definitions, review procedures and configuration settings so the client's staff can operate them.
- We deliver evidence packs such as exported role assignments, review logs and change records mapped to the PR.AA-05 outcome.
- Independent auditors or assessors decide whether the evidence is sufficient. DeployOpen prepares the evidence but does not issue reports or certifications.
How we support
- Ongoing support, upgrades and continuous testing of access controls are available as retainers.
- Ask us to confirm which access review cycles and role changes the retainer covers before signing.
- Retainers can cover periodic reruns of access reviews and updates when joiner, mover and leaver processes change.
