SOC 2 Logical Access Controls: CC6 Requirements Explained
CC6 is the largest criteria cluster in SOC 2. Learn what logical and physical access controls are required, how to implement least privilege, and what evidence auditors collect.
- CC6.1 through CC6.8 cover logical access, physical security, encryption in transit, and third-party access — the broadest criteria cluster in SOC 2.
- CC6.1 requires that access to assets is limited to authorized personnel through identification, authentication, and authorization mechanisms.
- MFA enforcement, least-privilege IAM roles, and quarterly access reviews are the three most commonly tested CC6 controls.
- Offboarding procedures — revoking access on the day of termination — are tested rigorously and a frequent source of exceptions.
- Third-party access (contractors, vendors) must be governed by formal access agreements with defined access scope and termination conditions.
In this guide
CC6 Overview
The CC6 cluster contains eight criteria covering logical access (CC6.1–CC6.3), physical security (CC6.4), logical access restrictions during data disposal (CC6.5), encryption of data in transit (CC6.6 via CC6.1), restriction of access to software development environments (CC6.7), and vendor and third-party access (CC6.8). CC6.1 is the foundational criterion and the most heavily tested of all SOC 2 criteria.
Together, these criteria represent the largest single cluster in the SOC 2 Common Criteria — more controls and more evidence tests than any other area. Access control is treated as foundational because unauthorized access is the root cause of the vast majority of security incidents. A mature CC6 control environment significantly reduces the likelihood of both external breaches and insider threats.
For most SaaS companies, CC6 maps to four operational areas: identity and access management (IAM) in cloud platforms, SSO and directory services (Okta, Azure AD), physical access to offices and data centers, and governance processes like access reviews and offboarding. Each area has specific evidence requirements.
CC6.1: Access Control Foundations
CC6.1 requires that logical access to assets is restricted to authorized and identified users, equipment, and software. The criterion covers identification (users must be identified uniquely — no shared accounts), authentication (users must prove their identity — passwords, MFA), and authorization (authenticated users only access resources they are explicitly permitted to access — RBAC, IAM policies).
Shared accounts are a direct violation of CC6.1. If multiple engineers share a single AWS IAM user account, the auditor cannot attribute actions to individuals, and the identity and authentication requirements cannot be satisfied. All production system access must be via individually assigned accounts. This applies to database accounts, cloud platform accounts, and third-party SaaS tools.
Authentication requirements under CC6.1 have evolved significantly. The current expectation is that MFA is enforced for all access to systems in scope — not just encouraged, but technically enforced with no bypass path. Password-only access to production environments is considered a gap even if your policy requires strong passwords.
MFA Requirements
Multi-factor authentication (MFA) is effectively required for SOC 2 at all access points to in-scope systems. This includes: AWS Console and CLI access (enforce via IAM policy requiring MFA token for all actions), GitHub/GitLab repository access (enforce via organization security settings), SSO portal access (enforce via Okta, Azure AD, or Google Workspace policy), customer-facing application admin interfaces, and VPN access to internal network resources.
The evidence for MFA enforcement is not a policy document — it is a screenshot or configuration export showing that MFA is technically required. For AWS, this means an IAM policy with a `Condition` block requiring MFA token presence. For GitHub, this means the "Require two-factor authentication" setting enabled at the organization level. For Okta, this means a global authentication policy requiring MFA. Auditors will ask to see these configuration screenshots, not just your policy document.
Phishing-resistant MFA methods (hardware security keys like YubiKey, FIDO2 passkeys) are considered best practice and may be required for highly sensitive roles. TOTP apps (Google Authenticator, Authy) and push notifications (Duo, Okta Verify) are acceptable for most SOC 2 purposes. SMS-based MFA is considered weak due to SIM-swapping attacks and is not recommended, though auditors rarely require its elimination if other MFA methods are also available.
Least Privilege and Role-Based Access
Least privilege means that each user, service, and system has access to exactly the resources needed for their function — no more. For cloud IAM, this translates to: developers have read access to production resources for debugging but not write access; CI/CD service accounts have deployment permissions scoped to specific resources; database access roles are scoped to the schemas and tables needed for each service; and admin access to the cloud console requires elevation through a privileged access management (PAM) system with MFA and session recording.
Role-based access control (RBAC) is the standard mechanism for implementing least privilege at scale. Define access roles (e.g., Developer, SRE, ReadOnly, Admin) with documented permission sets, and assign users to roles rather than granting individual permissions. This approach is auditable (you can show the auditor your role definitions and user-to-role assignments) and maintainable (changing a permission for a job function requires updating one role definition, not 20 individual user records).
Access provisioning should follow a documented request-and-approval process. Access requests should be logged (ticket, form, email thread) with the business justification, the approver's identity and approval date, and the provisioned access scope. Auditors will sample access grants during the observation period and verify that each had an appropriate approval. Access granted by an IT admin in response to a Slack DM with no ticket record is an exception.
Periodic Access Reviews
Access reviews are the process of periodically validating that the current set of users with access to each system is still appropriate. CC6.1 requires that access is reviewed and modified when no longer appropriate. In practice, this means conducting formal access reviews for all in-scope systems at regular intervals — quarterly is the standard for most SOC 2 programs, though semi-annual is accepted for lower-risk systems.
The access review process: export the current user access list for each in-scope system, distribute the list to the system owner (typically the business owner of the application or the engineering team lead), request that the owner confirm which accounts are still appropriate and flag any that should be revoked, process revocations promptly (within 5 business days of the review date), and document the review: who reviewed, what was reviewed, any changes made, and the completion date.
Access review evidence includes: the pre-review user list with export date, the reviewer's sign-off (email, ticket comment, or digital signature), the post-review user list showing revocations, and a log of the revocation actions taken. This four-part evidence package is what auditors look for in CC6.1 access review testing. Any system where the access review was not completed during the observation period is an exception.
Offboarding and Access Revocation
Offboarding is the highest-risk moment in the access lifecycle: a departing employee's access must be revoked before or immediately upon their last day of employment to prevent unauthorized access after departure. CC6.1 testing frequently focuses on offboarding — auditors will sample terminated employees during the observation period and verify the timestamp of their access revocation against the termination date.
The offboarding process must cover all access vectors: SSO/IdP account (deactivating the Okta or Azure AD account revokes SSO-federated app access), direct application accounts not federated through SSO (must be revoked individually — this is a common gap), cloud platform accounts (AWS IAM users or roles assigned to the individual), SSH keys, API keys, and physical access (building badges, key fobs). A checklist-based offboarding procedure ensures no access vector is missed.
Best practice: offboarding access revocation should occur on the last day of employment, not when IT gets around to it. Automate as much as possible — deactivating the Okta account should trigger automated deprovisioning of downstream applications through SCIM provisioning. For applications not supported by SCIM, create a manual checklist integrated into your HR offboarding workflow. Document revocation timestamps for each access vector to demonstrate timely action.
Third-Party Access
CC6.8 addresses access by third parties — contractors, vendors, and partners who are granted access to your in-scope systems. Third-party access must be governed by formal access agreements defining the scope of access, the purpose, the access duration, and the termination conditions. These agreements are typically incorporated into your vendor contracts or supplemental access agreements.
Third-party accounts must follow the same access controls as employee accounts: individual (non-shared) accounts, MFA enforcement, least-privilege scoping, and inclusion in periodic access reviews. A contractor who finished their engagement six months ago but whose GitHub access was never revoked is a CC6.8 exception. Include contractors in your offboarding process — contractor offboarding should be triggered by contract end date or notice of engagement termination.
For vendors who access your systems for support or integration purposes (cloud infrastructure vendors, your managed security provider, your compliance tooling vendor), document the access scope and review it as part of your vendor management process (CC9.2). Access that is no longer needed for the vendor's service delivery should be revoked even if the vendor relationship continues.
Evidence Auditors Collect
For CC6, auditors typically collect: (1) MFA enforcement configuration screenshots for each in-scope system; (2) RBAC role definitions and the user-to-role assignment list for production environments; (3) access provisioning records for a sample of new hires or role changes during the observation period; (4) access review records for all in-scope systems (reviewer sign-off, pre/post access lists, revocation logs); (5) offboarding records for all terminated employees in the observation period (revocation timestamps vs. termination dates); and (6) third-party access agreements and access scope documentation.
Access reviews and offboarding procedures generate the most exceptions in first-time SOC 2 audits. Companies frequently have MFA enforced and IAM well-structured but have not formalized the quarterly review process or have gaps in their offboarding checklist. These are also among the easiest controls to implement and document, making them high-value items to address in pre-audit readiness work.
Compliance automation platforms that integrate with Okta, AWS, GitHub, and your HRIS can automatically pull access lists, match them against the employee roster, flag stale access, and generate access review records. Automating this workflow reduces the manual overhead of CC6 compliance from several days per quarter to a few hours.
Frequently Asked Questions
Does CC6 require a privileged access management (PAM) tool?
How often do access reviews need to happen under CC6?
Do personal GitHub repositories count for CC6 scope?
We use AWS Organizations — does that change our CC6 approach?
What counts as "physical access" under CC6.4 for a fully remote company?
Automate your compliance today
AuditPath runs 86+ automated checks across AWS, GitHub, Okta, and 14 more integrations. SOC 2 and DPDP Act. Free plan available.
Start for free