AC-6(7): Review of User Privileges

AC-6(7): Review of User Privileges requires you to regularly review the privileges assigned to defined users (for defined systems) and validate that each privilege is still needed. Operationalize it by setting a review cadence, scoping in-scope systems and privileged roles, generating authoritative access reports, collecting manager/system owner attestations, and removing or downgrading unnecessary access with ticketed evidence. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Key takeaways:

• Define scope and cadence, then run repeatable privilege review cycles with clear owners and due dates. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Reviews must validate business need, not just confirm the user is active; record decisions and remediate exceptions. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Audit success depends on evidence: access snapshots, attestations, exception approvals, and completed removal tickets. (NIST SP 800-53 Rev. 5 OSCAL JSON)

AC-6(7): review of user privileges requirement sits inside the broader “least privilege” expectation: users should have only the access needed to do their jobs, and that access should be revalidated as jobs, systems, and risks change. The control enhancement is narrow but examiners assess it as a strong signal of operational discipline because it forces you to reconcile three things that frequently drift apart: HR reality (who works here), identity reality (who can log in), and authorization reality (what they can do once inside). (NIST SP 800-53 Rev. 5)

For a Compliance Officer, CCO, or GRC lead, the fastest path is to turn AC-6(7) into a recurring, time-bound workflow: (1) define who and what is in scope, (2) produce a reliable list of privileges, (3) route those privileges to the right reviewers, (4) require a business-need decision for each high-risk privilege, and (5) prove you acted on the results. If you can do those five things consistently, you can usually satisfy assessors even when tooling differs across platforms. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Regulatory text

NIST excerpt (control enhancement AC-6(7)): “Review [organization-defined frequency] the privileges assigned to [organization-defined personnel or roles] to validate the need for such privileges; and …” (NIST SP 800-53 Rev. 5 OSCAL JSON)

What the operator must do

1. Pick and document a review frequency (the “how often”) that you can execute consistently. (NIST SP 800-53 Rev. 5 OSCAL JSON)
2. Define whose privileges are reviewed (the “who”), typically privileged users, admins, elevated roles, and sensitive application roles. (NIST SP 800-53 Rev. 5 OSCAL JSON)
3. Perform the review and validate need: each privilege must have a current, job-aligned justification, not a historical reason. (NIST SP 800-53 Rev. 5 OSCAL JSON)
4. Complete the “and …” operationally: even though the excerpt truncates here, assessors will still expect outcomes (remediation, exceptions, and traceability) because a “review” without action does not reduce risk in practice. Keep your procedure explicit about what happens after findings. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Plain-English interpretation

AC-6(7): review of user privileges requirement means you must periodically prove that elevated or sensitive access is still necessary. The review is not a simple access recertification checkbox; it is a decision point: keep, reduce, or remove specific privileges based on current responsibilities and approved need. (NIST SP 800-53 Rev. 5)

Treat it like a controlled reconciliation:

• Input: authoritative privilege lists from systems of record (IdP, directory, PAM, SaaS admin consoles, databases).
• Decision: a responsible reviewer attests to necessity for each privileged entitlement.
• Output: revocations/downgrades completed, exceptions documented, and evidence packaged for assessment. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Who it applies to

Entities

• Federal information systems and programs implementing NIST SP 800-53 controls. (NIST SP 800-53 Rev. 5)
• Contractor systems handling federal data where NIST SP 800-53 is contractually flowed down (common in government contracting and regulated environments). (NIST SP 800-53 Rev. 5)

Operational contexts where assessors focus

• Privileged infrastructure access (directory admins, cloud admins, hypervisor admins).
• Security tooling admins (SIEM, EDR, DLP, firewall management).
• Financial or mission-critical applications with powerful roles (ERP admins, payroll admins, claims processing overrides).
• Data-layer privileges (DBA, production data query roles, key management roles). (NIST SP 800-53 Rev. 5)

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

Step 1: Define scope, cadence, and ownership (make it assessable)

Create a short “AC-6(7) privilege review standard” that specifies:

• In-scope systems: identity platforms, cloud platforms, core business apps, and any system with privileged roles.
• In-scope privileges: admin roles, privileged groups, break-glass access, service accounts with elevated rights, and sensitive application entitlements.
• Reviewers: manager for business justification plus system owner for technical appropriateness is a common split; pick one accountable approver per entitlement set.
• Frequency: document your organization-defined frequency and ensure it matches your operational capacity. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Practical tip: if you can’t review everything at once, define tiers (highest-risk platforms first) and document the rationale so the scope decision is defensible. (NIST SP 800-53 Rev. 5)

Step 2: Build an authoritative privilege inventory (no screenshots-only programs)

For each in-scope system, define:

• System of record for access (e.g., IdP groups, cloud IAM roles, application RBAC tables).
• Export method (API export, scheduled report, directory query).
• Data fields you will retain: user/service account, privilege/role name, scope (prod/non-prod), effective permissions if available, grant date, grantor, last used if available.

Your goal is a repeatable report that can be regenerated for any period under audit. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Step 3: Normalize privileges into “reviewable units”

Review fatigue kills these programs. Convert raw entitlements into a format reviewers can decide on:

• Collapse low-risk entitlements into bundles where reasonable (but keep admin rights atomic).
• Label entitlements with plain descriptions (“Can create new users in production tenant”).
• Tag each entitlement with risk tier and required reviewer type (manager vs system owner).

If you use Daydream to run the workflow, map AC-6(7) to a control owner, a written procedure, and a recurring evidence set so the reviews produce consistent artifacts every cycle. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Step 4: Execute the review workflow (attestations with consequences)

Run each review cycle as a ticketed or workflow-driven process:

1. Freeze the access snapshot (export and store it as the review population).
2. Route to reviewers with due dates and escalation rules.
3. Require one of three decisions per privilege: keep (with justification), remove, or exception (time-bound, approved).
4. Track non-response as risk: if a reviewer does not respond, define who can make the decision and document why.
5. Open remediation tickets automatically for removals and required reductions.

What assessors look for: evidence that someone competent evaluated necessity, and that removals happened. (NIST SP 800-53 Rev. 5)

Step 5: Remediate and prove closure

For every entitlement marked “remove” or “reduce,” retain:

• The change ticket.
• The before/after access state (or a new export showing revocation).
• The date/time and implementer.
• Any post-change validation (for example, a control test that confirms the user no longer has the role).

Do not leave results sitting in spreadsheets. A “review” that produces findings but no completed actions will fail under scrutiny. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Step 6: Manage exceptions without breaking least privilege

You will have legitimate exceptions (e.g., emergency access, legacy application constraints). Control them:

• Document the reason, compensating controls, approving authority, and an expiration/next review trigger.
• Track exceptions as a register so you can show they are known, approved, and revisited.

Keep the exception process inside the same AC-6(7) evidence trail so audits don’t turn into email archaeology. (NIST SP 800-53 Rev. 5)

Required evidence and artifacts to retain

Maintain an “AC-6(7) evidence packet” per review cycle:

Core artifacts

• Privilege review procedure/standard (scope, roles, cadence, reviewers). (NIST SP 800-53 Rev. 5 OSCAL JSON)
• In-scope system list and privileged role catalog. (NIST SP 800-53 Rev. 5)
• Point-in-time access exports used as the review population.
• Completed reviewer attestations with rationale for “keep.”
• Exception approvals and exception register entries.
• Remediation tickets and closure proof (before/after or post-change export).

Operational artifacts that help in real audits

• Evidence of reviewer assignment (workflow logs).
• Escalation records for overdue reviews.
• Metrics you can defend qualitatively (for example, “overdue items tracked and escalated”) without inventing percentages.

Common exam/audit questions and hangups (what they mean operationally)

Audit question	What the auditor is probing	What to show
“What is your defined frequency and who is in scope?”	Did you fill the organization-defined parameters?	A dated standard + scoped system list. (NIST SP 800-53 Rev. 5 OSCAL JSON)
“How do you know the report is complete?”	Population integrity	Export method, data sources, and a repeatable query/report definition.
“Who approved keeping admin access?”	Accountable review	Named reviewers, approval logs, and justification text.
“Show me removals from the last cycle.”	Review leads to action	Tickets + before/after evidence.
“How do you handle exceptions?”	Risk acceptance discipline	Exception register entries + approvals + expiry/next review.

Hangup to anticipate: reviewers “rubber stamp” because the review unit is too large or poorly described. Fix it by making admin privileges granular and understandable. (NIST SP 800-53 Rev. 5)

Frequent implementation mistakes (and how to avoid them)

1. Reviewing accounts, not privileges. You need to validate the necessity of the privilege itself (admin role, sensitive entitlement), not just confirm the user is employed. Avoid this by structuring the review around entitlements. (NIST SP 800-53 Rev. 5 OSCAL JSON)
2. No system owner accountability. Managers often cannot assess technical appropriateness; system owners can. Assign explicit ownership per system for the final decision. (NIST SP 800-53 Rev. 5)
3. Evidence gaps due to ad hoc spreadsheets. Spreadsheets can work, but only if you retain immutable exports, approval trails, and closure tickets. A workflow tool (including Daydream) reduces evidence sprawl by packaging artifacts per cycle. (NIST SP 800-53 Rev. 5 OSCAL JSON)
4. Failure to close the loop. If removals are not executed and verified, the control is not operating. Require closure evidence as part of the same review record. (NIST SP 800-53 Rev. 5)
5. Ignoring non-human accounts. Service accounts and automation identities often hold powerful permissions. Include them in scope and require documented ownership and justification. (NIST SP 800-53 Rev. 5)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page avoids enforcement-specific claims. The practical risk remains straightforward: stale or excessive privileges increase the blast radius of account compromise, insider misuse, and operational error, and they create adverse audit outcomes when you cannot prove disciplined access governance. (NIST SP 800-53 Rev. 5)

Practical 30/60/90-day execution plan

First 30 days (stand up the control)

• Publish the AC-6(7) standard: scope, reviewers, and organization-defined frequency. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Identify in-scope systems and privileged role types; name system owners.
• Create export methods for each system and test one end-to-end review on a single high-risk platform.

Days 31–60 (run a full cycle and fix friction)

• Run the first full review cycle for your highest-risk systems.
• Tighten entitlement descriptions and split bundles where reviewers hesitate.
• Implement an exception register and require expiration/next-review triggers for approvals.
• Start packaging evidence consistently (one folder/case per cycle).

Days 61–90 (make it repeatable and audit-ready)

• Expand scope to remaining in-scope systems based on your tiering plan.
• Add escalation and tracking for overdue attestations.
• Standardize remediation closure proof (ticket + post-change export).
• In Daydream, map AC-6(7) to the control owner, implementation procedure, and recurring evidence artifacts so each cycle produces the same audit-ready outputs. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Frequently Asked Questions

What counts as a “privilege” for AC-6(7)?

Treat privileges as any entitlement that increases capability or expands data access, especially admin roles, privileged groups, sensitive application roles, and powerful service account permissions. Define the list in your scope document so reviewers know what they are approving. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Can I satisfy AC-6(7) with an annual access recertification?

Only if your organization-defined frequency is annual and the review actually validates specific privileged entitlements and triggers removals or exceptions. If your recertification is only “user still needs an account,” it will not meet the intent of reviewing privileges. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Who should approve keeping privileged access: manager or system owner?

Use an approver model you can execute consistently, then document it. A common approach is manager attestation for business need plus system owner confirmation for appropriateness on that platform. (NIST SP 800-53 Rev. 5)

How do I handle break-glass or emergency admin access in the review?

Keep it in scope and require documented ownership and justification, even if access is rarely used. If the account is intended for emergencies, document the conditions for use and review it on your defined cadence like any other privileged identity. (NIST SP 800-53 Rev. 5)

What evidence do auditors ask for most often?

They typically ask for the access population report, completed attestations with justification, proof of removals (tickets and after-state), and the written procedure that defines frequency and scope. Store these per review cycle to avoid rebuilding history under pressure. (NIST SP 800-53 Rev. 5 OSCAL JSON)

We have inconsistent tooling across teams. Can we still pass an assessment?

Yes, if you standardize the workflow and evidence even when the source systems differ. Define required fields for exports, require documented approval decisions, and track remediation in a consistent ticketing path across systems. (NIST SP 800-53 Rev. 5)