AC-13: Supervision and Review — Access Control

AC-13 requires you to actively supervise and periodically review how access control is being administered, not just define access rules. Operationally, you assign accountable owners, set a review cadence for privileged and delegated access administration, document what gets checked, and retain evidence that issues are found and fixed. ¹

Key takeaways:

• AC-13 is about oversight of access administration: supervision, review, and follow-up, not writing an access policy. ¹
• You need a repeatable runbook with ownership, triggers, review scope, and evidence outputs for each cycle. ²
• Auditors will look for proof of operation: review logs, exception approvals, and remediation tickets tied to findings. ¹

AC-13: Supervision and Review — Access Control is the control that forces a simple question: “Who watches the people and systems that grant access, and how do we prove that oversight happens?” The control exists because access control failures often occur in the gaps between design (what the policy says) and operation (what admins and automated tooling actually do day to day). ¹

For a Compliance Officer, CCO, or GRC lead, the fastest way to operationalize AC-13 is to treat it like an access governance operating control, not a technical configuration standard. You are building a management loop: define who supervises access administrators (human and automated), define what they review, define how often reviews occur or what events trigger them, and define what happens when a review finds problems. ¹

This page is written to help you stand up that loop quickly with a control “card,” an evidence bundle, and a durable workflow that survives staff changes, tool migrations, and audit sampling. Where helpful, it also shows how to map AC-13 into common access governance components like privileged access management, identity governance, and security operations ticketing. ¹

Regulatory text

Requirement excerpt: “NIST SP 800-53 control AC-13.” ²

Operator interpretation: AC-13 requires supervision and review of access control administration. That means you must (1) assign oversight responsibility for how access is granted/changed/removed, (2) periodically review that administration for correctness and policy alignment, and (3) document outcomes and corrective actions. ¹

What examiners typically expect you to show is not the sophistication of your access tooling, but the existence of a functioning oversight mechanism with traceable evidence: reviewers, review scope, findings, approvals, and closure of issues. ¹

Plain-English interpretation (what AC-13 is really asking)

AC-13 asks you to prove you are watching access administration. “Administration” includes:

• People who can grant access (IT admins, application owners, DBAs, cloud admins).
• Systems that grant access automatically (IAM workflows, HR-driven provisioning, scripts, CI/CD pipelines, infrastructure-as-code).
• Delegated access processes (help desk groups that can reset passwords or add users to groups). ¹

Supervision and review means you verify that:

• Admin actions are appropriate, authorized, and logged.
• Elevated privileges are controlled and not accumulating.
• Exceptions have approvals and expirations.
• Access changes follow your own rules (joiner/mover/leaver discipline, segregation-of-duties constraints where relevant). ¹

Who it applies to (entity and operational context)

AC-13 is relevant anywhere you claim alignment with NIST SP 800-53, especially:

• Federal information systems and programs using NIST SP 800-53 as a control baseline. ¹
• Contractor systems handling federal data where NIST 800-53 controls are contractually flowed down (common in regulated, public sector, and critical programs). ¹

Operationally, it applies across:

• Corporate IT (SSO/IAM, endpoint admin rights, directory services).
• Cloud control planes (IAM roles/policies, break-glass access).
• Production applications (admin consoles, database access, service accounts).
• Third-party administered systems where your organization retains responsibility for access governance outcomes (for example, SaaS with delegated admin roles). ¹

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

1) Create an AC-13 control card (make it runnable)

Write a one-page runbook with:

• Objective: Supervise and review access administration for defined systems.
• Owner: Named role (for example, IAM Manager) with backup owner.
• Reviewers: Security/GRC, system owners, or independent reviewer for privileged actions.
• Scope: Systems, platforms, and privileged roles covered; include “shadow admin” paths (help desk tools, cloud consoles, break-glass).
• Triggers: Scheduled cadence and event-driven triggers (new admin onboarding, tool changes, incident, major release).
• Steps: What is checked, by whom, with what data sources.
• Exceptions: How to request, approve, time-bound, and review exceptions. ²

This is the fastest way to remove ambiguity during an audit and prevent “tribal knowledge” control operation.

2) Define “access administration” populations you will supervise

Build and maintain an inventory list of:

• Privileged groups/roles (directory admins, cloud admins, app admins).
• Accounts with admin capabilities (named admins, shared admin accounts if any, break-glass).
• Service accounts with privileged scopes.
• Delegated admin paths (ticketing tool permissions, endpoint management platforms). ¹

Tie the inventory to authoritative sources (IdP, directory, cloud IAM, PAM, HRIS feed where relevant). If you cannot produce a population list, you cannot credibly claim you review it.

3) Implement a repeatable supervision mechanism

Pick supervision controls that match your environment, such as:

• Dual control for privileged group membership changes (approval plus implementation).
• Independent review of privileged actions (log review of admin events).
• PAM session recording or command logging where feasible.
• Separation between request approver and implementer for high-risk changes. ¹

Document which mechanisms apply to which systems. AC-13 can be satisfied with different mechanisms by system risk tier, but you must be explicit.

4) Run periodic reviews and record outcomes

Your review procedure should produce consistent outputs:

• Confirm only authorized admins exist for each in-scope system.
• Validate tickets/approvals exist for sampled or complete admin changes.
• Identify stale privileges, orphaned admin accounts, and emergency access that was not revoked.
• Verify logging coverage for admin events and confirm logs are reviewed (or at least retained and queryable). ¹

Operational tip: define review “tests” that a reviewer can execute without special heroics (export list, compare to approval records, open exceptions list, verify closure).

5) Track findings to validated closure

AC-13 is weak if the review ends at “we looked.” You need:

• A findings log (ticketing system or GRC issue register).
• Severity/priority, owner, due date, and remediation evidence.
• Closure validation (someone confirms the fix, not the same person who caused the issue in high-risk cases). ²

6) Add control health checks (prove it runs continuously)

Run recurring check-ins that confirm:

• Reviews occurred as scheduled.
• Evidence was stored in the expected location.
• Open issues are aging appropriately and escalated when overdue.
• Scope updates happened when systems changed. ²

If you use Daydream, this is where it should feel natural: keep the AC-13 control card, define the minimum evidence bundle, schedule recurring control health checks, and track remediation items through to closure in one place. ²

Required evidence and artifacts to retain

Store evidence in an audit-friendly location with consistent naming (by system and review period). Minimum bundle:

• AC-13 control card (owner, scope, cadence, steps, exceptions).
• System/role population exports (privileged groups, admin roles, service accounts).
• Review workpapers (checklist completed, reviewer name/role, date, systems covered).
• Approval records for admin grants/changes (tickets, workflow approvals).
• Exception register (business justification, approver, expiration, compensating controls).
• Findings log with remediation tickets and closure evidence (screenshots, exports, change records).
• Change/scope change notes (new system onboarded, tool migration, org changes). ¹

Retention: follow your enterprise retention schedule. AC-13 does not set a retention period in the provided excerpt, so do not invent one; align to contractual and policy requirements.

Common exam/audit questions and hangups

Auditors and assessors tend to probe these points:

• “Who supervises access administrators, and how is independence handled for high-risk access?” ¹
• “Show the last completed review for privileged access administration for system X.” ¹
• “How do you know the population you reviewed is complete?” ¹
• “Show an example where a review found an issue and you remediated it.” ¹
• “How do you manage emergency access and ensure it is time-bound and reviewed?” ¹

Hangup to anticipate: teams often produce an access review report (AC-2/AC-6 adjacent) but cannot show supervision of the admins and processes that generate those access states. AC-13 wants that oversight loop. ¹

Frequent implementation mistakes (and how to avoid them)

1. Policy-only compliance

• Mistake: an access control policy that says “we review” without a runbook or evidence.
• Fix: publish the control card plus evidence bundle checklist. ²

2. Reviewing users but ignoring admin paths

• Mistake: recertifying application users while ignoring who can grant access.
• Fix: explicitly include admin roles, delegated admin tools, and break-glass accounts in scope. ¹

3. No population integrity

• Mistake: pulling an incomplete list from a single system and calling it “the admin list.”
• Fix: define authoritative sources per platform and reconcile discrepancies as findings. ¹

4. Findings with no closure discipline

• Mistake: issues logged in email or meeting notes with no owner or due date.
• Fix: require ticketed remediation and closure validation evidence. ²

5. Undocumented exceptions

• Mistake: “temporary admin access” granted informally during outages.
• Fix: require after-the-fact documentation and a forced expiration review for emergency access. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite any. Practically, AC-13 failures raise incident risk: if privileged access changes are not supervised and reviewed, unauthorized access can persist and investigations become harder because approvals and logs are incomplete or unreviewed. ¹

AC-13 also affects audit outcomes: assessors frequently treat weak supervision and review as evidence that access control is not operating effectively, even when the technical controls are strong on paper. ¹

Practical execution plan (30/60/90-day)

You asked for a fast path; the plan below is intentionally operational and evidence-driven. Timeframes are planning buckets, not a factual claim about how long implementation “must” take.

First 30 days (stand up the control)

• Assign an AC-13 owner and backup, and publish the control card.
• Define in-scope systems and admin populations; document authoritative sources.
• Choose supervision mechanisms per platform (approvals, PAM controls, log review).
• Define the minimum evidence bundle and where it will be stored. ²

Days 31–60 (run the first complete cycle)

• Execute the first supervision/review cycle for highest-risk systems (cloud IAM, directory admins, production admin consoles).
• Log findings in a ticketing system; assign owners and due dates.
• Capture evidence exactly as the bundle specifies; fix gaps in data exports and access logs. ¹

Days 61–90 (stabilize and prove repeatability)

• Expand scope to remaining systems; standardize review checklists.
• Add recurring control health checks (did reviews happen, are issues closing).
• Perform a mini “audit drill”: pick one system and produce end-to-end evidence in a single folder within a day. ²

Ongoing (keep it durable)

• Update scope when systems change, new admins are onboarded, or tooling changes.
• Trend recurring findings (for example, stale access, emergency access cleanup) and drive root-cause fixes. ¹

Frequently Asked Questions

Does AC-13 require a formal access recertification campaign?

AC-13 focuses on supervision and review of access control administration, not user access recertification specifically. If your recertification includes oversight of admin grants/changes and tracks findings to closure, it can support AC-13. ¹

What systems should be in scope first?

Start with systems that can grant or materially change access broadly, such as directory services, cloud IAM control planes, and privileged access tooling. Then extend to application admin consoles and databases with privileged roles. ¹

Can the same team administer access and perform the review?

For low-risk systems, you may rely on supervisory review within the same function, but independence expectations rise with privilege and impact. Document how you prevent self-approval for high-risk access changes. ¹

What evidence is most persuasive in an assessment?

A dated review checklist tied to a complete population export, plus proof that exceptions were approved and findings were remediated through tickets to closure. Assessors want to see operation, not intent. ¹

How do we handle third-party managed systems (SaaS) where we cannot see all admin logs?

Define what you can supervise: who holds tenant admin roles, how admin access is approved, and what audit data the provider gives you. Record gaps as risk decisions or contractual requirements in your third-party management process. ¹

Where does Daydream fit if we already have IAM and a ticketing system?

Use Daydream to standardize the AC-13 control card, enforce a consistent evidence bundle, and track recurring control health checks and remediation closure across systems and teams. That closes the common “we did it but can’t prove it” gap. ²

Footnotes

1. NIST SP 800-53 Rev. 5

2. NIST SP 800-53 Rev. 5 OSCAL JSON