DC-001 Design scenario 2026-08-06

Design Case 1: Migrate the Payment API in 90 Days, Regulator Watching

A regional bank's payment API moves from on-premises to GCP in 90 days. The regulator wants evidence that cardholder data is segmented and that privileged access is time-bound and auditable. The team is three people. Every rejected alternative is on the page.

The scenario

A regional bank runs its customer-facing payment API on-premises. Leadership wants the workload on GCP within 90 days. The regulator requires evidence that cardholder data is segmented, and that privileged access to production is time-bound and auditable. The migration team is three people.

Scope

In: the payment API tier and its data path, the cardholder data environment boundary, the privileged access model for production, and evidence generation for both regulatory requirements.

Out: the core banking system, which stays on-premises. Database replatforming. Every other workload. A 90-day window that attempts more than this delivers nothing.

Constraints

Trust boundaries

  1. Customer device to internet. Nothing on the far side is controlled. Clients are assumed hostile.
  2. Internet to GCP edge. Inspection, rate limiting and DDoS absorption live here, at the provider edge and Cloud Armor, not at the API gateway.
  3. Edge to service tier. Authenticated, authorized, logged.
  4. Service tier to cardholder data environment. The compliance boundary. The design goal is to make this boundary defend itself by shrinking what sits behind it.
  5. The admin plane. Every human who can touch production is a trust boundary with a name on it. This one gets its own design, not a bullet point.

Assumptions

  1. The bank may not need to store PAN at all. If a payment service provider can tokenize at capture, the cardholder data environment shrinks toward zero. This is the highest-value question in the engagement and it gets verified in week one.
  2. A GCP organization with at least a minimal landing zone exists. If it does not, standing one up is week-one work rather than an afterthought. Every control below inherits its posture from that foundation.

Design commitments

1. Single managed ingress. A managed API gateway fronts the API, with Cloud Armor at the provider edge for DDoS and Layer 7 filtering.

Rejected: a self-managed gateway (Kong, Envoy on GCE or GKE). A three-person team cannot safely operate ingress infrastructure and execute a migration at the same time. The risk is not the build. It is the operate.

2. Tokenization at the payment service provider, before PAN reaches bank infrastructure. Payment fields are served directly from the PSP through hosted fields or a client SDK. The raw card number travels from the customer’s device over TLS straight into the PSP’s vault, the vault returns a token, and the client submits the token. Every bank-side system, gateway, service tier, database and log sees tokens only. De-tokenization for settlement happens inside the PSP’s vault, on the PSP’s compliance scope.

That answers the regulator’s first question by construction. With no PAN in the environment, the cardholder data environment collapses to the integration boundary, and the segmentation obligation is met by architecture rather than by compartmentalization alone.

DLP then moves to its correct job. It is not there to block exfiltration. It is there to prove the negative: continuous scanning for card-number patterns turns “no PAN exists in our systems” from an assertion into a monitored, logged, testable claim.

Rejected: running an in-house token vault. Full control and no provider dependency, at the cost of owning a regulated CDE with its own segmentation, monitoring and assessment scope. A three-person team cannot carry that in 90 days.

The tokenised payment data pathThe card number travels from the customer's device straight into the payment service provider's vault and never enters bank infrastructure. A token comes back to the client, and every bank-side component on GCP — Cloud Armor, the managed API gateway, the service tier, the store and its logs — sees only tokens. The cardholder data environment therefore sits inside the provider's compliance scope rather than the bank's.PSP COMPLIANCE SCOPE — THE CDEPSP hosted fieldsserved by the PSPPSP token vaultde-tokenises for settlementCustomer deviceassumed hostilePAN over TLStoken returned to the clientPAN never crosses this line into bank infrastructureBANK ON GCP — TOKENS ONLYCloud Armoredge, L7 filteringManaged API gatewaythe single ingressService tiertokens onlyStore and logstokens onlyDLP scans these continuously for card-number patterns. It proves the negative; it is not the blocker.tokenretained dependencyCore bankingon-premises, out of scopecard numbertoken
The whole argument is the horizontal line. The card number never crosses it, so the cardholder data environment sits inside the provider’s compliance scope and the bank’s segmentation obligation is met by the shape of the design rather than by compartmentalising a problem it chose to keep.

3. Zero standing privileged access, with elevation that expires on its own. Engineers hold read-only roles by default. Elevation runs through a tracked workflow: a request, a recorded approval from a second person, a time-boxed grant scoped by IAM Condition to the one resource in question, and every request, approval, grant and expiry written to an append-only ledger. Break-glass exists for real emergencies, needs two people, alarms on use, and gets reviewed the next morning.

One detail here is worth more than the rest of the design, because it is the part I got wrong first.

The reference build originally carried its own revocation function. I deleted it. Google’s Privileged Access Manager expires the grant on its own, which left a second revocation path whose only remaining justification was that it already existed. What replaced it is a read-only reconciliation job that sweeps for grants outliving their window and writes a flag to the ledger.

That job detects an overrun. It does not contain one. Nothing is revoked automatically, and that is a decision rather than a gap. Automated revocation is an action taken against a production access-control plane, and an action needs an alerting and rollback story before it runs unattended. So the claim I can defend to a regulator is “detected inside roughly one sweep,” not “contained in fifteen minutes.” Two different sentences, and only one of them is true.

What survives is the useful part: the audit log of the grant lifecycle is the regulator’s evidence. The control and the proof are the same artifact, which is the strongest available answer to “time-bound and auditable.”

The privileged access grant lifecycleAn engineer holding read-only access by default raises a request, a second person records an approval, and Privileged Access Manager creates a grant scoped by IAM Condition to one resource. PAM expires the grant on its own; the reference build's own revocation function was deleted rather than kept as a second path. A read-only reconciliation sweep runs on a schedule and writes a flag to the ledger when a grant outlives its window, so an overrun is detected inside roughly one sweep. It detects an overrun; it does not contain one. Every event lands in an append-only ledger, which is both the control record and the regulator's evidence.Engineerread-only by defaultRequesta tracked workflowApprovala second personPAM grantIAM Condition, one resourceExpiryPAM, on its ownevery event, written onceBreak-glasstwo people, alarms on usereviewed the next morningReconcile sweepread-only, on a scheduledetected inside one sweeprevoke_accessdeleted, not defendedPAM already owns expiryDetects an overrun. Does not contain one.a flag on the ledgerAppend-only ledgerRequest, approval, grant, expiry, and every overrun flag.The control and the regulator's evidence are the same artifact.
The struck-through box is the part worth defending in an interview. Two enforcement paths that can disagree is how you get an incident where each one assumes the other handled it, so the second path was deleted rather than kept for having already been written. What replaced it detects and does not contain, which is a narrower claim and a true one.

Rejected: bastion hosts with standing SSH access. Unauditable standing privilege, which fails the second regulatory requirement by design.

4. Continuous compliance evidence. Infrastructure changes pass policy-as-code evaluation in CI before merge, the pattern built in Compliance as Code : PCI DSS v4.0, SOC 2 and NIST 800-53 mappings, gated jobs, blocking on violation. Compliance posture becomes continuous and version-controlled instead of annual and screenshot-based.

The limit belongs in the design document rather than in a footnote discovered later. A policy engine reading Terraform plan output can enforce “you must declare a value.” It cannot enforce “that value is truthful,” because verifying that needs runtime knowledge the plan JSON does not contain. Anything in that gap needs a different control, not a weaker version of this one.

The risk statement

A failed segmentation assessment means failed audits, card-brand penalties, and a breach blast radius where one compromised credential becomes a reportable event. Realistically a seven-figure exposure, against controls whose incremental cost is a fraction of that.

The two decisions compound. Even a fully compromised admin credential lands in an environment holding no card numbers. Each control shrinks the other’s worst case, which is the argument for doing both rather than picking the cheaper one.

First steps

Week one: verify the PAN-storage assumption, stand up or validate the landing zone, put the on-premises connectivity question on the table, and open the PSP contract review.

Next: Case 2, approving an AI vendor for KYC . Method and grounding: Design Cases .