Make the case

You have evaluated compliance.tf and now need approval to adopt it. This page is for the platform lead or security engineer writing that case, and for the CISO or head of GRC who reads it. It gives you the summary, the cost model, the scope boundary and the governance answers, in the order the people who approve a purchase tend to ask for them.

Summary for leadership

Compliance.tf serves terraform-aws-modules, the widely used open-source Terraform modules for AWS, with the controls of the compliance framework you choose already set in the module source. A team changes one line per module:

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

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

The same terraform init, plan and apply follow. No agent runs in your environment.

• What it enforces. The framework's controls on every module compliance.tf serves, at plan time. The compliance.tf provider for AWS checks hand-written aws_* resources before Terraform calls AWS. Operational rules, such as allowed regions or protection against destroying data stores, are applied to modules at download.
• How it is governed. An organization can give each project's dev, staging and prod its own approved posture, promote changes through a gate, grant time-limited waivers, and read back who did each of those in an audit trail.
• What it costs. Sold through AWS Marketplace; current plans are on the pricing page.
• How you leave. Change the source line back to upstream. Inputs, outputs and state are the same.

What it replaces, what stays

What it replaces:

• Custom wrapper modules maintained to force compliance defaults
• Setting compliance values by hand on every module call
• Scan-and-remediate cycles for the infrastructure settings the modules now set
• Custom OPA, Sentinel or Checkov rules written only to enforce infrastructure defaults

What stays:

• Your scanners and AWS Config, now as independent verification that the controls held
• Policy-as-code for organization rules compliance.tf does not cover
• Every organizational, HR, incident-response, vendor and identity control your framework requires
• Your CI/CD platform and state backend, unchanged

The comparisons with each kind of tool are in Compare approaches.

Cost model

Pricing and plans are on the pricing page and the AWS Marketplace listing. Purchase runs through AWS Marketplace, so the subscription and invoice sit inside your existing AWS agreement rather than a new vendor contract. Evaluation does not: every new account starts on a trial of every framework with no card and no AWS account. See Plans and entitlements.

Use this worksheet to estimate the time your team stops spending. Fill in your own numbers.

Worked example, low end of every range: 10 modules, 2 engineers, 1 framework, one audit a year, 5 findings per audit.

At $100/hr that is $11,000 a year. These ranges are planning estimates, not results; replace them with your team's experience.

Risk reduction and scope boundary

Preventive, on the path it protects. Most infrastructure compliance is detective: deploy, scan, find, fix, rescan. Compliance.tf is preventive: for resources built from its modules, the framework's settings are in the module before the plan runs, so a missing encryption or logging setting is not there to find later. The provider applies the same idea to the hand-written resources its controls cover, failing the plan in hard_fail mode.

Fewer findings for the settings it covers. When encryption at rest, logging, access restrictions and similar settings are set by default, there are fewer of those findings to remediate. That applies to those settings only.

Where it ends. Compliance.tf acts on Terraform. It does not see changes made in the AWS console, CLI, SDKs, CloudFormation or CDK, resources brought in with terraform import, or hand-written resources when the provider is not in use. It does not replace access reviews, security awareness training, incident response, vendor risk management, HR controls, or your policies. Which framework requirements are enforced and which are mapped only is on each framework page; the modules served are listed in the module catalog. The full boundary is on Audit evidence.

Governance and evidence

Before a CISO or auditor relies on the platform, they want these answers.

• Approval. A config's posture is frozen into an immutable snapshot when published, and approved as a separate act. A protected environment (prod) accepts only an approved snapshot, through a promotion gate.
• Who approves. The approver capability is granted separately from role, so the admins who author a posture need not be the people who approve it. See Access control.
• Separation of duties: off by default. Enforced separation between the publisher and the approver or promoter is enabled with our help, not by a setting you can change. Until it is enabled, separation holds by how you assign the approver capability, and the audit trail shows who did each act. An admin can grant themselves the approver capability.
• Exceptions. On a project environment, an exception is a waiver: proposed and approved separately, with a justification and an expiry that decides whether a promotion can still freeze it into the environment's binding. A frozen waiver stays in force until a later promotion replaces the binding. Turning a control off with ?disable= in a module source is refused there. On a framework endpoint, ?disable= names the control in the source line, where code review sees it. See Waivers.
• Audit trail. Publishing, approving, promoting, rolling back and every waiver decision are recorded with the person and the time, in the same operation as the change. Records are kept for 90 days and cannot be exported from the app today, so keep your own copy for longer audits. Membership changes and edits to live operational rules are not in the trail. See The audit trail.
• Evidence for the auditor. The module source and pinned versions, scan reports, AWS-native findings, and what each supports are on Audit evidence.

Questions your security team will ask

"Is this a vendor dependency?"

It's shallow. Compliance.tf modules use the same inputs, outputs, and state as the upstream terraform-aws-modules. So your state holds nothing compliance.tf-specific. To leave, change the source line back to the upstream registry and run terraform init. Your infrastructure keeps working without the enforced controls. To adopt the provider, change its source and run one terraform state replace-provider. Leaving reverses both steps.

"How do we verify the controls are enforced?"

With the tools you already trust. The enforced values are in the terraform plan output and in the downloaded module. Run Checkov, Prowler, Powerpipe or AWS Config against your plans or deployed resources to check them independently. See Audit evidence.

"What about our own standards?"

Compliance.tf's operational rules cover a set of organization standards at download time, including allowed regions, instance-type restriction, deletion protection, and lifecycle rules that stop Terraform destroying data or fighting autoscaling. The rule catalog lists them. Standards outside that catalog, such as naming conventions or cost policy, stay in your existing policy tooling.

"Which frameworks and controls are covered?"

See the generated catalogs rather than a copy: frameworks for what each framework's page enforces and maps, and controls for each control and the modules that implement it.

Questions your engineering team will ask

"Do I need to change my Terraform workflow?"

No. The change is the module source line, plus registry authentication: terraform login or a token, as with any private registry. State, backends and provider setup stay the same. See Get started.

"Does it work with HCP Terraform, Spacelift, Atlantis or GitHub Actions?"

Any tool that runs terraform init and can hold a registry token works. Platform setup is in CI/CD integration.

"Can I still configure modules the way I do now?"

The modules take the same input variables and return the same outputs as upstream. Settings that a control enforces keep their enforced value whatever you pass.

"What if a control blocks my deployment?"

On a framework endpoint, turn the specific control off with ?disable= in the module source, which puts the exception in code review; see Turn controls on and off. On a project environment, ask an approver for a waiver instead.

"What if compliance.tf is unavailable?"

Modules are fetched at terraform init. A workspace that already has them under .terraform/modules/ runs plan and apply against that copy without contacting compliance.tf for modules, and already-deployed infrastructure is unaffected. Terraform downloads a module again when its source or version changes, or when you run terraform init -upgrade. Paid plans carry a 99.9% monthly uptime commitment in the SLA; the free plan is best effort.

• Cache .terraform/ between CI runs, so a pipeline's init does not download modules it already holds. On an organization's host, a cached copy keeps the posture it was downloaded with until the next terraform init -upgrade.
• Air-gapped environments. Run terraform init where the registry is reachable and copy .terraform/modules/ into the isolated environment; plan and apply there need no access to compliance.tf. Terraform's filesystem and network mirrors cover providers, not modules. Do not put a shared caching proxy in front of the registry: different callers receive different modules for the same URL, so a proxy can serve one team's posture to another (How a module request resolves). For other setups, contact us.

"What happens when terraform-aws-modules releases a new version?"

Compliance.tf publishes upstream releases with the controls applied. Check a module's page on the registry for the versions served, then upgrade as you would any module: change the version and run terraform init. With a version range rather than an exact pin, terraform init -upgrade moves to the newest release the range allows.

"Can we adopt this incrementally?"

Yes, one module at a time. Compliance.tf and upstream modules coexist in one configuration. The migration kit suggests where to start.

Vendor due diligence

Compliance.tf has completed a SOC 2 Type II audit. Request the report through the Trust Center.

• Security practices: how modules are built and distributed
• Trust Center: SOC 2 Type II reports and penetration test summaries
• SLA: uptime commitments and support response times
• DPA: data processing agreement
• License / EULA: terms of use
• Contact: reach the team

Next steps

• Get started: set up a token and run your first terraform plan
• Start a free trial: every framework, no card and no AWS account
• Audit evidence: what to hand your auditor
• Compare approaches: how compliance.tf sits next to your current tools