The Complete Guide to SOC 2 Access Control Requirements

If your company is pursuing SOC 2 Type II, access controls will consume more of your preparation time than any other domain. Auditors spend roughly 40% of their evidence review on logical access — who can reach what, how you know, and what happens when someone's role changes.

This guide covers the three Common Criteria that define SOC 2 access control requirements: CC6.1, CC6.2, and CC6.3. We'll walk through what auditors actually look for, the controls that satisfy each criterion, and the identity governance practices that keep you compliant between audits.

Understanding CC6.1, CC6.2, and CC6.3

SOC 2 organizes its Trust Services Criteria into Common Criteria (CC) groups. Access controls fall primarily under CC6 — Logical and Physical Access Controls. Three sub-criteria matter most:

CC6.1 — Logical Access Security Software, Infrastructure, and Architectures

CC6.1 asks whether your organization has implemented logical access security over its information assets. In practice, auditors want to see:

• Authentication mechanisms — how users prove their identity (SSO, MFA, password policies)
• Authorization models — how you determine what authenticated users can access
• Network segmentation — how you restrict lateral movement between systems
• Encryption — how data is protected in transit and at rest

The key question: can you demonstrate that only authorized individuals access production systems and sensitive data?

CC6.2 — Provisioning and Deprovisioning of Access

CC6.2 focuses on the lifecycle of access. Auditors evaluate:

• Provisioning workflows — how new employees and contractors receive access
• Role-based assignments — whether access is granted based on job function rather than ad hoc requests
• Deprovisioning procedures — how quickly access is revoked when someone leaves or changes roles
• Approval documentation — who approved each access grant, and when

This criterion catches more companies than any other. The gap between "we revoke access when someone leaves" and "we can prove access was revoked within 24 hours for every termination in the audit period" is where audit findings live.

CC6.3 — Role-Based Access and Least Privilege

CC6.3 requires that access is restricted to the minimum necessary for each user's job function:

• Role definitions — documented roles with explicit permission sets
• Least privilege enforcement — no user has more access than their role requires
• Segregation of duties — critical functions require multiple individuals (e.g., code deploy vs. code review)
• Periodic access reviews — regular validation that current access matches current roles

Logical Access Controls vs. Physical Access Controls

SOC 2 CC6 covers both logical and physical access. Most mid-market companies handle physical access adequately — badge systems, visitor logs, server room locks. Where they struggle is logical access: the permissions, roles, and authentication mechanisms that govern access to software systems.

Logical access controls include:

• Identity provider (IdP) configuration — Okta, Azure AD, Google Workspace acting as the source of truth for authentication
• Single sign-on (SSO) — centralized authentication that ensures every application login routes through your IdP
• Multi-factor authentication (MFA) — a second factor for all production and administrative access
• Conditional access policies — location-based, device-based, or risk-based restrictions on authentication
• API key and service account management — non-human identities with scoped permissions and rotation schedules

The audit evidence you need: IdP configuration exports, SSO enrollment reports, MFA enforcement logs, and conditional access policy documentation.

User Access Reviews and Access Certifications

Access reviews are the single most important recurring control for SOC 2 compliance. An access review (also called an access certification) is a periodic process where managers or application owners validate that every user's current access is appropriate for their role.

What Auditors Expect

For a SOC 2 Type II audit, you need to demonstrate:

1. Defined review frequency — quarterly is the standard for sensitive systems, semi-annual for lower-risk applications
2. Documented review process — who reviews, what they review, and how decisions are recorded
3. Evidence of completion — timestamped records showing each reviewer certified or revoked each access entry
4. Remediation tracking — when a reviewer flags inappropriate access, evidence that it was revoked and when

Common Mistakes

• Reviewing at the application level instead of the permission level. Confirming that "Jane has access to Salesforce" is insufficient. Auditors want to see that Jane's Salesforce profile and permission sets match her role.
• Delegating reviews to IT instead of business owners. IT can verify technical access, but only the business owner knows whether the access is appropriate for the user's current responsibilities.
• Missing the review window. If your policy says quarterly reviews and you miss Q3 by two weeks, that's a gap in your audit period. Auditors will flag it.

RBAC and Least Privilege Implementation

Role-Based Access Control (RBAC) is the foundation of SOC 2 access control compliance. Rather than assigning permissions to individual users, you define roles that map to job functions and assign users to roles.

Building an RBAC Model That Survives Audit

Step 1: Inventory your applications and permission levels. List every system in scope, the permission levels each system supports, and which permissions constitute sensitive or administrative access.

Step 2: Define roles based on job functions. Roles should map to actual job titles or departments — "Engineering IC," "Engineering Manager," "Finance Analyst," "Finance Admin." Avoid generic roles like "Power User" that bundle unrelated permissions.

Step 3: Map roles to permissions. For each role, document exactly which applications and permission levels are included. This becomes your role-permission matrix — the artifact auditors will review.

Step 4: Assign users to roles. Each user should have exactly one primary role. Exception-based access (permissions beyond the role) should require documented approval and periodic re-certification.

Step 5: Enforce through your IdP. Configure your identity provider to automatically assign application access based on role. In Okta, this means group-based application assignments. In Azure AD, this means dynamic groups tied to user attributes.

Least Privilege in Practice

Least privilege means every user has the minimum access required to perform their job — nothing more. In practice:

• Default to no access. New role assignments start with zero permissions. Access is added explicitly, not inherited by default.
• Separate read and write permissions. Most users who need to view dashboards don't need to edit them.
• Time-bound elevated access. Administrative or break-glass access should be just-in-time (JIT) with automatic expiration.
• Service accounts scoped to single functions. A CI/CD service account should not have the same permissions as a human administrator.

The Joiner-Mover-Leaver Lifecycle

The joiner-mover-leaver (JML) lifecycle is the operational backbone of access control. Every access control finding in a SOC 2 audit traces back to a JML process failure.

Joiners

When a new employee or contractor starts:

1. HR creates the user record in your HRIS (BambooHR, Rippling, Workday)
2. The HRIS triggers provisioning in your IdP via SCIM or API integration
3. The IdP assigns applications based on the user's role/department
4. The user receives access to exactly the systems their role requires — no more, no less

Audit evidence: Provisioning logs showing the timestamp, role assignment, and applications granted for each new hire during the audit period.

Movers

When an employee changes roles:

1. HR updates the user's department or title in the HRIS
2. The change propagates to the IdP
3. Old role-based access is revoked; new role-based access is granted
4. Any exception-based access from the old role is reviewed and removed if no longer appropriate

This is where most companies fail. The new access gets added, but the old access doesn't get removed — creating "permission creep" that accumulates over time.

Leavers

When an employee or contractor departs:

1. HR marks the user as terminated in the HRIS
2. The IdP disables the account immediately (within your SLA — typically same-day)
3. All application sessions are revoked
4. Shared credentials the user had access to are rotated

Audit evidence: A reconciliation showing every termination during the audit period, the termination date, and the timestamp when IdP access was disabled. Any gap beyond your SLA is a finding.

Common Audit Findings and How to Avoid Them

After supporting dozens of SOC 2 audits, these are the findings we see repeatedly:

1. Orphaned Accounts

The finding: Active accounts exist in applications for users who are no longer employed.

The fix: Automate deprovisioning through SCIM. Run monthly reconciliation reports comparing your IdP user list against each application's user list. Any application user without a matching active IdP account is an orphan that needs investigation.

2. Excessive Permissions

The finding: Users have administrative or elevated access beyond what their role requires.

The fix: Implement quarterly access reviews at the permission level, not just the application level. Use your role-permission matrix as the baseline — any deviation requires documented justification.

3. Missing MFA

The finding: Production systems or administrative consoles accessible without multi-factor authentication.

The fix: Enforce MFA at the IdP level for all applications. Use conditional access policies to require MFA for sensitive applications even from trusted networks. Audit MFA enrollment reports monthly.

4. Shared Accounts

The finding: Multiple users share a single set of credentials for a system.

The fix: Eliminate shared accounts wherever possible. Where shared accounts are unavoidable (some legacy systems), implement a privileged access management (PAM) solution that logs individual usage of the shared credential.

5. Incomplete Access Review Evidence

The finding: Access reviews were performed but evidence is missing or incomplete.

The fix: Use a purpose-built access review tool or at minimum a tracked workflow (not email). Every review cycle should produce a dated, signed-off report showing each user reviewed, the decision made, and the reviewer's identity.

6. Delayed Deprovisioning

The finding: Terminated users retained access for days or weeks after their departure.

The fix: Integrate your HRIS with your IdP via SCIM so terminations propagate automatically. Set your SLA (same-day is the standard) and monitor it. Run weekly reports comparing HR termination dates against IdP disable dates.

How Identity Governance Tools Map to SOC 2

Modern identity governance platforms handle most CC6 requirements natively. Here's how the major platforms map:

The gap for most mid-market companies isn't the tooling — it's the configuration. Having Okta or Azure AD in your stack doesn't mean your access controls are SOC 2 compliant. The platform needs to be configured with:

• SCIM provisioning enabled for every in-scope application
• Group-based application assignments mapped to your RBAC model
• MFA policies enforced globally, not just for specific apps
• Access review campaigns scheduled and assigned to business owners
• Deprovisioning workflows triggered by HR status changes

Building Your SOC 2 Access Control Program

If you're starting from scratch or remediating findings, here's the sequence that produces audit-ready controls most efficiently:

1. Deploy SSO and MFA universally. This closes the largest surface area of findings immediately.
2. Document your RBAC model. Define roles, map permissions, and get sign-off from department leads.
3. Automate provisioning and deprovisioning. Connect your HRIS to your IdP. Enable SCIM for every application that supports it.
4. Implement quarterly access reviews. Start with your highest-risk applications and expand.
5. Monitor and report. Build dashboards that surface orphaned accounts, MFA gaps, and review completion rates.

The companies that pass SOC 2 audits without findings aren't doing anything exotic. They have automated JML processes, enforced RBAC models, and regular access reviews with complete evidence trails. The companies that struggle are the ones managing access through tickets, spreadsheets, and tribal knowledge.

Your identity infrastructure either produces audit evidence automatically, or your team scrambles to reconstruct it every quarter. The first approach scales. The second one doesn't.