How is this different from OPA or Sentinel?

OPA and Sentinel are policy engines where you write rules in Rego or Sentinel language. With compliance.tf, compliance controls are pre-built into the modules — no policy authoring or engine deployment needed. Many teams use both. Starting Q2 2026, compliance.tf custom rules can scan, edit, and enforce organizational policies directly in the modules.

Which Terraform modules are available today?

34 modules based on terraform-aws-modules, including S3, VPC, EKS, RDS, Lambda, ALB, DynamoDB, and more. Same variables, same outputs, same interface. Custom module support is in beta.

Does this work with OpenTofu, Terragrunt, or Terramate?

Yes. Our registry uses the standard Terraform module protocol, which OpenTofu supports natively. Run tofu login registry.compliance.tf instead of terraform login and everything else works the same way. Terragrunt and Terramate orchestrate runs without changing how modules are resolved, so they work out of the box.

What does Compliance.tf cover vs. what do I still own?

We enforce controls at the Terraform module level — encryption, logging, versioning, access blocking for 34 AWS modules. You still own IAM policies, network architecture, application security, runtime monitoring, and incident response.

What if I need to disable a control for a legitimate reason?

Disable specific controls via a query parameter in the module source. Every exception is logged with the control ID, who authorized it, and why.

Does this replace Vanta, Drata, or Sprinto?

No. We enforce controls inside Terraform modules. Your GRC platform tracks policies, collects evidence, and manages audit workflows. We feed evidence into your GRC platform, not the other way around.

How do I get started?

Sign up at compliance.tf — no AWS account or credit card required. Run terraform login registry.compliance.tf, change your module source line, and run terraform init. If you use OpenTofu, run tofu login registry.compliance.tf instead. You can also subscribe through AWS Marketplace.

What if Compliance.tf shuts down or I want to leave?

Our modules are standard Terraform. They work with Terraform, OpenTofu, Terragrunt, Terramate, and any tool that speaks the Terraform module protocol. Every module is a drop-in replacement for upstream terraform-aws-modules (same variables, same outputs). Change your module source back and run terraform init. No lock-in, no proprietary state.

PCI DSS Compliant Terraform Modules
Enforced Before `terraform apply`

Cardholder data protection starts at the infrastructure layer. Every module enforces encryption, access controls, logging, and key management before deployment.

If your application stores, processes, or transmits credit card numbers, PCI DSS is mandatory. Non-compliance can result in fines or loss of card processing privileges. Even if you use Stripe, your AWS infrastructure may be in scope.

278

Controls

Clauses

AWS Modules

Start Free Trial View All Controls

No credit card or AWS account needed to start.

From the team behind terraform-aws-modules. 2B+ provisions worldwide.

IAM · S3 · RDS · CloudWatch Logs · General · VPC|SOC 2 Type II Certified|Available on AWS Marketplace

Three Steps to PCI DSS Compliant Infrastructure

For terraform-aws-modules users, migration is a one-line change. Same workflow, same interface. Bringing your own modules? We can make those compliant too. Join the beta.

Change One Line

main.tf

module "s3" {
- source = "registry.terraform.io/..."
+ source = "pcidss.compliance.tf/..."
 
  bucket = "awesome-docs"
}

Run Terraform Commands

terminal

$ terraform init
Initializing modules...
- module.s3 in pcidss.compliance.tf/...
Terraform has been successfully initialized!
$ terraform apply
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Compliance Enforced

10.2.1 · Logging Enabled

10.5.1 · Object Lock Enabled

3.2.1 · Versioning + Lifecycle

3.4.1 · Default Encryption

3.4.1 · KMS Encryption

1.3.1 · Public Access Blocked

4.2.1 · SSL Requests Only

10.3.1 · MFA Delete

Every compliance requirement you define is enforced automatically. Nothing to scan, nothing to remediate.

Controls Enforced for PCI DSS

278 controls across 40 clauses and AWS services

Enforced (22)Detected (23)

Additional Controls

233 additional controls enforced for PCI DSS

Enforced (110)Detected (123)

View full control documentation with implementation details

View PCI DSS reference documentation

PCI DSS Scope: What We Handle vs. What You Own

compliance.tf handles the infrastructure configuration layer for PCI DSS. Here is what it covers and what stays with your team.

compliance.tf Enforces for PCI DSS

Infrastructure-level data protection controls (encryption, access blocking, logging)
PCI DSS v4.0 requirement mapping with specific requirement IDs
Deployment-time evidence generation via AWS-native tools
Upstream module updates (terraform-aws-modules kept in sync)
Exception management with audit trail
Control documentation and requirement mapping matrices

See which modules are covered

View PCI DSS reference documentation

Your Team Still Handles for PCI DSS

SAQ completion and submission
QSA engagement and on-site assessments
Penetration testing and vulnerability scanning
Security awareness training programs
Physical security of cardholder data environments
Application-level security controls
Network segmentation and firewall rules

compliance.tf handles the PCI DSS requirements that map to AWS resource configuration. Your QSA still assesses your full cardholder data environment.

PCI DSS Audit Evidence, Generated Automatically

Your auditor does not need to trust compliance.tf. Evidence comes from AWS-native tools they already accept.

Evidence your auditor already trusts

Every compliance.tf module enforces controls at deploy time. When AWS Config, Security Hub, or Audit Manager evaluates your resources, they report clean findings because the controls are built into the modules, not bolted on after the fact.

AWS Config rules validate resource configuration continuously
Security Hub aggregates findings across accounts and regions
Audit Manager generates assessment reports mapped to PCI DSS
Downloadable control mapping matrices for your auditor

evidence.json

{
    "framework": "PCI DSS",
    "clause": "3.4.1",
    "control": "s3_bucket_default_encryption_enabled",
   "status": "COMPLIANT",
    "source": "AWS Config",
    "resource": "arn:aws:s3:::awesome-docs",
    "evaluated": "2026-03-04T10:30:00Z"
}

Prevention vs. Detection for PCI DSS

compliance.tf prevents non-compliant deployments. Scanning tools detect them after the fact. Most mature programs use both.

Dimension	IaC Scanning Checkov / Trivy / Prowler	compliance.tf
Prevents non-compliant configs before terraform apply	No (post-plan scan)	Yes
Maps controls to framework clause IDs	Partial	Yes
Produces auditor-accepted evidence (AWS-native)	Scan reports only	Yes
Exception management with audit trail	Suppression rules	Yes
Same interface as terraform-aws-modules	N/A	Yes
Keeps pace with upstream module updates	N/A	Yes
Catches runtime drift / console changes	Yes	No
Covers non-Terraform resources	Yes	No
Internal engineering time	Medium	Low

We recommend keeping scanning tools active alongside compliance.tf for defense in depth. The scanner validates what compliance.tf already enforces.

PCI DSS Compliance Questions

Can compliance.tf reduce my PCI DSS scope?

compliance.tf does not change your PCI DSS scope — that is determined by where cardholder data flows. What it does is ensure that every AWS resource within scope is configured to meet PCI DSS requirements before deployment. This means fewer findings during your QSA assessment and less remediation work.

Is this PCI DSS v3.2.1 or v4.0?

compliance.tf supports PCI DSS v4.0, the current version effective since March 2024. Controls are mapped to v4.0 requirement IDs. If you need v3.2.1 mappings for transition purposes, contact us.

How is this different from Checkov, Trivy, or Prowler?

Those tools are detective controls. They scan infrastructure after you write it and report findings you fix manually. compliance.tf is a preventive control. The modules themselves cannot produce non-compliant resources. There is nothing to scan, nothing to remediate. Most teams keep their scanners running alongside compliance.tf for defense in depth.

Can I adopt this gradually, or is it all-or-nothing?

Fully incremental. Start with one module in one environment. Your existing modules continue working untouched. If you use Terragrunt or Terramate to orchestrate your runs, nothing changes — you’re only swapping the module source line. There is no global policy agent to deploy, no wrapper binary, no sidecar. Each module source line is independent.

Will my auditor accept this as evidence?

Your auditor does not need to trust compliance.tf directly. Evidence comes from AWS-native tools they already accept: AWS Config, Security Hub, and Audit Manager. We enforce controls at deploy time so those AWS tools always report clean findings.

What if I want to switch back or compliance.tf shuts down?

Our modules are standard Terraform. They work with Terraform, OpenTofu, Terragrunt, Terramate, and any tool that speaks the Terraform module protocol. Every module is a drop-in replacement for its upstream terraform-aws-modules equivalent with the same variables and outputs. Change your module source line back, run terraform init. Your infrastructure does not change. No lock-in, no proprietary state.

Start Deploying PCI DSS-Compliant Infrastructure

$100/year for all 34 modules, all frameworks. 30-day free trial.

Start Free Trial Contact Sales

No credit card required. Switch back at any time.

Stay Informed About New Features

Join the mailing list for releases, new modules, and roadmap updates. No spam. Unsubscribe anytime.

Not convinced yet or dying for a feature we don't have? Send us an email — we really want to hear your feedback!

PCI DSS Compliant Terraform ModulesEnforced Before terraform apply

Three Steps to PCI DSS Compliant Infrastructure

Change One Line

Run Terraform Commands

Compliance Enforced

Controls Enforced for PCI DSS

1.3.2: Network access to and from the cardholder data environment is restricted.

1.4.2: Network connections between trusted and untrusted networks are controlled.

1.4.4: Network connections between trusted and untrusted networks are controlled.

10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.

10.3.2: Audit logs are protected from destruction and unauthorized modifications.

10.3.4: Audit logs are protected from destruction and unauthorized modifications.

10.4.2: Audit logs are reviewed to identify anomalies or suspicious activity.

10.5.1: Audit log history is retained and available for analysis.

11.5.2: Network intrusions and unexpected file changes are detected and responded to.

2.2.1: System components are configured and managed securely.

2.2.6: System components are configured and managed securely.

3.2.1: Storage of account data is kept to a minimum.

3.7.4: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.

6.2.4: Bespoke and custom software are developed securely.

6.3.3: Security vulnerabilities are identified and addressed.

7.2.5: Access to system components and data is appropriately defined and assigned.

7.3.1: Access to system components and data is managed via an access control system(s).

8.2.6: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.

8.3.2: Strong authentication for users and administrators is established and managed.

8.3.7: Strong authentication for users and administrators is established and managed.

8.4.3: Multi-factor authentication (MFA) is implemented to secure access into the CDE.

8.6.2: Use of application and system accounts and associated authentication factors is strictly managed.

8.6.3: Use of application and system accounts and associated authentication factors is strictly managed.

Additional Controls

RDS

S3

IAM

CloudWatch Logs

VPC

EC2

CloudFront

OpenSearch

ECS

Redshift

WAF

API Gateway

CodeBuild

ELB

Neptune

CloudTrail

DynamoDB

EBS

EFS

ElastiCache

Backup

EKS

Elasticsearch

Network Firewall

SageMaker

DMS

DocumentDB

Lambda

Secrets Manager

WAFv2

Account

ECR

Elastic Beanstalk

EMR

SSM

ACM

AppSync

Athena

Auto Scaling

CloudFormation

CloudWatch

CodeDeploy

Config

DAX

FSx

API Gateway v2

GuardDuty

Kinesis

KMS

Route 53

PCI DSS Compliant Terraform Modules
Enforced Before `terraform apply`