AC-2(7): Privileged User Accounts

AC-2(7) requires you to create and manage privileged user accounts using a defined access scheme (role-based or attribute-based), so admin-level access is intentional, standardized, and provably controlled. Operationalize it by defining what “privileged” means in your environment, mapping those privileges to approved roles/attributes, enforcing provisioning rules in your IAM/PAM tooling, and retaining reviewable evidence. ¹

Key takeaways:

• Define and publish a privileged access scheme (RBAC or ABAC) and tie every privileged account to it.
• Separate “privileged accounts” from standard accounts, with stricter provisioning, review, and offboarding steps.
• Keep an evidence bundle that proves each privileged account has an approved basis (role/attribute), owner, and lifecycle history.

AC-2(7): Privileged User Accounts is one of those requirements that auditors treat as a “show me” control: show me the scheme, show me which accounts are privileged, and show me that each one exists for a defined reason and is administered consistently. The control language is short, but the operational surface area is broad because “privileged” shows up across humans (admins, engineers), service accounts, break-glass access, cloud platform roles, databases, network devices, CI/CD, and third-party managed services.

For a CCO or GRC lead, the fastest path is to turn AC-2(7) into a requirement control card with: a crisp definition of privileged access, a single source of truth inventory, provisioning rules bound to RBAC or ABAC, and a recurring control health check that catches drift. You are not trying to write a perfect policy. You are trying to make privileged access predictable, reviewable, and hard to create casually.

This page gives you a requirement-level interpretation and a practical runbook you can hand to IAM, Security Operations, and system owners, with the evidence artifacts you’ll need for assessments aligned to NIST SP 800-53 Rev. 5. ²

Regulatory text

Requirement (verbatim): “Establish and administer privileged user accounts in accordance with [a role-based access scheme or an attribute-based access scheme];” ¹

What the operator must do:

• Establish a formal scheme that determines how privileged access is granted. The scheme must be either:
  • Role-based access control (RBAC): privileges are tied to predefined job/system roles (e.g., “Linux Server Administrator,” “Database Administrator”), or
  • Attribute-based access control (ABAC): privileges are tied to attributes (e.g., department=IT, clearance=Production-Admin, device_trust=Managed, employment_status=Active).
• Administer privileged accounts consistently under that scheme. In practice, that means your provisioning, modification, and deprovisioning steps must follow the scheme and be demonstrable with records.

The key audit point: privileged accounts cannot be “handcrafted exceptions” that exist outside your access model. Each privileged account needs a documented basis that maps back to an approved role or attribute rule. ²

Plain-English interpretation

A privileged user account is any identity (human or non-human) that can bypass normal controls or materially change system behavior: administer systems, change security configurations, manage identities, access sensitive data at scale, or alter logging/monitoring. AC-2(7) expects you to manage those identities through a consistent model (RBAC or ABAC), not ad hoc approvals.

If your organization can’t answer “why does this privileged account exist?” in one sentence and point to the role/attribute rule that allows it, you have an AC-2(7) gap. ²

Who it applies to

Entities and environments

• Federal information systems and programs aligned to NIST SP 800-53.
• Federal contractors and service organizations handling federal data where NIST SP 800-53 is a contractual or assessment baseline. ²

Operational scope

• Identity systems: IdP, directory services, SSO, IAM governance, MFA services.
• Privileged access tooling: PAM vaults, session recording, just-in-time elevation, secrets managers.
• Platform control planes: cloud IAM roles/policies, Kubernetes cluster-admin, CI/CD admin.
• Critical apps and data stores: ERP admin, database admin, security admin consoles.
• Third parties: managed service providers, consultants, and support vendors with elevated access paths (direct accounts, federated access, shared tooling). AC-2(7) still applies because you are establishing/administering privileged accounts, even if the identity is external.

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

1) Write a “privileged account” definition you can enforce

Create a definition that your teams can apply consistently. Include categories, not just examples.

Minimum elements to specify:

• Identity types: human users, service accounts, automation/bots, break-glass accounts.
• Privilege criteria: ability to administer systems, manage identities, change security controls, access production data broadly, disable logging, or modify audit trails.
• In-scope systems: where privilege matters most (cloud, directories, endpoints, network, databases, CI/CD).
  This definition becomes your scoping anchor for inventory and reviews. ²

2) Choose your access scheme: RBAC or ABAC (document the decision)

You must be able to state which scheme you use for privileged accounts. ¹

A practical decision matrix:

Decision point	RBAC is a fit when	ABAC is a fit when
Org structure	Stable job functions	Dynamic teams/projects
Systems	Traditional enterprise apps, server admin	Cloud-native, ephemeral access
Controls	Clear role catalog	Strong identity attributes and policy engine
Reviewer expectations	Simpler to explain in audits	Stronger for conditional access

You can use both across different systems, but avoid hybrid ambiguity. If you do both, document where RBAC applies and where ABAC applies, and how you prevent conflicts.

3) Build a privileged role/attribute catalog (the heart of AC-2(7))

For RBAC, define privileged roles with:

• Role name and description
• Allowed systems and permission sets
• Eligibility criteria (who can have it)
• Approval authority (role owner + security/IAM approver)
• Segregation of duties notes (what it must not be paired with)
• Review frequency trigger (event-based is fine: role change, manager change, project end)

For ABAC, define:

• Required attributes (employment status, department, team, training completion)
• Environmental conditions if used (managed device, network, MFA strength)
• Policy logic (high level) and where it is implemented (IdP conditional access, cloud policy engine)

Tie every privileged account to an entry in this catalog. If you can’t tie it, either fix the catalog or remove the privilege. ²

4) Establish lifecycle workflows: request, approve, provision, change, revoke

Turn the scheme into workflows that consistently produce logs/evidence:

Request

• Require requestor, business justification, target systems, and duration/expiry (if your model supports temporary access).
• Require selection of an approved privileged role (RBAC) or confirmation of eligibility attributes (ABAC).

Approval

• Require the role owner (system owner or control owner) and IAM/Security approval for privileged roles.
• If a third party is involved, add sponsor approval (internal owner accountable for the external identity).

Provision

• Provision through centralized IAM/PAM where possible.
• Prohibit direct console grants without a tracked ticket except break-glass.

Change

• Treat permission changes as re-approval, not an “FYI.”

Revoke

• Trigger on termination, contract end, role change, access no longer needed, or policy failure (attribute no longer true).
• Ensure revocation covers group memberships, cloud roles, PAM entitlements, and local admin rights.

AC-2(7) does not list these steps explicitly, but this is what “establish and administer” looks like in an environment that can pass an audit. ²

5) Inventory privileged accounts and reconcile to the scheme

Create a living inventory that answers:

• Account identifier and type (human/service/break-glass/third party)
• Privileged role/attribute policy mapping
• System(s) where privilege is granted
• Owner (human accountable party)
• Provisioning record (ticket/approval)
• Last review date and outcome
• Termination/offboarding status where applicable

Reconcile the inventory to:

• IAM groups / directory roles
• Cloud IAM roles
• PAM vault and entitlement lists
• Local administrator groups where you can measure them

This reconciliation is where teams find “ghost admins,” stale contractor access, and one-off grants. ²

6) Operationalize with control health checks and exception handling

Auditors look for sustained operation. Run a recurring check that tests:

• Any privileged account not mapped to a role/attribute policy
• Any privileged account without an owner
• Any privileged account without approval evidence
• Any privileged account belonging to inactive users
• Any direct grants outside IAM/PAM workflow

Track findings to closure with dates, owners, and validation. The point is traceability. ²

Exceptions Document exceptions with:

• Time-bounded approval
• Compensating controls (extra monitoring, session recording, restricted source IPs)
• Planned remediation date

7) Package it as an operator-ready “requirement control card” (fastest way to scale)

Create a one-page card that includes:

• Objective: privileged accounts follow RBAC/ABAC scheme
• Control owner: IAM lead (execution), Security (oversight), System owners (role owners)
• Trigger events: onboarding, role change, third-party onboarding/offboarding, incident response, quarterly access review cadence if you adopt one
• Execution steps: the workflow above
• Evidence bundle: see next section
• Exceptions: break-glass rules, legacy system constraints

Daydream can help by turning this into a reusable control record with assigned owners, required evidence, and recurring health checks so you are not rebuilding the story for each audit. ²

Required evidence and artifacts to retain

Keep evidence that proves both design (the scheme exists) and operation (accounts follow it).

Design evidence

• Privileged access standard/policy stating RBAC or ABAC for privileged accounts ²
• Privileged role catalog or ABAC policy definitions with owners and approval requirements
• System list in scope for privileged access management
• Exception process definition (who can approve, how long exceptions last)

Operational evidence (sample-based is fine if consistent)

• Access requests and approvals for privileged roles/attributes (tickets/workflow exports)
• Provisioning logs from IAM/PAM showing role assignment timestamps and actor
• Privileged account inventory export with mappings to roles/attributes and owners
• Review records (access recertification outputs, reconciliation reports, remediation tickets)
• Termination/offboarding evidence showing privileged access removal (HR feed trigger + IAM deprovision logs)

Retention Store evidence in a system that preserves integrity and supports retrieval by period and system. Keep it searchable by account and by privileged role.

Common exam/audit questions and hangups

Expect these questions:

1. “Define privileged. How do you decide what counts?”
2. “Show me your RBAC/ABAC scheme for privileged access.” ¹
3. “List all privileged accounts across your environment. Who owns each?”
4. “Pick five privileged accounts. Show approvals and the role/attribute rule that allowed them.”
5. “How do you prevent engineers from granting admin directly in the console?”
6. “How do you handle third-party privileged access and offboarding?”
7. “Show evidence your control runs repeatedly, not only during audit season.”

Hangups that stall audits:

• Privileged access spread across tools with no reconciliation.
• “Everyone in Engineering” mapped to a single high-power role with no granularity.
• Break-glass accounts with no owner, no test logs, or shared credentials.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating “privileged” as a short list of admin titles.
   Fix: Base it on capability (identity admin, security control changes, broad production data access), then map systems accordingly.

2. Mistake: Role catalog exists, but real accounts don’t match it.
   Fix: Make the catalog the only allowed pathway. Flag and remediate direct grants.

3. Mistake: Service accounts ignored.
   Fix: Put service accounts in the same inventory. Give them owners, purpose statements, and role mappings.

4. Mistake: No clear role owners.
   Fix: Assign a business/system owner per privileged role. IAM can administer mechanics, but a system owner must attest need.

5. Mistake: Evidence is scattered.
   Fix: Define a minimum evidence bundle per workflow and store it centrally. Daydream-style evidence checklists prevent “we can’t find the ticket” failures.

Enforcement context and risk implications

No public enforcement cases are provided in the source catalog for AC-2(7), so you should treat this as an audit and contractual compliance expectation rather than a requirement with a cited enforcement pattern here.

Risk-wise, privileged accounts are a primary path for control failure: a single unmanaged admin identity can change security configuration, suppress logging, exfiltrate data, or create persistent access. AC-2(7) reduces that risk by forcing a consistent entitlement model and making privileged access reviewable. ²

A practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Name a control owner and backups (IAM execution + Security oversight).
• Publish your privileged account definition and in-scope systems list.
• Decide RBAC or ABAC for privileged accounts; document where it applies. ¹
• Draft the privileged role catalog (start with highest-risk systems: IdP/directory, cloud root/admin, security tooling).
• Start an inventory by exporting privileged role memberships from your highest-value systems.

Days 31–60 (enforce workflows and capture evidence)

• Implement request/approval workflow for privileged access (ticketing or IGA tool).
• Require role/attribute mapping for every new privileged grant.
• Implement a basic reconciliation: inventory vs actual privileged group/role membership.
• Define your minimum evidence bundle and retention location (requests, approvals, provisioning logs, reviews).
• Stand up an exception process for legacy systems and break-glass access.

Days 61–90 (operationalize and prove control health)

• Expand inventory coverage across remaining platforms (databases, CI/CD, endpoints, network).
• Run a control health check and open remediation items for unmapped/stale privileged access.
• Validate offboarding triggers remove privileged access promptly (test with recent terminations/contract ends).
• Prepare an audit-ready sample set: select privileged accounts and package their role mapping + approvals + current entitlement evidence.
• Consider automating attestations and evidence collection in Daydream to reduce manual compilation and improve repeatability. ²

Frequently Asked Questions

What counts as a “privileged user account” for AC-2(7)?

Any account (human or non-human) with permissions that can administer systems, manage identities, change security controls, or access sensitive data broadly should be treated as privileged. Write a capability-based definition and apply it consistently across systems. ²

Do we have to choose RBAC or ABAC, or can we do both?

The control requires privileged accounts be established and administered in accordance with RBAC or ABAC. You can operate both across different systems, but document which scheme applies where and ensure every privileged account maps to the applicable scheme. ¹

How do we handle break-glass accounts under AC-2(7)?

Treat break-glass as privileged by definition, assign a named owner, restrict creation, and document the role/attribute basis and exception controls. Keep activation logs and post-use review records in your evidence bundle. ²

Are service accounts and CI/CD bots in scope?

Yes if they hold privileged permissions. Put them in the privileged inventory, assign an accountable owner, tie entitlements to an approved role/policy, and review them for continued need and drift. ²

What evidence do auditors usually want to see first?

They typically start with your privileged access scheme documentation (RBAC/ABAC), the privileged account inventory, and a sample of accounts showing approval + provisioning records + current entitlement proof. If you cannot produce those quickly, the audit will stall. ²

How does this apply to third-party admins (MSPs, consultants)?

If a third party has elevated access into your environment, you still need a privileged account model: sponsor ownership, mapped roles/attributes, controlled provisioning, and timely deprovisioning when the engagement ends. Capture evidence the same way you do for employees. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5 PDF