A PCI-DSS platform for a buy-now-pay-later lender

A buy-now-pay-later lender needed to pass a PCI-DSS assessment and had roughly six months before the audit date. The product already worked. What did not exist was a way to prove to an assessor how card data was protected, who could reach it, and what had happened to it.

Scope first, architecture second

The single most useful decision was shrinking what was in scope. Card data touches three services. Everything else was moved so it never sees a PAN, which took the audit from an estate-wide exercise to a bounded one.

• Card-handling services in their own AWS account, own VPC, no shared subnets
• Tokenisation at the edge of that boundary, so downstream services store a token and nothing else
• Everything outside the boundary explicitly documented as out of scope, with the network controls that make that true

How it runs

• ECS Fargate for every service, in private subnets, reached only through an internal load balancer
• Aurora PostgreSQL multi-AZ with read replicas for the transaction lookup path
• CloudFront in front of the public API with AWS WAF rules and Shield Advanced for volumetric protection
• NAT gateways for egress, with egress restricted to an allowlist of payment network endpoints

Fargate was chosen partly for operations and partly for the audit. There is no host operating system, so there is no patch evidence to produce, no SSH access to justify, and no bastion to explain.

Keys

KMS with envelope encryption: a customer master key per data class, data keys generated per record, and annual rotation configured rather than promised. Key policies name the roles allowed to use each key, which is the answer to the question an assessor actually asks. Not "is it encrypted" but "who can decrypt it".

Evidence, not screenshots

Every control that could be expressed in Terraform is in Terraform, so the evidence for a control is a plan output rather than a person taking a screenshot on the day.

• CloudTrail to the logging account, with object lock so logs cannot be altered
• Config rules alerting on any security group opened to the internet
• Access reviewed from IAM Access Analyzer output, not from memory
• Quarterly segmentation testing run as a job, with results retained

Latency

The transaction API had to stay fast under the extra encryption work. Reads went to Aurora replicas, connection pooling stopped the per-request connection churn, and the two slowest queries were rewritten after reading their actual plans. The API settled under 50ms at the median for lookups.

Where it landed

• PCI-DSS assessment passed with zero critical findings
• Sub-50ms responses on the transaction lookup path
• Key rotation on a schedule rather than a calendar reminder
• Audit evidence gathered from tooling, which cut the next assessment's preparation time sharply

What was hard

Persuading everyone that reducing scope was worth two months of application work. It was. The alternative was auditing every service the company runs, every year, forever.

What we still do

Managed operations on the platform, quarterly segmentation testing, and we sit in the assessment meetings so the answers come from the people who built the thing.