AC-2: Account Management

AC-2 is often treated as “IAM hygiene,” but auditors read it as governance: can you prove you control what kinds of accounts exist in the environment, and can you show you intentionally disallow risky account patterns. The specific requirement here is narrow and operational: define and document the types of accounts allowed and specifically prohibited for use within the system. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to turn AC-2 into a short standard plus repeatable execution: (1) a taxonomy of account types, (2) clear rules for when each type is permitted, (3) explicit “never allowed” categories, (4) a small set of enforcement points (HR-driven joiner/mover/leaver, access requests, and recurring access reviews), and (5) evidence you can hand to an auditor without rebuilding it during the exam.

This page focuses on operationalizing the requirement quickly: what to write, who needs to approve it, how to roll it into workflows, and what artifacts to retain so you can demonstrate control design and control operation.

Regulatory text

Requirement excerpt: “Define and document the types of accounts allowed and specifically prohibited for use within the system;” ¹

What the operator must do:

1. Define account types that exist (or could exist) in your system boundary (human and non-human).
2. Document which types are allowed (and under what conditions).
3. Document which types are prohibited (explicitly named, not implied).
4. Make the document enforceable by connecting it to provisioning and review activities so prohibited accounts do not appear, and allowed accounts have consistent controls.

A policy statement alone rarely passes. You need a standard that an engineer, IT admin, and auditor can all use to answer: “Is this account category permitted here? If yes, what guardrails apply? If no, what do we do if we find one?”

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

AC-2, in this specific excerpt, is asking for account-type governance:

• “Allowed” means you have intentionally sanctioned categories of accounts (for example, employee user accounts, service accounts, break-glass accounts) and defined the guardrails for each.
• “Prohibited” means you’ve explicitly banned specific categories (for example, shared named-user accounts, anonymous accounts, or unmanaged local admin accounts) within the system boundary.

Auditors commonly test this by hunting for the prohibited patterns you forgot to name. If you do not explicitly prohibit a risky account type, you will struggle to justify why it exists or why it is controlled.

Who it applies to (entity and operational context)

This requirement is most often applied in environments aligned to NIST SP 800-53, including:

• Federal information systems and programs inheriting NIST controls. ²
• Federal contractors and contractor systems handling federal data, where NIST control mapping is part of authorization, customer security requirements, or assurance expectations. ²

Operationally, it applies wherever identities exist:

• Corporate identity providers (IdP), directories, and SSO
• Cloud IAM (AWS, Azure, GCP)
• Endpoints and local accounts
• Databases, network devices, SaaS admin consoles
• Non-human identities (service accounts, API tokens, bots)

If your “system” boundary is narrower than the enterprise, document that boundary and keep the account type rules scoped to it. If you cannot clearly define the boundary, audits will drift into “prove it everywhere.”

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

Step 1: Create an “Account Type Standard” (one page is fine)

Publish a controlled document that includes:

• System scope: what environments and platforms are in-scope.
• Account type taxonomy: the list of account types you recognize.
• Allowed vs. prohibited matrix: explicit yes/no per type.
• Required attributes per allowed type: owner, purpose, approval, authentication constraints, lifecycle rules.
• Exception process: who can approve exceptions, for how long, and how you review them.

A practical starting taxonomy (adapt to your environment):

• Human user accounts (employees)
• Human user accounts (contractors)
• Privileged admin accounts (named)
• Emergency / break-glass accounts
• Service accounts (workload identities)
• Shared accounts (prohibited in most environments)
• Local accounts (restricted; sometimes prohibited except break-glass)
• Default vendor accounts (prohibited until changed/disabled)
• Anonymous/guest accounts (prohibited unless explicitly required and controlled)

Step 2: Define “prohibited” so it is testable

Write prohibited types as conditions an auditor can validate from logs and inventories. Examples of testable prohibited patterns:

• “Shared accounts for interactive use are prohibited.”
• “Accounts without a named owner are prohibited.”
• “Default accounts shipped by software are prohibited unless disabled or renamed and controlled.”

Keep this grounded: prohibit what you can actually detect and enforce.

Step 3: Map each allowed account type to lifecycle controls

For each allowed type, specify:

• Provisioning trigger: HR event, ticket, CI/CD pipeline, vendor onboarding, etc.
• Approver: manager, system owner, security, data owner (pick one primary and one backup).
• Identity proofing: what must be true before creation (employment/contract status, vendor contract, background check if your program requires it).
• Authentication requirements: MFA required, key management, rotation expectations (state requirements qualitatively if you don’t have hard standards yet).
• Deprovisioning trigger: termination, contract end, inactivity, system retirement.
• Periodic review: how you validate continued need (tie to your access review program).

This is where AC-2 becomes operational rather than a PDF.

Step 4: Connect the standard to enforcement points (minimum viable)

Pick enforcement points you already have and tighten them:

• Access request workflow: require selecting an account type; block “other.”
• Directory/IAM guardrails: naming conventions, group-based access, disallow local admin creation by default.
• CI/CD for non-human identities: require code owners or system owners to approve service accounts and secrets.
• Recurring account inventory checks: query for prohibited types and missing required attributes.

If you use Daydream to manage controls, create a control card for AC-2 with the objective, owner, trigger events, execution steps, and exception rules so the requirement runs the same way each cycle and is not dependent on tribal knowledge. ²

Step 5: Run a control health check and remediate findings to closure

Turn findings into a tracked remediation list:

• Identify prohibited account instances
• Assign owners and due dates
• Disable/remove, or document exception with compensating controls
• Validate closure with evidence (before/after exports, tickets)

A recurring health check matters because auditors look for sustained operation, not a one-time cleanup. ²

Required evidence and artifacts to retain

Build an “AC-2 evidence bundle” that you can export quickly:

1. Account Type Standard (controlled document)
   • Version history, approver(s), effective date
2. Account inventory extracts
   • From IdP/directories and cloud IAM showing account names, types (or tags), owners, status
3. Configuration evidence (where relevant)
   • Screenshots or exports showing disabled guest access, blocked local admin creation, or other guardrails tied to prohibited types
4. Access request samples
   • Completed tickets or workflow records showing account type selection and approvals
5. Exception register
   • Approved exceptions with expiry dates and compensating controls
6. Periodic review records
   • Review outputs, findings, and remediation tracking to validated closure ²

Store evidence in a defined location with retention aligned to your audit needs. The failure mode is “evidence is spread across tickets, chat, and admin consoles.”

Common exam/audit questions and hangups (with operator answers)

Q: “Show me the account types you allow and prohibit.”
Have the matrix ready. If you can’t show prohibited types, the examiner will infer you don’t manage them.

Q: “How do you prevent shared accounts?”
Answer with your workflow enforcement (no ticket approval without an owner), plus detection (inventory query for missing owner attribute).

Q: “How do you classify service accounts?”
Define minimum metadata: owning application, system owner, secret storage method, and rotation responsibility.

Q: “Do you have accounts with no owner?”
If yes, treat as a finding. If no, show the inventory field and validation query.

Q: “What about third-party access?”
Treat third-party identities as a defined allowed type (for example, “contractor” or “support access”), or prohibit them except via a controlled method (federation, time-bound access). Document it either way.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Listing allowed types but not prohibited types.
   Fix: Write a prohibited list that includes shared interactive accounts, orphaned accounts, and default accounts. Keep it auditable.

2. Mistake: Taxonomy that doesn’t match reality.
   Fix: Start from your account inventory export and define types that map to fields you can tag or infer.

3. Mistake: “Service accounts” treated as a dumping ground.
   Fix: Require an owning system, purpose, and lifecycle event (who disables it when the app is retired).

4. Mistake: No exception mechanism.
   Fix: Add an exception register with time bounds and explicit compensating controls. Otherwise, exceptions become permanent shadow policy.

5. Mistake: Evidence depends on screenshots collected during the audit.
   Fix: Define the minimum evidence bundle per cycle and store it centrally after each review. ²

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement outcomes.

Risk still compounds quickly when account types are uncontrolled:

• Prohibited account patterns (shared, anonymous, orphaned) reduce accountability and weaken incident response.
• Untracked non-human identities create long-lived access paths that survive org changes and system migrations.
• Weak account governance becomes an audit multiplier: once an auditor doubts account control, they expand testing across access control, monitoring, and change management.

Practical 30/60/90-day execution plan

Days 0–30: Define and publish the rulebook

• Draft the Account Type Standard (allowed/prohibited matrix, required attributes, exception process).
• Confirm system boundary and in-scope identity stores.
• Identify owners: control owner, IAM operator, system owners for major apps.
• Implement the smallest workflow gate: every new account request must declare an account type and an owner.

Days 31–60: Make it enforceable and measurable

• Add tags/attributes needed to classify accounts (owner, type, purpose).
• Build an account inventory report you can rerun consistently.
• Run the first prohibited-account sweep; open remediation items.
• Stand up the evidence bundle location and naming convention; store outputs after each run.

Days 61–90: Prove repeatability

• Execute a second inventory sweep and show delta closure.
• Operationalize exceptions: approvals, expirations, and reviews.
• Run a lightweight control health check and document what broke and how you fixed it. ²
• If you use Daydream, convert the runbook into a control card with triggers and required evidence so operation does not degrade when staff changes. ²

Frequently Asked Questions

Do I need a separate policy for AC-2, or is a standard enough?

A policy can state intent, but AC-2 testing usually hinges on a standard that lists allowed and prohibited account types and the required attributes. Keep the standard controlled and approved so it functions as audit-ready governance. ¹

How do we handle shared admin accounts used by IT today?

Treat shared interactive accounts as prohibited, then migrate to named privileged accounts with individual accountability. If you must keep a shared account temporarily, document a time-bound exception with compensating controls and an exit plan.

Are break-glass accounts allowed under AC-2?

They can be, if you explicitly define them as an allowed type with strict conditions (ownership, storage, access logging, and controlled activation). If you don’t define them, they often show up as “mystery accounts” in audits.

What about service accounts created automatically by cloud services?

Define “cloud-managed service identities” as a recognized account type, and document how you discover them and assign ownership at the system level. The key is that they are intentional and reviewed, not invisible.

How do we scope this to one system when identities live in a shared corporate directory?

Document the system boundary and specify how you determine which directory accounts are “used within the system” (groups, roles, application assignment). Then run reports based on that scoping method so you can defend it consistently.

What evidence is the fastest to produce during an audit?

The Account Type Standard plus a recent account inventory export showing type/owner/status covers most AC-2 questions quickly. Add a sample of approvals and your last remediation log to prove the control operates, not just exists. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5