If you're building a SaaS product or handling customer data, SOC 2 compliance isn't optional—it's often a requirement to close enterprise deals. While SOC 2 is primarily about processes and policies, the technical controls you implement in AWS form the foundation of your compliance program.

This guide focuses on the practical AWS security controls that align with SOC 2 Trust Services Criteria, particularly around security, availability, and confidentiality.

Understanding SOC 2 in the AWS Context

SOC 2 Type II compliance requires demonstrating that your controls are not only designed properly but also operating effectively over time. For AWS infrastructure, this translates to:

  • Access controls: Who can access what, and how is it logged?
  • Data encryption: Data at rest and in transit
  • Logging and monitoring: Comprehensive audit trails
  • Change management: Controlled, documented infrastructure changes
  • Backup and recovery: Data durability and disaster recovery

1. Identity and Access Management (IAM)

IAM is the cornerstone of AWS security and a critical component of SOC 2 compliance. Your auditor will scrutinize how you manage access to AWS resources.

Essential IAM Controls

  • No root account usage: The root account should be locked down with MFA and only used for account-level changes
  • Least privilege access: Users and services should only have the permissions they need
  • MFA enforcement: Multi-factor authentication for all human users, especially those with admin access
  • Role-based access: Use IAM roles for services, not long-lived credentials
  • Regular access reviews: Quarterly reviews of who has access to what
# Example: IAM policy enforcing MFA
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllExceptListedIfNoMFA",
      "Effect": "Deny",
      "NotAction": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:GetUser",
        "iam:ListMFADevices",
        "iam:ListVirtualMFADevices"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

2. Data Encryption

SOC 2 requires appropriate encryption of sensitive data. In AWS, this means implementing encryption both at rest and in transit.

Encryption at Rest

  • S3: Enable default encryption with AWS KMS
  • RDS/Aurora: Enable encryption for all databases
  • EBS volumes: Encrypt all volumes, including root volumes
  • Secrets Manager: For storing sensitive configuration and credentials

Encryption in Transit

  • TLS everywhere: Use Application Load Balancer or CloudFront to terminate TLS
  • Certificate management: Use AWS Certificate Manager for certificate lifecycle
  • VPC endpoints: Keep AWS service traffic within AWS network

3. Logging and Monitoring

Comprehensive logging is essential for both security and compliance. Your auditor needs to see that you have visibility into what's happening in your environment.

Required Logging Setup

  • CloudTrail: Enable in all regions with log file validation
  • VPC Flow Logs: Monitor network traffic for anomalies
  • CloudWatch Logs: Centralized application and system logs
  • AWS Config: Track resource configuration changes
  • GuardDuty: Threat detection and continuous monitoring
Critical: All logs should be stored in a separate, restricted AWS account with restricted access and long retention periods (typically 1+ years for SOC 2).

4. Network Security

Proper network segmentation and controls are fundamental to a secure AWS environment:

  • VPC design: Public, private, and data subnets with proper routing
  • Security groups: Restrictive, documented security group rules
  • Network ACLs: Additional layer of network-level controls
  • No direct internet access: Use NAT gateways for outbound traffic from private subnets
  • Bastion hosts or SSM: Controlled, auditable access to instances

5. Backup and Disaster Recovery

SOC 2's availability criteria requires demonstrating that you can recover from incidents:

  • Automated backups: Enable automated backups for RDS, EBS snapshots
  • Cross-region replication: For critical S3 buckets
  • Disaster recovery plan: Documented and tested recovery procedures
  • RTO/RPO defined: Clear recovery time and point objectives

6. Infrastructure as Code and Change Management

SOC 2 auditors want to see controlled, documented changes to infrastructure:

  • Terraform or CloudFormation: All infrastructure defined as code
  • Version control: Infrastructure code in Git with pull request process
  • CI/CD pipelines: Automated, repeatable deployments
  • Approval workflows: Production changes require review and approval

Continuous Compliance

SOC 2 Type II is about demonstrating controls over time. Implement these practices from day one:

  • Monthly security reviews and access audits
  • Automated compliance checks with AWS Config Rules
  • Regular vulnerability scanning and patching
  • Incident response procedures and regular drills

Conclusion

Achieving SOC 2 compliance is not a one-time project—it's an ongoing commitment to security and operational excellence. The good news is that building these controls into your AWS infrastructure from the start is much easier than retrofitting them later.

At Core Infrastructure, we've helped multiple companies achieve and maintain SOC 2 compliance by implementing these controls as part of their AWS foundation. If you're preparing for SOC 2 or need to strengthen your security posture, we'd be happy to help.