compliance.tf
Sign inStart Free Trial

GDPR Compliant Terraform Modules
Enforced Before terraform apply

GDPR Article 32 requires technical measures to protect personal data. These modules enforce encryption at rest and in transit, access controls, and audit logging on every AWS resource before deployment.

If your application processes personal data of EU residents, GDPR applies regardless of where your company is based. Fines reach 4% of global annual turnover. US companies with European users are in scope.

105

Controls

3

Clauses

34

AWS Modules

Start Free TrialView All Controls

No credit card or AWS account needed to start.

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

IAM · CloudWatch Logs · CloudTrail · RDS · ELB · RedshiftSOC 2 Type II CertifiedAvailable on AWS Marketplace

Three Steps to GDPR 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.

1

Change One Line

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

Run Terraform Commands

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

Compliance Enforced

Art. 32 · Default Encryption
Art. 32 · KMS Encryption
Art. 32 · SSL Requests Only
Art. 32 · EBS Encryption
Art. 32 · RDS Encryption
Art. 30 · CloudTrail Logging
Art. 32 · CloudFront HTTPS
Art. 5(1)(f) · Public Access Blocked

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

Controls Enforced for GDPR

105 controls across 3 clauses and AWS services

Enforced (51)Detected (53)
  • CloudTrail S3 buckets should not be publicly accessible
  • CloudTrail trails should be enabled in all regions
  • CloudTrail trails should have at least one multi-region trail present in an account
  • CloudTrail multi region trails should be integrated with CloudWatch logs
  • CloudTrail S3 buckets should have access logging enabled
  • CloudTrail trails should have at least one enabled trail present in a region
  • CloudTrail trails should have at least one trail enabled in the AWS account
  • CloudTrail trails should be integrated with CloudWatch logs
  • CloudTrail trails should have logs encrypted using a customer managed KMS key
  • CloudTrail trails should have log file validation enabled
  • Config configuration recorders should not fail to deliver logs
  • AWS Config should be enabled in all regions
  • IAM password policies should have minimum length set to 14 or greater
  • IAM password policies should require at least one lowercase letter
  • IAM password policies should require at least one number
  • IAM password policies should require at least one symbol
  • IAM password policies should require at least one uppercase letter
  • IAM password policies should prevent password reuse
  • IAM password policies should have strong configurations with minimum length of 8 or greater
  • IAM password policies should have strong configurations
  • IAM inline policy should not have administrative privileges
  • IAM password policies should expire passwords within 90 days or less
  • IAM policies should not allow full administrative privileges
  • IAM policies should not allow full '*' administrative privileges
  • IAM policy should not have statements with admin access
  • IAM root user should have MFA enabled for console access
  • IAM root user hardware MFA should be enabled
  • IAM root user MFA should be enabled
  • IAM root user should not have access keys
  • IAM support roles should be created to manage incidents with AWS Support
  • IAM user access keys should be rotated at least every 90 days
  • IAM users with access keys unused for 45 days or greater should be disabled
  • IAM users with console access should have MFA enabled
  • IAM users with console access unused for 45 days or greater should be disabled
  • IAM user MFA should be enabled
  • IAM user should not have any inline or attached policies
  • IAM user credentials that have not been used in 90 days should be disabled
  • IAM administrator users should have MFA enabled
  • KMS CMK rotation should be enabled
  • CloudWatch log metric filters should be configured for S3 bucket policy changes
  • CloudWatch log metric filters should be configured for CloudTrail configuration changes
  • CloudWatch log metric filters should be configured for AWS Config configuration changes
  • CloudWatch log metric filters should be configured for AWS Management Console authentication failures
  • CloudWatch log metric filters should be configured for AWS Management Console sign-in without MFA
  • CloudWatch log metric filters should be configured for disabling or scheduled deletion of customer managed keys
  • CloudWatch log metric filters should be configured for IAM policy changes
  • CloudWatch log metric filters should be configured for changes to Network Access Control Lists (NACL)
  • CloudWatch log metric filters should be configured for changes to network gateways
  • CloudWatch log metric filters should be configured for usage of root account
  • CloudWatch log metric filters should be configured for route table changes
  • CloudWatch log metric filters should be configured for security group changes
  • CloudWatch log metric filters should be configured for unauthorized API calls
  • CloudWatch log metric filters should be configured for VPC changes
  • VPC flow logs should be enabled

Additional Controls

1 additional controls enforced for GDPR

Enforced (1)Detected (0)

View full control documentation with implementation details

View GDPR reference documentation

GDPR Scope: What We Handle vs. What You Own

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

compliance.tf Enforces for GDPR

  • Encryption at rest and in transit for all supported AWS services
  • Access controls and public access blocking
  • Audit logging and trail validation
  • IAM policies and key rotation enforcement
  • Upstream module updates (terraform-aws-modules kept in sync)
  • Exception management with audit trail

See which modules are covered

View GDPR reference documentation

Your Team Still Handles for GDPR

  • Data Protection Officer (DPO) appointment
  • Data Protection Impact Assessments (DPIAs)
  • Consent management and legal basis documentation
  • Data subject requests: access, rectification, erasure (Art. 15-22)
  • Breach notification to supervisory authorities (Art. 33-34)
  • Data processor agreements (Art. 28)
  • Privacy policies and records of processing (Art. 30 organizational)

compliance.tf handles Article 32 technical measures: encryption, access controls, audit logging. Organizational GDPR requirements like consent management, DPIAs, data subject rights, and breach notification are your team's responsibility.

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

GDPR 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 GDPR
  • Downloadable control mapping matrices for your auditor
evidence.json
{
  "framework": "GDPR",
  "clause": "Art. 32",
  "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 GDPR

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

DimensionIaC Scanning
Checkov / Trivy / Prowler		Compliance.tf
Prevents non-compliant configs before terraform applyNo (post-plan scan)Yes
Maps controls to framework clause IDsPartialYes
Produces auditor-accepted evidence (AWS-native)Scan reports onlyYes
Exception management with audit trailSuppression rulesYes
Same interface as terraform-aws-modulesN/AYes
Keeps pace with upstream module updatesN/AYes
Catches runtime drift / console changesYesNo
Covers non-Terraform resourcesYesNo
Internal engineering timeMediumLow

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 →

GDPR Compliance Questions

Which GDPR articles does this cover?

The controls map primarily to Article 32 (security of processing), which requires encryption, access controls, and the ability to restore data. Article 5(1)(f) (integrity and confidentiality principle) and Article 25 (data protection by design) also apply. These are the GDPR articles that translate directly to infrastructure configuration.

Does this make me GDPR compliant?

No. GDPR compliance requires organizational measures that no infrastructure tool can handle: appointing a DPO, conducting DPIAs, managing consent, responding to data subject requests, and notifying authorities of breaches within 72 hours. compliance.tf handles the Article 32 technical measures layer. You still need the rest.

We're a US company. Do we need GDPR modules?

If you process personal data of people in the EU, yes. GDPR applies based on whose data you handle, not where your company is located. A US SaaS product with European users is in scope.

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

Start Deploying GDPR-Compliant Infrastructure

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

Start Free TrialContact 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!