Operational Rules

No. Operational Rules and compliance controls are independent layers. Controls are applied first (regulatory enforcement), rules are applied second (operational standards). A rule cannot override, weaken, or bypass a compliance control.

If a rule and a control affect the same resource attribute, the changes are merged additively (e.g., both adding to ignore_changes). Explicit conflict detection, where a rule contradicts a control, is planned for a future release.

Rules live in a separate scope from controls: controls enforce encryption, logging, access blocking, and other regulatory requirements. Rules enforce lifecycle blocks, tagging behavior, provisioner removal, and instance restrictions.

Rules are not compliance controls and should not be presented to auditors as regulatory enforcement. They are operational safety measures.

That said, several rules support operational practices that auditors view favorably:

• Prevent Destroy Data and Prevent Destroy Encryption reduce the risk of accidental data loss, which supports data protection and availability objectives.
• No Provisioners removes a supply chain risk vector from module code, which supports change management and code integrity objectives.
• Restrict Instance Types supports cost governance, which is relevant to resource management controls.

If an auditor asks about these, position them as operational safeguards that complement your compliance controls, not as compliance controls themselves.

Yes. Per-request overrides are available using the ?rules= query parameter in the HTTPS module source URL:

# Remove a rule for this download
module "s3_bucket" {
  source = "https://soc2.compliance.tf/terraform-aws-modules/s3-bucket/aws?version=5.0.0&rules=-pofix/prevent_destroy_data"
}

# Add a rule that is not in org defaults
module "s3_bucket" {
  source = "https://soc2.compliance.tf/terraform-aws-modules/s3-bucket/aws?version=5.0.0&rules=+pofix/ignore_ami_changes"
}

Free tier: You can apply rules per-request by adding ?rules= to your module source URL. Rules are not forced; you choose which to include.

Paid tier: Org admins configure which rules are enabled by default for the organization. Individual developers can override the org defaults on a per-request basis using the ?rules= query parameter. The - prefix removes a rule for that download; the + prefix adds one. Org admins can also disable specific rules for the entire organization via the API.

Yes. Operational Rules modify the module source code (standard HCL) before it is downloaded. The resulting module works identically with Terraform and OpenTofu. There are no provider-specific or CLI-specific dependencies in the rule transformations.

All lifecycle meta-arguments (prevent_destroy, ignore_changes) and the absence of provisioner blocks are standard HCL features supported by both Terraform and OpenTofu.

Rules are applied at download time (terraform init). If your org admin enables a new rule or changes the rule configuration, the change takes effect on the next terraform init -upgrade that downloads a fresh copy of the module.

Modules already downloaded and cached in .terraform/modules/ are not retroactively modified. To pick up new rules, run terraform init -upgrade. You can inspect the downloaded .tf files to see which rules were applied to a given module copy.

Not yet. All rules are currently managed by compliance.tf. Org-authored rules (custom HCL transformation rules defined by your team) are on the roadmap. When available, custom rules will follow the same transformation, manifest, and preview model as builtin rules.

Yes. Rules are applied server-side during module download. Any tool that runs terraform init and downloads modules from the compliance.tf registry will receive modules with rules applied. This includes:

• Atlantis: configure the compliance.tf access token in the Atlantis server's .terraformrc
• Terragrunt: calls terraform init under the hood. Configure credentials as you would for plain Terraform.
• Terraform Cloud agents: configure the compliance.tf token in the workspace or organization credential settings
• Spacelift, env0, Scalr: configure the access token in each platform's credential management

No platform-specific integration is required. If the platform can download modules from a private Terraform registry, rules work.

Inspect the downloaded module source directly. The module is standard HCL. Open any .tf file in .terraform/modules/ and read it. The lifecycle blocks, provisioner removals, and other transformations are visible in the code.

When the Preview API becomes available, you will also be able to see unified diffs before downloading.

For now, you can compare the downloaded .tf files directly across environments. If the same module version was downloaded with the same ?rules= parameter (or the same org defaults), the resulting HCL will be identical. A simple diff or checksum of the downloaded module directories confirms consistency.

When you need to intentionally destroy a protected resource (database migration, bucket replacement, key rotation), use a per-request override to remove the Prevent Destroy Data or Prevent Destroy Encryption rule for a single terraform init:

module "s3_bucket" {
  source = "https://soc2.compliance.tf/terraform-aws-modules/s3-bucket/aws?version=5.0.0&rules=-pofix/prevent_destroy_data"
}

Run terraform init -upgrade to download the module without prevent_destroy. Run your terraform destroy or replacement plan. After the operation, change the source back to remove the override and run terraform init -upgrade again to restore the protection.

The per-request override is visible in the downloaded HCL: the prevent_destroy lifecycle block will be absent. Org admins can also adjust the org defaults via the API if the override is needed permanently.

Downloaded modules are standard Terraform HCL. The lifecycle blocks, tagging behavior, and provisioner changes are all written directly in the .tf files. To leave compliance.tf:

1. Change the module source URL back to terraform-aws-modules/...
2. Manually add the lifecycle blocks that your team needs (or don't; they are standard Terraform features you can add to any module)
3. Run terraform init -upgrade and terraform plan

Because the lifecycle settings in compliance.tf modules are identical to what you would write by hand, there is no state migration, no resource recreation, and no proprietary format to unwind. If your existing state already has the values that rules enforce (e.g., prevent_destroy = true), the plan will show no changes.

Fair question. Here is what compliance.tf provides that a wrapper repo does not:

• Transparency: The downloaded module is plain HCL. You can read every .tf file and see exactly what was transformed. A manifest file (.ctf-rules-manifest.json) that records applied rules and a SHA-256 hash is planned for a future release. Your wrapper repo may add lifecycle blocks, but there is no standard manifest format documenting what changed.
• Consistency: When the same rules are applied (via ?rules= or org defaults), the same module version produces identical HCL. Wrapper repos depend on consistent builds and artifact promotion, which is possible but adds moving parts.
• No maintenance burden: Wrapper repos require re-wrapping on every upstream module update. compliance.tf applies rules to the latest upstream version automatically.
• Inspectability: Open the downloaded .tf files and read them. When the Preview API ships, you can see the diffs before downloading.

That said, if your wrapper repo is well-maintained and working, rules are not a forced migration. They are an option for teams that want the same outcome without the fork tax.