Every payment is also a stream of personal information — and POPIA, GDPR and PCI DSS all reach for it from different angles. They overlap but do not align: PCI tells you to protect the card number, POPIA and GDPR tell you why you may hold it at all, for how long, and what to do when it leaks. Here is where each one bites payments.
PCI says "protect the PAN." POPIA and GDPR say "justify holding it, minimise it, time-limit it, and tell the regulator when it leaks." You need all three answers.
A payment generates personal data: names, card numbers, account details, device and location signals, transaction histories. Three regimes govern it from different angles, and payments teams must satisfy all of the applicable ones at once.
PCI DSS is a security standard — it tells you how to protect cardholder data, but is silent on whether you should have collected it. POPIA (SA’s Protection of Personal Information Act) and GDPR (EU, with the UK GDPR mirror) are data-protection laws — they govern the lawful basis to process, purpose limitation, minimisation, retention, data-subject rights, breach notification and cross-border transfer. They answer why, how long, and what if it leaks.
They overlap but never fully align. PCI compliance does not make you POPIA/GDPR compliant, and vice versa. A card number is both PCI account data and personal information — so a card-data breach is simultaneously a PCI incident and a statutory breach-notification event.
The principle that bites payments hardest is minimisation: the cheapest, most defensible card data is the data you never stored. It is also the throughline to PCI scope — less stored data, smaller CDE, lower breach exposure, all at once.
| Principle | POPIA term | GDPR term | Payments impact |
|---|---|---|---|
| Lawful basis | Justification / consent | Lawful basis (Art. 6) | You need a basis to process — usually contract necessity for the payment itself; consent for marketing/secondary use. |
| Purpose limitation | Purpose specification | Purpose limitation | Card data collected to take a payment cannot be silently repurposed (e.g. profiling) without basis. |
| Minimisation | Minimality | Data minimisation | Collect and retain only what the payment/obligation needs — the strongest argument against storing full PANs. |
| Retention limits | Retention & restriction | Storage limitation | Delete when the purpose ends — in tension with AML’s 5-year retention duty (resolve by ring-fencing). |
| Security | Security safeguards | Integrity & confidentiality | Where PCI DSS does most of the heavy lifting for card data. |
| Data-subject rights | Access, correction, deletion | Access, erasure, portability | Customers can request their data — but legal-retention duties (AML) can override erasure. |
Show first-6 / last-4 at most by default. The familiar "last 4" on receipts and screens is the PCI display rule and a minimisation good-practice at once.
Storing only a truncated PAN (e.g. last 4) takes it out of "render unreadable" obligations — you simply do not hold the sensitive part.
Replace the PAN with a token. The token is not (by itself) personal/account data, slashing both PCI scope and data-protection exposure. The single best lever across all three regimes.
Where you must hold the PAN, strong encryption + key management (PCI) also helps satisfy the security principle under POPIA/GDPR.
The clearest intersection is the Primary Account Number (PAN). PCI DSS requires the PAN to be unreadable wherever stored and masked when displayed — the well-known rule that you may show at most the first six and last four digits (BIN + last 4) to those without a business need to see more. POPIA/GDPR minimisation pushes the same direction from the other side: do not display or retain more than you need.
POPIA/GDPR say delete when the purpose ends; AML/FIC Act says keep CDD and transaction records (commonly 5 years after the relationship ends). Resolve it by retaining the AML-required minimum under a documented legal basis, ring-fenced from operational use — not by keeping everything forever.
On reasonable grounds to believe personal information was accessed by an unauthorised person, you must notify the Information Regulator and affected data subjects "as soon as reasonably possible." Since 1 April 2025, breach notifications must go through the Regulator’s eServices portal — email submissions are no longer accepted.
GDPR requires notification to the supervisory authority within 72 hours of becoming aware of a breach (where risk to individuals exists), and to data subjects without undue delay where high-risk. A card-data breach almost always qualifies.
Routing payment/personal data offshore (cloud regions, processors, correspondent chains) is restricted. POPIA section 72 needs adequacy, consent, contract necessity, or BCR-style safeguards; GDPR Chapter V needs an adequacy decision or SCCs/BCRs. Your cloud region choice is a data-protection decision, not just an architecture one.
A PCI-clean shop can still breach POPIA/GDPR — e.g. over-retaining data, no lawful basis for secondary use, or ignoring a data-subject access request. Different questions, different regulators, different penalties.
The efficient path treats data protection and PCI as one programme with shared controls, then layers the law-specific duties (rights, notification, transfer) on top. Do not run them as silos — the overlap is where the savings are.
The data you never collect or never store cannot breach, cannot be over-retained, and is out of PCI scope. Tokenization + truncation + redirects is the single highest-leverage move across PCI, POPIA and GDPR simultaneously.
You cannot honour retention, rights requests, or transfer rules over data you have not mapped. Inventory where payment/personal data lives — especially cloud regions and processors abroad.
Document which data you keep for AML (and for how long), ring-fenced from operational use, vs what you delete on purpose-end. Pick one defensible rule per data class; do not default to "keep everything."
POPIA → Information Regulator eServices portal (since 1 Apr 2025) + data subjects; GDPR → supervisory authority within 72 hours. A card-data breach triggers both PCI forensics and statutory notification — rehearse the combined path.
You likely face POPIA and GDPR at once. Build to the stricter requirement per topic (often GDPR on rights/transfer; POPIA on local notification mechanics) rather than maintaining two divergent programmes.
POPIA carries administrative fines up to R10 million and potential imprisonment; GDPR up to €20m or 4% of global turnover. Add PCI penalties via the acquirer and the breach’s own costs — a single card-data incident can trigger all three at once.