Account Management | Disable Accounts for High-Risk Individuals

To meet NIST SP 800-53 Rev. 5 AC-2(13) in a FedRAMP context, you must disable any user account tied to an individual who is determined to pose significant risk, within a time limit you define and can prove you meet. Operationalize this by defining “significant risk,” establishing triggers and owners, and executing rapid, logged disablement across all identity and application accounts. ¹

Key takeaways:

• Define “significant risk” and your disablement SLA in policy, then map it to real triggers (HR, insider threat, fraud, legal).
• Build an end-to-end kill switch: identity provider disablement plus downstream account/session/token revocation.
• Keep evidence that proves timeliness, authorization, scope, and completeness of disablement actions.

AC-2(13) is a requirement about speed and decisiveness under uncertainty: once you discover an individual poses significant risk, you disable their accounts within a defined time period. The hard part is not writing the policy. The hard part is making sure you can execute disablement quickly across your full estate (IdP, SaaS apps, cloud consoles, admin panels, break-glass accounts) and then prove to assessors that it happened within your stated window. ¹

For FedRAMP-bound systems, this shows up in assessor testing and continuous monitoring as a design-and-operation question: do you have clear triggers, do the right people have authority to act, and do your logs/tickets show you met your own timeline? Poor implementation creates two immediate risks: lingering access for a high-risk person (insider threat, fraud, sabotage) and an inability to defend access decisions during authorization or annual assessment activities. ¹

This page turns the control text into an operator-ready playbook: applicability, definitions you need to choose, step-by-step execution, required artifacts, common audit hangups, and a practical rollout plan you can run as a CCO, security GRC lead, or compliance owner.

Regulatory text

Requirement (verbatim): “Disable accounts of individuals within an organization-defined time period of discovery of significant risk posed by the individual.” ¹

What the operator must do

You must do three things, and assessors will look for all three:

1. Define your time period (your internal SLA) from “discovery” to “account disabled.” Your choice must be explicit and testable. ¹
2. Define what qualifies as “significant risk” and what counts as “discovery” (who can declare it, and through which channels). ¹
3. Disable accounts for the identified individual across the systems in scope, then retain evidence showing you met your SLA. ¹

Plain-English interpretation

If you learn that a person with access has become high-risk, you cannot wait for the next quarterly access review or standard offboarding. You need a documented trigger and a fast path to shut off their access, including privileged access, remote access, and any “shadow” accounts that bypass the primary identity system. Your policy must be matched by real workflows, permissions, and logs that show the shutoff happened on time. ¹

“High-risk” here is broader than termination. Common real triggers include credible insider-threat indicators, suspected fraud, legal/regulatory restrictions, violent threats, serious policy violations, confirmed malware involvement, or coercion/blackmail risk. The standard does not force a single definition; it forces you to define yours and execute it consistently. ¹

Who it applies to (entity and operational context)

Entities

• Cloud Service Providers (CSPs) operating a FedRAMP-authorized system boundary. ¹
• Federal Agencies operating or overseeing systems within the authorization boundary. ¹

Operational context (where this control “lives”)

This is an account lifecycle and incident-response-adjacent requirement. It typically involves:

• Identity and Access Management (IAM) / directory services team
• Security Operations / Insider Threat / Incident Response
• HR and Legal (as trigger sources and approvers)
• Application owners (to ensure downstream apps lose access)
• GRC/compliance (to define SLA, testing, and evidence)

If you use third parties (contractors, MSPs, consultants) with accounts inside your boundary, treat them the same way. “Individual” is role-agnostic; it’s about risk posed by the person with credentials.

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

Step 1: Define “significant risk” and “discovery” in one page

Create a short standard that answers:

• Risk criteria: What conditions qualify? Use categories (insider threat referral, HR escalation, legal hold, confirmed policy breach, credible threat, suspected credential compromise tied to a person, etc.).
• Discovery sources: Who can declare discovery (SOC lead, Insider Threat PM, HR director, Legal), and what artifacts count (case ID, ticket, HR file reference, hotline report ID).
• False-positive handling: You can re-enable later, but your default should favor disablement when criteria are met.

Keep it operational. Avoid philosophical language.

Step 2: Set an “account disablement SLA” you can meet

AC-2(13) requires an organization-defined time period. Pick a time window that fits your operating model and staff coverage, then engineer for it. Document:

• Start time: timestamp of the “discovery” event in your case system/ticketing
• End time: timestamp the account is disabled in the IdP/directory (plus downstream actions completed or queued)

Auditors will test whether you meet your own SLA, not a generic industry target. ¹

Step 3: Build a kill-switch workflow (with clear ownership)

Implement a standard runbook with:

• Intake channel: a single “High-Risk Account Disablement” request type in your ticketing/IR system
• Authority: who can approve disablement (and who can execute without prior approval in emergencies)
• Executor: primary and backup on-call teams
• Mandatory steps checklist: disable primary identity, revoke sessions, remove privileged roles, disable VPN, and disable local/system-specific accounts

This must work after hours. If your SLA implies rapid action, you need coverage to match.

Step 4: Scope the systems you must disable (don’t stop at the directory)

Create and maintain an “Account Disablement Coverage Map” that lists:

• System of record identity: IdP/directory (e.g., Entra ID/AD/Okta)
• Privileged access tooling (PAM)
• Cloud provider consoles (AWS/GCP/Azure roles)
• CI/CD and code repositories
• Ticketing/admin tools
• Database consoles, jump boxes, VPN, VDI
• Any application with local users (break-glass admin panels are common gaps)

Tie each system to a disablement method (SCIM, API, manual, or via group removal). Update this list as part of change management.

Step 5: Execute disablement with completeness checks

For each high-risk case, execute in this order:

1. Disable the primary identity (directory/IdP account) and force sign-out where supported.
2. Revoke active sessions and tokens (IdP session invalidation, OAuth token revocation where possible).
3. Remove privileged access (PAM disablement, admin group removal, cloud role removal).
4. Disable remote access (VPN/VDI) and rotate shared secrets the individual knew (service account passwords, break-glass vault access).
5. Hunt for secondary accounts (local app users, unmanaged accounts, test accounts tied to the person).
6. Validate: confirm authentication fails and privileges are gone; capture screenshots/log extracts.

Step 6: Handle exceptions without breaking the control

Sometimes you cannot disable immediately (e.g., legal direction to preserve access for monitoring, or operational safety constraints). If you take an exception:

• Require written approval from an authorized leader (Security + Legal/HR as appropriate)
• Implement compensating controls (enhanced monitoring, step-up auth, restricted network access)
• Set a review time and re-approval cadence
• Keep the exception record with the case

Step 7: Test the control like an assessor would

Run tabletop tests and “walkthrough evidence”:

• Pick recent cases (or run simulations) and show timestamps from discovery to disablement
• Prove downstream coverage (not just the IdP)
• Show that approvals and roles match your written procedure

FedRAMP assessment expectations often center on whether you can demonstrate operation with artifacts, not just intent. For documentation structure and common SSP patterns, align to FedRAMP templates. ²

Required evidence and artifacts to retain

Keep evidence that answers: who, what, when, where, and proof it worked.

Minimum artifact set (practical):

• Policy/standard defining significant risk, discovery, SLA, roles, and authority (maps to AC-2(13)). ¹
• Runbook / SOP for high-risk account disablement.
• System coverage map listing all systems and disablement method.
• Case/ticket records with:
  • discovery timestamp and source
  • approval (or emergency authorization)
  • execution timestamps
  • executor identity
• System logs/audit trails from IdP, PAM, VPN, and key apps showing disablement and privilege removal.
• Validation evidence (test login failure, access denied, removed role screenshot/log).
• Exceptions register with compensating controls and approvals.
• Periodic QA review results (sample checks that SLA is met and disablement is complete).

Daydream (or any GRC system) fits best here when it is used to: standardize the trigger-to-ticket workflow, map systems to evidence requirements, and produce assessor-ready evidence packets without scrambling across tools.

Common exam/audit questions and hangups

Expect these lines of questioning in FedRAMP assessments and internal audits:

• “What is your organization-defined time period?” Show the written SLA and demonstrate multiple instances where you met it. ¹
• “Define ‘significant risk’.” If your definition is vague (“at management discretion”), expect a finding.
• “What counts as discovery?” Auditors will test whether your “clock start” is consistent.
• “How do you ensure disablement across all systems?” They will look for local accounts and privileged access paths.
• “Who can approve and who can execute?” Separation of duties and emergency authority must be documented and followed.
• “Show evidence.” A verbal walkthrough without logs/tickets is rarely enough.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	How to avoid it
SLA exists only in a policy PDF	You can’t prove consistent operation	Put the SLA into the ticket template and report on it
Disabling only the IdP account	Sessions, tokens, local accounts, and cloud roles can persist	Include token revocation, PAM disablement, and a downstream checklist
No clear “discovery” definition	Timeline becomes subjective and untestable	Define discovery sources and authorized declarers
Exceptions handled informally in Slack/email	No governance, no compensating controls	Use an exceptions register with explicit approvals and monitoring
Privileged access left behind	Highest-impact abuse path remains	Remove admin roles early and validate
Contractors treated differently	Access persists in third-party managed accounts	Extend the same trigger and disablement process to third-party identities

Enforcement context and risk implications

No specific public enforcement cases were provided for this requirement in the supplied sources, so don’t anchor your program to enforcement narratives. The practical risk is still clear: if you fail to disable accounts promptly after discovering significant risk, you increase the chance of unauthorized access, sabotage, data exfiltration, or compliance-impacting incidents. Separately, weak evidence creates authorization and continuous monitoring friction because assessors cannot verify your stated control operation. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Write the one-page Significant Risk + Discovery + SLA standard and get Security, HR, and Legal sign-off. ¹
• Create the high-risk disablement ticket type with required fields and approval routing.
• Inventory systems in scope and draft the Account Disablement Coverage Map.
• Identify the executor team and establish after-hours coverage expectations aligned to your SLA.

Days 31–60 (build repeatable execution)

• Publish the disablement runbook with a checklist and validation steps.
• Integrate where possible: IdP disablement plus automated downstream deprovisioning (SCIM/APIs) for top systems.
• Stand up an exceptions workflow with required compensating controls and a register.
• Run two internal simulations and fix gaps (local accounts, cloud roles, stale admin groups).

Days 61–90 (prove it and prepare for assessment)

• Start monthly QA sampling of cases (real or simulated) against the SLA and completeness checklist.
• Package an assessor-ready evidence set: policy, runbook, coverage map, sample tickets, and logs aligned to AC-2(13). ¹
• Align documentation format to FedRAMP expectations (SSP/control implementation details and attachments conventions). ²
• If you use Daydream, configure a control page and evidence requests so each case automatically collects required artifacts and timestamps.

Frequently Asked Questions

What counts as “significant risk” for AC-2(13)?

You define it, but it must be specific enough that different teams make the same call. Most programs tie it to insider threat referrals, HR/legal escalations, suspected fraud, credible threats, or confirmed serious policy violations. ¹

Does disabling the account in the IdP satisfy the requirement?

Usually not by itself. Assessors commonly expect you to address downstream access paths such as cloud roles, PAM, VPN/VDI, and apps with local users, and to validate the disablement worked. ¹

When does the “time period of discovery” clock start?

Define “discovery” in your procedure (for example, creation of an insider threat case or a specific ticket type) and apply it consistently. Your evidence should show a clear timestamp that starts the SLA clock. ¹

Can we keep access enabled for monitoring purposes?

If you do, treat it as an exception with written approval and compensating controls such as heightened monitoring and tighter network restrictions. Keep the exception record with the case so an assessor can follow the rationale. ¹

How does this relate to normal offboarding and termination?

Offboarding handles expected lifecycle events; AC-2(13) is a fast-path for elevated risk scenarios that can occur before termination or without termination. Your processes can share tooling, but AC-2(13) needs its own trigger and SLA. ¹

What evidence is most persuasive in a FedRAMP assessment?

Time-stamped tickets tied to the discovery event, IdP and system logs showing disablement and role removal, and a coverage map proving you addressed all access paths. Using FedRAMP documentation conventions reduces back-and-forth with assessors. ²

Footnotes

1. NIST Special Publication 800-53 Revision 5

2. FedRAMP documents and templates