Frequently Asked Questions
Do I need to comply with both PCI DSS and UK GDPR?
Yes — if your SME accepts card payments and processes or stores personal data of UK/EU residents, both regimes apply. PCI DSS governs the security of cardholder data for payment card schemes, while UK GDPR governs personal data privacy and lawful processing. Practical steps: map where cardholder and personal data flow, avoid storing card data where possible (use tokenization), maintain PCI compliance (SAQ or QSA as needed), and keep GDPR records (RoPA), lawful-basis documentation, and appropriate technical/organizational measures.
Can PCI DSS compliance be used as proof of GDPR compliance?
PCI DSS can help demonstrate technical and organizational measures required by GDPR (for example, encryption, access controls, logging), but it is not sufficient by itself. GDPR also requires lawful basis, transparency (privacy notices), data subject rights, data protection impact assessments (DPIAs) for high-risk processing, and data processing agreements. For SMEs: treat PCI controls as part of your GDPR security evidence, and separately document GDPR-specific obligations (consents, DPIAs, RoPA, retention schedules).
What should my SME do about breach notification if card data and personal data are involved?
Follow both regimes: under UK GDPR you must notify the ICO within 72 hours of becoming aware of a personal data breach unless it’s unlikely to result in risk to individuals, and you must inform affected individuals when there’s high risk. For PCI incidents, notify your acquiring bank and relevant card brands immediately and follow their incident response requirements. Practical SME checklist: activate an incident response plan, contain the breach, preserve logs, notify your acquirer and the ICO within legal timeframes, and prepare communications for customers.
How long can I retain transaction and cardholder data under GDPR and PCI?
Keep data only as long as necessary for the purposes you documented (data minimization principle). PCI DSS forbids storage of sensitive authentication data after authorization (e.g., full magnetic stripe, CVV) and limits retained cardholder data to what’s needed (card number, expiry) with protections (encryption/formatted storage). For SMEs: define retention periods in your retention policy (e.g., invoices for accounting, statutory periods), justify each period in your RoPA, securely delete or tokenise card data when no longer required, and document business need and legal basis for retention.
| Control area |
PCI DSS |
UK GDPR |
Overlap & SME action |
| Encryption & data-at-rest protection |
Requires strong cryptography for stored cardholder data and transmission |
Requires appropriate technical measures (encryption advised for personal data where risks exist) |
Use PCI-approved encryption to satisfy both; ensure key management, document encryption decisions in DPIA/RoPA |
| Access control & logging |
Strict access controls (need-to-know), unique IDs, logging of admin access |
Data minimization and integrity; logs help demonstrate accountability and detect breaches |
Implement role-based access, multi-factor auth, retain logs for investigations and ICO evidence; review access regularly |
| Data retention & deletion |
Prohibits storing sensitive authentication data post-authorization; minimizes stored card data |
Requires retention limitation and lawful basis for processing; data subject rights (erasure) |
Create retention schedule mapping PCI and legal accounting needs, tokenise instead of storing PAN, implement secure deletion procedures |
| Breach response & notification |
Requires incident response plan, notify acquirer/card brands per their rules |
Notify ICO within 72 hours; inform affected individuals if high risk |
Maintain a unified incident response plan that covers immediate PCI reporting to acquirers and GDPR notification obligations to ICO/customers |