Logical Access
Workforce, privileged, customer-support, service-account, administrative, and third-party access is reviewed on a defined cadence with evidence of owner approval, remediation, and closure.
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
System and business owners periodically confirm that workforce, privileged, support, machine, and third-party access remains appropriate and that rejected access is actually removed.
First SOC 2 program
Begin with the identity provider and the handful of systems that can change production or expose customer data. Preserve point-in-time access exports, have accountable owners decide keep or remove for every identity, and track the resulting removals to verified completion.
As the company scales
Use identity-governance connectors and risk-tiered campaigns, reconcile human and machine identities against authoritative owner data, require reviewers to explain exceptions, and measure overdue decisions and remediation.
Tier systems and roles by risk, identify the accountable reviewer for each, and define which workforce, privileged, support, service-account, and third-party populations must be included.
You should end up with: A review schedule and scope map tied to systems, role types, and named reviewers.
Export active users, groups, roles, direct grants, service accounts, and external identities with timestamps and source-system identifiers before reviewers begin.
You should end up with: Immutable, dated access populations that can be reproduced and sampled later.
Require the responsible manager or system owner to decide retain, change, or remove for every listed assignment and explain unusual privilege or exceptions.
You should end up with: Complete reviewer decisions with identity, entitlement, reviewer, date, and rationale where needed.
Create assigned work for removals and role changes, prioritize high-risk findings, and capture the target-system event that proves the entitlement changed.
You should end up with: Remediation records linked to actual removal or modification evidence.
Reconcile all decisions and remediation, resolve missing owners or incomplete records, and document coverage, exceptions, overdue items, and final sign-off.
You should end up with: A completed review package showing population completeness, decisions, remediation, and accountable closure.
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.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
Confirm what the record proves
The accountable manager or system owner made an explicit retain, change, or remove decision for each entitlement presented for review.
Include this context
Review campaign or record ID
Include this context
Identity and entitlement
Include this context
Reviewer and authority
Include this context
Decision
Include this context
Decision date
Include this context
Rationale for exceptions
Weak evidence to avoid
A single ‘looks good’ sign-off with no line-level decisions, reviewer authority, exception rationale, or connection to the preserved population.
Confirm what the record proves
The designated reviewer confirmed population coverage, completed decisions, resolved follow-up work, and formally closed the access review.
Include this context
Review scope
Include this context
Population count
Include this context
Reviewer
Include this context
Completion date
Include this context
Open and closed findings
Include this context
Final status
Weak evidence to avoid
A signature and date with no scope, population count, unresolved-item status, or evidence that required removals were completed.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
The reviewer received a preserved point-in-time population of in-scope human, privileged, support, machine, and third-party entitlements rather than a changing live view.
Include this context
Identity
Include this context
System
Include this context
Role or entitlement
Include this context
Assignment source
Include this context
Account status
Include this context
Export timestamp
Weak evidence to avoid
A live access page captured after decisions were made, with no export time, direct grants, service accounts, or record of the original review population.
Confirm what the record proves
Entitlements rejected or changed during the review were assigned, acted upon, and verified in the affected target system.
Include this context
Finding or review ID
Include this context
Identity and entitlement
Include this context
Required action
Include this context
Assignee and due date
Include this context
Completion time
Include this context
Target-system evidence
Weak evidence to avoid
A closed ticket saying ‘access fixed’ without the affected entitlement, target-system removal event, completion time, or link to the review decision.
Type 1
As of the selected date, retain the current review scope and schedule, the latest preserved entitlement population, all reviewer decisions, and verified closure for the latest completed review.
Type 2
Include every required access-review campaign during the review period, every in-scope entitlement present in each campaign’s point-in-time population, every reviewer decision, and every remediation, exception, overdue item, and final sign-off associated with those campaigns.
Reconcile each preserved campaign population to identity-provider and target-system exports, including direct, local, external, and machine access, then reconcile every change or remove decision to verified target-system state before sign-off.
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: System and business owners periodically confirm that workforce, privileged, support, machine, and third-party access remains appropriate and that rejected access is actually removed.
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 each preserved campaign population to identity-provider and target-system exports, including direct, local, external, and machine access, then reconcile every change or remove decision to verified target-system state before sign-off.
As of the selected date, retain the current review scope and schedule, the latest preserved entitlement population, all reviewer decisions, and verified closure for the latest completed review.
Include every required access-review campaign during the review period, every in-scope entitlement present in each campaign’s point-in-time population, every reviewer decision, and every remediation, exception, overdue item, and final sign-off associated with those campaigns.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
For each selected record, confirm it demonstrates The accountable manager or system owner made an explicit retain, change, or remove decision for each entitlement presented for review.
For each selected record, confirm it demonstrates The designated reviewer confirmed population coverage, completed decisions, resolved follow-up work, and formally closed the access review.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
For each selected record, confirm it demonstrates The reviewer received a preserved point-in-time population of in-scope human, privileged, support, machine, and third-party entitlements rather than a changing live view.
For each selected record, confirm it demonstrates Entitlements rejected or changed during the review were assigned, acted upon, and verified in the affected target system.
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.