CC6: Logical and Physical Access Controls for SOC 2

What Is CC6?

CC6 is the Logical and Physical Access Controls criterion of SOC 2. It is the most expansive of the common criteria, containing eight sub-criteria (CC6.1 through CC6.8). It governs who can access your systems, how they authenticate, how access is reviewed, how data is encrypted, and how physical facilities are secured.

For most SaaS companies, CC6 generates the highest volume of audit evidence requests. Auditors will pull access provisioning records, MFA configuration screenshots, access review reports, encryption settings, and physical access logs. Getting CC6 right requires both technical configuration and documented process.

CC6.1: Access Provisioning and Least Privilege

CC6.1 requires that access to systems is provisioned based on an approved request, uses the principle of least privilege, and is revoked when no longer needed. The three key processes are: joiner (access granted on hire), mover (access updated on role change), and leaver (access revoked on termination).

For AWS, least privilege means IAM roles and policies grant only the permissions needed for the specific job function — not AdministratorAccess for everyone. Use IAM Access Analyzer to identify overly permissive policies and remediate before your audit.

Evidence auditors request for CC6.1: sample of access provisioning tickets (Jira/ServiceNow) with approvals, IAM policy configurations for key roles, and records of access revocation within 24-48 hours of employee terminations during the audit period.

CC6.2: Authentication Controls

CC6.2 requires authentication controls prior to allowing access to systems. For production and privileged access, this means MFA. Auditors will check that MFA is enforced — not just available — for AWS Console access, VPN, SSO, and any other system that accesses production data.

In AWS, enforce MFA by attaching an IAM policy that denies all actions except MFA enrollment if the user hasn't authenticated with MFA (the "deny without MFA" policy pattern). For SSO via Okta or Google Workspace, enable MFA enforcement at the IdP level with no bypass options.

Password policies (minimum length, complexity, rotation) are also part of CC6.2. AWS IAM password policy should be configured to require 14+ character passwords, prohibit reuse of the last 24 passwords, and require rotation annually at minimum.

CC6.3: Periodic Access Reviews

CC6.3 requires periodic reviews of user access to verify that access remains appropriate. Quarterly access reviews are the de facto standard — most auditors expect to see at least four access reviews during a 12-month Type II period.

An access review involves pulling a list of users and their permissions, having the relevant manager or system owner review each entry, confirming access is still appropriate, and revoking access where the answer is "no." The review results must be documented — a spreadsheet with approver signatures and dates, or a GRC tool record.

Automated tools like AuditPath, Vanta, or Okta Workflows can generate access review reports and route them to the appropriate approvers. The output is a signed-off access certification, which serves as the CC6.3 evidence.

CC6.6: Encryption at Rest and in Transit

CC6.6 requires that sensitive data is encrypted both at rest and in transit. For AWS: S3 buckets should use SSE-S3 or SSE-KMS encryption, RDS instances should have encryption enabled at instance creation, EBS volumes should be encrypted, and all API endpoints should use TLS 1.2 or higher.

In transit: enforce HTTPS-only access to your application using an Application Load Balancer with an SSL/TLS certificate from AWS Certificate Manager, and set the security policy to TLSv1.2_2021 or higher. Disable HTTP access entirely — redirect all port 80 traffic to 443.

Evidence: AWS Config rule "s3-bucket-server-side-encryption-enabled", RDS encryption status screenshot, ACM certificate configuration, and ALB listener configuration showing TLS policy.

CC6.7: Transmission Controls

CC6.7 requires controls over the transmission of confidential information to protect against unauthorized access. This includes encrypted transmission (TLS), secure API authentication (OAuth 2.0, API keys with appropriate scopes), and controls over email transmission of sensitive data.

For API security: use AWS API Gateway with Cognito or IAM authorization, ensure API keys are rotated periodically, and log all API calls via CloudTrail. For email: document your policy on transmitting sensitive data via email — most companies prohibit sending PII in email body and require secure file transfer for sensitive attachments.

CC6.8: Malware Protection

CC6.8 requires controls to prevent or detect unauthorized or malicious software. For cloud infrastructure: AWS GuardDuty provides malware detection for EC2 and ECS workloads. For developer endpoints: endpoint detection and response (EDR) tools like CrowdStrike Falcon, SentinelOne, or Jamf Protect satisfy CC6.8 for macOS.

Document your anti-malware policy: which endpoint types require EDR, what the response procedure is for a malware detection, and how you verify that all managed endpoints have the agent installed. Use your MDM tool (Jamf, Intune, Kandji) to generate a compliance report showing EDR coverage.

Physical Access Controls

CC6.4 and CC6.5 cover physical access to data center facilities and physical media. For SaaS companies on AWS, your physical security controls are inherited from AWS — and the AWS SOC 2 report covers the data center physical controls. Reference the AWS shared responsibility model in your system description.

For your own offices, you need controls on physical access to workstations and meeting rooms where confidential discussions occur. Badge access systems, clean desk policies, and visitor log procedures satisfy the physical access requirements for office environments.

CC6 Evidence Checklist

(1) Access provisioning records — sample tickets with approval for the audit period. (2) Termination records showing access revoked within SLA. (3) MFA enforcement config — AWS IAM policy, Okta MFA policy screenshot. (4) Quarterly access review records — four reviews for a 12-month audit. (5) S3, RDS, and EBS encryption configuration screenshots. (6) ALB/CloudFront TLS configuration. (7) AWS GuardDuty enabled screenshot. (8) MDM compliance report showing EDR on all endpoints. (9) AWS SOC 2 report reference for data center physical controls.