Fintech Starter Kit: PCI DSS v4.0

For payment platforms, neobanks, buy-now-pay-later (BNPL) providers, and any fintech company approaching PCI DSS certification. The architecture decisions that are hardest to fix later (CDE network segmentation, RDS encryption at creation, tokenization scope) are built in from the start.

GitHub: compliancetf/starter-kit-fintech-pcidss

Registry: pcidss.compliance.tf

Resources deployed: approximately 130

Architecture

The architecture has two distinct layers. The public edge (CloudFront + WAF + ALB) handles request routing and protocol enforcement. The CDE layer (EKS, Lambda, EC2, RDS Aurora, DynamoDB, ElastiCache) is fully private, with no public routes to any data store.

Quick Start

Prerequisites: Terraform >= 1.3, AWS credentials, a compliance.tf account, a Route 53 hosted zone, and an S3 replication IAM role + destination bucket (a kit prerequisite supporting audit-log durability; PCI DSS Req. 10.5.1 itself mandates 12 months of log retention with the most recent 3 months immediately available). See Create the replication prerequisites if you do not have those yet.

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

cp terraform.tfvars.example terraform.tfvars
# Edit terraform.tfvars: set project_name, domain_name, route53_zone_id,
# availability_zones, s3_replication_role_arn, s3_replication_destination_bucket_arn

terraform login pcidss.compliance.tf

terraform init
terraform plan
terraform apply

terraform plan fails if any PCI DSS control is violated. The error names the specific control and the module that triggered it. Fix the issue and re-run.

Module Inventory

CDE Scoping

Reducing Cardholder Data Environment (CDE) scope reduces QSA audit hours and the total assessment cost.

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 enforced at terraform plan time (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.

PCI DSS v4.0 Control Coverage

What compliance.tf Covers vs. What You Own

What this kit handles

• KMS encryption at rest for all CDE data stores (Req. 3.5.1)
• TLS 1.2+ at both ALB and CloudFront, enforced by the registry at plan time
• WAF with AWS managed rules: OWASP Top 10, known bad inputs, IP reputation (Req. 6.4.1)
• CDE network isolation; databases and caches have no public routes (Req. 1.3)
• IMDSv2 on all EC2 instances, IMDSv1 disabled (Req. 2.2)
• IAM authentication required for RDS, DynamoDB, and OpenSearch
• VPC flow logs, ALB access logs, EKS audit logs, CloudWatch log groups (Req. 10.2, 10.3)
• Deletion protection on RDS and ALB in environment = "prod"

What you own

• 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

Common Customizations

Disable a specific control

If a control does not apply to your use case, disable it with a query parameter on the module source. Query parameters require the HTTPS URL format (the Registry format does not support them):

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 configure unless something in your account consumes those events. Do not use this to switch off an encryption, public-access, or logging control on a module in CDE scope — your QSA will ask why the control is absent, and the answer has to be a scoping decision rather than a disabled check.

Control identifiers are listed in the controls catalog; see Customize modules for the full enable/disable interface.

QSA Pre-Verification Checklist

When your QSA asks about infrastructure controls, use this to locate the evidence:

Cost Estimate

Next Steps

• PCI DSS v4.0 Framework Reference: full control list per requirement
• Audit Evidence Guide: how to prepare infrastructure evidence for QSA review
• Brownfield Migration Kit: if you have existing Terraform to migrate rather than starting fresh
• Version Compatibility Matrix: supported module versions