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.

339

Controls

134

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 · RDS · S3 · CloudWatch Logs · VPC · CloudTrail|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

339 controls across 134 clauses and AWS services

Enforced (168)Detected (163)

CloudFront distributions should encrypt traffic to custom origins
CloudFront distributions should require encryption in transit
CloudFront distributions should not use deprecated SSL protocols between edge locations and custom origins
CloudFront distributions should encrypt traffic to non S3 origins
CloudFront distributions should use SNI to serve HTTPS requests
CloudFront distributions should use secure SSL cipher
ELB application and network load balancers should only use SSL or HTTPS listeners
ELB application and network load balancer listeners should use secure protocols
ELB classic load balancers should use SSL certificates
ELB classic load balancers should only use SSL or HTTPS listeners
Elasticsearch domain node-to-node encryption should be enabled
OpenSearch domains should use HTTPS
OpenSearch domains node-to-node encryption should be enabled
Redshift cluster encryption in transit should be enabled
S3 buckets should enforce SSL
Transfer Family servers should not use FTP protocol for endpoint connection
VPC security groups should not allow ingress from 0.0.0.0/0 to remote server administration ports (IPv4)

Additional Controls

8 additional controls enforced for PCI DSS

Enforced (2)Detected (6)

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.

Operational Rules (lifecycle blocks, tagging, instance restrictions) are also applied alongside PCI DSS compliance controls.

PCI DSS Audit Evidence — Built Into Your Workflow

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.

Detailed: compliance.tf vs Checkov/Trivy →Detailed: compliance.tf vs OPA/Sentinel →All comparisons →

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.

From Our Blog

Make Non-Compliant Terraform Impossible

Replace scanning with built-in compliance controls

Why Enterprises Choose Compliance.tf

Compare hidden costs of DIY compliance

Start Deploying PCI DSS-Compliant Infrastructure

$1,000/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.2.5: Network security controls (NSCs) are configured and maintained.

1.2.8: Network security controls (NSCs) are configured and maintained.

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

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

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

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

1.4.3 Anti-spoofing measures are implemented to detect and block forged source IP addresses from entering the trusted network

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

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

1.4.4: System components that store cardholder data are not directly accessible from untrusted networks

1.4.5 The disclosure of internal IP addresses and routing information is limited to only authorized parties

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

1.5.1 Security controls are implemented on any computing devices, including company- and employee-owned devices, that connect to both untrusted networks

1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.

2.2.5: System components are configured and managed securely.

2.2.5: System components cannot be compromised by exploiting insecure services, protocols, or daemons

2.2.7: System components are configured and managed securely.

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

3.3.1.1: Sensitive authentication data (SAD) is not stored after authorization.

3.3.1.3: Sensitive authentication data (SAD) is not stored after authorization.

3.3.2: Sensitive authentication data (SAD) is not stored after authorization.

3.3.3: Sensitive authentication data (SAD) is not stored after authorization.

3.5.1: Primary account number (PAN) is secured wherever it is stored.

3.5.1.1: Primary account number (PAN) is secured wherever it is stored.

3.5.1.3: Primary account number (PAN) is secured wherever it is stored.

3.6.1: Cryptographic keys used to protect stored account data are secured.

3.6.1.2: Cryptographic keys used to protect stored account data are secured.

3.6.1.3: Cryptographic keys used to protect stored account data are secured.

3.6.1.4: Cryptographic keys used to protect stored account data are secured.

3.7.1: 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.

3.7.2: 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.

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.

3.7.5: 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.

3.7.6: 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.

3.7.7: 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.

4.2.1: PAN is protected with strong cryptography during transmission.

4.2.1.1: An inventory of the entity's trusted keys and certificates used to protect PAN during transmission is maintained

4.2.1.1: PAN is protected with strong cryptography during transmission.

5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.

6.3.3: All system components are protected from known vulnerabilities by installing applicable security patches/updates

6.3.3: Security vulnerabilities are identified and addressed.

6.4.1: Public-facing web applications are protected against attacks.

6.4.2: For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks

6.4.2: Public-facing web applications are protected against attacks.

6.5.6: Test data and test accounts are removed from system components before the system goes into production

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

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

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

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

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

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

7.2.6: 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).

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

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

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

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

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

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

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

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

8.2.8: If a user session has been idle for more than 15 minutes, the user is required to re-authenticate to re-activate the terminal or session

8.2.8: 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.2: Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components

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

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

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

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

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

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

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

8.3.11: Where authentication factors such as physical or logical security tokens, smart cards, or certificates

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

PCI DSS Compliant Terraform Modules
Enforced Before `terraform apply`