SOC 2 Controlssoc 2 cc6soc 2 logical access controlscc6.1 awssoc 2 access control

SOC 2 CC6 Logical Access Controls: AWS Implementation Guide

A technical implementation guide for SOC 2 CC6 (Logical Access) controls in AWS — covering CC6.1 through CC6.8 with specific AWS service configurations and evidence requirements.

SecureSpect Team··8 min

Understanding SOC 2 CC6 Logical Access Controls

The CC6 category — Logical and Physical Access Controls — is the largest and most technical section of the SOC 2 Security TSC. It covers everything from how users authenticate to how you protect system boundaries and manage cryptographic keys. If CC6 is a mess, your audit will fail.

Here's a practical implementation guide for each CC6 sub-criterion, mapped to specific AWS services and configurations.

CC6.1 — Logical Access Measures

What it requires: Logical access security measures are implemented to protect against threats from outside system boundaries. Includes credential management, MFA, and access provisioning/deprovisioning.

AWS implementation:

  • IAM MFA required for all IAM users (especially those with console access)
  • Root account MFA enabled, root access keys deleted
  • IAM access keys rotated within 90 days
  • Access keys for inactive users (>90 days no activity) disabled or deleted
  • Password policy: minimum 14 chars, complexity required, 90-day expiration
  • AWS Secrets Manager for application credentials (no hardcoded secrets)
  • IAM role-based access rather than long-lived user credentials for EC2/ECS/Lambda
Evidence SecureSpect collects:
aws.iam.mfa_privileged_users

aws.iam.access_key_rotation

aws.iam.root_mfa

aws.iam.inactive_users

aws.secretsmanager.rotation_enabled

CC6.2 — User Access Registration and Authorization

What it requires: Prior to issuing system credentials, users are registered and authorized. Access provisioning follows a formal process.

AWS implementation:

  • IAM users created only with documented business justification
  • IAM permission boundaries or SCPs limiting what new users can self-grant
  • Tagging convention for all IAM users and roles (owner, department, purpose)
  • Access reviews conducted quarterly — document who has access to what and why
Evidence: Quarterly access review documentation, IAM user creation logs from CloudTrail.

CC6.3 — User Access Removal

What it requires: Access is removed when it's no longer needed (employee departure, role change, contract end).

AWS implementation:

  • Offboarding checklist that includes IAM deactivation within 24 hours of departure
  • IAM user deactivation (not deletion — preserve CloudTrail audit trail)
  • Quarterly inactive user review — users with no activity in 90 days
  • SSO deprovisioning if using AWS IAM Identity Center
Evidence: CloudTrail records of access key deactivation and user deactivation, timestamped against departure dates.

CC6.4 — User Access Reviews

What it requires: Access is reviewed periodically and removed when no longer needed.

AWS implementation:

  • Quarterly: review all IAM users and their attached policies
  • Semi-annual: review all IAM roles and their trust policies (who can assume them)
  • Annual: review SCPs and permission boundaries
  • Tool: AWS IAM Access Analyzer generates findings for unused access
Evidence: Quarterly access review records documenting who reviewed, what was reviewed, and actions taken.

CC6.6 — Logical Access Controls — Boundary Protection

What it requires: Logical access controls protect against unauthorized access from outside system boundaries.

AWS implementation:

  • EC2 security groups: no unrestricted inbound (0.0.0.0/0) on sensitive ports (22, 3389, 5432, 3306)
  • WAF Web ACL applied to all public-facing services
  • VPC with private subnets for application and database tiers
  • EKS API server endpoint not publicly unrestricted
  • VPC flow logs enabled for network visibility
Evidence SecureSpect collects:
aws.ec2.security_groups_unrestricted

aws.waf.web_acl_exists

aws.vpc.flow_logs_enabled

aws.eks.endpoint_access

CC6.7 — Encryption in Transit and at Rest

What it requires: Confidential information is encrypted during transmission and at rest.

AWS implementation:

At rest:

  • S3: server-side encryption enabled (SSE-S3 or SSE-KMS)
  • S3: SSL-only bucket policy (deny HTTP, require HTTPS)
  • RDS: storage encryption enabled at creation (cannot be added retroactively)
  • KMS CMK rotation enabled for all customer-managed keys
In transit:
  • ACM certificates with TLS 1.2 minimum on all ALBs
  • HTTPS-only endpoints (HTTP → HTTPS redirect)
  • RDS SSL/TLS connections enforced via parameter groups
Evidence SecureSpect collects:
aws.s3.encryption_at_rest

aws.s3.ssl_only_policy

aws.rds.encryption_at_rest

aws.kms.key_rotation

CC6.8 — Malicious Code Prevention

What it requires: Detection and prevention of unauthorized or malicious software.

AWS implementation:

  • Amazon Inspector v2 enabled for EC2 and ECR vulnerability scanning
  • ECR image scanning on push enabled
  • ECR tag immutability enabled (prevents overwriting image tags)
  • Dependabot alerts enabled on GitHub repositories
  • GuardDuty for runtime threat detection
Evidence SecureSpect collects:
aws.inspector.enabled

aws.ecr.scan_on_push

aws.ecr.tag_immutability

aws.guardduty.enabled

The CC6 Evidence Checklist

For each CC6 sub-criterion, you need two types of evidence:

  • Design evidence: Showing the control exists and is configured (screenshots, CLI output, policy documents)
  • Operating effectiveness evidence: Showing the control ran consistently throughout the audit period (CloudTrail logs, periodic access review records, rotation logs)
  • Automated tools like SecureSpect handle the operating effectiveness evidence by generating timestamped check results throughout the audit period. This is why starting continuous monitoring 6+ months before your audit period ends matters so much.

    FAQ

    Which CC6 controls are most commonly failed? CC6.1 (especially access key rotation and inactive users), CC6.6 (security groups with unrestricted access), and CC6.7 (RDS without encryption — this is hard to remediate retroactively).

    Can I get an exception for a failing CC6 control? Auditors can note compensating controls. But material exceptions on CC6 are a red flag for customers. Fix the controls.

    Does SOC 2 require multi-factor authentication for all users? CC6.1 requires MFA for users with "privileged" access. In practice, auditors expect MFA for all IAM users with console access. Root account MFA is non-negotiable.

    Automate your SOC 2 evidence collection

    Connect your AWS and GitHub environments and start collecting audit-ready evidence today. Free to start.

    Start Free →More Articles