AC-2(3): Disable Accounts

The ac-2(3): disable accounts requirement is easy to describe and surprisingly easy to fail in audits: you need a repeatable, provable way to disable accounts quickly when predetermined events occur. The control is written as a timing requirement (“disable accounts within [organization-defined time period]”) plus condition logic (“when the accounts…”). That means auditors will test two things: (1) did you clearly define the time window and the disabling conditions, and (2) can you demonstrate, with logs and tickets, that you actually met it for real events.

Operationally, AC-2(3) sits at the intersection of HR, identity and access management (IAM), IT service management (ITSM), and system owners. If any one of those groups operates on an informal “we usually remove access quickly” practice, you get gaps: orphaned accounts, active accounts for terminated users, service accounts that never get reviewed, and scattered system-specific processes.

This page translates AC-2(3) into a tight runbook: who owns it, what to configure, what to automate, what evidence to retain, and how to answer the audit questions that routinely stall teams.

Regulatory text

Excerpt (requirement): “Disable accounts within {{ insert: param, ac-02.03_odp.01 }} when the accounts:” ¹

What the operator must do with this text

• Define the parameter: The placeholder indicates your organization must set a specific time window for disabling accounts (for example, “within same business day” or “within X hours”). Your defined value becomes the SLA auditors test against. ¹
• Define the conditions: The “when the accounts:” clause means disablement is triggered by specific situations you document and enforce (common examples include user termination, transfer, contract end, or inactivity). The control expectation is not “disable accounts sometimes,” but “disable them reliably when conditions occur.” ²

Plain-English interpretation

You must be able to say, without hesitation:

1. Which accounts are in scope (workforce users, privileged admins, contractors, third-party accounts, service accounts, shared accounts if you allow them, break-glass accounts), and across which systems (SSO apps, cloud consoles, VPN, email, endpoint management, databases, production platforms).
2. What events require disabling (your trigger list).
3. How fast you disable after the event (your defined timeframe).
4. How you prove it happened (audit evidence that ties the event timestamp to the disable timestamp).

The fastest path to compliance is to treat AC-2(3) as an identity control with system-owner backstops. Centralize disablement in your identity provider (IdP) where you can, then implement compensating steps for “non-SSO” systems.

Who it applies to

AC-2(3) commonly applies in environments aligned to NIST SP 800-53, including:

• Federal information systems and programs using NIST 800-53 control baselines.
• Federal contractors and service organizations handling federal data or operating systems assessed against NIST controls. ²

Operational context where this becomes urgent:

• High churn roles (call centers, seasonal workforce, contractors).
• Decentralized SaaS sprawl where app owners provision directly.
• Engineering environments with many privileged pathways (cloud IAM, CI/CD, secrets managers).
• Third-party support access to production systems.

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

1) Write the control “control card” (your runbook)

Create a one-page control card with:

• Owner: IAM lead (primary), HR operations + ITSM (inputs), system owners (execution for non-integrated systems).
• In-scope accounts: workforce, contractors, third-party users, service accounts, privileged accounts, emergency access.
• Trigger events: termination, contract end, role change, access no longer required, inactivity threshold you define, policy violation requiring access suspension.
• Disablement SLA: your defined time period (the parameter).
• Exception rules: legal hold, investigations, regulated records retention (account disabled, data retained), and break-glass handling.
• Evidence bundle: exactly what you retain and where.
  This aligns to the practical expectation that teams can show ownership, cadence, and evidence for sustained operation. ²

2) Define “disable” precisely ²

Auditors will ask what “disabled” means. Define it per platform:

• SSO / IdP-managed apps: user set to suspended/disabled, sessions revoked, tokens invalidated where supported.
• Non-SSO apps: local account disabled, password randomized, API tokens revoked, SSH keys removed.
• Privileged access: remove from privileged groups/roles; disable the underlying identity if required; rotate shared credentials if any exist.
• Service accounts: disable if no longer required; otherwise restrict scope, rotate secrets, and attach ownership/expiry metadata.

Document these definitions in your standard and map them to systems.

3) Build your authoritative sources and integrations

You need a clear “source of truth” for joiner/mover/leaver status:

• HRIS drives employment status for employees.
• Contractor management / procurement drives end dates for non-employees and third parties.
• IAM/IdP enforces disablement downstream.

Implementation pattern:

• HRIS/contractor system updates status → automated workflow opens ITSM ticket and/or triggers IAM action → IdP disables user → downstream systems deprovision automatically or via tasks.

4) Implement automated disablement for the majority case

Automation is how you meet your disablement window reliably.

• Configure HR-driven provisioning (or equivalent) so termination immediately triggers disablement.
• For apps behind SSO, configure SCIM deprovisioning where available.
• For endpoint and VPN access, integrate identity status so disabled users cannot authenticate.

Where automation is not possible, implement a manual but measurable workflow:

• Termination event creates a high-priority ticket with tasks for each non-integrated system.
• Require completion evidence (screenshots, exported admin logs, or API event logs).

5) Close the “stragglers” problem: discovery and reconciliation

Even good IAM programs miss accounts.

• Maintain an application inventory of systems that hold identities (including niche admin consoles and legacy tools).
• Run recurring reconciliations: compare HR/contractor rosters to active accounts in key systems, and compare IdP-disabled users to app-local active users.

Your goal is to detect:

• Accounts that stayed active after the trigger event.
• Local accounts not governed by IdP.
• Service accounts with no owner or no last-used date.

6) Put SLAs and escalation into operations

Define:

• SLA clock start (timestamp of HR termination, manager request approval, contract end time).
• SLA stop (timestamp of disable action in IdP/app).
• Escalation (missed SLA pages IAM/on-call, notifies system owner, creates audit log entry).

Track misses to closure with a remediation ticket and root-cause tag (integration gap, unclear ownership, app not in inventory). This supports control health checks and sustained operation. ²

7) Manage exceptions without breaking the control

Typical exception: “We need mailbox/data access for business continuity.”
Handle it like this:

• Disable the user account on time.
• Grant delegated access to a manager or shared mailbox as a separate, approved access request.
• Retain approvals and configuration evidence.

For incident investigations: disable interactive access, preserve logs, and grant time-bound investigator access through documented channels.

Required evidence and artifacts to retain

Retain evidence that proves timely disablement, complete scope, and repeatability:

Policy and design artifacts

• Access control / account management standard stating disablement triggers and timeframe (your parameter). ²
• Control card/runbook with owner, triggers, steps, exceptions.
• System inventory indicating which systems are IdP-managed vs manual.

Operational evidence (the audit gold)

• HR/contractor termination or end-date records (event timestamp).
• IAM/IdP audit logs showing disablement timestamp.
• ITSM tickets for manual systems with completion timestamps and approver.
• Admin console exports or screenshots for non-integrated apps showing user status disabled.
• Privileged access change logs (group/role removal) for affected identities.

Ongoing assurance

• Reconciliation reports and remediation tickets.
• Control health check results and open/closed action items.

A practical tip: store evidence in a single control folder with a consistent naming scheme per event. Daydream can help by generating a control card template, defining the minimum evidence bundle, and tracking recurring health checks so you can show sustained operation without scrambling. ²

Common exam/audit questions and hangups

Expect these questions:

• “What is your defined timeframe for disabling accounts?” If you cannot state it and show where it’s approved, you will stall. ¹
• “What events trigger disablement?” Auditors test real samples: terminations, transfers, contractor offboarding.
• “Show me 10 terminated users and prove they were disabled within the SLA across email, VPN, and cloud console.”
• “How do you handle accounts not connected to SSO?” “We email the app owner” is not a control.
• “How do you control service accounts?” Ownership, purpose, and disable rules must be documented.

Frequent implementation mistakes and how to avoid them

1. Policy-only compliance: A written standard with no logs, no tickets, and no sampling evidence.
   Fix: define the evidence bundle and collect it per cycle.

2. No explicit SLA: Teams say “promptly.” The control requires an organization-defined time period.
   Fix: set a clear disablement window and document it. ¹

3. Incomplete scope: Only workforce accounts are covered; contractors, third parties, and service accounts are ignored.
   Fix: include all identity types that can authenticate to in-scope systems.

4. IdP blind spot: Assuming disabling in IdP disables everything. Local accounts persist.
   Fix: inventory and reconciliation; track “non-SSO” systems as explicit manual control steps.

5. Exceptions turn into permanent bypasses: “VIPs” or “mailbox access” becomes a reason not to disable.
   Fix: disable the account, provide separate delegated access with approval.

Risk implications (why operators care)

If you miss AC-2(3), you create a known, repeatable path to unauthorized access: former employees, expired contractors, and abandoned privileged accounts. The risk is operational (fraud, data loss), investigative (unclear attribution), and audit-driven (control failure with sampling evidence). NIST frames this requirement as part of disciplined account management expectations. ²

A practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Set the organization-defined disablement timeframe and document it in your standard and control card. ¹
• Publish trigger events and scope (include third-party and service accounts).
• Identify top systems to test: IdP, email, VPN, cloud console, endpoint tool, ticketing.
• Start evidence collection on every termination event for a short pilot sample.

Days 31–60 (automate and close coverage gaps)

• Implement HR-to-IdP termination automation if missing.
• Turn on SCIM deprovisioning for high-risk SaaS where supported.
• Build the manual workflow for non-integrated apps with ITSM tasking and required completion proof.
• Stand up a reconciliation report for at least one high-risk platform category (privileged access or cloud IAM).

Days 61–90 (prove operation and harden)

• Run a formal control health check: sample terminations and validate disablement timeliness and completeness.
• Fix systemic misses (app not in inventory, unclear owner, broken integration).
• Create a standing cadence for reconciliation and remediation tracking tied to your GRC calendar.
• Prepare an “audit packet” with the control card, standard, sample evidence, and reconciliation outputs.

Frequently Asked Questions

What does “disable” mean versus “delete” for AC-2(3)?

AC-2(3) calls for disabling within your defined timeframe; deletion is not required by the excerpt you’re implementing. Define “disabled” per system (no authentication, no active tokens, privileged roles removed) and keep evidence that shows the status change. ¹

Do contractor and other third-party accounts have to follow the same disablement SLA?

If the account can authenticate to in-scope systems, treat it as in scope and apply the same triggers and SLA unless you document a justified exception. The common failure is offboarding via email without timestamps or proof.

How should we handle “mailbox access after termination” without violating AC-2(3)?

Disable the terminated user’s account on time, then provide delegated access or export data through an approved request. Keep the disablement log plus the approval and configuration record for the delegated access.

What evidence do auditors usually accept for disablement?

The strongest evidence links the trigger event timestamp (HR/contract end or approved request) to the disablement timestamp (IdP/app audit log) with a ticket trail for any manual steps. Screenshots alone are weak unless they include system time and user status plus a change record.

We use SSO for most apps. Do we still need reconciliations?

Yes. SSO reduces risk but does not eliminate local accounts, API tokens, and niche admin consoles. A simple reconciliation between terminated users and app-local active accounts catches the failures auditors like to sample.

Who should own the ac-2(3): disable accounts requirement in practice?

Assign primary ownership to IAM/security, with HR operations as the trigger source and IT/system owners accountable for systems outside centralized identity control. Put those roles and handoffs in the control card so audits don’t turn into finger-pointing. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5