CC6 is the most extensively tested cluster in every SOC 2 audit. It covers logical access — who can authenticate to systems, what they are authorized to do, and how that access is managed over time — and physical access to facilities, data centers, and server rooms. Access control failures are the single most common source of exceptions in SOC 2 Type II reports, and the area where the most remediation effort is typically concentrated in readiness programs.
The reason CC6 receives this level of scrutiny is straightforward: unauthorized access is the root cause of most data breaches and security incidents. Auditors know this and concentrate their testing accordingly. CC6 has more sub-criteria than any other cluster — eight in total — and each generates its own evidence request and testing procedure in a Type II audit.
CC6.1 — Logical Access Security Software
CC6.1 covers the security software and configurations that form the perimeter of the organization’s logical access controls: firewalls, network segmentation, intrusion detection systems, endpoint protection, and the identity and access management (IAM) systems that govern authentication and authorization. Auditors will request evidence that these systems are in place, configured appropriately, and actively monitored.
| Technology Control | What Auditors Verify | Evidence Requested |
|---|---|---|
| Firewalls / network security groups | Rules are documented; only necessary ports and protocols are permitted; rule review process exists | Firewall rule exports; documentation of rule review; evidence of rule removal when no longer needed |
| Identity provider / SSO | All production systems require authentication through a central identity provider where MFA is enforced | IdP configuration screenshots; evidence of SSO coverage across in-scope systems; MFA enforcement settings |
| Endpoint protection | All in-scope endpoints (laptops, servers) have active endpoint protection deployed | EDR/antivirus deployment report; evidence of active monitoring and alert response |
| Network segmentation | Production environments are separated from development/test environments and corporate networks | Network diagram; VPC/VLAN configuration; evidence that production data cannot be accessed from dev environments |
CC6.2 — Authentication and Multi-Factor Authentication
MFA is the single control that receives the most attention in any SOC 2 audit. CC6.2 requires that prior to issuing system credentials and granting access, the organization implements controls to authenticate users. In practice, this means MFA must be enforced — not just offered — for all access to in-scope systems.
| IMPORTANT | MFA exceptions are one of the most common Type II findings. Common exception patterns: MFA enforced for standard user accounts but not for service accounts; MFA enforced at the SSO layer but not for direct console access to cloud infrastructure; MFA enforced for employees but not contractors or third-party vendors with system access. Auditors will probe all three. |
CC6.3 — Authorization
CC6.3 covers the authorization model: given that a user has authenticated, what are they authorized to do? This requires a documented access control model (role-based access control is the most common implementation), the principle of least privilege applied to role definitions, and segregation of duties for roles with conflicting responsibilities.
Evidence for CC6.3 includes the RBAC matrix (a table of roles and their permissions), evidence that roles are reviewed when systems change, and documentation of segregation of duties for sensitive functions — for example, ensuring that the same person cannot both approve a financial transaction and process it, or both request and approve their own system access.
CC6.4 — Access Provisioning and Deprovisioning
Access provisioning — the process by which new access is granted — and deprovisioning — the process by which access is revoked — are tested extensively in Type II audits. Auditors will sample provisioning events from the audit period and trace each from access request through approval through implementation. They will also sample termination events and verify that access was revoked within the defined timeframe.
| Process | Required Controls | Acceptable Evidence |
|---|---|---|
| New user provisioning | Formal access request with business justification; approval by manager or system owner; access granted following approval, not before | Ticketing system records showing access requests, approvals, and implementation; HR system integration showing provisioning triggered by hire date |
| Role changes / transfers | Access is reviewed and adjusted when an employee changes roles; prior role access is revoked, not just new access added | Offboarding/transfer checklist completion records; ticket trail showing role change triggered access review |
| Employee termination | Access revoked same day as termination or within defined SLA (typically 24 hours); all systems, not just Active Directory | HR termination notification records; access revocation confirmation across all in-scope systems; offboarding checklist |
| Contractor / vendor access | Third-party access follows same provisioning process; time-limited where possible; revoked when engagement ends | Contractor access records; contract end date vs. access revocation date comparison |
CC6.5 — Logical Access Reviews
Periodic access reviews — typically quarterly for privileged access and production systems, semi-annually for standard access — require that system owners review who has access to their systems and confirm that access is still appropriate. This is one of the controls that most commonly fails in Type II audits: it is performed, but not documented in a format auditors can test.
| KEY IDEA | A completed access review that is not documented is, from an audit perspective, the same as an access review that never happened. The minimum acceptable documentation: a list of users with access, the date of review, the name of the reviewer, confirmation that each access is appropriate (or notation of access revoked), and a signature or system-captured timestamp showing the review was completed. |
CC6.7 — Physical Access Controls
Physical access to facilities, data centers, and server rooms is covered under CC6.7. For organizations that host their own infrastructure, this includes badge access systems, visitor logs, physical security monitoring (CCTV), and data center environmental controls. For cloud-native organizations, physical security obligations flow to the cloud provider — and the SOC 2 report from your IaaS provider (AWS, Azure, GCP) typically satisfies the physical access requirement, provided you have obtained and reviewed that report.
| BITLION INSIGHT | Cloud-native organizations should obtain and review the SOC 2 reports of their key infrastructure providers annually as part of CC6.7 compliance. This review should be documented — a note recording that you reviewed the AWS SOC 2 Type II report for the relevant period, verified the scope includes the services you use, and found no material exceptions — satisfies the physical access monitoring requirement for cloud-hosted infrastructure. |