AC-2(13): Disable Accounts for High-risk Individuals

AC-2(13) requires you to disable accounts for “high-risk individuals” within a defined time window after you discover a qualifying high-risk condition. To operationalize it, you need (1) a clear definition of “high-risk,” (2) monitored discovery triggers, (3) automated or tightly run disablement workflows, and (4) audit-ready evidence that ties discovery time to disablement time. ¹

Key takeaways:

• Define “high-risk individual” and “discovery events” in writing, then map them to real identity sources (HR, SOC, Insider Risk, legal).
• Build a time-bound, measurable disablement SLA that you can prove from system logs, not emails.
• Retain an evidence bundle that shows the clock start, the action taken, who approved exceptions, and how access was restored (if ever).

The ac-2(13): disable accounts for high-risk individuals requirement is a time-based access control obligation: once you discover a specified high-risk condition, the organization must disable the individual’s account within a defined timeframe. The control text is short, but the implementation work is not. Most control failures come from ambiguity (“Who counts as high-risk?”), poor clock-start definitions (“When did we ‘discover’ it?”), and gaps between systems (HR knows, but IAM does not; SOC escalates, but IT does not act).

This requirement typically sits at the boundary of security operations, identity and access management (IAM), HR/people operations, and legal or investigations. Your job as a Compliance Officer, CCO, or GRC lead is to turn an abstract statement into an operational control with unambiguous triggers, owners, steps, and evidence. That means you need a runbook, automation where possible, and exception handling that does not quietly turn into “we didn’t disable it.”

If you want this to survive audits and customer due diligence, treat AC-2(13) like an incident-response-adjacent control: measurable, time-stamped, and tested. ²

Regulatory text

Control requirement (verbatim): “Disable accounts of individuals within {{ insert: param, ac-02.13_odp.01 }} of discovery of {{ insert: param, ac-02.13_odp.02 }}.” ¹

What the operator must do

1. Set the parameters. Your system security plan (SSP) or control implementation statement must define:
   • The time window (“within X of discovery”).
   • The high-risk condition(s) that start the clock (“discovery of Y”). ¹
2. Detect discovery events reliably. You need monitoring and intake paths that make discovery time defensible (ticket timestamps, SIEM alerts, HR case creation, legal notice).
3. Disable access consistently. Disablement must cover all relevant account types in scope for the system: workforce identity, admin roles, application accounts, remote access, and any local accounts that still exist.
4. Prove it with timestamps. You must be able to show auditors the discovery timestamp, the disablement timestamp, and the account state change in authoritative logs.

Plain-English interpretation

When someone becomes “high-risk” (by your defined criteria) and you find out, you must quickly remove their ability to access systems by disabling their accounts. The intent is to reduce insider-threat and fraud risk by shrinking the time between risk identification and loss of access. The control expects speed plus proof: “We disabled the account” is not enough without evidence showing how fast you acted and what exactly was disabled. ²

Who it applies to

Entities

AC-2(13) commonly applies to:

• Federal information systems and programs aligned to NIST SP 800-53.
• Federal contractors and service organizations handling federal data where 800-53 is contractually flowed down or used as the security baseline. ²

Operational context (where it shows up in practice)

• Workforce identities: employees, contractors, temps, and interns.
• Privileged access: admins, cloud console users, database admins, CI/CD admins.
• Third-party access: consultants, support providers, outsourcing partners with direct logins. ²

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

Step 1: Write the control card (your “runbook in one page”)

Create a requirement-level control card that includes:

• Objective: Disable accounts for high-risk individuals within the defined time window after discovery.
• Owner: Name a primary owner (often IAM lead) and a compliance owner (GRC) who validates evidence.
• Trigger events: Enumerate “discovery of high-risk condition” sources (HR, SOC, insider risk, legal).
• Systems in scope: List identity providers, directories, privileged access tools, and key apps.
• Exception rules: Emergency access needs, investigations, break-glass handling, and who can approve exceptions. This addresses a common audit failure: teams cannot show ownership and operating mechanics. ²

Step 2: Define “high-risk individual” and “discovery” in operational terms

You do not need an essay. You need an implementable definition:

• High-risk individual categories (examples to tailor):
  • Under HR investigation for policy violations tied to system misuse.
  • Identified by SOC/IR as suspected compromised credentials tied to an individual.
  • Legal or insider risk flags indicating heightened misuse risk.
  • Terminated for cause, especially for security-relevant reasons.
• Discovery definition: Pick the authoritative system-of-record for “discovered at,” such as:
  • The timestamp when an HR case is created with a qualifying label.
  • The timestamp when a SOC alert is promoted to an incident ticket with a specific classification.
  • The timestamp when legal/investigations issues a documented access restriction request. Document these choices so you can defend them in an audit. ¹

Step 3: Map triggers to disablement actions (make a coverage matrix)

Build a matrix that answers: “If the trigger happens, what do we disable, where, and how?”

Trigger source	Trigger artifact	Account types to disable	Execution mechanism	Evidence output
HR / People Ops	HR case or termination event	SSO, directory, email	HRIS→IAM workflow or IT ticket	IAM event log + ticket closure
SOC / IR	Incident ticket classification	SSO, VPN, privileged roles	SOAR playbook or IAM admin action	SIEM alert + change log
Insider Risk / Legal	Written restriction request	App accounts, shared access	Access change ticket + approvals	Approved ticket + app audit logs

The point is to prevent “we disabled SSO but forgot VPN” failures.

Step 4: Implement the disablement workflow (automation first, then tight manual)

Minimum viable workflow:

1. Intake: A discovery event creates a tracked work item (ticket/IR case) with the individual identifier(s).
2. Identity resolution: Confirm the person’s canonical identity and linked accounts (SSO, directory, privileged accounts).
3. Disable: Execute disablement actions across systems in scope.
4. Validate: Confirm account status is disabled and tokens/sessions are handled per your standard (where your tooling supports it).
5. Record: Attach proof to the case (logs/screenshots/exports) and close with timestamps.

Where possible, automate:

• HRIS-driven disablement for HR events.
• SOAR-assisted disablement for IR events.
• Privileged access management actions for admin role removal. ²

Step 5: Build exception handling that does not gut the control

You will get edge cases: litigation hold, monitoring during an investigation, or safety concerns. Handle them with:

• Documented exception request (why disablement cannot occur immediately).
• Compensating controls (temporary access restriction, increased monitoring, role reduction).
• Time-bound approval by a named authority (security leadership + HR/legal as needed).
• Revalidation before extending the exception.

Auditors typically accept exceptions when they are controlled, approved, and time-bound, and when you can show you still reduced risk.

Step 6: Define the minimum evidence bundle (audit-ready by default)

Store evidence centrally (GRC repository, ticketing system with retention, or a controlled evidence folder). Your bundle per event should include:

• Trigger artifact (HR case ID, incident ticket ID, legal request).
• Discovery timestamp (system timestamp, not a human recollection).
• Identity/account mapping output (list of accounts disabled).
• Disablement proof:
  • IAM/SSO audit logs showing “account disabled” action.
  • Directory logs (if separate).
  • Privileged role removal logs.
• Approvals and exceptions (if any).
• Closure note that includes who executed and who validated. ²

Daydream tip: build an evidence checklist tied to the control card so each execution produces the same artifacts every time, not a bespoke scramble during audit season.

Common exam/audit questions and hangups

• “How do you define ‘high-risk’?” Expect a request for written criteria and examples mapped to trigger sources.
• “What starts the clock?” Auditors will test whether “discovery” is defined and consistently used.
• “Show me three examples.” They will pick samples and ask you to prove timestamps and disablement across systems.
• “What about privileged and non-SSO accounts?” They often look for local accounts, service accounts with human ownership, and legacy apps outside SSO.
• “How do you know it works when HR/SOC misses something?” They may ask about detective controls, periodic reviews, and reconciliation checks. ²

Frequent implementation mistakes (and how to avoid them)

1. Mistake: “High-risk” is a vibe, not a definition.
   Fix: Publish a short, testable definition with named trigger events and owning functions.
2. Mistake: Only disabling the primary SSO account.
   Fix: Maintain an application/account inventory for access paths and include VPN, PAM, and direct app accounts in the matrix.
3. Mistake: Discovery is tracked in email/Slack.
   Fix: Require a system-of-record case/ticket for every trigger and treat that timestamp as the clock start.
4. Mistake: Exceptions become permanent.
   Fix: Require expiring approvals and compensating controls; re-approve with documented rationale.
5. Mistake: Evidence is screenshots with no linkage.
   Fix: Use exportable logs where possible and attach them to the case with the user identifier and timestamps. ²

Enforcement context and risk implications

No public enforcement cases were provided in the source material for this specific enhancement, so do not frame this as “regulators fined X for AC-2(13).” What you can say internally is straightforward: failure to rapidly disable accounts for high-risk individuals increases the likelihood and impact of insider misuse, unauthorized access after HR actions, and extended dwell time after credential compromise. This control is also a due-diligence flashpoint for federal customers and prime contractors because it is measurable and sample-testable. ²

Practical 30/60/90-day execution plan

Use phases rather than calendar promises. Your goal is operational control plus evidence, not a slide deck.

First 30 days (Immediate)

• Assign control owner(s) and publish the one-page control card (objective, triggers, steps, exceptions).
• Define “high-risk” categories and “discovery” clock-start sources with HR, SOC, and legal.
• Create the coverage matrix for systems and account types; identify gaps (apps not in SSO, orphaned admin accounts).
• Define the minimum evidence bundle and where it will be retained. ²

By 60 days (Near-term)

• Implement or tighten workflows:
  • HRIS-triggered disablement (or a mandatory ticket path if automation is not possible).
  • SOC/IR-triggered disablement playbook tied to incident classification.
• Build exception workflow with expiring approvals and compensating controls.
• Run a tabletop: simulate a high-risk discovery and collect the full evidence bundle end-to-end.

By 90 days (Ongoing operations)

• Start recurring control health checks:
  • Reconcile HR terminations/investigations against disabled accounts.
  • Review a sample of high-risk cases for time-to-disable and evidence completeness.
• Track remediation items to validated closure with due dates, and keep that log audit-ready. ²

Frequently Asked Questions

What counts as a “high-risk individual” for AC-2(13)?

NIST leaves the definition to you via the control parameters, so you must document specific categories and triggers that your organization treats as high-risk. Pick definitions that map to real discovery sources like HR cases, incident tickets, or legal requests. ¹

What does “within X of discovery” mean in practice?

You need to define both the time window and what event starts the clock, then enforce that definition consistently. Auditors will expect system timestamps that show when discovery occurred and when disablement occurred. ¹

Do we have to disable every account type or just the main login?

Scope it to the system boundary you are assessing, but your workflow should cover all access paths that let the individual reach that system, including privileged roles and non-SSO accounts where they exist. Your coverage matrix is how you prove completeness. ²

How should we handle shared accounts or service accounts tied to a person?

Treat any human-owned shared or “service” credential as an access path that must be addressed when the owner becomes high-risk. The clean approach is to remove the person’s knowledge/control of the credential and rotate secrets while you disable or reassign the account.

What evidence is usually persuasive to auditors?

Time-stamped tickets or cases that show discovery, plus IAM/directory/PAM audit logs showing the disable action and the resulting account state. Keep approvals and exception documentation attached to the same record so the story is complete. ²

We have multiple identity systems. Who should own AC-2(13)?

Put operational ownership with the IAM function that can execute disablement across systems, and require HR/SOC/legal to own trigger quality. GRC should own testing, evidence standards, and issue tracking to closure. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5