Safeguard 5.3: Disable Dormant Accounts

Safeguard 5.3: disable dormant accounts requirement means you must identify accounts that have not been used for a defined period and disable them (or otherwise prevent authentication) in a repeatable, auditable way. Operationalize it by setting a clear dormancy threshold per account type, running scheduled detection across all identity stores, documenting exceptions, and retaining evidence of timely disablement. ¹

Key takeaways:

• Define “dormant” per account type (workforce, privileged, service, third party) and document exceptions with owner approval.
• Automate discovery and disablement across every system that can authenticate users, not just your primary directory.
• Keep assessor-ready evidence: population, dormancy results, disablement actions, and exception tickets for each review cycle.

Dormant accounts are one of the easiest ways for attackers, former employees, or over-provisioned third parties to regain access without triggering your “new account” controls. Safeguard 5.3: disable dormant accounts requirement focuses on preventing that scenario by making inactivity a hard stop: if an account isn’t used, it should not remain capable of authenticating indefinitely. ¹

For a Compliance Officer, CCO, or GRC lead, the practical challenge is rarely “do we agree with the requirement?” It’s operational scope and evidence: which identity systems are in-scope, what counts as inactivity, who approves exceptions, and how you prove the control runs consistently. If you only disable accounts in your HR-driven IAM but leave local admin accounts, SaaS-native users, or third-party support portals untouched, you will still fail the intent of the safeguard.

This page gives requirement-level implementation guidance: who must comply, how to implement it step-by-step, what artifacts auditors ask for, and how to avoid common failure modes. It is written to help you assign work to IAM, IT Ops, Security Ops, and application owners and get to stable, recurring evidence capture quickly. ¹

Regulatory text

Framework requirement: “CIS Controls v8 safeguard 5.3 implementation expectation (Disable Dormant Accounts).” ¹

Operator interpretation of the text: You must (1) define what “dormant” means in your environment, (2) continuously or periodically detect accounts that meet that dormancy definition, and (3) disable those accounts so they can no longer authenticate. The control is not “review sometimes.” The expected outcome is disabled access for inactive identities, plus a traceable record of the decision and action. ¹

Plain-English interpretation (what the requirement is really asking)

You need a consistent mechanism to remove login capability from accounts that are no longer actively used. “Dormant” is determined by inactivity signals (for example, last login) and policy decisions (for example, different thresholds for privileged vs. standard accounts). Your program must cover:

• Where accounts live: directories, SaaS applications, cloud consoles, VPNs, databases, and any system with its own identity store.
• Which accounts matter: employee, contractor, third party, privileged/admin, break-glass, and service accounts.
• How you prove it: a recurring report or export of dormant accounts, the disablement actions taken, and documented exceptions. ¹

Who it applies to (entity and operational context)

Entities: Enterprises and technology organizations implementing CIS Controls v8. ¹

Operational scope: Any environment with user authentication, including:

• Central IAM (IdP), directories, and SSO integrations
• Cloud providers and management planes
• SaaS apps with direct logins or local user tables
• Remote access (VPN, VDI, jump hosts)
• Privileged access tooling and local admin accounts
• Third-party access paths (support portals, managed service access) ¹

Practical scoping rule: If an account can authenticate to a production system or to sensitive data, it is in-scope for dormancy disablement, even if it is “owned” by a business unit or external party.

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

Step 1: Define dormancy criteria by account class

Create a small decision table and get it approved by Security + IT + application owners:

Account class	Dormancy signal	Action	Exception path
Workforce (standard)	Last interactive login	Disable at threshold	Manager-approved ticket
Privileged/admin	Last privileged use + last login	Disable faster than standard	Security-approved ticket
Third party	Last login + contract status	Disable at threshold; remove group access	Sponsor-approved ticket
Service accounts	Non-interactive use metrics	Rotate/disable if unused	System owner approval
Break-glass	No interactive use expected	Keep enabled but compensating controls	Document rationale

You do not need one global threshold, but you do need a documented rule per class and a consistent workflow. ¹

Step 2: Build a complete “account population” inventory

Your weakest point is almost always “unknown accounts.” Create an authoritative list of identity stores and applications that can authenticate. Include:

• IdP / directory (primary source of truth)
• Cloud tenants and admin consoles
• High-risk SaaS (finance, HR, customer data, code repos)
• On-prem systems with local accounts
• Third-party remote support tools

Deliverable: an in-scope systems list with a named technical owner and a method to extract last-login or usage data. ¹

Step 3: Implement detection (scheduled and repeatable)

Detection can be automated scripts, IAM reports, or SIEM queries, but it must be repeatable. Minimum operator standard:

• A scheduled job or recurring runbook produces a list of accounts exceeding the dormancy threshold.
• The output includes account identifier, system, last activity timestamp (if available), and account type.
• The output is stored in an evidence location with access controls.

If some systems cannot provide last-login data, document that limitation and use a compensating signal (for example, last password change, last token use, or last successful authentication event from logs). ¹

Step 4: Disable dormant accounts with controlled workflow

Disablement should be:

• Fast: no long manual back-and-forth for routine cases.
• Safe: avoid breaking production integrations by treating service accounts separately.
• Auditable: every disablement ties back to a detection record and a ticket/change record.

Typical workflow:

1. Detection produces candidate list.
2. System owner reviews for false positives (service accounts, seasonal workers, etc.).
3. Approved candidates are disabled.
4. Any exceptions require a ticket with: business justification, risk acceptance, compensating controls, and an expiration/review date.
5. Re-enable requires the same approvals as provisioning, plus verification of identity and continued need.

Step 5: Add governance and recurring evidence capture (the part auditors care about)

Safeguard 5.3 often fails in audits because teams “do it” but cannot prove it consistently. Build a control operation pack:

• Control description mapped to Safeguard 5.3
• Run frequency and responsible role
• Evidence checklist (what is saved each run)
• Exception handling rules
• Metrics that indicate drift (for example, accounts older than threshold still enabled)

This is where Daydream typically fits: tracking the recurring control run, capturing artifacts each cycle, and keeping exceptions and approvals tied to the requirement so you can answer assessment questions without scrambling. ¹

Required evidence and artifacts to retain

Retain evidence that shows both coverage (what systems/accounts were checked) and operation (what you disabled and why):

1. Dormant account policy / standard

   • Definitions per account type
   • Roles responsible for review/approval
   • Exception criteria and compensating controls ¹

2. System scope register

   • List of identity stores/apps reviewed
   • Data source for last login / activity per system
   • System owner and review cadence

3. Recurring detection outputs

   • Report/export of dormant accounts per system
   • Time/date of run and who ran it (or automation proof)

4. Disablement records

   • Tickets/changes showing accounts disabled
   • Screenshots or system logs showing account state change where tickets are weak

5. Exceptions

   • Approved exception tickets with rationale
   • Expiration date and re-review outcomes
   • Evidence of compensating controls (for example, MFA enforced, network restriction, PAM checkout)

Common exam/audit questions and hangups

Expect these questions and prepare your evidence package to answer them cleanly:

• “What is your dormancy threshold and who approved it?” Auditors look for documented criteria and governance.
• “Show me your population.” They will test whether you covered SaaS-native accounts, local accounts, and third-party access.
• “Prove these accounts were disabled.” A report alone is insufficient; show the state change and the workflow record.
• “How do you prevent reactivation without approval?” You need controls over re-enable and re-provisioning.
• “How do you handle service accounts and break-glass?” Exceptions are acceptable, but they must be controlled and documented. ¹

Frequent implementation mistakes (and how to avoid them)

1. Only addressing the primary directory. Fix: maintain an in-scope systems register and review it with IT annually or on major architecture changes.
2. No account classification. Fix: label accounts (privileged, third party, service) in IAM and use different rules.
3. Relying on manual reviews without evidence. Fix: export reports, save immutable artifacts, and tie actions to tickets.
4. Service account outages from blanket disablement. Fix: separate service-account workflow, require owner attestation, and monitor non-interactive use.
5. Perpetual exceptions. Fix: require an expiration date and periodic re-approval; remove access when sponsorship ends. ¹

Risk implications (why this matters operationally)

Dormant accounts increase the probability of unauthorized access because they often:

• evade day-to-day oversight,
• keep old entitlements,
• have weak ownership (no active manager/sponsor),
• remain enabled across multiple systems.

From a GRC perspective, the risk is twofold: preventable access paths remain open, and you cannot demonstrate control operation if a security event triggers scrutiny. Safeguard 5.3 reduces both risks when implemented with scope discipline and recurring evidence. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and definitions)

• Draft and approve dormancy definitions by account type (workforce, privileged, third party, service, break-glass).
• Build the in-scope systems register with owners and extraction method for activity signals.
• Run a one-time baseline discovery in the highest-risk systems (IdP, cloud consoles, VPN, finance/HR SaaS) and document findings. ¹

Days 31–60 (operationalize detection + disablement)

• Implement scheduled detection for the top systems and route results to a ticket queue.
• Establish the disablement workflow with approvals, SLAs, and rollback steps.
• Create the exception template (justification, compensating control, expiration date, approver). ¹

Days 61–90 (evidence, automation, and audit readiness)

• Expand coverage to remaining systems in the register; document compensating controls where activity signals are weak.
• Produce a “control operation packet” with last cycle evidence: population, dormant list, tickets, disablement proofs, exceptions.
• Add recurring control attestations and reminders in Daydream (or your GRC system) so evidence is captured every cycle without manual chasing. ¹

Frequently Asked Questions

What counts as “dormant” if an application can’t show last login?

Document the limitation and use an alternative activity signal you can extract reliably, such as authentication logs, token use, or system access logs. Pair that with a compensating control and keep the rationale in your exception documentation. ¹

Do service accounts fall under safeguard 5.3: disable dormant accounts requirement?

Yes, if they can authenticate, they are in scope. Treat them as a separate class with owner attestation and non-interactive usage checks to avoid breaking integrations. ¹

How do we handle seasonal workers or employees on leave?

Put them into a documented exception path with an expiration date and sponsor approval, and remove elevated access while they are inactive. Re-enable should follow your normal access provisioning approvals. ¹

Is “disable” the same as “delete”?

Deletion can be acceptable, but disablement is safer for auditability and recovery. Your policy should state the lifecycle: disable at dormancy, then delete after a separate retention period that aligns to your HR/legal needs. ¹

How do we prove this control works across dozens of SaaS apps?

Keep a systems register that shows which apps are covered, how dormancy is measured, and the last run’s evidence per app. Centralize evidence capture so each review cycle produces the same artifact set. ¹

What’s the minimum evidence an assessor will accept?

A documented dormancy standard, the in-scope population, a dormant account report for a completed cycle, and tickets or logs showing those accounts were disabled or formally excepted. Missing recurring evidence is a common failure mode. ¹

Footnotes

1. CIS Controls v8; CIS Controls Navigator v8