PCI DSS vs GDPR: Where GDPR and PCI Compliance Meet

GDPR and PCI compliance are two separate obligations that meet at the same data. PCI DSS is a card security standard you agree to in your merchant agreement; UK GDPR is the law on personal data, enforced by the Information Commissioner’s Office (ICO). Card data about your customers is personal data, so both apply to it at once. Treat PCI DSS as the detailed rulebook for card data and as strong evidence for the UK GDPR Article 32 security duty, then cover the privacy duties it leaves out.

What is the difference between PCI DSS and GDPR?

PCI DSS protects one type of data, payment card data, with prescriptive, testable controls. UK GDPR protects all personal data with principles and a duty to take “appropriate” measures for the risk. One is enforced by contract, the other by a regulator.

UK GDPR fines have two tiers: Article 32 security failures go up to £8.7 million or 2% of worldwide annual turnover, whichever is higher, while breaches of the principles, including integrity and confidentiality (Article 5(1)(f)), reach the higher tier. The PCI SSC sets no fines; our guide to the PCI non-compliance fee explains what acquirers charge.

Does PCI compliance mean GDPR compliance?

No. A clean Attestation of Compliance shows your card data is well protected. It says nothing about the rest of your personal data, or about privacy, and the ICO’s security guidance says plainly that PCI DSS compliance is not necessarily the same as meeting the UK GDPR security principle. UK GDPR duties that PCI DSS does not cover:

• A lawful basis for each type of processing (Article 6).
• Privacy notices that tell people what you collect and why (Articles 13 and 14).
• Individuals’ rights, including access, correction and erasure (Articles 15 to 22).
• Records of processing activities (Article 30).
• Data protection impact assessments for high-risk processing (Article 35).
• Rules on transfers of personal data outside the UK (Chapter V).
• Security for personal data outside the CDE: HR files, customer emails, marketing lists, CCTV.

The reverse is also true: GDPR never tells you to run quarterly scans by an Approved Scanning Vendor or to monitor payment page scripts. Our PCI compliance UK guide covers what your acquirer will expect.

Which PCI DSS controls evidence UK GDPR Article 32?

Most of them, at least for card data. Article 32 asks for security “appropriate to the risk” and lists four examples; PCI DSS gives you tested controls for each. The ICO’s own guide to data security says that if you process card data you must comply with PCI DSS, and that after a breach it will consider whether the measures PCI DSS requires were in place.

Two more links: Requirement 3.2.1 (a retention and disposal policy for card data, with a check at least every three months that anything past its retention period has been securely deleted) is storage limitation under Article 5(1)(e) in practice, and Requirement 12.8 on service providers lines up with Article 28 processor contracts. For the detail behind the first row, our guide to PCI DSS encryption requirements explains how stored card numbers must be protected, including why disk encryption alone no longer counts.

Where do PCI DSS and GDPR pull in different directions?

Rarely, but there are four places where a PCI control needs a GDPR answer:

• Log retention. Requirement 10.5.1 asks you to keep audit logs for at least 12 months, with the latest three months immediately available. Logs hold personal data such as user IDs and IP addresses, so record PCI DSS as the reason in your retention schedule.
• Staff monitoring. PCI DSS requires unique user IDs (Requirement 8.2.1) and audit logs that tie access to card data and administrator actions to individual users (Requirement 10.2.1). Tell staff in your employee privacy notice that payment systems are logged and why.
• Pre-employment screening. Requirement 12.7.1 asks you to screen people before they are given access to the CDE, “within the constraints of local laws”. If your screening includes criminal record checks, that is criminal offence data (UK GDPR Article 10), which needs a condition under the Data Protection Act 2018.
• Call recordings. PCI DSS forbids keeping the card security code after authorisation, including in recordings. UK GDPR asks you to justify why you record at all and for how long. Fixing the first (pausing or masking) usually helps with the second.

What do you have to do if card data is breached?

Two notification paths start at once: your acquirer under the merchant agreement, and the ICO under UK GDPR. PCI DSS Requirement 12.10.1 already says your incident response plan must cover notifying card brands and acquirers and an analysis of legal requirements for reporting compromises, which is where your ICO duty belongs.

Do I report a card breach to the ICO?

Usually, yes: stolen card data carries an obvious risk of fraud and financial loss. The 72 hours run from when you become aware of the breach, not from when your investigation ends, and Article 33(4) lets you send the details in phases if you do not have them all yet. If you decide a breach is not reportable, document why. Our incident response plan template is mapped to PCI DSS 12.10 and lists the other UK notification deadlines.

How do you build one GDPR and PCI compliance framework?

Build the PCI DSS controls once, record which UK GDPR duties each one supports, then add the privacy layer. That gives you one framework rather than two projects competing for the same people and evidence.

1. One data map. The data-flow diagrams PCI DSS Requirement 1.2.4 asks for can sit inside your Article 30 record of processing.
2. Minimise first. Hosted payment pages, tokenisation and not storing card numbers at all shrink your PCI scope and your GDPR risk together. Our guide to PCI tokenisation explains how, and our free PCI compliance check shows which SAQ your current set-up points to.
3. One risk method. Use the same risk register for PCI DSS targeted risk analyses (12.3.1) and your GDPR risk assessments.
4. One incident plan with both notification routes and named owners.
5. One supplier process covering PCI DSS 12.8 checks and Article 28 contract terms.
6. One testing calendar. Quarterly scans and annual penetration tests support Article 32(1)(d) as well as Requirement 11.
7. One evidence library your QSA, data protection lead and auditors can all draw on.

The same approach extends to ISO 27001 (see PCI DSS vs ISO 27001) and to the baseline certificate many buyers ask for (see Cyber Essentials and GDPR). For privacy management itself, ISO 27701 adds controller and processor controls that map to UK GDPR.

Why Sovereign Secure

Sovereign Secure Ltd (Companies House 08334453, incorporated 2012) is headquartered in Accrington, Lancashire. The PCI Security Standards Council has approved us as a Qualified Security Assessor (QSA) company, a Qualified PIN Assessor (QPA) and a Card Production Security Assessor (CPSA), and we are a member of its Global Executive Assessor Roundtable (GEAR) for 2026 to 2028.

We are ISO 27001 certified and ICO registered. We assess PCI DSS and carry out penetration testing, and the same reports and evidence can support your UK GDPR accountability records. We do not give legal advice. The PCI DSS standard is free from the PCI SSC document library.

Next step

If you want one set of controls to satisfy your acquirer and stand up to the ICO, start with a scoped PCI compliance audit or a gap review. Contact our PCI team or call +44 161 523 5276 for a fixed quote.