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.
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
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
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
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
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
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
- ACM certificates with TLS 1.2 minimum on all ALBs
- HTTPS-only endpoints (HTTP → HTTPS redirect)
- RDS SSL/TLS connections enforced via parameter groups
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
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:
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.