How to Meet SOC 2 CC6 Access Controls
To meet SOC 2 CC6 access control requirements, you enforce least privilege and MFA on every system, provision and deprovision access through a documented and approved workflow, run access reviews on a fixed schedule, encrypt data in transit, control physical access to any hardware you own, and keep evidence that each of these controls operated for the entire audit period.
Quick answer. To meet SOC 2 CC6 access control requirements, enforce MFA and least privilege on every system, approve and log every access grant, deprovision leavers within 24 hours, run access reviews on a fixed schedule, encrypt data in transit, and retain evidence across the full audit period. CC6 is the SOC 2 Logical and Physical Access Controls category, spanning eight sub-criteria, CC6.1 through CC6.8.
CC6 is the most-tested category in a SOC 2 audit. It covers who gets in, how they authenticate, what they can do, and what happens when they leave, so getting it right is the difference between a clean report and a long list of findings. This guide breaks down each sub-criteria, what auditors look for, and where teams fall short. For the wider picture, start with the SOC 2 Trust Service Criteria overview and the SOC 2 readiness checklist.
CC6.1: Logical Access Security
What it covers: The tools, infrastructure, and architecture you use to restrict access to systems and data. This is the foundational control: MFA, role-based access, and least privilege.
What auditors test:
- Is MFA enforced for all users, including admins?
- Is access granted based on defined roles rather than ad hoc?
- Are privileged accounts limited, named, and reviewed?
- Is there an access control policy that employees acknowledge?
Common gap
Common gaps: MFA available but not required. Admin accounts shared between team members. No documented role definitions. Engineers with standing production access that no one reviews.
Evidence to collect: MFA policy screenshot, SSO configuration showing enforcement, admin account roster, access control policy with acknowledgments.
CC6.2: Credential Issuance and Registration
What it covers: The process for granting new users access. Before issuing credentials, you must verify identity, get appropriate authorization, and document the request.
What auditors test:
- Is there an approval workflow before access is granted?
- Are new accounts tied to a real person with a documented business need?
- Is there a record of who approved each access grant?
Common gap
Common gaps: Access provisioned informally over Slack or email with no ticket or approval record. Generic or shared accounts created without tracking individual users.
Evidence to collect: Your access request process, whether a ticket system, an HRIS workflow, or a documented procedure. Sample access requests showing approval before provisioning. Identity providers like Okta make this evidence easy to export.
CC6.3: Access Removal and Modification
What it covers: Removing or modifying access when someone changes roles or leaves the organization.
This is the highest-risk sub-criteria in most audits. Auditors will pull a list of terminated employees and check whether their access was removed, and how quickly.
What auditors test:
- Is there a documented offboarding process?
- Are terminated employees deprovisioned on the same day or within 24 hours?
- When someone changes roles, is old access removed rather than just new access added?
Common gap
Common gaps: Employees offboarded in HR but still active in SSO. Role changes that stack permissions over time. No log of deprovisioning actions.
Evidence to collect: Your offboarding procedure. A sample of termination events showing deactivation timestamps in your SSO or directory. For role changes, evidence that old group memberships were removed.
CC6.4: Physical Access Controls
What it covers: Physical access to facilities and hardware where your systems live. For cloud-hosted SaaS, this partially transfers to your cloud provider's physical controls.
What auditors test:
- Do you run a data center or office with servers, and if so who can access it and how is that logged?
- If you are fully cloud-hosted, do you hold your cloud provider's SOC 2 or ISO 27001 report?
- Is employee access to offices with sensitive equipment logged?
Common gap
Common gaps: No physical access log for server rooms. Missing cloud provider compliance reports, which also surface as a vendor management gap.
Evidence to collect: If cloud-only, your cloud provider's SOC 2 report, which AWS, GCP, and Azure all publish. If you hold physical hardware, badge access logs and visitor logs.
CC6.5: Logical Access Removal at Termination
What it covers: A specific requirement to remove all logical access, not just SSO, when someone terminates. This extends CC6.3 to access that exists outside your primary directory.
What auditors test:
- Are there systems with local accounts that bypass SSO?
- Are API keys, service account credentials, or shared passwords rotated when someone with access leaves?
- Is there a checklist that ensures every access point is covered, not just the obvious ones?
Common gap
Common gaps: AWS IAM users that persist after an employee's SSO account is deactivated. Shared API keys that were never rotated after an offboarding. GitHub organization membership left in place. A secrets manager like 1Password helps make this rotation evidence auditable.
Evidence to collect: Offboarding checklist that explicitly covers non-SSO access. Evidence that the checklist was followed for sample terminations.
CC6.6: Logical Access Restrictions for External Users
What it covers: How you manage access for vendors, contractors, customers, and any external party who touches your systems.
What auditors test:
- Are external users limited to only what they need?
- Is external access time-bounded or regularly reviewed?
- Are external users prevented from reaching systems beyond their contracted scope?
Common gap
Common gaps: Contractors with access that outlasted their engagement. Vendors with broader access than necessary. No review process for external user accounts.
Evidence to collect: Policy covering external user access. Sample of external user accounts showing limited scope. Evidence of periodic review or time-bound access.
CC6.7: Transmission Integrity and Encryption
What it covers: Data transmitted over public networks must be encrypted, and the communication must be authenticated. This maps to TLS enforcement across your application.
What auditors test:
- Is TLS enforced on all public-facing endpoints, with no HTTP fallback?
- Are certificates current and from a trusted authority?
- Are internal service-to-service calls over private networks also encrypted where sensitive data is involved?
- Are email communications containing sensitive data encrypted?
Common gap
Common gaps: Older TLS versions such as TLS 1.0 or 1.1 still supported. HTTP not redirecting to HTTPS. Internal APIs transmitting data without encryption. Weak endpoints often surface during penetration testing.
Evidence to collect: TLS configuration evidence such as an SSL Labs scan output and certificate details. HTTP redirect enforcement. Security headers showing HSTS.
CC6.8: Prevention of Unauthorized Software
What it covers: Preventing unauthorized or malicious software from entering systems, through endpoint protection, software approval, and controls on what can be installed.
What auditors test:
- Is endpoint protection such as EDR or antivirus deployed on all company devices?
- Is there a process for approving software before it is installed?
- Are developers restricted from deploying directly to production without an approval process?
Common gap
Common gaps: Endpoint protection deployed but not enforced, so employees can disable it. No change management process for production deployments, which overlaps with CC8 change management. Personal devices reaching systems without MDM enrollment.
Evidence to collect: Endpoint protection policy and deployment evidence. MDM enrollment showing coverage. Change management process for production deployments.
CC6 at a Glance
| Sub-Criteria | Focus Area | Highest Risk |
|---|---|---|
| CC6.1 | MFA, RBAC, least privilege | MFA not enforced |
| CC6.2 | Access provisioning approval | Informal access grants |
| CC6.3 | Deprovisioning on role change or termination | Terminated users still active |
| CC6.4 | Physical access controls | Missing cloud provider reports |
| CC6.5 | Complete logical access removal | Non-SSO access missed |
| CC6.6 | External user access management | Stale contractor accounts |
| CC6.7 | Encryption in transit | HTTP accessible, old TLS |
| CC6.8 | Unauthorized software prevention | Endpoint protection gaps |
Common CC6 Audit Findings
These are the CC6 findings that recur most often in real SOC 2 engagements. Treat it as a pre-audit sweep: close each one before your auditor pulls samples.
The finding: A terminated employee kept an active SSO or IAM account past their last day. Auditors compare HR termination dates to directory deactivation timestamps, so any gap is visible.
The fix: Wire offboarding to a single trigger, deactivate within 24 hours, and keep the log that proves the timeline.
The finding: MFA is configured and most people use it, but the policy does not require it, so a few accounts stay exempt.
The fix: Enforce MFA at the identity provider for every user, including service and admin accounts, and screenshot the setting.
The finding: Access was granted correctly, but there is no record of who requested it, who approved it, or the business reason, which still fails CC6.2.
The fix: Route every grant through a ticket that captures requester, approver, and justification before provisioning.
The finding: Reviews were never run, or run once and never repeated. Auditors want a recurring cadence with evidence of findings and actions.
The fix: Run privileged access reviews at least quarterly and standard user reviews at least annually, and keep the sign-off.
The finding: SSO was cleaned up at offboarding, but local accounts, shared API keys, and repository access were not. CC6.5 exists to catch this.
The fix: Keep an offboarding checklist that names every access point outside SSO and rotate shared secrets when a holder leaves.
The finding: Engineers hold permanent production access that no one reviews, which breaks least privilege under CC6.1.
The fix: Move to just-in-time or reviewed production access, and document who can elevate and how it is logged.
Who Owns CC6 End to End
The hardest part of CC6 is not configuring the controls, it is proving they operated continuously across the audit period. A snapshot of your SSO settings is far weaker than evidence that MFA was always enforced and no leaver kept access past 24 hours, which is why CC6 fails on operation and evidence more than on design.
Implementing and evidencing these controls across your identity provider, cloud accounts, and endpoints is exactly what a fractional CISO does. If you would rather have someone own CC6 end to end, from the SOC 2 readiness plan through the frameworks you commit to and a cloud security review of where access lives, Xorabyte works as your fractional CISO without a full-time hire. Book a call and you will leave with a clear path, not a sales pitch. See pricing if you want the numbers first.