SOC 2 Compliant Terraform Modules
Enforced Before `terraform apply`

Your SOC 2 audit needs encryption, logging, access controls, and versioning on every AWS resource. These modules enforce all of it before terraform apply.

If you sell software or cloud services to other businesses, your customers will ask for a SOC 2 report. Procurement teams at enterprise buyers treat it as a gate - no report, no signed contract.

111

Mapped Controls

78 enforced by modules

Clauses

AWS Modules

Start Free Trial View All Controls

No credit card or AWS account needed to start.

From the maintainer of terraform-aws-modules - 2B+ downloads.

IAM · VPC · RDS · CloudTrail · S3 · EC2|SOC 2 Type II report|Available on AWS Marketplace

Three Steps to SOC 2 Compliant Infrastructure

For terraform-aws-modules users, migration is a one-line change. Same workflow, same interface. Bringing your own modules? We can make those compliant too. Join the beta.

Change One Line

main.tf

module "s3" {
- source = "registry.terraform.io/..."
+ source = "soc2.compliance.tf/..."
 
  bucket = "awesome-docs"
}

Browse SOC 2 modules at soc2.compliance.tf →

Run Terraform Commands

terminal

$ terraform init
Initializing modules...
- module.s3 in soc2.compliance.tf/...
Terraform has been successfully initialized!
$ terraform apply
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Compliance Enforced

CC7.4 · Versioning Enabled

CC6.2 · Default Encryption

CC6.1 · Public Access Blocked

C1.1 · Object Lock Enabled

CC6.2 · SSL Requests Only

CC7.2 · Logging Enabled

CC7.3 · Event Notifications

C1.2 · Lifecycle Policy

Controls with module coverage are enforced automatically. Enforced controls ship as compliant defaults; mapped controls without module coverage stay visible for your team.

Controls Mapped for SOC 2

111 controls mapped, 78 enforced by modules, across 38 clauses and AWS services

Enforced: the module configures this by default. Detected: mapped for visibility and evidence, not set by the module.

Enforced (77)Detected (164)

EC2 Auto Scaling groups should have Capacity Rebalancing enabled
EC2 auto scaling groups should use multiple instance types in multiple availability zones
DynamoDB tables should have auto scaling enabled

Additional Controls

8 additional controls mapped for SOC 2

Enforced (1)Detected (7)

View full control documentation with implementation details

View SOC 2 reference documentation

SOC 2 Scope: What We Handle vs. What You Own

compliance.tf handles the infrastructure configuration layer for SOC 2. Here is what it covers and what stays with your team.

compliance.tf Enforces for SOC 2

Module-level infrastructure controls (encryption, logging, access, versioning)
Trust Services Criteria mapping (CC6.1, CC6.6, CC7.2, and more)
Deployment-time evidence generation via AWS-native tools
Upstream module updates (terraform-aws-modules kept in sync)
Exception management with audit trail
Control documentation and compliance mapping matrices

See which modules are covered

View SOC 2 reference documentation

Your Team Still Handles for SOC 2

Organizational policies and procedures
Employee background checks and security training
Change management procedures and approval workflows
Vendor management and third-party risk assessments
Incident response and communication plans
Business continuity and disaster recovery testing
Resources outside compliance.tf module coverage

Infrastructure controls are typically 30-40% of SOC 2 audit findings. compliance.tf handles that portion so your team can focus on organizational controls.

Operational Rules (lifecycle blocks, tagging, instance restrictions) are also applied alongside SOC 2 compliance controls.

SOC 2 Audit Evidence - Built Into Your Workflow

Your auditor does not need to trust compliance.tf. Evidence comes from AWS-native tools they already accept.

Evidence your auditor already trusts

Every compliance.tf module enforces controls before terraform apply. When AWS Config, Security Hub, or Audit Manager evaluates your resources, they report clean findings because the controls are built into the modules, not bolted on after the fact.

AWS Config rules validate resource configuration continuously
Security Hub aggregates findings across accounts and regions
Audit Manager generates assessment reports mapped to SOC 2
Downloadable control mapping matrices for your auditor

evidence.json

{
    "framework": "SOC 2",
    "clause": "CC6.2",
    "control": "s3_bucket_default_encryption_enabled",
   "status": "COMPLIANT",
    "source": "AWS Config",
    "resource": "arn:aws:s3:::awesome-docs",
    "evaluated": "2026-08-14T10:30:00Z"
}

Prevention vs. Detection for SOC 2

compliance.tf prevents non-compliant deployments. Scanning tools detect them after the fact. Most mature programs use both.

Dimension	IaC Scanning Checkov / Trivy / Prowler	Compliance.tf
Prevents non-compliant configs before terraform apply	No (post-plan scan)	Yes
Maps controls to framework clause IDs	Partial	Yes
Produces auditor-accepted evidence (AWS-native)	Scan reports only	Yes
Exception management with audit trail	Suppression rules	Yes
Same interface as terraform-aws-modules	N/A	Yes
Keeps pace with upstream module updates	N/A	Yes
Catches runtime drift / console changes	Yes	No
Covers non-Terraform resources	Yes	No
Internal engineering time	Medium	Low

We recommend keeping scanning tools active alongside compliance.tf for defense in depth. The scanner validates what compliance.tf already enforces.

Detailed: compliance.tf vs Checkov/Trivy →Detailed: compliance.tf vs OPA/Sentinel →All comparisons →

SOC 2 Compliance Questions

Which Trust Services Criteria does this cover?

compliance.tf enforces infrastructure controls mapped to CC6 (Logical and Physical Access Controls), CC7 (System Operations), and CC8 (Change Management). These are the criteria tied to AWS resource configuration: encryption at rest and in transit, access blocking, logging, versioning, and lifecycle policies. Criteria like CC1 (Control Environment) and CC2 (Communication) are organizational and remain your team's responsibility.

How is this different from Checkov, Trivy, or Prowler?

Those tools are detective controls. They scan infrastructure after you write it and report findings you fix manually. compliance.tf is a preventive control. The modules cannot silently produce non-compliant resources - every exception is an explicit parameter in your code, visible in review. Compliant defaults ship up front instead of findings to remediate later. Most teams keep their scanners running alongside compliance.tf for defense in depth.

Can I adopt this gradually, or is it all-or-nothing?

Fully incremental. Start with one module in one environment. Your existing modules continue working untouched. If you use Terragrunt or Terramate to orchestrate your runs, nothing changes - you’re only swapping the module source line. There is no global policy agent to deploy, no wrapper binary, no sidecar. Each module source line is independent.

Does compliance.tf replace our GRC platform (Vanta, Drata, Sprinto)?

No. We enforce controls inside Terraform modules. Your GRC platform tracks policies, collects evidence, and manages audit workflows. We feed evidence into your GRC platform, not the other way around.

Will my auditor accept this as evidence?

Your auditor does not need to trust compliance.tf directly. Evidence comes from AWS-native tools they already accept: AWS Config, Security Hub, and Audit Manager. We enforce controls before terraform apply, so those tools report the enforced controls as passing.

What if I want to switch back or compliance.tf shuts down?

Our modules are standard Terraform. They work with Terraform, OpenTofu, Terragrunt, Terramate, and any tool that speaks the Terraform module protocol. Every module is a drop-in replacement for its upstream terraform-aws-modules equivalent with the same variables and outputs. Change your module source line back, run terraform init. Your infrastructure does not change. No lock-in, no proprietary state.

Start Deploying SOC 2-Compliant Infrastructure

$1,000/year for all 35 modules, all frameworks. 30-day free trial.

Start Free Trial Contact Sales

No credit card required. Switch back at any time.

Or browse the SOC 2 registry first - no signup needed: soc2.compliance.tf

Stay Informed About New Features

Join the mailing list for releases, new modules, and roadmap updates. No spam. Unsubscribe anytime.

Not convinced yet, or missing a feature you need? Send us an email - we really want to hear your feedback!

SOC 2 Compliant Terraform ModulesEnforced Before terraform apply

Three Steps to SOC 2 Compliant Infrastructure

Change One Line

Run Terraform Commands

Compliance Enforced

Controls Mapped for SOC 2

A1.1 The entity maintains, monitors, and evaluates current processing capacity and use of system components to manage capacity demand

A1.2 The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data back-up processes, and recovery infrastructure to meet its objectives

C1.1 The entity identifies and maintains confidential information to meet the entity's objectives related to confidentiality

C1.2 The entity disposes of confidential information to meet the entity's objectives related to confidentiality

CC1.3 COSO Principle 3: Management establishes, with board oversight, structures, reporting lines, and appropriate authorities and responsibilities in the pursuit of objectives

CC2.1 COSO Principle 13: The entity obtains or generates and uses relevant, quality information to support the functioning of internal control

CC3.1 COSO Principle 6: The entity specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to objectives

CC3.2 COSO Principle 7: The entity identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed

CC3.3 COSO Principle 8: The entity considers the potential for fraud in assessing risks to the achievement of objectives

CC3.4 COSO Principle 9: The entity identifies and assesses changes that could significantly impact the system of internal control

CC4.2 COSO Principle 17: The entity evaluates and communicates internal control deficiencies in a timely manner to those parties responsible for taking corrective action, including senior management and the board of directors, as appropriate

CC5.2 COSO Principle 11: The entity also selects and develops general control activities over technology to support the achievement of objectives

CC6.1 The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives

CC6.2 Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity

CC6.6: The entity implements logical access security measures to protect against threats from sources outside its system boundaries.

CC6.7 The entity restricts the transmission, movement, and removal of information to authorized internal and external users and processes, and protects it during transmission, movement, or removal to meet the entity's objectives

CC6.8: The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software to meet the entity's objectives.

CC7.1: To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.

CC7.2: The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analyzed to determine whether they represent security events.

CC7.3 The entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives (security incidents) and, if so, takes actions to prevent or address such failures

CC7.4 The entity responds to identified security incidents by executing a defined incident response program to understand, contain, remediate, and communicate security incidents, as appropriate

CC7.5 The entity identifies, develops, and implements activities to recover from identified security incidents

CC8.1 The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives

P4.2 The entity retains personal information consistent with the entity's objectives related to privacy

PI1.2 System inputs are measured and recorded completely, accurately, and timely to meet the entity's processing integrity commitments and system requirements

PI1.3 Data is processed completely, accurately, and timely as authorized to meet the entity's processing integrity commitments and system requirements

PI1.4 System outputs are complete, accurate, distributed only to intended parties, and retained to meet the entity's processing integrity commitments and system requirements

PI1.5 Stored data is maintained complete, accurate, and protected from unauthorized modification to meet the entity's processing integrity commitments and system requirements