Logical Access
New or modified privileged access to production systems, cloud environments, repositories, security tooling, and customer-facing administrative functions is approved by an authorized owner or manager.
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
Privileged access begins only after an authorized owner approves a specific role, system, business reason, and duration, and the granted entitlement matches that decision.
First SOC 2 program
Define which roles count as privileged, route requests through one ticketing channel, require approval from the system or business owner before adding a user to a managed group, and record emergency grants for prompt retrospective review.
As the company scales
Use identity-governance or privileged-access workflows for time-limited elevation, enforce separation between requester and approver, and automatically reconcile approved decisions against actual entitlements.
Catalog administrator, owner, write-to-production, security-management, data-export, and equivalent roles for each critical system, including who is allowed to approve them.
You should end up with: A privileged-entitlement catalog with system owners and authorized approvers.
Capture the named user, target system, exact role, business need, requested start and end dates, and any customer or environment limitation before routing a request.
You should end up with: Access requests with enough detail for an owner to make an informed decision.
Route the request to an authorized owner who is not the requester, and prevent fulfillment until the approval and any conditions are recorded.
You should end up with: Time-ordered records showing approval preceded the privileged entitlement change.
Fulfill access through a managed role or group, apply the approved duration, and capture the identity-system event that shows what was actually granted.
You should end up with: A completed request linked to the resulting group membership or entitlement event.
Compare privileged memberships with approved requests, investigate unmatched or expired access, and document emergency grants and their follow-up review.
You should end up with: A reconciliation record with unauthorized, expired, or mismatched access removed or formally resolved.
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 full request describes the named identity, exact privileged entitlement, target system, business need, and intended duration before a decision is made.
Include this context
Request ID
Include this context
Named identity
Include this context
Target system
Include this context
Requested role
Include this context
Business reason
Include this context
Requested duration
Weak evidence to avoid
A request reading ‘needs admin’ with no exact entitlement, system, duration, or reason the privilege is necessary.
Confirm what the record proves
An authorized system or business owner made an attributable decision on the requested privileged scope before it was fulfilled.
Include this context
Request ID
Include this context
Approver identity
Include this context
Approver authority
Include this context
Decision
Include this context
Decision timestamp
Include this context
Conditions or expiry
Weak evidence to avoid
An approval emoji from an unidentified chat participant with no role, request reference, decision time, or approved duration.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
The native workflow preserves the sequence from request through approval, fulfillment, expiry, and closure without rewriting the history after the fact.
Include this context
Ticket ID
Include this context
Created and approved times
Include this context
Requester and fulfiller
Include this context
Workflow status
Include this context
Target entitlement
Include this context
Closure time
Weak evidence to avoid
A manually assembled summary row with no native workflow history, actor transitions, entitlement value, or stable ticket link.
Confirm what the record proves
The target system shows that the approved role was granted to the intended identity at the recorded time and later changed or expired as required.
Include this context
Identity
Include this context
System and role
Include this context
Grant or removal action
Include this context
Actor or automation
Include this context
Event timestamp
Include this context
Source event ID
Weak evidence to avoid
A current administrator list that cannot show when the entitlement was granted, who changed it, or whether it matched the approved request.
Type 1
As of the selected date, retain the privileged-entitlement catalog, authorized approver list, current approval workflow, and one latest completed request whose target entitlement matches the recorded decision.
Type 2
Include every privileged access request submitted during the review period, including approved, rejected, cancelled, expired, and emergency requests, together with every resulting grant, modification, renewal, expiry, and removal event.
Reconcile all workflow requests to target-system entitlement events, then independently export privileged grants and removals from each target system to identify direct, emergency, expired, or unmatched changes that bypassed the request channel.
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: Privileged access begins only after an authorized owner approves a specific role, system, business reason, and duration, and the granted entitlement matches that decision.
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 workflow requests to target-system entitlement events, then independently export privileged grants and removals from each target system to identify direct, emergency, expired, or unmatched changes that bypassed the request channel.
As of the selected date, retain the privileged-entitlement catalog, authorized approver list, current approval workflow, and one latest completed request whose target entitlement matches the recorded decision.
Include every privileged access request submitted during the review period, including approved, rejected, cancelled, expired, and emergency requests, together with every resulting grant, modification, renewal, expiry, and removal event.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
For each selected record, confirm it demonstrates The full request describes the named identity, exact privileged entitlement, target system, business need, and intended duration before a decision is made.
For each selected record, confirm it demonstrates An authorized system or business owner made an attributable decision on the requested privileged scope before it was fulfilled.
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 native workflow preserves the sequence from request through approval, fulfillment, expiry, and closure without rewriting the history after the fact.
For each selected record, confirm it demonstrates The target system shows that the approved role was granted to the intended identity at the recorded time and later changed or expired as required.
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.