Tokenized Payment Data in a Multi-Region SaaS Platform
A multi-tenant SaaS provider processes payments for EU retailers. The CRM stores customer names, emails, partial addresses, and payment tokens; the card-number vault is a separate, PCI-scoped service that returns a token and never the card number. For analytics, the entire CRM database is replicated nightly from eu-central-1 to us-east-1 and loaded into a shared warehouse where 40 analysts hold SELECT on raw tables and 3 hold export rights. Encryption at rest uses provider-managed keys throughout. The DPO must confirm a contractual commitment that "cardholder data never leaves the EU." Nine days passed before anyone noticed a contractor exporting 1.2 million rows to a personal drive.
1. Does the architecture satisfy the "cardholder data never leaves the EU" commitment, and where should the DPO focus instead?
Read the worked answer
Start by classifying the assets rather than the sentence. If the token is non-invertible without the vault and the vault never leaves the region, the card numbers themselves do not cross the border, so the commitment is technically met for cardholder data.
But that is the wrong analysis to stop at:
- The commitment is mis-scoped. What actually moved was identifiable personal data - names, emails, partial addresses - which is in scope for cross-border transfer rules regardless of tokenization. A tokenized dataset of 1.2M rows is still personal data.
- Tokenization is a scoping tool, not a control. It only reduces scope if the CRM genuinely cannot re-derive the PAN. If the vault is queryable from the analytics plane, the token is effectively a pointer and the PCI scope extends to the warehouse.
- Provider-managed keys shift the boundary. The firm cannot demonstrate that a compulsion order served on the provider in us-east-1 fails to reach the replicated data.
The DPO should renegotiate the wording to reflect the real data flow, produce a data-flow map for the analytics pipeline, and put a transfer mechanism in place. Answering "yes, compliant" on the current wording and stopping is the failure mode.
2. With 40 analysts able to query raw tables and 3 able to export, which controls would you prioritise to reduce exfiltration risk?
Read the worked answer
Rank by what actually failed: an authorised user exported 1.2M rows and it took nine days to notice. That is primarily a detection failure, secondarily an entitlement breadth failure.
Priority order:
- Detect volume anomalies in minutes. Baseline per-analyst row volumes and outbound bytes; alert on deviations and on bulk-export API calls. Cheapest, fastest payoff, and it attacks the nine-day dwell.
- Shrink the export population. Move raw-table SELECT from 40 to a small approved set; give the rest governed, row- and column-limited views or aggregated datasets. Export rights should be just-in-time with an approval record and session recording rather than a standing grant.
- Make exports attributable and constrained. Egress via a proxy that blocks personal-cloud destinations, watermarking, and row-count ceilings per job.
- Reduce the raw data available at all. Deterministic pseudonyms or pre-aggregated marts mean the analyst joins on a surrogate key and never sees an email address.
Perimeter controls alone (blocking personal cloud drives) are weak over web egress and should be treated as defence in depth, not the answer.
3. The analytics team requests a full copy of raw PII in the warehouse so joins are simpler. How do you respond?
Read the worked answer
Treat it as a trade, not a refusal, and force the trade to be explicit.
The request buys convenience at the cost of duplicating the most sensitive dataset into an environment with 40 readers and weaker change control. State that plainly, then offer alternatives in order of preference:
- Join on a surrogate. Keep the identity mapping in a small, tightly controlled mapping table or in the vault-adjacent service; the warehouse holds pseudonyms. Most joins - cohort, revenue, churn - do not need the actual email.
- Restricted-enclave analysis. If a join genuinely needs identifiers, run it in a clean-room style environment with no export path, output only aggregates, and log sessions.
- Field-level minimization. Copy only the columns the use case needs, with the rest derived at source.
If the team still wants the raw copy, the decision should be recorded with an owner, an expiry date, and the compensating controls above. The judgement being tested is refusing to let "it is easier" silently override the data-classification decision that already exists.