Logical Access
Access is assigned based on least privilege, role, business need, environment, customer assignment, and data classification.
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
People and machine identities receive only the permissions needed for their role, assigned environment, customer responsibilities, and approved business purpose.
First SOC 2 program
Create a small role matrix tied to real job functions, grant access through groups, separate production from development, and begin with no access rather than broad default roles. Document the few one-off exceptions instead of silently accumulating them.
As the company scales
Maintain an entitlement catalog, model incompatible duties, use attribute- or policy-based decisions where roles become unwieldy, and continuously detect direct grants, unused privilege, and divergence from approved role design.
Identify permissions that change production, administer identities, access customer data, export records, alter security settings, or approve financial and business actions.
You should end up with: A prioritized entitlement inventory with high-risk actions clearly identified.
Group only the permissions needed by each job function and distinguish environment, customer assignment, data sensitivity, and administrative responsibility.
You should end up with: A role matrix that explains the allowed permissions and exclusions for each function.
Map approved roles to identity-provider and target-system groups, remove avoidable direct grants, and make the restrictive role the default for new users.
You should end up with: Group-to-role mappings and exported entitlement configurations aligned to the approved design.
Keep development access from automatically granting production rights and identify combinations, such as requesting and approving the same sensitive action, that need separation or compensating review.
You should end up with: Environment boundaries and a short record of incompatible duties with their handling approach.
Review direct grants, role changes, inherited permissions, unused elevated access, and exceptions; remove or justify assignments that no longer match the role design.
You should end up with: A least-privilege review with identified drift, approved exceptions, and completed removals.
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.
Documents that define the control, its scope, ownership, and expected way of working.
Confirm what the record proves
The approved access design maps job functions, environments, customer responsibilities, and sensitive actions to narrowly defined roles and explicit exclusions.
Include this context
Job function
Include this context
Role name
Include this context
Allowed permissions
Include this context
Environment or customer scope
Include this context
Excluded permissions
Include this context
Owner and version
Weak evidence to avoid
A list of role names with no permission detail, environment boundary, sensitive-action exclusions, owner, or effective version.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
Confirm what the record proves
An accountable reviewer compared actual privilege with role need, identified drift and incompatible access, and completed or governed follow-up actions.
Include this context
Review scope and date
Include this context
Reviewer
Include this context
Identity or role reviewed
Include this context
Decision and rationale
Include this context
Finding or exception
Include this context
Remediation status
Weak evidence to avoid
A signed statement that access is appropriate with no reviewed population, permission detail, drift findings, or removal evidence.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
The current group structure and membership implement approved roles through managed assignments rather than unexplained individual grants.
Include this context
Group name
Include this context
Mapped role
Include this context
Member identity
Include this context
Assignment source
Include this context
Environment
Include this context
As-of timestamp
Weak evidence to avoid
A screenshot of one group without complete membership, its mapped role, nested groups, direct grants, or capture time.
Confirm what the record proves
The current permissions attached to roles and identities in target systems match the least-privilege design and reveal inherited or direct access.
Include this context
System and resource
Include this context
Role or identity
Include this context
Permission set
Include this context
Inheritance source
Include this context
Environment
Include this context
Generated-at timestamp
Weak evidence to avoid
A policy name with no effective permissions, inherited access, resource scope, environment, or current-state export.
Type 1
As of the selected date, retain the current approved role matrix, current group and effective-entitlement exports, and the latest least-privilege review with completed follow-up.
Type 2
Include every role-definition change and every human or machine-identity assignment event during the review period: grants, modifications, and removals made through managed roles or groups, provisioning workflows, and direct target-system changes. Also include every exception, each required least-privilege review, the complete entitlement snapshot used in each review, and every resulting finding, correction, removal, or accepted exception.
Derive the complete assignment-event history from managed group membership, provisioning, and direct target-system logs. For every scoped system, reconcile the opening effective-entitlement snapshot to the closing snapshot by applying every grant, modification, and removal in sequence, including nested and inherited access; then match every event to approved role design, an authorized request, or a current exception and trace every review decision to completed follow-up.
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: People and machine identities receive only the permissions needed for their role, assigned environment, customer responsibilities, and approved business purpose.
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.
Derive the complete assignment-event history from managed group membership, provisioning, and direct target-system logs. For every scoped system, reconcile the opening effective-entitlement snapshot to the closing snapshot by applying every grant, modification, and removal in sequence, including nested and inherited access; then match every event to approved role design, an authorized request, or a current exception and trace every review decision to completed follow-up.
As of the selected date, retain the current approved role matrix, current group and effective-entitlement exports, and the latest least-privilege review with completed follow-up.
Include every role-definition change and every human or machine-identity assignment event during the review period: grants, modifications, and removals made through managed roles or groups, provisioning workflows, and direct target-system changes. Also include every exception, each required least-privilege review, the complete entitlement snapshot used in each review, and every resulting finding, correction, removal, or accepted exception.
Documents that define the control, its scope, ownership, and expected way of working.
For each selected record, confirm it demonstrates The approved access design maps job functions, environments, customer responsibilities, and sensitive actions to narrowly defined roles and explicit exclusions.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
For each selected record, confirm it demonstrates An accountable reviewer compared actual privilege with role need, identified drift and incompatible access, and completed or governed follow-up actions.
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 current group structure and membership implement approved roles through managed assignments rather than unexplained individual grants.
For each selected record, confirm it demonstrates The current permissions attached to roles and identities in target systems match the least-privilege design and reveal inherited or direct access.
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.