SOC 2 Compliance on AWS: A Practical Implementation Guide

SOC 2 is a compliance framework that evaluates how service providers handle customer data across five Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Most SaaS companies pursuing SOC 2 target the Security and Availability criteria — the foundational ones that almost every customer audit requires. Adding Confidentiality and Privacy is common for companies handling sensitive personal or financial data.

AWS infrastructure makes many SOC 2 controls straightforward to implement, but it doesn't implement them automatically. You're responsible for configuring services correctly, maintaining those configurations, and generating evidence that your controls operated continuously during the audit period. Auditors don't accept "we know it was configured correctly" — they want screenshots, log exports, and automated compliance reports with timestamps.

The Shared Responsibility Model for Compliance

AWS is SOC 2 compliant for its own infrastructure — data centers, hardware, hypervisors, managed service infrastructure. AWS publishes a SOC 2 Type II report that covers these components. Your SOC 2 report covers the layer you're responsible for: how you configure and use AWS services, your application code, and your operational processes.

This division means that when an auditor asks about physical security of your servers, you point to AWS's SOC 2 report. When they ask about IAM controls, encryption at rest, and access logging, that's your report. Understanding this boundary prevents both over-engineering (building controls AWS already provides) and gaps (assuming AWS covers things it doesn't).

Security Criterion: Access Controls

The Security criterion (CC1-CC9) covers logical access controls, authentication, and authorization. AWS controls that directly address these requirements:

IAM policies and least privilege: Implement and document IAM policies for all users and roles. Auditors want to see that access is limited to what's needed, that policies are reviewed regularly, and that privilege escalation paths are controlled. Use AWS IAM Access Analyzer to generate findings about policies with overly broad permissions. See IAM security best practices for detailed implementation guidance.

Multi-factor authentication: Require MFA for all IAM users with AWS console access, especially for the root account. Use an SCP to enforce MFA requirements at the organization level. Document the MFA enforcement policy and maintain evidence that it applies to all users.

CloudTrail logging: Enable CloudTrail with multi-region logging, log file integrity validation, and a protected S3 bucket that no single user can delete logs from. Auditors verify that CloudTrail logs cover the entire audit period without gaps — log file integrity validation is the evidence that logs haven't been tampered with. See CloudTrail best practices for setup details.

Change management: For production infrastructure changes, implement a change management process with documented approval. Infrastructure-as-code (Terraform, CloudFormation) with peer review through GitHub pull requests is the standard modern approach — it creates an automatic audit trail of who approved each change.

Security Criterion: Monitoring and Incident Response

CC7 covers how you detect and respond to threats. The required controls include:

Security monitoring: AWS GuardDuty provides automated threat detection. Enable it in all regions and configure alerting for high-severity findings. Configure GuardDuty correctly and maintain evidence that it was enabled continuously during the audit period.

Vulnerability management: AWS Inspector scans EC2 instances and container images for known vulnerabilities. Enable Inspector and document your process for remediating critical findings within defined SLAs. Auditors will check whether you have a documented remediation timeline and whether you met it for findings that occurred during the audit period.

Incident response plan: Document an incident response plan that covers detection, containment, eradication, and recovery. It doesn't need to be lengthy, but it needs to exist and employees need to have seen it. Some auditors conduct tabletop exercises; be prepared to demonstrate that key personnel know the plan.

Availability Criterion: Uptime and Redundancy

The Availability criterion (A1) requires controls that ensure system availability as committed. Key AWS configurations:

Multi-AZ deployments: Production workloads should run across multiple Availability Zones. Single-AZ configurations fail the availability criterion — AWS AZs experience isolated outages, and without multi-AZ redundancy, a single AZ outage takes down the entire service. Enable multi-AZ for RDS databases, use Auto Scaling groups spanning multiple AZs for compute, and design for AZ failure in your application architecture.

Backup and recovery: Enable automated backups for RDS, DynamoDB point-in-time recovery, and regular snapshots for EBS volumes. Document your Recovery Time Objective (RTO) and Recovery Point Objective (RPO) and test recovery procedures annually. Auditors ask for evidence of backup testing — run a restore drill each year and document the results.

Uptime monitoring: Use CloudWatch alarms and external uptime monitoring to track availability. Maintain a record of incidents, root causes, and resolution times during the audit period. A simple incident log in a shared document with date, description, duration, and root cause is sufficient for most SOC 2 audits.

Confidentiality Criterion: Encryption and Data Protection

The Confidentiality criterion requires protecting sensitive information throughout its lifecycle:

Encryption at rest: Enable encryption for all S3 buckets containing sensitive data, RDS databases, EBS volumes, and DynamoDB tables. Use AWS KMS for key management and maintain a KMS key rotation policy (annual rotation at minimum). S3 encryption configuration covers the details for that service.

Encryption in transit: Enforce TLS for all external API and web traffic. Use Security Groups and NACLs to prevent unencrypted traffic on ports like port 80 (HTTP) for services that should only accept HTTPS. ALB listeners should redirect HTTP to HTTPS or accept only HTTPS.

Data retention and deletion: Document how long you retain customer data and implement automated deletion at the retention boundary. S3 lifecycle policies, DynamoDB TTL, and RDS automated backup retention limits are the technical implementation — the compliance requirement is that you can describe the policy and show it's enforced.

Evidence Collection with AWS Config

Auditors need evidence that controls were operating continuously, not just that they're configured today. AWS Config records configuration history for all AWS resources, providing point-in-time snapshots that demonstrate how resources were configured throughout the audit period. Set up AWS Config before your audit period begins and ensure it's enabled in all regions where you have resources.

AWS Config's compliance history feature shows when resources were compliant or non-compliant with each rule over time. For SOC 2 audits, export this history as evidence. AWS Security Hub aggregates Config findings, GuardDuty findings, and findings from other services into a single compliance dashboard that's well-suited for audit evidence packages.

Related Reading

• AWS compliance risk score — using risk scoring to prioritize compliance improvements
• AWS Config conformance packs — pre-built rule sets for compliance frameworks
• CloudTrail best practices — audit logging for SOC 2 evidence
• IAM security best practices — access control implementation for SOC 2

FAQ

How long does SOC 2 audit preparation typically take?

For organizations starting from scratch, 6-12 months of preparation is typical before the first audit. The time is spent implementing missing controls (often the quickest part), establishing processes and documentation, and building evidence that controls have operated for a sufficient period. Most auditors want to see controls operating for at least 3-6 months before issuing a Type II opinion. Type I opinions (controls are designed correctly, without the operational evidence period) can be issued faster.

Do I need to use a specific auditing firm?

SOC 2 audits must be performed by a licensed CPA firm. There's no AWS-specific requirement for the firm. Common firms used by SaaS companies include Drata's partner network, Vanta's partner network, and independent CPA firms specializing in technology audits. The firm must be independent of your organization and hold appropriate CPA licenses.

Can I automate SOC 2 evidence collection?

Yes, and you should. Tools like Drata, Vanta, and Secureframe connect to your AWS account and automatically collect evidence from CloudTrail, AWS Config, GuardDuty, and other services. They map AWS configurations to SOC 2 criteria and generate evidence reports. This substantially reduces the manual work of preparing for an audit, especially for continuous monitoring during the audit period.