Logical Access
Access to critical systems is removed or modified within defined timelines after termination, role change, contract completion, or loss of business need.
Use this guide to put the control into operation, decide what records to retain, and check that an auditor can trace the evidence back to the work your team performed.
Maintained by GreenHat Security · Reviewed August 21, 2026
Access is disabled or adjusted promptly when employment, contract, role, or business need changes, including sessions, local accounts, tokens, and privileged paths outside the main identity provider.
First SOC 2 program
Use one authoritative departure and role-change signal, disable the central identity first, and follow a system checklist covering cloud, source control, support, devices, local accounts, and credentials. Record both the trigger time and each completed action.
As the company scales
Connect the human-resources system to identity lifecycle automation, use automated provisioning where reliable, monitor completion targets, and reconcile downstream systems for accounts, sessions, or credentials that automation missed.
Specify the triggers for termination, contract end, leave, transfer, and loss of business need, along with who communicates each event and the desired completion time by risk.
You should end up with: A lifecycle event matrix with authoritative sources, owners, actions, and timing targets.
Route each event from the human-resources or contractor owner into a timestamped workflow that identifies the person, effective time, manager, and affected role or relationship.
You should end up with: A reliable event record that starts and timestamps the removal or modification process.
Disable sign-in, revoke active sessions and recovery methods, remove privileged groups, and prevent new tokens from being issued at the effective time.
You should end up with: Identity-provider events showing disablement, session revocation, and privileged-group removal.
Address local accounts, cloud keys, source-control tokens, shared secrets known to the person, support access, physical credentials, and company devices rather than assuming central disablement reaches everything.
You should end up with: System-specific completion evidence plus credential rotation, device lock, recovery, or wipe results where applicable.
Compare expected actions with actual downstream state, investigate late or failed actions, and confirm movers lost access from their former role instead of only gaining the new role.
You should end up with: A closed lifecycle record with completion timestamps, verified system state, and resolved exceptions.
Build the evidence set in three layers: what defines the control, who approved or reviewed it, and what proves it operated. Collect operating records when the work happens so they remain dated, attributable, correctly scoped, and traceable to the underlying activity.
Before sharing, remove unrelated personal or customer data, never expose passwords, tokens, or secret values, preserve enough source context to authenticate the record, and use the secure exchange approved for the engagement.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
Every authoritative departure, role-change, contract-end, or loss-of-need trigger starts a traceable workflow with the effective time and all required identity and downstream actions.
Include this context
Lifecycle record ID
Include this context
Person and event type
Include this context
Authoritative trigger source
Include this context
Effective timestamp
Include this context
Required system actions
Include this context
Completion status and times
Weak evidence to avoid
An IT ticket created after a departure that omits the authoritative trigger, effective time, direct accounts, former role, and per-system completion status.
Confirm what the record proves
The central identity was disabled or changed at the effective time and its active sessions, privileged groups, and recovery paths were revoked as intended.
Include this context
Identity
Include this context
Disable or change action
Include this context
Event timestamp
Include this context
Actor or automation
Include this context
Session and group outcome
Include this context
Source event ID
Weak evidence to avoid
A current disabled-user screenshot with no event time, triggering lifecycle record, session revocation, group changes, or source event ID.
Confirm what the record proves
Direct and non-single-sign-on accounts, local roles, tokens, and system-specific access reached the required removed or modified state for the lifecycle event.
Include this context
Lifecycle record ID
Include this context
Target system
Include this context
Account or entitlement
Include this context
Required action
Include this context
Completion timestamp
Include this context
Verified resulting state
Weak evidence to avoid
A general active-user export that is unrelated to the specific departure or mover and does not show the direct account’s removal action or final state.
Type 1
As of the selected date, retain the current lifecycle trigger matrix and the latest completed departure, mover, contract-end, or loss-of-need case showing central identity action plus verified direct and non-single-sign-on system state.
Type 2
Start with every authoritative departure, mover, contract-end, and documented loss-of-business-need trigger effective during the review period. For each trigger, include the identity-provider disable or role-change event and the required removal or modification state for every direct, local, and non-single-sign-on account, token, privileged role, and system assignment identified by the lifecycle workflow.
Reconcile all effective departure, mover, contract-end, and loss-of-need triggers from human-resources, contractor, vendor, and manager-approved sources to lifecycle records. Then reconcile each record to identity-provider events and independently exported direct and non-SSO target-system removal state, explicitly documenting systems where the person had no account.
Use this checklist to prepare for procedures an auditor may perform. The exact steps and sample selection depend on your engagement scope and the service auditor's professional judgment.
Determine whether the control is designed to achieve this result: Access is disabled or adjusted promptly when employment, contract, role, or business need changes, including sessions, local accounts, tokens, and privileged paths outside the main identity provider.
Compare the documented owner with the intended role (IT / Infrastructure Owner / System Owners), then compare dated records with the stated cadence: Per request/change; periodic review quarterly/annually by risk.
Reconcile all effective departure, mover, contract-end, and loss-of-need triggers from human-resources, contractor, vendor, and manager-approved sources to lifecycle records. Then reconcile each record to identity-provider events and independently exported direct and non-SSO target-system removal state, explicitly documenting systems where the person had no account.
As of the selected date, retain the current lifecycle trigger matrix and the latest completed departure, mover, contract-end, or loss-of-need case showing central identity action plus verified direct and non-single-sign-on system state.
Start with every authoritative departure, mover, contract-end, and documented loss-of-business-need trigger effective during the review period. For each trigger, include the identity-provider disable or role-change event and the required removal or modification state for every direct, local, and non-single-sign-on account, token, privileged role, and system assignment identified by the lifecycle workflow.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
For each selected record, confirm it demonstrates Every authoritative departure, role-change, contract-end, or loss-of-need trigger starts a traceable workflow with the effective time and all required identity and downstream actions.
For each selected record, confirm it demonstrates The central identity was disabled or changed at the effective time and its active sessions, privileged groups, and recovery paths were revoked as intended.
For each selected record, confirm it demonstrates Direct and non-single-sign-on accounts, local roles, tokens, and system-specific access reached the required removed or modified state for the lifecycle event.
Use the categories that apply to this control: connect any policy or design artifact to its approval or review record, then trace a selected operating record through execution, result, and any exception or remediation.
These identifiers help you navigate related Trust Services Criteria. They do not reproduce the criteria or prove that this control fully addresses them in your environment.
Confirm final scope, mappings, and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.