Skip to content

SOC 2

Best for: Any technology or cloud service provider that handles customer data and needs to prove its security posture to enterprise buyers. SaaS companies, managed service providers, data centers, and IT outsourcing firms run into SOC 2 requirements during sales cycles. There is no revenue or size threshold; even a five-person startup selling to a Fortune 500 will be asked for a SOC 2 Type II report.

Mandatory?Voluntary — required by enterprise procurement
Who validates?Licensed CPA firm (SSAE 18) · No self-assessment
RenewalTypically annual
Observation periodType II: 3–12 months

🏛 American Institute of Certified Public Accountants (AICPA) · 2017 TSC (2022 revised) Official source →

Get Started

module "..." {
  source  = "soc2.compliance.tf/terraform-aws-modules/<module>/aws"
  version = "<version>"
}

What Compliance.tf Covers vs. What You Handle

  • What Compliance.tf automates

    • Encryption at Rest: Covers encryption configuration across API Gateway caches, Backup recovery points, and CloudFront distributions. Any service where encryption is available but not enabled will surface as a finding.
    • Encryption in Transit: Checks CloudFront distribution TLS enforcement and field-level encryption settings, including whether HTTPS is required and HTTP-to-HTTPS redirect policies are in place.
    • Audit Logging: Covers 11 controls across CloudTrail (multi-region trail, S3 data events for both read and write), API Gateway stage logging, AppSync field-level logging, Athena workgroup logging, Bedrock invocation logging, and CloudFront access logging.
    • Backup and Recovery: Confirms backup plans exist in configured regions, enforces minimum 35-day retention, validates deletion protection on recovery points, and checks that individual recovery points meet retention requirements.
    • Certificate Management: Flags ACM certificates expiring within 30 days so teams can renew before expiration triggers an availability or security event.

  • What you handle

    • Encryption at Rest: Your encryption policy document, KMS key rotation schedules, and ensuring your encryption standards are reflected accurately in the SOC 2 system description.
    • Encryption in Transit: TLS version floor decisions (e.g., requiring TLS 1.2 minimum), custom SSL certificate management, and documenting encryption-in-transit requirements in vendor agreements.
    • Audit Logging: Log review cadence, SIEM integration, alert tuning, and demonstrating to the auditor that logs are reviewed on a defined schedule. Evidence of actual review is what assessors ask for.
    • Backup and Recovery: RPO and RTO definitions, annual restoration testing, documented recovery procedures, and mapping backup coverage to the commitments stated in your system description.
    • Certificate Management: A certificate lifecycle management process, ownership assignment for renewals, and tracking any certificates issued outside ACM.

Controls by Category

Data Retention and Backup (A1.2, A1.3) (1 control)

Evidence here centers on backup plan configuration and regional coverage. Assessors want to see plans covering all in-scope systems with retention periods that match the organization's stated commitments, deletion protections on recovery points, and backup jobs running in every region where workloads operate. The typical gap: backups are configured in the primary region but absent from disaster recovery regions.

Backup plan min frequency and min retention check

Encryption and Data Protection (CC6.1, CC6.7, C1.1) (3 controls)

The most common finding in this category is selective encryption: some services are protected while adjacent components like API Gateway caches are left in plaintext. Assessors check TLS enforcement across all in-scope endpoints, key management practices, and whether default encryption settings are actually applied to caches and storage throughout the environment.

API Gateway stage cache encryption at rest should be enabled CloudFront distributions should require encryption in transit compliance.tf module CloudFront distributions should have field level encryption enabled compliance.tf module

Logging and Monitoring (CC7.1, CC7.2, CC7.3) (4 controls)

This category draws the most scrutiny. Auditors verify that logging is enabled across all in-scope services, that logs are retained for the full review period, and that someone actually reviews them. They check CloudTrail coverage across all regions (not just the primary region), S3 data event logging for both reads and writes, and evidence of log integrity controls. Gaps for newer services like Bedrock are a frequent deficiency, particularly when teams added those services mid-period.

API Gateway stage logging should be enabled AppSync graphql API logging should be enabled compliance.tf module Athena workgroups should have logging enabled CloudFront distributions access logs should be enabled compliance.tf module
Additional Controls (103)

AWS CloudTrail (4)

At least one enabled trail should be present in a region CloudTrail trails should be integrated with CloudWatch logs CloudTrail trail logs should be encrypted with KMS CMK CloudTrail trail log file validation should be enabled

AWS CodeBuild (1)

CodeBuild projects should have logging enabled

AWS Database Migration Service (2)

DMS endpoints for Redis OSS should have TLS enabled DMS replication instances should not be publicly accessible compliance.tf module

AWS IAM (1)

IAM password policies for users should have strong configurations

AWS KMS (1)

KMS CMK rotation should be enabled compliance.tf module

AWS Lambda (3)

Lambda functions concurrent execution limit configured compliance.tf module Lambda functions should be configured with a dead-letter queue compliance.tf module Lambda functions should be in a VPC compliance.tf module

AWS Step Functions (1)

Step Function state machines should have logging turned on compliance.tf module

AWS WAF (1)

AWS WAF rules should have CloudWatch metrics enabled

Amazon CloudWatch (3)

CloudWatch alarm should have an action configured compliance.tf module CloudWatch alarm action should be enabled compliance.tf module Log group retention period should be at least 365 days compliance.tf module

Amazon CloudWatch Logs (1)

Log group encryption at rest should be enabled compliance.tf module

Amazon DynamoDB (3)

DynamoDB table should be encrypted with AWS KMS compliance.tf module DynamoDB table should have encryption enabled compliance.tf module DynamoDB table point-in-time recovery should be enabled compliance.tf module

Amazon DynamoDB Accelerator (1)

DynamoDB Accelerator clusters should be encrypted in transit

Amazon EBS (3)

Attached EBS volumes should have encryption enabled compliance.tf module EBS snapshots should be encrypted EBS volume encryption at rest should be enabled compliance.tf module

Amazon EC2 (8)

EC2 Client VPN endpoints should have client connection logging enabled EC2 instance detailed monitoring should be enabled compliance.tf module EC2 instance should have EBS optimization enabled compliance.tf module EC2 instances should be in a VPC compliance.tf module EC2 instances should not have a public IP address compliance.tf module EC2 instances should use IMDSv2 compliance.tf module AWS EC2 launch templates should not assign public IPs to network interfaces compliance.tf module EC2 transit gateways should have auto accept shared attachments disabled

Amazon ECR (1)

ECR repositories should have image scan on push enabled compliance.tf module

Amazon EFS (1)

EFS file system encryption at rest should be enabled compliance.tf module

Amazon EMR (1)

EMR cluster Kerberos should be enabled compliance.tf module

Amazon ElastiCache (2)

ElastiCache Redis cluster automatic backup should be enabled with retention period of 15 days or greater compliance.tf module ElastiCache for Redis replication groups should be encrypted in transit compliance.tf module

Amazon Kinesis (3)

Kinesis streams should be encrypted with CMK Kinesis streams should have an adequate data retention period Kinesis streams should have server side encryption enabled

Amazon MQ (1)

Active MQ brokers should stream audit logs to CloudWatch

Amazon MSK (1)

MSK clusters should be encrypted in transit among broker nodes compliance.tf module

Amazon Neptune (1)

Neptune DB clusters should be configured to copy tags to snapshots

Amazon OpenSearch Service (2)

OpenSearch domains should have audit logging enabled. compliance.tf module OpenSearch domains logs to AWS CloudWatch Logs compliance.tf module

Amazon RDS (17)

Aurora PostgreSQL DB clusters should publish logs to CloudWatch Logs compliance.tf module RDS clusters should have deletion protection enabled compliance.tf module RDS DB clusters should be encrypted with CMK compliance.tf module RDS DB clusters should be encrypted at rest compliance.tf module RDS DB instance backup should be enabled compliance.tf module RDS DB instances backup retention period should be greater than or equal to 7 compliance.tf module RDS DB instances should be integrated with CloudWatch logs compliance.tf module RDS DB instances should be configured to copy tags to snapshots compliance.tf module RDS DB instances should have deletion protection enabled compliance.tf module RDS DB instance encryption at rest should be enabled compliance.tf module RDS DB instances should have iam authentication enabled compliance.tf module Database logging should be enabled compliance.tf module RDS for MariaDB DB instances should publish logs to CloudWatch Logs compliance.tf module RDS DB instances should not use public subnet compliance.tf module RDS for PostgreSQL DB instances should publish logs to CloudWatch Logs compliance.tf module RDS DB instances should prohibit public access compliance.tf module RDS for SQL Server DB instances should publish logs to CloudWatch Logs compliance.tf module

Amazon Redshift (6)

AWS Redshift audit logging should be enabled compliance.tf module AWS Redshift clusters should have automatic snapshots enabled compliance.tf module Redshift cluster encryption in transit should be enabled compliance.tf module Redshift cluster audit logging and encryption should be enabled compliance.tf module AWS Redshift should have required maintenance settings compliance.tf module Redshift clusters should prohibit public access compliance.tf module

Amazon S3 (15)

S3 bucket cross-region replication should be enabled compliance.tf module S3 bucket default encryption should be enabled compliance.tf module S3 bucket default encryption should be enabled with KMS compliance.tf module S3 buckets should have event notifications enabled compliance.tf module S3 buckets should have lifecycle policies configured compliance.tf module S3 bucket logging should be enabled compliance.tf module S3 bucket ACLs should not be accessible to all authenticated user compliance.tf module S3 bucket object lock should be enabled compliance.tf module S3 buckets object logging should be enabled S3 bucket policy should prohibit public access compliance.tf module S3 buckets should prohibit public read access compliance.tf module S3 buckets should prohibit public write access compliance.tf module S3 buckets with versioning enabled should have lifecycle policies configured compliance.tf module S3 bucket versioning should be enabled compliance.tf module S3 public access should be blocked at account level compliance.tf module

Amazon SNS (1)

SNS topics should be encrypted at rest compliance.tf module

Amazon SageMaker (3)

SageMaker endpoint configuration encryption should be enabled SageMaker notebook instances should not have direct internet access SageMaker notebook instance encryption should be enabled

Amazon VPC (2)

VPC security groups should restrict ingress from 0.0.0.0/0 or ::/0 to cassandra ports 7199 or 9160 or 8888 compliance.tf module VPC subnet auto assign public IP should be disabled compliance.tf module

Elastic Load Balancing (3)

ELB application and classic load balancer logging should be enabled compliance.tf module ELB application load balancers should be configured to drop HTTP headers compliance.tf module Application Load Balancer should be configured to drop invalid http headers compliance.tf module

Other (10)

DataSync tasks should have logging enabled Elasticsearch domains should have audit logging enabled ES domain encryption at rest should be enabled ES domains should be in a VPC Elasticsearch domain should send logs to CloudWatch Elasticsearch domain node-to-node encryption should be enabled Access logging should be configured for API Gateway V2 Stages compliance.tf module Glue jobs CloudWatch logs encryption should be enabled Glue jobs S3 encryption should be enabled MSK Connect connectors should be encrypted in transit

  • NIST 800-53 Rev 5 — 🟢 High overlap (65%)

    The SOC 2 Trust Services Criteria map extensively to NIST 800-53 control families. AICPA published an official mapping between TSC points of focus and NIST 800-53 controls. Organizations with an existing NIST 800-53 program will find significant reuse, particularly in the AU (Audit and Accountability), SC (System and Communications Protection), and CP (Contingency Planning) families.

  • ISO 27001 — 🟢 High overlap (60%)

    Both frameworks address information security management but differ in structure. ISO 27001 requires a formal ISMS with Annex A controls, while SOC 2 evaluates controls against Trust Services Criteria. Many organizations pursue both, using ISO 27001 for international markets and SOC 2 for North American enterprise buyers.

  • HIPAA — 🟡 Medium overlap (35%)

    SOC 2 reports can include HIPAA-relevant criteria, and the AICPA offers a SOC 2 + HIPAA combined report option. The overlap is strongest in the Security and Confidentiality categories. HIPAA adds requirements around PHI-specific safeguards and breach notification that SOC 2 does not cover on its own.

Frequently Asked Questions

Does SOC 2 apply to my company?

SOC 2 is voluntary. No law requires it. Enterprise customers and their procurement teams, however, often make a SOC 2 Type II report a contract prerequisite for B2B software or services that touch their data. The trigger is customer demand, not regulation.

What is the difference between Type I and Type II?

Type I evaluates whether your controls are properly designed at a single point in time. Type II evaluates both design and operating effectiveness over a period, usually 6 to 12 months. Most enterprise buyers require Type II because it proves controls actually worked, not just that they existed on paper. A Type I can serve as a stepping stone for first-time audits.

How long does it take to get SOC 2 certified?

SOC 2 produces an attestation report, not a certification (a distinction auditors will correct you on). If you have no existing controls, plan for 3 to 6 months to implement them, then 3 to 12 months of operating them for the Type II observation window, then 4 to 8 weeks for the audit itself. Organizations with mature security programs move faster. A Type I can typically be obtained within 2 to 4 months from the start of readiness work.

Which Trust Services Categories should I include?

Security (Common Criteria) is mandatory. The other four (Availability, Processing Integrity, Confidentiality, Privacy) are optional and should reflect your actual customer commitments. SaaS providers typically include Security and Availability at minimum. Add Confidentiality if you handle sensitive data. Privacy is worth including only if you process personal information and want to address it within the SOC 2 scope rather than a separate privacy framework.

How much does a SOC 2 audit cost?

CPA firm fees run from $20,000 to $100,000+ depending on scope, number of Trust Services Categories, company size, and environment complexity. First-year audits cost more because of the readiness assessment phase. Factor in internal costs too: staff time for evidence collection, tooling for continuous monitoring, and remediation work on any gaps found during readiness.