vs custom wrappers

Read this if your platform team maintains its own wrapper modules around terraform-aws-modules today. You keep the wrapper for what is specific to your organization: naming, tags, network layout. Compliance.tf takes over the compliance layer underneath it, so the wrapper stops carrying framework controls and their mappings. This page is for the platform lead who owns the Terraform standards.

Summary

Dimension	Compliance.tf	Custom wrapper modules
Compliance controls maintained by	Compliance.tf	Your team
Upstream compatibility	Same inputs and outputs as terraform-aws-modules, tracked per release	Your team reviews and adapts every upstream release
Framework mapping	Controls mapped to clause IDs on the framework pages	You build and maintain it, if at all
Hand-written resources	The compliance.tf provider for AWS checks `aws_*` resources before apply	Covered only if they go through a wrapper
Organization-specific logic	Not included; keep a thin wrapper on top	Anything you write
Operational rules	Download-time rules (prevent destroy, ignore tag changes, allowed regions) from an org Baseline, without editing module code	Written into each wrapper
Catalog scope	Modules in the compliance.tf catalog	Any module or resource
Governance and evidence	Versioned snapshots per environment, approval before production, waivers with an expiry, an audit trail of posture changes	Your Git history and release process
External dependency	The compliance.tf registry	None
Cost	Paid subscription with a free trial	Engineering time
Time to the first enforced module	One `source` change, plus fixing the validation errors it surfaces	Building and testing the wrapper

What each tool solves

Compliance.tf serves terraform-aws-modules with the controls of the framework you pick, from an endpoint such as soc2.compliance.tf. The modules keep the upstream interface, track upstream releases, and map each control to the framework clauses it addresses. The provider covers the aws_* resources you declare directly.

Custom wrapper modules are modules your platform team writes and maintains. They usually wrap terraform-aws-modules or raw AWS resources with your defaults, input validation and policy decisions.

Where compliance.tf is stronger

Upstream releases are handled for you. With a wrapper, every upstream release means a review, an update, tests and an internal release.
Framework mappings come with the controls. Keeping a mapping from your defaults to SOC 2, PCI DSS, HIPAA or NIST 800-53 clauses current takes compliance knowledge and ongoing work. Compliance.tf publishes the mapping per control.
Less dependence on the people who wrote it. When the engineer who built the wrappers moves on, the compliance logic becomes someone else's problem. Compliance.tf moves that maintenance to a vendor, which is a dependency of its own (see Compare approaches).
Rules and posture without code changes. Org-wide operational rules apply at download time, and a project environment's control set changes by promoting a reviewed snapshot rather than releasing a new wrapper version.

Where custom wrappers are stronger

Your conventions. Naming patterns, tagging schemas, network topology and deployment conventions are yours to encode. You choose which variables to expose and what each default is.
No external dependency. Wrappers keep working whatever happens to a third-party service, and there is no subscription.
Any scope. You can wrap any module, any provider's resources or any combination.
Your release cycle. A requirement change ships when you push it. A change to a compliance.tf control follows the vendor's releases; per module you can still turn individual controls on and off.
Cost already budgeted. The engineering time is part of the platform team you already pay for.

Use both together

Use compliance.tf modules as the base layer and keep a thin wrapper for your organization's logic. The compliance.tf module is the wrapper's source; the wrapper adds naming and tags:

# modules/s3-bucket/main.tf - your thin wrapper
module "s3_bucket" {
  source  = "soc2.compliance.tf/terraform-aws-modules/s3-bucket/aws"
  version = "5.0.0"

  # Your naming convention, plus the inputs you choose to expose.
  bucket        = "${var.org_prefix}-${var.environment}-${var.name}"
  force_destroy = var.force_destroy

  # Your required tags, merged with whatever the caller adds.
  tags = merge({
    Environment = var.environment
    CostCenter  = var.cost_center
  }, var.tags)
}

When a framework requirement changes, compliance.tf updates the controls. When your conventions change, you update the wrapper.

To move one wrapper over, the migration kit has per-module playbooks.

Compare approaches
Compatibility with terraform-aws-modules
Turn controls on and off
Rule catalog
Make the case: build the internal argument for adopting it