Logical Access
Customer access enforces strong authentication, role-based authorization, and customer/tenant boundaries for portals, reports, evidence, and administrative roles.
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
Each customer user is strongly authenticated and can reach only the tenants, records, reports, and administrative actions explicitly assigned to that identity.
First SOC 2 program
Use a reputable managed authentication service, define a small set of customer roles, derive tenant context on the server, and enforce authorization in API and data-access code rather than relying on hidden interface elements. Add negative tests that try to cross tenant boundaries.
As the company scales
Move authorization rules into a shared policy layer, automate role and tenant-boundary tests in delivery pipelines, govern support impersonation, and monitor customer administrator changes and repeated authorization failures.
For each customer role, list allowed actions, sensitive objects, administrative capabilities, and whether access is limited to one tenant or a defined set of tenants.
You should end up with: A customer role-and-permission matrix that product and engineering owners can review.
Configure session lifetime, recovery, lockout or throttling, strong authentication for sensitive roles, and secure handling of tokens across web, API, and mobile entry points.
You should end up with: Authentication settings and test results for login, recovery, session expiry, and sensitive-role access.
Resolve customer and role context from the authenticated identity on the server, and reject attempts to substitute a tenant identifier supplied only by the browser or request body.
You should end up with: Documented tenant-context flow with representative middleware or policy configuration.
Apply the same tenant and role checks to APIs, background jobs, reports, exports, object downloads, search results, and customer-support functions.
You should end up with: A path-by-path authorization inventory linked to implemented enforcement points.
Create automated tests that use valid identities with the wrong role or tenant and attempt direct-object, report, export, and administrative access.
You should end up with: Repeatable negative-test results showing that unauthorized requests are denied without exposing another customer’s data.
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 defines which customer roles may perform sensitive actions and which tenant or customer scope limits each role.
Include this context
Role name
Include this context
Allowed actions
Include this context
Prohibited actions
Include this context
Tenant scope
Include this context
Role owner
Include this context
Approval or version date
Weak evidence to avoid
A product screenshot showing three role names without their server-enforced permissions, tenant scope, owner, or version.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
The current authentication service enforces the intended login, session, recovery, and sensitive-role settings for the scoped customer application.
Include this context
Application or tenant
Include this context
Authentication method
Include this context
Session settings
Include this context
Recovery settings
Include this context
Sensitive-role safeguards
Include this context
Generated-at timestamp
Weak evidence to avoid
A generic authentication-provider settings page that does not show the production application, effective policy, session values, or capture date.
Confirm what the record proves
Valid users assigned to one customer are denied when they attempt direct API, object, report, or administrative access in another customer context.
Include this context
Test run ID and date
Include this context
Source tenant and role
Include this context
Target tenant and object
Include this context
Access path tested
Include this context
Expected and actual result
Include this context
Failure and retest link
Weak evidence to avoid
A green unit-test summary that tests missing login only and never uses two valid customer identities against a production-like authorization path.
Confirm what the record proves
Current customer identities, roles, tenant assignments, and sensitive authentication settings in the application match authorized customer administration decisions.
Include this context
Customer identity
Include this context
Tenant
Include this context
Assigned role
Include this context
Account status
Include this context
Authentication setting
Include this context
As-of timestamp
Weak evidence to avoid
One user profile with no tenant identifier, effective role, account status, source population, or as-of timestamp.
Type 1
As of the selected date, retain the current customer role model, production authentication and tenant-enforcement configuration, current customer role assignments, and the latest successful cross-tenant negative test.
Type 2
Include every customer role or tenant-assignment grant, change, and removal; every material authentication or authorization configuration change; every required cross-tenant test run for API, object, report, and administrative paths; and every governed support override during the review period.
Reconcile customer identities and role assignments between the authentication service and application data store, then reconcile authorization deployments and the complete scheduled test history to the role model and supported data paths.
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: Each customer user is strongly authenticated and can reach only the tenants, records, reports, and administrative actions explicitly assigned to that identity.
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 customer identities and role assignments between the authentication service and application data store, then reconcile authorization deployments and the complete scheduled test history to the role model and supported data paths.
As of the selected date, retain the current customer role model, production authentication and tenant-enforcement configuration, current customer role assignments, and the latest successful cross-tenant negative test.
Include every customer role or tenant-assignment grant, change, and removal; every material authentication or authorization configuration change; every required cross-tenant test run for API, object, report, and administrative paths; and every governed support override during the review period.
Documents that define the control, its scope, ownership, and expected way of working.
For each selected record, confirm it demonstrates The approved access design defines which customer roles may perform sensitive actions and which tenant or customer scope limits each role.
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 authentication service enforces the intended login, session, recovery, and sensitive-role settings for the scoped customer application.
For each selected record, confirm it demonstrates Valid users assigned to one customer are denied when they attempt direct API, object, report, or administrative access in another customer context.
For each selected record, confirm it demonstrates Current customer identities, roles, tenant assignments, and sensitive authentication settings in the application match authorized customer administration decisions.
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.