AC-2(3): Disable Accounts

AC-2(3): Disable Accounts is one of the account management requirements that auditors and assessors use as a proxy for access governance maturity. If you cannot rapidly disable accounts after a trigger event, you carry a predictable risk: former workforce members, stale contractors, and abandoned service accounts keep access long after the business intent ends. That exposure shows up in incident response, in customer due diligence, and in government or prime contractor assessments.

This requirement is intentionally parameterized: you set the time period and define the relevant trigger conditions for your environment. That flexibility is useful, but it creates a common failure mode: teams write a policy statement and stop there. For AC-2(3), policy language is not enough. You need a working mechanism that (1) detects disablement triggers, (2) disables accounts within your defined SLA across systems, (3) handles exceptions with documented approvals, and (4) produces defensible evidence on demand. ¹

This page gives requirement-level implementation guidance you can hand to IAM, IT, Security Operations, and HR/People Ops to get the control running and keep it auditable. ²

Regulatory text

Control requirement (excerpt): “Disable accounts within [time period] when the accounts:” ³

What the operator must do:

1. Choose and document the [time period] (your disablement SLA) and apply it consistently.
2. Define the account conditions (triggers) that require disablement (the excerpt is incomplete in the provided text, so your implementation must explicitly enumerate triggers in your control documentation).
3. Execute disablement across the systems in scope (IAM directory, SSO, SaaS, endpoints, cloud consoles, databases, and any system with local accounts).
4. Retain evidence that disablement occurred within your defined time period, and that exceptions were approved and time-bounded. ¹

Plain-English interpretation

You must promptly turn off accounts when they should no longer be able to log in. “Promptly” is not vibes; it is a defined time period you set, measure, and enforce. “Accounts” means more than employee SSO: include contractors, interns, shared admin accounts (ideally eliminated), break-glass accounts, and service accounts used by applications and integrations.

A practical interpretation that passes audits:

• If the business relationship or authorization ends, disable access.
• If the account is no longer needed or becomes risky (for example, extended inactivity), disable it.
• If you allow exceptions, they must be documented, approved, and reviewed. ¹

Who it applies to (entity and operational context)

AC-2(3) commonly applies where NIST SP 800-53 is used as the security baseline, including:

• Federal information systems and programs adopting NIST controls.
• Federal contractors and service organizations that handle federal data or provide systems/services assessed against NIST SP 800-53. ²

Operationally, it applies to:

• Identity and Access Management (IAM) owners (Okta/Azure AD/Entra ID, Google Workspace, on-prem AD).
• IT operations (endpoint identity, local accounts, privileged access workflows).
• Security operations (monitoring, incident response, and detection of anomalous or stale accounts).
• HR/People Ops and Procurement/Vendor Management as trigger sources for joiner/mover/leaver events and contractor offboarding.
• Application owners for systems that are not integrated with centralized IAM (legacy apps, databases, network devices).

Third-party angle: if a third party’s personnel receive accounts in your environment (support engineers, implementation consultants), your disablement triggers must include contract end, ticket closure for temporary access, or sponsor revocation.

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

1) Define scope and account population (make the inventory real)

Create an account population list that you can reconcile:

• Human accounts (employees, contractors, interns)
• Privileged accounts (admin roles, cloud root-equivalent roles, PAM-managed accounts)
• Non-human accounts (service accounts, API tokens mapped to an identity record where possible)
• Local accounts on servers/network gear (if still present)

Deliverable: a system list with account sources and owners (IAM team vs app owner).

2) Set your disablement SLA and triggers (write them down)

Because the control uses “[time period],” you must set the parameter. Do this as a small decision record owned by the CISO/CCO/GRC lead with IAM sign-off. Typical trigger categories to define in your control card/runbook:

• Separation/offboarding: voluntary/involuntary termination, end of contract, end of engagement.
• Role change (mover): transfer that removes privileged access or access to regulated environments.
• Inactivity: accounts not used for a defined period, tuned by risk tier (privileged vs standard vs service).
• Policy or risk triggers: failed background check outcome, security incident involving the identity, sponsor removal for contractors, or access certification failure.

Also define exceptions:

• Litigation hold / investigation
• Critical service account that cannot be disabled without change control
• Planned leave (if you choose to disable, specify; if you choose not to, document the rationale)

Deliverable: a “requirement control card” with objective, owner, triggers, execution steps, and exception rules (recommended practice). ¹

3) Make one system authoritative for each trigger

Auditors will ask, “How do you know someone left?” Avoid manual email chains.

• Offboarding trigger source: HRIS for employees; vendor/contractor management roster for contractors; identity sponsor workflow for third-party access.
• Inactivity trigger source: IAM sign-in logs (SSO), PAM session logs, or application logs for non-SSO systems.

Document the mapping: Trigger → Source system → Control operator → Disable action path → Evidence output.

4) Implement disablement mechanics (automate first, then cover gaps)

Your disablement mechanism should be a layered model:

• Primary control: automatic disable in IdP directory on HRIS termination (or equivalent authoritative trigger).
• Secondary control: deprovision downstream apps via SCIM/provisioning connectors.
• Compensating control for gaps: ticket-driven disablement steps for non-integrated systems, with completion verification.

For privileged access:

• Remove admin roles first (fast path), then disable the base identity.
• If you use PAM, ensure checkout is blocked immediately when the trigger occurs.

For service accounts:

• Maintain an owner and purpose record.
• If a service account is tied to an app that is decommissioned or integration retired, disable the account through change management.

5) Add monitoring and control health checks (prove it keeps working)

Run recurring checks that detect drift:

• Accounts with no owner
• Accounts past inactivity threshold not disabled
• Terminated users still enabled
• Orphaned contractor identities with no sponsor
• “Break-glass” accounts enabled outside approved windows

Track findings to closure with due dates. This is how you show sustained operation, not a one-time cleanup. ¹

6) Define the minimum evidence bundle (so audits are cheap)

For each execution cycle (event-driven and periodic), define what evidence gets retained and where. Recommended practice is to standardize the bundle. ¹

A practical minimum bundle:

• Control design artifacts
  • Policy or standard covering account disablement
  • Control card/runbook (owner, triggers, SLA, steps, exceptions)
  • System scope list and RACI
• Control operating evidence
  • HRIS/offboarding report or termination feed extract (as input)
  • IAM event logs showing disable action timestamps (as output)
  • Deprovisioning logs (SSO/SCIM) or admin audit logs for key apps
  • Ticket records for manual deactivations (with timestamps and approvers)
  • Exception approvals with expiry and review notes
• Control health evidence
  • Periodic reconciliation report results
  • Remediation tracker items and closure evidence

Retention: store evidence in a controlled repository (GRC tool, secured evidence folder) with access controls and a naming convention tied to the audit period.

7) Operationalize with a simple workflow (what “good” looks like)

A workflow that works in real life:

1. Trigger occurs in HRIS / contractor roster / access review failure.
2. Automation disables identity in IdP; generates an event record.
3. Downstream provisioning removes app access; logs retained.
4. Any non-integrated apps create tickets to app owners with a required completion window aligned to your SLA.
5. Weekly reconciliation report flags outliers; GRC tracks remediation.

Where Daydream fits naturally: many teams fail on “prove it.” Daydream can serve as the control card + evidence bundle system of record, so you can attach trigger inputs, disablement outputs, and exception approvals to one control requirement without hunting across tools during audits. ¹

Required evidence and artifacts to retain (audit-ready checklist)

Use this checklist in your evidence request playbook:

• Account disablement policy/standard (approved, current)
• AC-2(3) control card/runbook (SLA, triggers, exceptions, owners)
• Role definitions for who can disable accounts and approve exceptions
• Sample set of disablement events with timestamps (terminate → disabled)
• Sample set of inactivity disables with supporting reports
• Tickets for manual disables in non-integrated systems
• Exception register with approvals, expiry dates, and periodic review outcomes
• Control health check results and remediation closure proof ¹

Common exam/audit questions and hangups

Expect these, and prepare the artifacts above to answer fast:

• “What is your defined [time period] and where is it documented?” ³
• “What events trigger disablement? Who decides and who executes?”
• “How do you ensure contractors and third-party users are disabled when engagements end?”
• “How do you handle accounts in systems not connected to SSO?”
• “Show me evidence for a sample of terminated users: termination date, disable date, and downstream deprovisioning.”
• “How do you prevent re-enablement without authorization?”
• “How do you manage exceptions, and how do exceptions expire?”

Frequent implementation mistakes and how to avoid them

• Mistake: Only disabling SSO, leaving local app accounts active.
  Fix: maintain a non-SSO system register and require app-owner attestations or ticket completion evidence.
• Mistake: Inactivity disablement defined, but no reliable signal.
  Fix: standardize on sign-in logs per system; for edge cases, run periodic access reviews and tie failure to disablement.
• Mistake: Service accounts have no owners.
  Fix: require an owner in your CMDB/IAM metadata; block creation without ownership.
• Mistake: Exceptions become permanent.
  Fix: enforce expiry dates and periodic review, with automatic reminders and re-approval requirements.
• Mistake: Evidence is scattered.
  Fix: define the minimum evidence bundle and central retention location; test evidence retrieval as part of control health checks. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, AC-2(3) maps to a common failure pattern in breaches and incidents: access persists after business need ends. That creates preventable pathways for unauthorized access, data exposure, and inability to prove effective access governance during assessments. Treat it as a control that reduces both likelihood (fewer valid credentials) and blast radius (fewer active privileged identities).

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Assign a single control owner (IAM or GRC with IAM operations owner).
• Publish the AC-2(3) control card: triggers, SLA, exceptions, and scope.
• Build the account/system inventory focusing on high-risk systems first (SSO, email, cloud consoles, production access).
• Define the evidence bundle and retention location; run a test evidence pull for one recent offboarding. ¹

Days 31–60 (implement and connect)

• Implement or tighten HRIS-to-IdP automation for disablement triggers.
• Add contractor sponsor workflow and an authoritative contractor roster trigger.
• Integrate downstream deprovisioning for top SaaS apps; document manual steps for the rest.
• Create recurring reconciliation reports for: terminated but enabled, inactive but enabled, no-owner accounts.
• Stand up an exception register with approval workflow and expiry tracking.

Days 61–90 (prove operation and harden)

• Run the first formal control health check; open remediation items with owners and due dates.
• Expand scope to legacy apps and infrastructure local accounts; require app owners to provide disablement evidence.
• Test an audit drill: pick a sample of disablement events and produce the full evidence bundle in one package.
• Add guardrails: prevent re-enable without ticket/approval; restrict who can re-enable and log the action. ¹

Frequently Asked Questions

What does “within [time period]” mean for AC-2(3)?

It means you must define a specific disablement SLA and then meet it consistently. Document it in your control card/runbook and measure actual disable timestamps against the trigger event timestamp. ³

Do I need to disable accounts in every application, or is disabling SSO enough?

Disabling the IdP is necessary but not sufficient if applications have local accounts or separate credentials. Maintain a list of non-integrated systems and require verified disablement evidence for each. ¹

How should we handle service accounts under AC-2(3)?

Treat them as in-scope accounts with named owners, purpose, and lifecycle triggers (integration retired, app decommissioned, credential compromise). Disable should follow change control where outages are possible, but exceptions must be documented and time-bounded. ¹

What evidence is most persuasive to auditors?

Time-stamped system logs or admin audit logs showing the disable action, tied to the triggering event record (HRIS termination, contractor end date, or inactivity report). Tickets help, but logs usually close the loop. ¹

We have contractors from third parties. Who is responsible for disabling their accounts?

You are responsible for accounts in your environment, even if the identity belongs to a third party. Require a sponsor model and a definitive end-of-engagement trigger source, then disable automatically or via enforced workflow. ¹

Can we keep accounts enabled for investigations after termination?

Yes, as an exception if you document the rationale, approval, compensating controls (for example, access blocked but data preserved), and an expiry/review cadence. Auditors will look for controlled exceptions, not informal one-offs. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 PDF

2. NIST SP 800-53 Rev. 5

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