compliance.tf

compliance.tf vs Custom Wrapper Modules

What each tool solves

compliance.tf provides compliance-ready Terraform modules that wrap terraform-aws-modules with enforced controls. The modules are maintained by the compliance.tf team, version-tracked against upstream releases, and mapped to compliance frameworks.

Custom wrapper modules are in-house Terraform modules that your platform or infrastructure team writes and maintains. They typically wrap terraform-aws-modules (or raw AWS resources) with organization-specific defaults, input validations, and policy enforcement. They encode your team's decisions about how infrastructure should be configured.

Where compliance.tf is stronger

When upstream terraform-aws-modules releases a new version, compliance.tf tracks and tests compatibility. With custom wrappers, your team must review every upstream release, update the wrapper, test for breaking changes, and release a new version internally.

Controls are mapped to SOC 2, PCI DSS v4.0, HIPAA, NIST 800-53, and 35+ other frameworks. Building and maintaining these mappings in-house requires deep compliance knowledge and ongoing research as framework requirements evolve.

  • Custom wrappers depend on the engineer(s) who built them. When they move on, keeping the compliance logic current becomes someone else's learning project. Compliance.tf moves that maintenance to a dedicated team, though this introduces a vendor dependency (see below).
  • Version-tracked control changes. When compliance requirements change, compliance.tf modules are updated in versioned releases with changelogs. Custom wrappers require someone to notice the requirement change, interpret it correctly, and update the module.

Where custom wrapper modules are stronger

Custom wrappers encode institutional knowledge that compliance.tf does not cover: your company's naming patterns, tagging schemas, network topology decisions, and deployment conventions. You decide which variables to expose, which to hide, what defaults to set, and how the module behaves for your teams.

  • No external dependency. Your wrappers work even if a third-party service is down, and there is no subscription to manage.
  • Custom wrappers are not limited to the compliance.tf catalog. You can wrap any Terraform module, any provider resource, or any combination of resources.
  • Faster iteration on changes. When your organization's requirements change, you push a new version of your wrapper immediately. With compliance.tf, you depend on the vendor's release cycle for changes to compliance controls.
  • Custom wrappers cost engineering time (which is not free), but the cost is already part of your infrastructure team's budget. There is no additional SaaS subscription.

When to use both together

Use compliance.tf modules as the compliance-enforced base layer. Wrap them in a thin wrapper module that adds your company-specific defaults: naming conventions, required tags, internal network configuration, and any business logic specific to your organization.

This separates concerns. Compliance.tf handles compliance (encryption, public access blocking, backup retention, and TLS configuration). Your thin wrapper handles business logic (naming, tagging, network topology, environment-specific configuration). When compliance requirements change, compliance.tf updates the controls. When your organizational requirements change, you update your thin wrapper.

In practice the wrapper is short — the compliance.tf module is its source, and the wrapper adds only what is specific to your organization:

# 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; everything else is passed straight through.
  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)
}

The thin wrapper becomes much simpler — it handles only business logic, not compliance logic. And you are not maintaining compliance framework mappings in-house.

Where a thin wrapper sits Layer stack: your thin wrapper adds naming, tags, network config and environment defaults; it calls the compliance.tf module, which adds encryption, logging, access controls and framework compliance on top of the upstream terraform-aws-modules resource configuration. SOURCE = SOURCE = YOURS Your thin wrapper naming · tags · network config · environment-specific defaults COMPLIANCE compliance.tf module encryption · logging · access controls · framework compliance UPSTREAM terraform-aws-modules core AWS resource configuration

Summary

Dimensioncompliance.tfCustom Wrapper Modules
Compliance controls maintained bycompliance.tf teamYour team
Upstream compatibility trackingTested and tracked per releaseYour responsibility to track
Framework mapping (SOC 2, PCI, etc.)Built in across 36 frameworksYou build and maintain it
Organization-specific logicNot included (use a thin wrapper on top)Fully customizable to your org
Module catalog scope51 modulesAny module or resource
CostPaid subscriptionEngineering time (already budgeted)
External dependencyYes (compliance.tf registry)None
Time from zero to compliantA source URL change, plus fixing the validation errors it surfacesWeeks to months of engineering

Need to make the case to your team? Internal advocacy guide.

On this page

Ask AI about this

Help improve this page