Payment workloads do not get to treat compliance as a phase. The landing zone they run on either makes PCI-DSS a property of the platform or it makes every release a fire drill. This is the foundation we build so it is the former.
The challenge
A payments platform - card acquiring, financial-data services, a tokenization proxy - lives or dies on trust, and that trust is regulated. Cardholder data brings PCI-DSS into scope from the first line of infrastructure, not as a retrofit before an assessment. The stakes are concrete: data residency obligations, network segmentation that holds up under scrutiny, least-privilege access everywhere, and auditors who expect the infrastructure to prove itself continuously rather than on the day of the audit.
What makes PCI-DSS on cloud genuinely hard is that the default cloud account is the opposite of what an assessor wants. Out of the box you get one shared blast radius, ambient credentials, flat networks, and scope that creeps until “everything” is in scope and nothing is cheaply auditable. The temptation is to draw PCI boundaries with carefully maintained firewall rules inside a single shared network - which works right up until someone changes a rule, and then your audit story is only as good as your last code review. The client here was building greenfield: a chance to get the foundation right, but also the full responsibility of authoring every control from zero.
Our approach
The reframe is that PCI scope should be drawn at the account boundary, not enforced as a rule inside a network. Everything else follows from that decision.
Isolation from the org structure
We start with the AWS Organization, not the application. The estate is split into focused account categories - core accounts for SSO and audit, shared services for the container registry and CI trust, and separate workload accounts per environment - so the cardholder-data workload lives in its own account, isolated from non-sensitive workloads and from shared tooling. When PCI scope is an account boundary, audit, network and IAM isolation come from the platform itself instead of from rules you have to keep correct by hand. The tradeoff is more accounts to provision, which is exactly why the whole estate is codified - so a new account inherits the controls instead of being assembled manually.
Identity over static keys
IAM Identity Center with permission sets gives engineers federated, least-privilege access in place of long-lived IAM users. There are no human users to offboard, no access keys to rotate, and the access model is the same shape an assessor wants to see. For the delivery path, the principle holds: short-lived, assumed credentials instead of anything stored. Static keys in a payments pipeline are an avoidable liability, and they are precisely the class of risk both auditors and attackers care about.
Residency and reproducibility encoded in code
Where residency is a regulatory requirement, we pin it in the infrastructure - every account and every byte of state in a single region - so it is a property of the platform, not a promise in a policy doc. And because the entire foundation is Terraform in version control, the compliant baseline is reproducible: environments inherit controls rather than drifting away from them, and the audit trail is the git history.
Under the hood
The estate is split across focused Terraform repositories, each with its own clean blast radius, with remote state in S3 and DynamoDB locking. The mechanics:
- A landing-zone repo provisions the multi-account AWS Organization and IAM Identity Center SSO.
- A shared-networking repo stands up a Transit Gateway as the hub wiring workload accounts to shared services, plus AWS Client VPN for private, identity-gated engineer access - environments are never exposed to the public internet.
- A shared-services repo holds one hardened ECR registry and the OIDC trust; container images flow from there out to each workload.
- Per-workload infra repos carry each environment separately, with KMS managing encryption keys throughout.
- GitHub Actions authenticates through OIDC, assuming a role via a short-lived token; pull-request workflows run plan and policy checks, merges trigger apply, with regional and global resources targeted by separate scoped workflows.
Alongside the foundation we author a concrete PCI-DSS hardening playbook - segmentation, WAF, database security, secrets management, monitoring, disaster recovery, container security and security testing - so the controls are written down and actionable rather than tribal knowledge.
The outcome
Compliance stops being a fire drill and becomes a property of the platform: isolation from the org structure, least-privilege by default, residency encoded in infrastructure, and a clean audit trail for every change. Our team has taken several payments platforms onto this pattern, from a card-acquiring platform to a payment service provider’s tokenization workloads - new environments land on a governed, codified baseline instead of inheriting drift.
Key takeaways
- Make PCI scope an account boundary, not a firewall rule. Isolation from the org structure is easier to build, reason about and evidence than rules inside a shared network.
- Build the landing zone before the application. Shipping onto a governed, codified foundation is far cheaper than retrofitting compliance later.
- Region-pin for residency. When residency is a regulatory requirement, encode it in the infrastructure rather than relying on process.
- Use OIDC for CI to cloud. Short-lived assumed credentials remove an entire class of credential-leak risk from the deployment path.
- Write the controls down. A documented PCI playbook turns a secure baseline into something a team can operate and an auditor can follow.