Safeguard 6.2: Establish an Access Revoking Process

Safeguard 6.2: establish an access revoking process requirement means you must have a documented, repeatable way to remove access quickly when a user’s job changes, they leave, or access is no longer justified. Operationalize it by defining triggers, owners, time expectations, and tooling for disabling accounts, revoking sessions/tokens, removing group memberships, and validating completion across all systems.

Key takeaways:

• Tie revocation to specific triggers (termination, role change, contractor offboarding, third-party disengagement) and route them through a single workflow.
• Cover more than “disable AD”: include SSO, SaaS apps, privileged access, API keys, service accounts, and physical access.
• Audit readiness comes from evidence of operation: tickets, logs, access review deltas, and exception records mapped to the control.

Access revocation is one of the few controls that directly limits damage after a personnel event. A strong revoking process reduces the window where former employees, contractors, or third parties can still access email, source code, customer data, or production systems. CIS Controls v8 Safeguard 6.2 sets the expectation that you formalize this into an operating process, not an informal “IT usually handles it” practice ¹.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat access revocation like a production workflow: clear triggers, defined service-level expectations, a standard checklist by system type, and proof that each event completed. The operational reality is messy: identities live across HRIS, IAM/SSO, on-prem directories, endpoint management, cloud consoles, databases, code repositories, and SaaS applications. If you don’t coordinate these, you end up with orphaned accounts, persistent sessions, forgotten API keys, and “shadow admins.”

This page gives requirement-level implementation guidance for building and running a revocation process that auditors can test and operators can execute under pressure, aligned to CIS Controls v8 Safeguard 6.2 ².

Regulatory text

CIS Controls v8 safeguard 6.2 implementation expectation (Establish an Access Revoking Process). ¹

Operator interpretation: You need a documented process that reliably revokes access when it should no longer exist. “Access” includes accounts, entitlements, group memberships, privileged roles, active sessions, tokens/keys, and physical or remote access paths. “Process” means: defined triggers, named owners, consistent execution steps, and records that prove it happened ².

Plain-English interpretation (what the requirement really asks)

Safeguard 6.2 expects you to answer four questions with operational clarity:

1. When must access be revoked? (termination, role change, end of engagement, policy violation, failed background check, emergency lockout)
2. Who initiates and who executes? (HR, manager, procurement/vendor management, IT/IAM, security)
3. What gets revoked and where? (SSO, directory, SaaS, cloud, PAM, endpoints, VPN, email, code repos, DBs, physical badges)
4. How do you prove it? (ticket trail, system logs, deprovisioning reports, exception approvals)

If you can’t show repeatable execution and evidence, you effectively have a “policy,” not a control.

Who it applies to (entity and operational context)

Applies to: Enterprises and technology organizations implementing CIS Controls v8 ¹.

Operational contexts where 6.2 becomes high-risk fast:

• High contractor/third-party usage: onboarding/offboarding happens outside HR, so accounts linger.
• Decentralized SaaS purchasing: app owners create accounts directly, bypassing IAM.
• Privileged access sprawl: cloud admin roles, break-glass accounts, shared credentials, local admin rights.
• M&A and reorganizations: role changes are frequent; access removal lags behind org charts.
• Remote workforce: VPN, device certificates, and endpoint management access must be terminated cleanly.

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

Use the steps below as your minimum viable operating model for safeguard 6.2: establish an access revoking process requirement.

Step 1: Define revocation triggers (write them down)

Create a short list of events that automatically require revocation action. Recommended trigger set:

• Employment termination (voluntary/involuntary)
• Role change / transfer (access must be removed before new access is added where feasible)
• Leave of absence / suspension (temporary disable, then re-enable via approval)
• Contractor/third-party end date reached (automatic expiration)
• Access no longer justified (manager attestation, access review findings)
• Security incident response (emergency lock, credential rotation)

Output artifact: “Access Revocation Triggers” section in your IAM standard operating procedure (SOP).

Step 2: Establish ownership and a single intake path

You want one consistent way revocation enters the system:

• System of record for identity: usually HRIS for employees, vendor/third-party management system for contractors, and an identity registry for service accounts.
• Single intake workflow: HR termination feed, ITSM ticket type, or automated IAM workflow.

Define RACI in practical terms:

• HR / People Ops: submits termination events and effective time.
• Manager: confirms access scope for role changes and validates unusual entitlements.
• IAM/IT: executes deprovisioning via SSO/directory and app connectors.
• Security: oversees privileged access removal, break-glass control, and exceptions.

Output artifact: RACI matrix embedded in the SOP and referenced in onboarding/offboarding procedures.

Step 3: Build a revocation checklist by access type (don’t rely on memory)

Create a checklist that operators run for every offboarding event. Break it into categories:

Identity & authentication

• Disable primary directory account(s)
• Remove from groups and distribution lists
• Revoke MFA factors and recovery methods
• Invalidate active sessions (where supported)

SSO/IAM

• Remove from SSO assignments and app tiles
• Revoke tokens and OAuth grants where applicable
• Remove from SCIM-provisioned apps (or let SCIM drive removal and verify)

Privileged access

• Remove admin roles (cloud IAM, database admin, SaaS super-admin)
• Check PAM vault: revoke privileged credentials, rotate shared secrets the user knew
• Remove from break-glass process distribution and paging lists

Cloud and developer access

• Remove from cloud accounts/projects/subscriptions
• Revoke access to code repos, CI/CD, artifact registries
• Rotate API keys the user created or had access to
• Review service accounts the user managed

Endpoints and remote access

• Disable VPN access; revoke device certificates if used
• Remove endpoint management enrollment where appropriate
• Trigger remote wipe for corporate-owned devices based on your policy

Physical access

• Deactivate badge access; recover keys or tokens

Output artifact: a one-page “Offboarding Access Revocation Checklist” that lives in the ticket template.

Step 4: Set time expectations and escalation rules

CIS 6.2 does not prescribe exact timelines in the provided excerpt, so set internal expectations that match your risk profile and can be met consistently ². Document:

• Standard termination processing target (e.g., “same business day” or “immediate for involuntary” as your internal rule)
• After-hours and urgent termination process
• Escalation path if deprovisioning can’t be completed (app owner unreachable, missing admin rights)

Output artifact: SLA/OLA section in the SOP plus an escalation runbook.

Step 5: Cover exceptions explicitly (because they will happen)

Common valid exceptions:

• Legal hold requiring mailbox preservation (without interactive login)
• Transition period for shared inboxes or customer communications
• Critical service account ownership transfer required before disablement

Exception rules you should enforce:

• Exceptions must be time-bound
• Exceptions must have named approver (HR + Security for terminations is common)
• Exceptions must specify compensating controls (monitoring, reduced access, password rotation)

Output artifact: exception register with approvals and expiry dates.

Step 6: Add verification and recurring evidence capture

Auditors test 6.2 by sampling terminations and checking whether access actually disappeared everywhere. Build verification into the process:

• A completion step that requires the operator to attach deprovisioning output (SSO screenshot/export, IAM event log, ITSM task completion list)
• Periodic reconciliation reports (HR roster vs directory vs SSO; contractor list vs accounts)
• A lightweight metric you can defend (e.g., “termination tickets closed with all checklist tasks completed”)

Daydream can help by mapping safeguard 6.2 to a documented control narrative and setting up recurring evidence capture so you are not assembling screenshots under audit pressure ¹.

Required evidence and artifacts to retain

Keep evidence in a form an auditor can reperform. Minimum evidence set:

Evidence type	What it proves	Example artifacts
Policy/SOP	Process exists and is approved	IAM SOP with revocation triggers, RACI, SLAs, exceptions
Ticket/workflow records	Execution per event	ITSM offboarding tickets with checklist tasks and timestamps
System logs/exports	Technical revocation occurred	SSO deprovisioning logs, directory disable logs, PAM removal logs
Access reconciliation	Orphan detection	Periodic roster-to-account reconciliation report
Exception register	Controlled deviations	Approved exceptions with expiry and compensating controls
Role-change records	Access removed on transfer	Transfer ticket and resulting entitlement changes

Retention period should follow your internal record retention standard. Document it in the SOP so teams don’t delete evidence mid-cycle.

Common exam/audit questions and hangups

Expect these questions and pre-answer them with artifacts:

1. “Show me three terminated users and prove they lost access everywhere.”
   Have a sampling-friendly package: HR termination record, ITSM ticket, SSO log, PAM log, and confirmation of removal from critical SaaS.

2. “How do you handle contractors and other third parties?”
   Auditors look for a non-HR pathway. Show an authoritative list (procurement/TPRM) and an end-date driven deprovisioning flow.

3. “What about service accounts and API keys?”
   Many programs fail here. Show ownership assignment, key rotation expectations, and a process for disabling keys on departure.

4. “How do you ensure role changes remove access, not only add more?”
   Provide a role-change workflow that includes removal tasks and manager attestation.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating revocation as “disable SSO” only.
  Fix: Maintain an application/system inventory and tag “must-disable” systems for offboarding (IAM, cloud, source control, ticketing, finance).

• Mistake: No single source of truth for workforce identities.
  Fix: Define system-of-record per population (employees, contractors, third parties, interns) and reconcile routinely.

• Mistake: Exceptions are informal and never expire.
  Fix: Require time-bound exceptions with re-approval and compensating controls.

• Mistake: Offboarding doesn’t include privilege cleanup.
  Fix: Add a privileged access section to the checklist and require PAM confirmation.

• Mistake: Evidence is screenshots with no linkage to a case.
  Fix: Store evidence inside the ticket or link immutable exports to the ticket ID.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this safeguard. Practically, weak revocation shows up as:

• Unauthorized access by former insiders
• Data exfiltration using still-valid tokens/keys
• Audit findings for identity lifecycle control gaps
• Incident response complexity because accounts persist across systems

Treat revocation as a containment control. If it fails, every other control has to work harder.

Practical 30/60/90-day execution plan

First 30 days (stabilize and document)

• Publish an access revocation SOP mapped to CIS Safeguard 6.2 ¹.
• Define triggers and RACI, including contractor/third-party offboarding.
• Create the offboarding ticket template with the checklist categories (SSO, privileged, cloud/dev, endpoints, physical).
• Start an exception register with required fields (reason, approver, expiry, compensating control).

Days 31–60 (connect systems and prove operation)

• Integrate HRIS termination feed to IAM/ITSM where possible; otherwise standardize manual intake.
• Identify your “top critical systems” list and ensure each has an owner and a revocation step.
• Run a pilot sample: pick recent terminations and validate end-to-end evidence completeness.
• Set up recurring evidence capture in Daydream (control narrative, sample sets, evidence requests) to avoid one-off audit drills ².

Days 61–90 (reduce blind spots and harden)

• Add reconciliation: compare HR/contractor rosters against directory and SSO accounts; track orphan remediation to closure.
• Expand scope to service accounts, API keys, and break-glass access governance.
• Formalize after-hours and urgent termination playbooks and run a tabletop exercise.
• Report to leadership: exceptions, recurring failure points, and systems not yet covered by automation.

Frequently Asked Questions

Does “access revocation” include SaaS applications outside SSO?

Yes. If accounts can exist directly in a SaaS app, your process needs a step to remove or disable them, even if SSO removal covers many users.

How do we handle email and files when someone leaves but the business needs continuity?

Preserve data through administrative access and retention controls while disabling interactive login. Document the approach as an approved exception with an expiry date.

What’s the minimum evidence an auditor will accept for safeguard 6.2: establish an access revoking process requirement?

You need a written SOP plus event-level proof. For sampled terminations, show the ticket/workflow record and technical evidence that access was removed in key systems.

We can’t automate deprovisioning everywhere. Is a manual process acceptable?

Yes, if it is consistent and verifiable. Use a standard checklist in the ticket, require completion evidence, and reconcile periodically to catch misses.

How should we treat shared accounts or shared credentials?

Avoid them where possible. If they exist, rotate the shared secret upon termination and record the rotation evidence in the offboarding ticket.

How do we operationalize this for third parties who are not in HRIS?

Maintain an authoritative third-party roster with start/end dates and drive offboarding from that list. Make the sponsoring manager accountable for confirming end dates and access scope.

Footnotes

1. CIS Controls v8

2. CIS Controls Navigator v8