Fintech - PCI DSS v4.0

For a payment platform, neobank, buy-now-pay-later provider or other fintech preparing for a PCI DSS v4.0 assessment. The kit deploys from the pcidss.compliance.tf registry host and builds in the decisions that are hardest to change later: cardholder data environment (CDE) segmentation, RDS encryption at creation and a private data layer. When you finish, the stack is applied and every PCI DSS v4.0 control its modules enforce has passed terraform plan.

Repository: compliancetf/starter-kit-fintech-pcidss · About 130 resources

Before you start

• The shared prerequisites on Compliance starter kits: an account whose plan includes PCI DSS v4.0, Terraform at a version every module accepts, AWS credentials, a Route 53 hosted zone, the replication role and destination bucket, and account-level CloudTrail. PCI DSS Req. 10.2 expects the CloudTrail trail alongside the resource logs this kit configures.
• Leave RDS encryption on. storage_encrypted = true has to be set when the database is created; AWS cannot encrypt an existing instance without a snapshot and restore to a new one. The kit enforces encryption by default.
• Decide how you will handle MFA delete before the first apply. The kit requests MFA delete on the data and logs buckets, and s3_bucket_mfa_delete_enabled enforces it, but AWS accepts that change only from the root user with an MFA code, and does not allow lifecycle rules on a bucket with MFA delete, while the logs bucket ships a 365-day lifecycle. The usual path: turn the control off for the rollout, keep the lifecycle, and if your QSA requires MFA delete, have the root user enable it on a bucket without lifecycle rules. Do not run the whole apply as root. Turning the control off means switching the s3_bucket_data and s3_bucket_logs sources in main.tf to the HTTPS form with ?disable=s3_bucket_mfa_delete_enabled (see Turn off a control) and adding a .netrc entry for pcidss.compliance.tf, because terraform login does not cover HTTPS sources; see Registry endpoints.

Deploy

git clone https://github.com/compliancetf/starter-kit-fintech-pcidss.git
cd starter-kit-fintech-pcidss

cp terraform.tfvars.example terraform.tfvars
# Set project_name, domain_name, route53_zone_id, availability_zones,
# s3_replication_role_arn and s3_replication_destination_bucket_arn

terraform login pcidss.compliance.tf

terraform init
terraform plan
terraform apply

If a value in terraform.tfvars violates a PCI DSS v4.0 control, terraform plan fails. The error names the control and the module. Fix the value and plan again.

What it deploys

Two layers. The public edge (CloudFront, WAF and ALB) routes requests and enforces protocols. The CDE layer (EKS, Lambda, EC2, Aurora PostgreSQL, DynamoDB and ElastiCache) is private, with no public route to any data store.

CloudFront accepts certificates only from us-east-1, wherever your other resources are, so the kit provisions two ACM certificates: a regional one for the ALB and a global one for CloudFront, through a provider alias. Both validate against the same Route 53 zone.

Control coverage

Settings a module enforces as a control fail the plan if you change them. The rest are kit defaults you can change. The PCI DSS v4.0 framework page lists the controls modules enforce. It also lists the mapped-only controls your team handles.

What you own

The kit configures the infrastructure settings above. These stay with you:

• Tokenization and PAN handling in application code (compliance.tf does not tokenize)
• Key rotation procedures and key administrator access policies
• User access reviews and role assignments
• Change management approvals and evidence collection
• Annual penetration testing (PCI DSS Req. 11.4 requires both internal and external testing at least once per 12 months)
• QSA engagement and Report on Compliance (ROC) preparation
• Cardholder data discovery and formal CDE scope documentation

CDE scoping

A smaller cardholder data environment means fewer QSA hours and a cheaper assessment.

In CDE scope: VPC private subnets, EKS, Lambda, EC2, RDS Aurora, DynamoDB, ElastiCache, S3 data bucket, OpenSearch

Typically out of CDE scope: SQS (application queuing for non-PAN data) and the CloudWatch log group (aggregated logs only). CloudFront is out of scope only when it serves static assets — a distribution that transmits cardholder data is in scope (covered under AWS's PCI attestation for the AWS-managed portion). Confirm scoping decisions with your QSA.

The modules in CDE scope have KMS encryption at rest, checked at terraform plan (the kit's customer-managed key is wired to EKS, Lambda, and OpenSearch; other services use their respective AWS encryption defaults unless you pass key ARNs). The out-of-scope modules use standard server-side encryption.

QSA evidence

When your QSA asks about infrastructure controls, this is where the evidence is:

Customize

Turn off a control

Use the HTTPS source with ?disable=:

module "s3_bucket_data" {
  source = "https://pcidss.compliance.tf/terraform-aws-modules/s3-bucket/aws?version=5.0.0&disable=s3_bucket_event_notifications_enabled"
  # ...
}

That example turns off the S3 event notification control, which has nothing to do unless something in your account consumes those events. Do not turn off an encryption, public-access or logging control on a module in CDE scope: your QSA will ask why it is absent, and the answer has to be a scoping decision, not a disabled check. Only a control the module enforces can be turned off; Turn controls on and off explains the limits and how to record the reason.

Adjust sizes or remove a module

Instance sizes and counts are variables; override them in terraform.tfvars, with the names in the repository's variables.tf. To drop a module the application does not use, delete its block from main.tf and its outputs from outputs.tf, then check that no other module references it.

Cost

The total is the sum of the rows above. The table has no rows for the two WAF web ACLs, DynamoDB, KMS or CloudWatch Logs, so add those. Usage charges come on top: data transfer, NAT gateway data processing, log ingestion, and KMS and WAF requests. Actual costs depend on usage, data transfer and region. Infracost estimates them from your own terraform plan.

Next steps

• Audit evidence
• PCI DSS v4.0 framework page
• Turn controls on and off
• Migration kit