CIS Safeguard 6.2 access revoking process: evidence

What the access revoking process in Safeguard 6.2 requires

Many teams already have an access granting process and still cannot show that access ends when it should. Safeguard 6.2 asks the enterprise to follow a documented process, preferably automated, that removes access as soon as a user leaves the organization, loses a right they no longer need, or moves to a different role. The process has to cover all three triggers, not only termination. Its completeness is what an assessor checks first, so a procedure that handles leavers but says nothing about transfers or rights withdrawn mid-tenure will not satisfy the Safeguard. Ask who owns each trigger, which system records it, and how the revocation is confirmed.

The Safeguard usually asks for *disabling* accounts rather than deleting them. A deleted account removes the user identifier, group memberships and often the link between past actions and a person, which makes investigations and audit trails harder to reconstruct. Disabling keeps the record intact while blocking sign-in. Decide the disable-versus-delete rule per system and write it down, because some applications require deletion after a retention period and others must keep the account for logging. Confirm with your auditor how they expect retention to interact with the revocation step.

Several conditions make revocation hard in practice. Applications outside the central directory keep local accounts that no one removes when the person leaves. Shared credentials, such as service logins or team passwords, have no single owner to revoke. HR records often reach IT days after the effective date, so the access window stays open. Start by listing every system that holds user accounts, marking which ones take their identity from the directory, and measuring how long HR changes take to arrive. Those three checks show where automation will help and where a manual step must stay in the process.

Which accounts, systems and third parties the revoking process must reach

Safeguard 6.2 is only as strong as the list of places it reaches. The cards below cover the account types and access paths that most often fall outside a revoking process, so the scope can be agreed before the process is written. Each one is a scoping decision that changes the work, not a generic best practice.

Directory accounts and joiners

Start with the central directory, because it is usually the source of truth for employee identity. Confirm that disabling a directory account on termination, rights loss or role change is the trigger that starts the process, and that someone owns the step. Check whether the process covers accounts created outside HR-driven onboarding, such as local accounts on workstations or accounts created by a manager directly in an application. Those are the ones that tend to survive a departure.

SaaS and third-party applications

Every application that keeps its own user store, or receives users through provisioning, needs a revocation path. A user disabled in the directory can still hold a live session or a local password in the application. Ask for a list of applications that are fed by the directory and a separate list of those that are not, then decide how each non-federated application is disabled and who checks it. Automated deprovisioning through SCIM, where an application supports it, reduces manual steps.

Privileged and administrative accounts

Administrator accounts, domain or cloud tenant roles and break-glass credentials carry the highest impact when they remain active. Include them explicitly rather than assuming the general process covers them. Check that a role change removes elevated rights even when the person stays in the company, and that shared or break-glass credentials have a documented owner who rotates them when someone with knowledge leaves.

Service accounts and API credentials

Service accounts are not people, so a departure process often skips them. Yet a service account or API key created by a leaving engineer can keep running business processes. Require an owner field for each service account and credential, and make the owner's departure trigger a review of what that owner created. Record how credentials are rotated or reassigned so the revocation does not break production without warning.

Contractors and service provider staff

Contractors, managed service providers and vendor staff often hold accounts that never appear in the employee directory. Their access should expire on the contract end date and be revoked when the engagement ends, regardless of who requested it. Ask the provider to confirm, in writing, how its staff leave its own tenant and whether it notifies you of personnel changes. This ties Safeguard 6.2 to the provider management work covered in Control 15.

Systems that authenticate outside the directory

Network devices, appliances, on-premises tools and some cloud consoles may keep local accounts or authenticate against their own user lists. Each of these is an access path the revoking process must reach. Build an inventory of authentication and authorization systems, then mark which ones use central identity and which keep local users. For local users, the procedure should name the person who removes the account and how the removal is recorded.

How to build a revoking process that runs on every exit

This sequence turns Safeguard 6.2 into a written, tested process that disables access on termination, rights revocation or role change, with each step leaving evidence an assessor can check.

Define the revocation triggers
List the events that must start revocation: termination of employment or contract, removal of a specific right, and a change of role that makes existing access inappropriate. Assign each trigger a named source, such as an HR leaver notice, a manager request or a role change form. The output is a short trigger table that the process document references. It is done when every trigger has a source and an owner, and when someone outside the process owner has reviewed the list for gaps.
Name an owner for each step
Write down who initiates the request, who executes the disablement in each system, who confirms completion, and who escalates when a step fails. Separate the people who request revocation from those who carry it out where your size allows it. The output is a responsibility matrix attached to the procedure. It is done when every step in the process has one accountable role and a named backup, and the matrix is approved by the process owner.
Map every system that holds an account
Build an inventory of the directories, single sign-on services, cloud consoles, SaaS applications, network devices and shared accounts where a person can hold access. Record for each system whether accounts are managed centrally, whether the system supports disabling, and whether it keeps audit history after disablement. The output is a system inventory with a revocation method for each entry. It is done when the inventory has been reconciled against the identity provider's application list and the gaps have owners.
Set the disable-first and retention rules
Decide that accounts are disabled before they are deleted, and state the retention period for disabled accounts and their audit trails in line with your own record-keeping obligations. Deletion happens only after the retention period ends and under a separate approved step. Where a system cannot disable an account, document the compensating action, such as removing group memberships or revoking tokens. The output is a written rule set that the procedure cites. It is done when legal, HR and security have each signed off on the retention wording.
Automate the trigger from HR or the identity provider
Where your HR system or identity provider can emit a leaver or role change event, connect it to provisioning so that deprovisioning starts without a ticket. For example, an identity provider's SCIM provider can push user changes and deletions to a connected application and deprovision users when they lose access, which covers the timing and deprovisioning behavior the Safeguard describes. Confirm in your own environment which applications support this push and which need a manual step. The output is a list of automated paths and a record of the connector configuration. It is done when a test change in the source system produces the expected disablement in each connected application.
Document the manual fallback
For systems that cannot be automated, write a manual procedure that uses a ticket in your service management tool, such as a GLPI Assistance ticket or a Zammad ticket, as the record of the request and the completion. The ticket should list each system, the action taken, the person who performed it and the time it was completed. The output is a fallback runbook and a ticket template. It is done when the template captures every system in the inventory that lacks automation.
Test the process with a sample leaver
Run the procedure end to end using a test or volunteer account that is treated as a leaver, then check that each system shows the account as disabled, that group and role memberships are removed, and that the audit trail is retained. Record the test date, the systems checked, the results and any defects, then fix defects and retest the affected steps. The output is a signed test record that an assessor can review. It is done when the sample passes in every system in the inventory, and the test is repeated after material changes to the process or the systems.

How an assessor tests the access revoking process

This table walks through how an assessor works through Safeguard 6.2, from confirming the process exists to sampling leavers and role changes and checking that disablement happened on time. Read each row as a test step with the evidence it produces and the gap that most often causes a finding.

Test step	What the assessor checks	Evidence usually requested
Existence of the process	A documented access revoking process exists. Under the CIS assessment specification, a missing process fails the Safeguard outright.	Written revocation procedure, owner, approval date and version history
Coverage of triggers	The process addresses all three triggers: termination, rights revocation and role change. Coverage gaps in any one trigger reduce the completeness result.	Procedure sections for each trigger, or a mapping from HR events to access actions
Population sample	The assessor selects a sample of leavers, rights removals and role changes from a period the organization agrees with them, and traces each one.	HR leaver and mover lists, with the dates each event took effect
Timeliness of disablement	Each sampled account was disabled when the process requires, measured from the effective date of the event, not from when a ticket was closed.	Directory or identity provider audit logs showing disable timestamps
Disable versus delete	Accounts that must keep audit trails were disabled, not deleted, and their logs and ownership records remain retrievable.	Account state history, retention settings and a sample of retained audit records
Ticket and approval trail	The steps were followed in practice, with requests, approvals and completion recorded in a system the assessor can review.	Service desk or ITSM tickets, approvals and closure records for the sampled events
Typical findings	Common gaps include disablement days after the leaver's last day, accounts deleted with their logs, role changes that never removed old rights, and no record of who approved the change.	Remediation plan with owners, dates and re-test results
Mapped framework references	CIS maps Safeguard 6.2 to NIST CSF 2.0 GV.RR-04, NIST SP 800-53 AC-2 and PS-4(2), ISO/IEC 27001:2022 Annex A 5.16 and 5.18, SOC 2 CC6.2 and CC6.3, and PCI DSS v4.0 8.2.4 and 8.2.5.	Confirm the mapping in the CIS Controls Navigator for v8.1 before relying on it in another framework's audit

Evidence that shows access was revoked on time

For Safeguard 6.2, the assessment looks for a documented revoking process and proof that it ran for real leavers, movers and rights changes. The cards below cover the records that prove the process exists, the records that prove it executed on time, and the routine checks that keep both current between assessments.

Written revoking process

The process document names who owns revocation, which events start it (termination, rights revocation and role change), the systems in scope and the expected time to disable each account. The assessment specification checks completeness against those three triggers, so a document that covers only terminations will fail the completeness check. Confirm the document is approved, dated and version-controlled, and that its owners still hold their roles.

Leaver and mover register

Keep a register with one row per event: the person, the trigger, the date HR or the manager submitted it, the date each account was disabled and the approver. Dates are what a reviewer compares against the notice and the disablement log, so gaps between submission and disablement must be explained. Store the register in a system with change history so later edits are visible.

Directory and application disablement logs

Export the directory and application logs that show each account changed from active to disabled, with timestamp and actor. Disabling should be the recorded action, and the log should show it reached every connected application, not only the identity provider. Pull samples across leavers, movers and rights removals so the reviewer sees all three triggers, not just one.

SCIM and provisioning logs

Where revocation is automated, the provisioning logs are the primary evidence. The authentik SCIM provider pushes user and group changes and deletions to target applications and runs a full sync every hour, so keep the sync and deprovisioning records for the period under review. Check that failed deprovisioning calls appear in the logs and generate alerts, because a silent failure leaves an active account behind.

Tickets for manual revocations

Applications without SCIM or API connectors need manual revocation. Record each one as a ticket with the request, the task assigned, the completion time and the evidence of disablement, such as a screenshot or admin log entry. GLPI's Assistance module tracks tickets through their stages, and Zammad holds the request thread, which together show who acted and when.

Retention and monthly reconciliation

Configure retention so disabled accounts and their attributes remain available for the audit trail period set in your policy, rather than being deleted at departure. Run a monthly reconciliation that compares the HR leaver list with disabled accounts and flags any active account whose owner has left. Confirm the retention period with your legal and records teams, since it is set by your obligations, not by this Safeguard.

What meeting Safeguard 6.2 costs in money and effort

This table breaks down the cost components of running an access revoking process under Safeguard 6.2, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a written quote and to compare what a self-hosted open-source approach removes from the budget and what it leaves in place. No prices or durations are stated because none were supplied; each row names what to ask for instead.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Tooling and licenses	Software vendor or open-source project; DeployOpen is paid for deployment and configuration only	Licenses one-time or recurring; open-source licenses carry no fee but support contracts may recur	Up: commercial identity suites and per-user fees. Down: open-source components such as authentik and FreeIPA, with support priced separately
Engineering to connect HR, directory and applications	Implementation partner or internal platform engineers	One-time for the initial connectors, recurring when new applications are added	Up: number of target applications and custom APIs without SCIM support. Down: a single identity source and standard provisioning protocols
Process design and written procedure	Internal HR, IT and security leads; partner if scoped	One-time, reviewed on a set cycle	Up: many teams with separate offboarding steps. Down: one documented procedure covering termination, rights revocation and role change
Ticketing and workflow for manual steps	Internal service desk; helpdesk tooling vendor or open-source project	Recurring operating cost of the service desk	Up: manual revocations that depend on tickets. Down: automated deprovisioning that only needs tickets for exceptions
Evidence upkeep	Internal control owner; time spent on records	Recurring, usually tied to each joiner, mover and leaver event and periodic reviews	Up: records scattered across systems and manual exports. Down: logs and tickets kept in a few systems with consistent timestamps
Testing the revocation path	Internal engineers or a testing provider under a written scope	Recurring, at least after each connector or directory change	Up: many applications and shared accounts. Down: a small set of test accounts and repeatable test scripts
External review of the process	Independent assessor or auditor; DeployOpen prepares evidence but does not issue findings	Recurring with each assessment cycle	Up: broad audit scope spanning several frameworks that test the same revocation evidence. Down: one evidence set mapped to each framework
Auditor sampling of leavers and movers	Auditor's fees, set by the audit engagement	Recurring with each audit period	Up: large leaver volumes and incomplete tickets that force extra samples. Down: complete, timestamped records for every departure and role change

Open-source tools that can produce revocation evidence

Open-source tools can produce much of the revocation evidence an assessor will ask for, but none of them makes the process compliant on its own. The organization owns the revoking process and its outcomes. A tool helps by disabling accounts at the source, recording who acted and when, and keeping a trail that matches the process as written. Before adopting any of the three tools below, confirm its fit with your own identity architecture, application estate and audit requirements.

authentik (MIT) is the most direct candidate for the automated path. Its SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0, runs a full sync every hour, and deprovisions users from the target when they lose access to the application. Confirm with your team which applications support SCIM, how deprovisioning behaves for applications that do not, and whether the hourly full sync meets the timing your revocation process commits to. Keep the sync logs as evidence that removal reached each target.

FreeIPA (GPL-3.0-or-later) uses 389 Directory Server as a multi-master LDAPv3 directory that stores users, groups, hosts and other network objects, with centralized access control and delegated administration through its web UI and command line tools. Delegated administration lets you limit who can disable accounts, which supports the separation of duties an assessor will look for. Confirm that your Linux, network and application estate authenticates against it, because accounts left in other directories will not be revoked by a change here. GLPI (GPL-3.0-or-later) and Zammad (AGPL-3.0-only) cover the manual side. GLPI's Assistance module lets users create, follow and process tickets, problems and changes following ITIL practices, which suits revocations that a person must carry out, such as removing a local account or a shared credential. Zammad brings requests from email, chat, telephone and social media into one ticket system, which gives you a single intake for revocation requests. Ticket records with timestamps, approvals and closure notes are the evidence that manual steps happened.

Who revokes access, and what a partner or auditor should do

Your organization owns Safeguard 6.2. The process has to be documented, approved and followed by people you employ, because the Safeguard is judged on whether the enterprise actually removes access when someone leaves, loses rights or changes role. HR and line managers usually provide the triggers, and the security or identity team decides how each revocation is carried out.

Process ownership: Assign a named owner for the revoking process and for each trigger: termination, rights revocation and role change.
HR triggers: Define how HR notifies identity administrators of departures and transfers, and the deadline for each notice.
Disable versus delete decisions: Decide, in writing, when accounts are disabled instead of deleted, for example where audit trails must remain attached to the account.
Approvals and exceptions: Document who approves any delayed revocation, such as an account kept open for a handover, and how long the exception may last.
Recurring review: Schedule checks that revoked accounts stay disabled and that the process still matches current HR and application records.

Before an assessment, confirm that someone on your side can explain each step and produce the records that show it ran.

Where organizations fall short on access revocation and how to close each gap

Most access revocation failures happen outside the main directory, in applications, shared accounts and manual steps that nobody tracks. The cards below cover the gaps assessors most often find under Safeguard 6.2 and the fix for each, tied to the process, the account inventory or the evidence trail.

Leavers still active outside the directory

HR removes a leaver from the directory, but local accounts in business applications, SaaS tools and internal databases remain active because nobody maps them to the joiner-mover-leaver workflow. Safeguard 6.2 asks for revocation on termination, so the process has to reach every system that grants access. Build an inventory of applications that authenticate users, then confirm each one either federates from the directory or appears on a manual deprovisioning checklist. Where the application supports SCIM, a provider such as authentik can push deactivations automatically. Check a sample of recent leavers against each application's user list.

Role changes that never remove old rights

When someone moves to a new team, the access granting process adds rights for the new role, but the rights from the previous role stay in place. Over time users accumulate access they no longer need. Safeguard 6.2 covers role change as a trigger for revocation, so the process should compare the old and new role and remove what the new role does not need. Ask HR to send mover events, not only leaver events, and require the approver of the new role to confirm which prior rights end. Sample movers from the last review period and check whether their group memberships match their current job.

Deletion that destroys audit trails

Deleting an account removes the user object and often the link between that identity and its historical actions in logs and tickets. Investigators then cannot attribute past activity to a person. Where audit trails must be kept, the process should disable the account, remove its group memberships and retain the record. Confirm that log retention and identity records are separate, so that disabling an account does not purge the events tied to it. Ask the team to show a disabled account with its activity history intact.

Shared and service accounts with no owner

Shared logins and service accounts often have no named owner, so no one is responsible for revoking them when the team that used them changes. Their passwords may also be known to former staff. Assign each shared or service account a named owner in the account inventory, record which systems it reaches and set a review point tied to that owner's own status. When the owner leaves, the process should reassign or retire the account. Ask for the list of shared accounts and confirm an owner is named for every one.

Contractor accounts without an end date

Contractor and vendor accounts are often created for a project and then left active after the engagement ends, because the contract end date never reaches the team that manages accounts. Safeguard 6.2 applies to every user type, so each external account needs an expiry date set at creation and a named sponsor inside the organization. The sponsor confirms the engagement is still active before extension. Reconcile active external accounts against current contracts and vendor records each time the access review runs.

Manual steps with no evidence trail

A revocation that depends on an email or a verbal request leaves no record that it happened, when, or who approved it. An assessor testing the process will ask for proof that the steps ran, and a missing record counts as a gap even if the work was done. Open a ticket for every leaver, mover and contractor end, and record each step, its owner and the completion time. Tools such as GLPI's Assistance module or Zammad can hold these tickets as the evidence. Pull five recent revocations and check that each ticket shows every system was disabled.

Questions buyers ask about the cost, effort and scope of Safeguard 6.2

How much work does it take to build an access revoking process?

The work scales with how many systems grant access, how many people join, move and leave each month, and how much of the revocation chain is already automated. Safeguard 6.2 asks for a documented process that disables accounts when someone leaves, loses rights or changes role. A small organization with one directory and a handful of applications can usually write and test that process in a short effort. An enterprise with dozens of SaaS tools, local accounts on servers and contractor identities has more systems to map, more owners to coordinate and more exceptions to document. Ask any partner to list the systems in scope before agreeing a price, because the system count drives most of the effort.

Can we build the access revoking process in-house?

Yes, many organizations do. The Safeguard does not require an outside firm, and CIS publishes its Controls free for internal use. The in-house team needs three skills: identity administration for the directory and SSO platform, application administration for each system that holds accounts, and documentation that an assessor can follow. The main gap is usually time. Revocation work competes with daily operations, and a process that only works when one administrator is available will fail an assessment. An outside partner can help with a fixed-scope build, but the organization still owns the process, its approvals and its records.

How long does it take to put a revocation process in place?

The duration depends on scope and must be agreed in writing before work starts. No supplied source gives a standard timeline for this Safeguard, so do not accept a figure from anyone who has not reviewed your environment. The main drivers are the number of identity sources, the state of existing offboarding tickets, whether HR systems can trigger changes, and how many application owners must test their own deprovisioning. Ask for a written plan that lists phases, owners and the point at which the process is tested end to end.

What do HR and application owners need to contribute?

HR must reliably record terminations, leaves, rights changes and role changes, and it must record them on time. Application owners must confirm how accounts are created, disabled and reactivated in their systems, and whether any local accounts exist outside the central directory. Managers usually confirm access to shared mailboxes, devices and project resources. Without these contributions, automation only covers the systems that are easy to connect, and the rest of the process depends on manual tickets. Agree the responsibility matrix early, because most delays in this work come from unanswered questions to owners, not from technical configuration.

Is automation required to meet Safeguard 6.2?

The Safeguard describes the process as preferably automated, so automation is the expected direction, but it is not the only way to satisfy the wording. The assessment specification checks whether a process exists and whether it covers termination, rights revocation and role change. A documented manual process with clear owners, service levels you set internally and records of completion can pass that test. Automation reduces the risk that a revocation is missed, and it shortens the window in which a former employee keeps access. Automated connectors also add ongoing maintenance, so cost depends on how many applications support provisioning and how often they change.

When should we disable accounts instead of deleting them?

Disable accounts instead of deleting them when audit trails, investigations, records retention or legal holds depend on the account identity still existing. Deleting an account can break the link between a user and the actions recorded under that identity in logs, tickets and approvals. Confirm retention needs with legal, compliance and the owners of each system before writing the rule. The process should state which account types are disabled, which are archived, when deletion happens and who approves it. Note that disabling does not remove group memberships or sessions in every system, so test that each application actually blocks access.

What does a fixed-scope engagement with DeployOpen cover?

DeployOpen plans, implements, integrates and documents self-hosted open-source platforms inside your own infrastructure. For this Safeguard, a fixed-scope engagement can cover mapping the systems that hold accounts, configuring identity tooling such as the authentik SCIM provider or FreeIPA for the systems in scope, connecting ticketing workflows in GLPI or Zammad, and producing the written process and records an assessor will review. Scope, deliverables and timelines are agreed in writing before work starts. DeployOpen does not issue audit reports or certifications, and it does not own your controls. Ongoing support and periodic testing are available as retainers.

What evidence will an assessor ask to see for this Safeguard?

Expect to show the written revocation process, the list of systems in scope, examples of completed revocations for leavers and role changes, and the records that link each action to an approved request. Assessors often sample recent terminations and check that accounts were disabled within the period your process sets. They also look for exceptions, such as accounts kept for audit trails, and whether those exceptions were approved. Keep ticket histories, directory audit logs and sync reports in a retrievable form. Confirm with your auditor which sample sizes and evidence formats they expect, since those requirements vary by assessment.

How DeployOpen scopes and prepares access revocation for an audit

DeployOpen works on Safeguard 6.2 as a self-hosted implementation project inside your own infrastructure: we scope the revocation process, wire it into your identity and ticketing systems, and hand over the documented process and evidence. Your organization owns the process and its controls, and an independent auditor or certification body is the one that assesses them.

How we scope

The written scope names the identity systems, applications and HR or ticketing sources in which revocation must be enforced.
We record which events trigger revocation: termination, rights revocation and role change, each as a defined scenario.
The scope states where accounts must be disabled instead of deleted so that audit trails remain intact.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We configure the SCIM provider in authentik, where supported, to deprovision users from target applications when they lose access.
We connect the authoritative joiner, mover and leaver source so revocation can be triggered without manual steps where possible.
We document manual fallback steps for applications that cannot be provisioned automatically, with named owners.
We test revocation for each scenario, including a role change and a termination, and keep the test records as evidence.

How we hand over

You receive the written access revoking process, mapped to the CIS Controls Assessment Specification measure for Safeguard 6.2.
The handover pack includes configuration records, test results and a list of applications with manual revocation steps.
Ticket and approval records from systems such as GLPI or Zammad are documented as the evidence trail for each revocation.
We walk your owners through the runbook so they can operate and show the process to an auditor.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
Retainers can cover periodic revocation tests, review of new applications added to the identity provider and runbook updates.
We do not issue audit reports or certificates; an independent auditor or certification body issues those.
Ask us to confirm in the written scope which evidence your auditor expects for the framework you are preparing for.