Compliance.tf documentation

Compliance.tf gives you Terraform modules for AWS with the controls for the framework you pick built in. There is also an AWS provider, which checks the hand-written resources its controls cover. Every control lists the clauses it maps to. Every framework page has two separate lists: the controls modules enforce, and the mapped-only controls that stay with your team. The docs explain adopting it one module at a time, keeping exceptions in reviewed code, and what to give your auditor.

Get started · How compliance.tf works

Change one source line

module "s3_bucket" {
  source  = "terraform-aws-modules/s3-bucket/aws"
  version = "5.0.0"
}

module "s3_bucket" {
  source  = "soc2.compliance.tf/terraform-aws-modules/s3-bucket/aws"
  version = "5.0.0"
}

Change the source, run terraform init, then terraform plan. Same inputs and outputs, no state migration. If the configuration breaks one of the module's controls, the plan fails with an error that names the control and links its page, which lists the frameworks that map it. To go back, point the source at terraform-aws-modules again, run terraform init and re-plan.

Look at the module catalog first. A terraform-aws-modules module that compliance.tf does not serve passes through from the public registry with no compliance.tf controls. Your org's operational rules still apply to it; see Compatibility.

Where compliance.tf acts

The default is soft_fail: the provider warns at plan and before apply. With hard_fail, a violated deny control stops the run before AWS creates or changes the resource. Controls marked warn stay warnings. The provider checks the resource types its controls cover in hand-written resources. Inside a child module it checks resources only when that module itself requires the compliance.tf provider; a module that declares hashicorp/aws, or declares no provider at all, is not checked.

Your scanners, policy engine and CI keep their existing jobs. Compliance.tf puts the controls in the modules your plan is built from.

Start from your job

• You have an audit date. Switch one module and re-plan; a control the configuration breaks fails the plan by name. Then plan the rest of the estate. Get started · Migration kit · Compliance starter kits · Make the case
• You own the Terraform standards. Check the source-line change, pin versions, keep exceptions in the reviewed diff. Compatibility · Registry endpoints · Turn controls on and off · Rules overview · CI/CD integration
• You write the Terraform for a service. Find the module, copy the example, fix a failed plan. Modules catalog · Get started: Failure case · Turn controls on and off
• You own the controls. See which controls modules enforce, which are mapped only, and the clauses each one maps to. Controls catalog · Frameworks · Compare approaches
• You run the organization. One baseline from one endpoint, versioned config per environment, a logged promotion between them. Platform overview · Promotion and gates · Rulesets in the console
• You prepare or assess the audit. Clause IDs per control, the config snapshot per environment, and the audit log. Audit evidence · The audit trail · Frameworks

What it covers and what it does not

Covers:

• Terraform modules for AWS that compliance.tf serves, drop-in for terraform-aws-modules, with the controls for your framework built in.
• Hand-written aws_* resources of the types the provider's controls cover, once you switch to the compliance.tf provider.
• For each framework: the controls it maps to, cited by clause ID. Each framework page lists enforced and mapped-only controls apart.

Does not cover:

• Mapped controls that no module enforces. They stay with your team; each framework page lists them.
• terraform-aws-modules modules compliance.tf does not serve. They pass through from the public registry without compliance.tf controls. Operational rules your org enforces still apply to them.
• Resources inside child modules that do not themselves require the compliance.tf provider. That covers every terraform-aws-modules module, which declares hashicorp/aws, and modules that declare no provider at all. The provider does not check them.
• What happens after apply. Drift and runtime findings stay with your CSPM and AWS-native tools.
• Whether your auditor accepts the mapping. That is their decision; Audit evidence lists what compliance.tf gives them.
• Azure and Google Cloud resources. Their control and framework pages are reference only.

Reference

Modules · Frameworks · Controls · Rule catalog · Glossary. Reference only: Azure frameworks and controls, Google Cloud frameworks and controls.

From the blog: Plan, Apply, Comply