Identity Deprovisioning

The identity deprovisioning requirement means you must promptly disable or remove user and system identities when they are no longer needed, including after termination, contract end, role change, or service retirement. Operationalize it by defining clear revocation triggers, routing deprovisioning through a controlled workflow, and retaining evidence that access was removed across all in-scope systems. ¹

Key takeaways:

• You need defined triggers and owners for identity removal, not ad hoc “please disable this user” emails.
• Deprovisioning must cover every identity type: workforce, contractors, third parties, service accounts, and shared/legacy accounts.
• Evidence matters as much as execution: auditors will ask for proof of timely, complete revocation and any approved exceptions. ¹

Identity deprovisioning is a control that fails quietly until it becomes an incident, or an audit finding you cannot explain. C2M2 ACCESS-1.B sets a simple expectation: identities are deprovisioned when no longer required. ¹ For a CCO, Compliance Officer, or GRC lead, the practical question is not “Do we disable accounts?” It’s whether you can prove that your organization consistently removes access based on reliable triggers, across the full environment scope you assessed under C2M2, including operational technology (OT) where applicable.

This page translates the requirement into an operator-ready approach: what “no longer required” means in real workflows, which systems and identity types must be included, how to sequence implementation, and what evidence to retain for internal control testing, customer diligence, or regulator review. The goal is a repeatable process you can run during normal operations and defend during scrutiny, without relying on heroics from IAM or HR to remember edge cases.

Regulatory text

Requirement (C2M2 ACCESS-1.B, MIL1): “Identities are deprovisioned when no longer required.” ¹

Operator interpretation (what you must do):

• Define what “no longer required” means for your environment (termination, role transfer, contract end, inactive identities, decommissioned systems, or changed business need).
• Ensure identities are disabled/removed through an accountable process that reaches all in-scope systems.
• Be able to show evidence that deprovisioning occurred and that exceptions are approved and tracked. ¹

This is a baseline maturity expectation (MIL1): consistent execution matters more than sophisticated tooling. You can meet it with a simple workflow if it is complete, owned, and evidenced.

Plain-English requirement

Remove access when the need for access ends. That includes:

• People leaving (voluntary/involuntary termination)
• People changing roles (especially moving out of privileged or sensitive duties)
• Contractors and third parties ending engagements
• Service accounts and integration identities no longer required
• Shared/legacy accounts that should be eliminated or tightly controlled, then removed when obsolete

The failure mode auditors and investigators focus on is straightforward: an identity still exists, still authenticates, and still has permissions after the business justification ended.

Who it applies to (entity and operational context)

This applies to organizations using C2M2 to assess cybersecurity maturity for a defined scope (business unit, function, or OT environment). ¹ In practice, that includes:

• Energy sector organizations and critical infrastructure operators
• Corporate IT environments (enterprise applications, cloud, endpoints)
• OT environments (plant networks, industrial control systems) where identities can exist in separate directories, local device accounts, jump hosts, historians, or vendor remote access solutions

Teams you need involved

• HR (authoritative source for workforce status changes)
• Procurement / Vendor Management (contract start/end signals for third parties)
• IAM / IT Operations (directory, SSO, MFA, endpoint access)
• OT Operations (local accounts, vendor access, plant-specific systems)
• Application owners (systems that are not integrated to SSO)
• Security Operations (monitoring, detection of orphaned accounts)

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

Step 1: Define deprovisioning triggers and “revocation outcomes”

Write a short standard that answers two questions:

1. What events trigger revocation?
   Common triggers: termination, role change, leave of absence transitions, contractor end date reached, third-party access request expired, system retirement, and extended inactivity.
2. What does “deprovisioned” mean per system?
   Examples of acceptable outcomes:
   • Account disabled in IdP/directory
   • Tokens/keys revoked and sessions invalidated where possible
   • Group memberships and privileged roles removed
   • Remote access paths closed (VPN, bastions, vendor portals)
   • For OT/local accounts, password rotation and account disablement recorded

Keep this definition tight. Auditors test against your own words.

Step 2: Establish authoritative sources and ownership (RACI)

You need a clear chain of custody from “status change happens” to “access removed everywhere.”

• Authoritative source for workforce: HRIS event (hire/term/transfer)
• Authoritative source for third parties: contract end date, engagement end ticket, or sponsor attestation
• Accountable owner: IAM/IT for enterprise identities; OT access owner for plant systems; app owners for standalone apps
• Approver for exceptions: system owner plus security/compliance sign-off, depending on risk

A common hangup is shared responsibility with no accountable party for orphaned apps. Assign an owner per system.

Step 3: Build an application/system coverage map (where access must be removed)

Create an inventory of in-scope systems where identities exist. At minimum:

• Identity provider/directory (AD/Azure AD/Okta equivalents)
• Email/collaboration
• VPN/remote access and jump hosts
• Cloud consoles and subscriptions
• Privileged access systems and admin consoles
• OT remote access solutions and local device accounts
• SaaS apps not connected to SSO (high-risk blind spot)
• Service accounts, API keys, certificates, and shared credentials repositories

This map becomes your deprovisioning checklist and your audit boundary.

Step 4: Implement a controlled workflow (automated where possible, manual where necessary)

Design the workflow around the triggers:

• Termination flow: HR/manager event creates an access removal ticket (or automated job) that disables the directory identity and cascades to connected systems.
• Role change flow: requires review and removal of old access, not just addition of new groups. Treat lateral moves as access risk events.
• Third-party flow: tie access to a sponsor and an end date; require periodic sponsor confirmation if the end date moves.

Even with automation, keep a manual backstop: a queue for “systems not integrated” with assigned owners and due dates.

Step 5: Add validation checks (proof that access is actually gone)

Deprovisioning that is not validated turns into “paper compliance.” Add checks such as:

• Directory report of disabled accounts vs. HR terminated list
• Delta report of accounts active past end date (workforce and third party)
• Privileged group membership changes for transfers
• Quarterly (or risk-based) orphan account review for apps not on SSO

Your validation method can be simple; it must be repeatable and evidenced. ¹

Step 6: Manage exceptions explicitly

You will have legitimate exceptions (e.g., litigation hold access for eDiscovery admins, short-term reactivation for approved business continuity, OT vendor emergency access). Define:

• Who can approve
• How long exceptions can last before renewal
• Compensating controls (MFA, time-bound access, session recording, restricted network paths)
• How exceptions are tracked and reported

Retain the exception record as part of your evidence set. ¹

Required evidence and artifacts to retain

Auditors rarely accept “we do it in the tool” without records. Keep:

• Identity deprovisioning standard/procedure (triggers, roles, timelines you set internally)
• System coverage map (where identities exist and who owns each system)
• Access removal tickets or workflow logs showing request/event, action taken, timestamp, and closer
• HR/contractor termination and role change feeds (or reports) used to trigger action
• Reconciliation/validation reports (terminated list vs disabled list; orphan accounts list and remediation)
• Exception register with approval, duration, and compensating controls
• Evidence of periodic review cadence you defined (meeting notes, review sign-offs, reports) ¹

If you use Daydream to run GRC workflows, treat it as the system of record for: control narrative, system ownership mapping, evidence requests, exception approvals, and recurring review tasks. That reduces the “evidence scavenger hunt” during audits.

Common exam/audit questions and hangups

Expect variations of:

• “Define ‘no longer required.’ What events trigger deprovisioning?”
• “Show me three terminated users. Prove they lost access everywhere in scope.”
• “How do you handle role changes? Do you remove prior access or only add?”
• “How do you deprovision third-party access, and who sponsors it?”
• “What about service accounts, API keys, certificates, and shared accounts?”
• “Which systems are not connected to SSO, and how do you control those?”
• “Show exceptions and the approvals. Why were they necessary?”

Hangup to plan for: Evidence across disconnected systems. If app owners deprovision manually, you need consistent logging (ticket closure notes, screenshots, admin logs exported) and a reconciliation process that catches misses.

Frequent implementation mistakes (and how to avoid them)

1. Stopping at directory disablement

• Mistake: disabling AD/IdP but leaving SaaS direct accounts, VPN accounts, local OT accounts, or API keys intact.
• Fix: enforce the system coverage checklist and require closure evidence from each system owner.

2. No process for role changes

• Mistake: transfers accumulate access over years.
• Fix: make role change a required “remove then add” event for sensitive access, with manager/app-owner attestation.

3. Third parties treated as “someone else’s problem”

• Mistake: no clear sponsor, no end date, no contract signal into IAM.
• Fix: require a sponsor and expiration for any third-party identity, and reconcile against procurement/contracting records.

4. Service accounts never deprovisioned

• Mistake: integrations persist indefinitely with broad permissions.
• Fix: assign an owner, purpose, and review requirement to each non-human identity; deprovision on system retirement and integration changes.

5. Exceptions approved verbally

• Mistake: “the plant manager said it was fine” with no record.
• Fix: require written approval and an expiration; store in your exception register with compensating controls.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the supplied sources, so this page does not list specific actions or outcomes.

Operationally, the risk is persistent inappropriate access that can enable fraud, sabotage, data loss, and difficult incident containment. From a governance perspective, weak deprovisioning creates gaps you cannot defend during internal control testing, audits, customer diligence, or regulator review because access decisions become hard to reconstruct. ¹

Practical 30/60/90-day execution plan

First 30 days (establish control design and scope)

• Confirm the C2M2 assessment scope (business unit / OT environment) and list in-scope identity stores and critical applications. ¹
• Publish a one-page deprovisioning standard: triggers, owners, exception handling, and required evidence.
• Build the system coverage map with named owners and deprovisioning method (SSO-cascaded vs manual).
• Stand up an exception register and require it for any delayed removal.

Days 31–60 (operate the workflow and start validation)

• Implement the termination and third-party end-of-engagement workflow with ticketing or IAM automation.
• Pilot role-change deprovisioning for a high-risk population (admins, OT remote access, finance systems).
• Run the first reconciliation: terminated/ended users vs active accounts across your top systems; document remediation.
• Define evidence collection: what gets attached to tickets and where it’s stored (Daydream or your GRC repository).

Days 61–90 (close gaps and make it repeatable)

• Expand coverage to remaining apps not integrated with SSO; assign owners and require deprovisioning proof.
• Formalize periodic reviews for orphaned accounts and non-human identities (service accounts, API keys).
• Test the control like an auditor: sample recent terminations, transfers, and third-party endings, then verify removal end-to-end.
• Report outcomes to leadership: open exceptions, recurring failure points, and systems needing integration work.

Frequently Asked Questions

What counts as an “identity” for deprovisioning?

Any credentialed entity that can authenticate or authorize actions, including employee accounts, contractor and third-party accounts, shared accounts, service accounts, and API keys tied to a principal.

Is disabling an account enough, or do we have to delete it?

The requirement is to deprovision identities when no longer required. ¹ In practice, disabling is often acceptable if it reliably prevents access and your retention needs require the record, but you still must remove entitlements and revoke tokens/keys where applicable.

How do we handle deprovisioning for SaaS apps that aren’t on SSO?

Put them on your system coverage map with an accountable app owner and a documented manual removal step. Then validate via periodic reconciliation reports or administrative exports to catch missed removals.

What’s the right way to manage third-party access offboarding?

Require a sponsor, an end date, and a defined trigger (contract end or engagement end ticket). Reconcile active third-party identities against current engagement lists so accounts do not persist past the business need.

Do role changes really need deprovisioning steps?

Yes. Role changes are a primary source of access creep. Treat transfers as a revocation trigger for old access and require an explicit review of privileged and sensitive entitlements.

How should we evidence deprovisioning for OT systems with local accounts?

Use a ticket with the triggering event, the named system, the action taken (disable/remove/rotate credentials), the operator who performed it, and an artifact such as an exported user list, device screenshot, or admin log excerpt stored with the ticket.

What you actually need to do

Use the cited implementation guidance when translating the requirement into day-to-day operating steps. ²

Footnotes

1. Cybersecurity Capability Maturity Model v2.1

2. DOE C2M2 program