Fintech Starter Kit: PCI DSS v4.0 + SOC 2

For payment platforms, neobanks, 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.

Module Inventory

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 (required for PCI DSS Req. 10.5.1, which mandates 12 months of audit log retention with 3 months immediately available).

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 message names the specific control and the module that triggered it.

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

Out of CDE scope: CloudFront edge nodes (AWS-managed infrastructure), SQS (application queuing for non-PAN data), CloudWatch log group (aggregated logs only)

The modules in CDE scope have KMS CMK encryption enforced at terraform plan time. 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 CMK 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 audit trail (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

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