Prevent Destroy Encryption

Adds prevent_destroy = true to KMS keys and Secrets Manager secrets. Blocks accidental deletion of encryption infrastructure.

Why this rule exists

Deleting a KMS key is irreversible after the waiting period (7-30 days). Any data encrypted with that key becomes permanently inaccessible: S3 objects, RDS snapshots, EBS volumes, everything. Deleting a Secrets Manager secret can break applications that depend on stored credentials, API keys, or configuration values.

Unlike data resources where backups might help, losing a KMS key means losing access to the data itself. There is no recovery path.

Related Terraform and OpenTofu issues

Affected resources

What this rule does

Adds a lifecycle { prevent_destroy = true } block to each matching resource. Terraform and OpenTofu will refuse to destroy these resources during terraform destroy or resource replacement.

Before and after

Before (upstream module):

resource "aws_kms_key" "this" {
  # ... resource configuration ...

  tags = var.tags
}

After (with Prevent Destroy Encryption applied):

resource "aws_kms_key" "this" {
  # ... resource configuration ...

  tags = var.tags

  lifecycle {
    prevent_destroy = true
  }
}

The only change is the rule transformation. All existing arguments, outputs, and module behavior remain identical.

Known limits

• Does not cover aws_kms_alias, aws_kms_grant, or other KMS-related resources.
• Does not prevent KMS key disabling (only deletion). A disabled key can be re-enabled.
• Does not cover AWS Certificate Manager (ACM) certificates or other encryption-adjacent resources.
• A resource that already declares prevent_destroy = false keeps that value. The rule adds the argument only where the lifecycle block does not already mention it.
• Only .tf and .tofu files are read. Modules written in JSON syntax (.tf.json, .tofu.json) are left untouched.
• Only the module's own directory and its first-level modules/* submodules are processed. Modules that this module calls by source URL are separate downloads and are handled on their own request.

Compliance framework support

This rule is not a compliance control. It supports these framework objectives as an operational safeguard:

Default configuration

These are the values the rule ships with. They are not settable from a module source URL: ?rules= carries rule names only, so a per-request enable uses exactly the defaults below. Your organization sets them per rule, in its Baseline or in a ruleset, from the Operational Rules page; see Baseline rules and rulesets.

How to enable

On a framework host, per request:

Add ?rules=lifecycle_prevent_destroy_encryption to your HTTPS module source. Use the full namespaced id. A bare lifecycle_prevent_destroy_encryption matches no rule: it is skipped server-side and your terraform init still succeeds, without the rule.

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

On your organization's host:

Add the rule to the organization's Baseline, which applies to every module served from the bare organization form <alias>.compliance.tf/<namespace>/<name>/<provider>, or to a named ruleset that one module selects with ?ruleset=<name> on the HTTPS form of that address. A project environment (<alias>.compliance.tf/<project>/<env>/<module>) serves the rules frozen in its bound snapshot instead: there the rule goes into the config draft and reaches the environment by promotion. On both organization forms ?rules= is refused with a 400 — including the subtractive - prefix — rather than dropped, so you cannot mistake an ignored override for an applied one. Change the configuration, not the URL. See Baseline rules and rulesets for the configuration flow, and registry resolution for how the address forms differ.

Break-glass path

On a framework host, add ?rules=-example/prevent_destroy_encryption to the module source URL and run terraform init -upgrade to fetch a copy without this rule. The copy in .terraform/modules/ stays until the next upgrade, so remove the override when you are done. On your organization's host the parameter is refused with a 400 rather than ignored. The rule comes from the organization's configuration: a Baseline rule applies to every module served from the bare organization form, so an admin disables it for the duration of the operation, or keeps it out of the Baseline and in a ruleset that only the modules needing protection select. On a project environment the posture is the bound snapshot and its waivers. See Baseline rules and rulesets.

Failure modes