GDPR vs PCI DSS

How the GDPR and PCI DSS differ on scope, proof and enforcement

This table compares the GDPR and PCI DSS on who they bind, what data they cover, the proof each produces, who enforces them and what fines can follow. Read it as two different kinds of obligation: the GDPR is law for personal data, while PCI DSS is a payment brand rulebook for account data, so most merchants face both.

Why encryption alone does not take card data out of PCI scope

Where GDPR and PCI DSS work overlaps and where it does not

GDPR and PCI DSS both expect security of processing, logging, testing and tight supplier control, so one control set can serve both. The overlap ends where the GDPR adds duties PCI DSS does not address, and where evidence from one assessment does not automatically satisfy the other.

How breach notice and rights deadlines differ in practice

This sequence shows a readiness reviewer which GDPR clocks run in parallel during a personal data incident or rights request, and where PCI DSS hands the reporting path to the payment brands and the acquirer. It produces a dated record the team can test before a real event.

1. Establish the awareness point for each incident

   The first step is fixing the moment the controller becomes aware of a potential personal data breach, because the Article 33(1) clock for notifying the supervisory authority within 72 hours starts there. Assign a named owner, usually the privacy lead with security, to log the time of first awareness, the source of the report and the initial scope. The output is a timestamped incident record that a reviewer can check against the clock. Confirm internally how awareness is defined, since a readiness review will test whether staff escalate quickly enough to meet the deadline.

2. Assess whether the breach is notifiable

   Next, the privacy and security leads decide whether the breach is likely to result in a risk to individuals and therefore needs supervisory authority notice, and whether it requires notice to affected individuals under Article 34. Record the categories of data, the approximate volume of records and individuals, likely consequences and the containment steps taken. The output is a documented assessment, including reasons if notice is not made, which the reviewer should be able to read without the original responder present. Keep this assessment separate from any card brand reporting, which follows its own path.

3. Notify the supervisory authority within the window

   Where the assessment requires it, the controller submits notice to the competent supervisory authority within 72 hours of awareness under Article 33(1). If the notice cannot include every detail within that window, the controller provides information in phases and records the reasons for the delay. The owner is the controller's data protection lead, with legal review. The output is a copy of the submitted notice, the submission time and any follow-up correspondence, all stored with the incident record so the reviewer can match the timing to the awareness point.

4. Inform affected individuals where Article 34 applies

   If the breach is likely to result in a high risk to individuals, the controller communicates it to the affected people in clear language under Article 34. The communication should describe the likely consequences and the measures taken or proposed, and name a contact point. The owner is the privacy lead, with customer communications support. The output is the notice text, the distribution method and the list of recipients or the method used for a public notice. A readiness reviewer should confirm that the template exists before an incident, not that it is drafted during one.

5. Log and route data subject rights requests

   Rights requests arrive through channels that are often outside the security team, so the process must capture each request on receipt and assign it to a responder. The owner is the privacy operations lead. The output is a request register showing the receipt date, identity verification steps, the request type and the status. Confirm the internal calendar that tracks the Article 12(3) response period, which allows one month from receipt, extendable by two months in complex or numerous cases with notice to the individual. Reviewers will sample this register to test whether clocks are actually watched.

6. Meet the Article 14 information duty for third-party data

   When personal data were not collected from the individual, Article 14 requires the controller to provide the information listed in that article within one month, subject to the exceptions it sets out. The owner is the privacy lead working with the teams that acquire or buy data. The output is a register of third-party data sources, the notice content for each and the dates the notice was given. A readiness review should check that the sources feeding the register are complete, because data arriving from brokers or partners is the usual gap.

7. Map the PCI DSS reporting path separately

   PCI DSS does not set its own breach notice clock in the way the GDPR does. Incident response expectations come through the payment brands, the acquirer or processor contract and the QSA process during assessment. Confirm with your acquirer the brand-specific reporting path, the parties to notify, the required timelines and the forensic investigator requirements, and record the answers in the same incident runbook. The output is a written reporting matrix that shows which notices go to supervisory authorities, which go to individuals, and which go to card brands or acquirers, so one incident does not get reported on the wrong clock.

8. Test the combined sequence before it is needed

   Finally, run a tabletop exercise that starts with a single event affecting both card data and personal data, and walk it through each clock. The owner is the incident response lead with privacy and payments representatives. The output is a dated exercise report listing where each deadline was met, missed or unclear, and the corrective actions assigned. Repeat the test after material changes to systems, vendors or payment flows. This is the evidence that shows the sequence works in practice, and it is the document a reviewer will ask to see first.

Who assesses each framework and what the assessment produces

This table compares who checks each regime, what document or decision results, and how often the proof is refreshed. Read it to see which obligations produce a validation document that your acquirer or customers may ask for, and which produce nothing a third party can hand over.

What non-compliance costs under each framework

Which combination fits merchants, acquirers and service providers

Doing both in an order that shares evidence

The sequence below scopes card data and personal data once, makes shared encryption and pseudonymization decisions, and builds one evidence set that feeds both the PCI DSS assessment and GDPR accountability records.

1. Map cardholder data and personal data together

   Run one data discovery exercise that records where primary account numbers, sensitive authentication data and other personal data enter, move, are stored and leave your environment. The privacy team and the PCI assessment lead should own this jointly, with system owners confirming each flow. Define the cardholder data environment and the connected systems that could affect it, since PCI DSS scope extends beyond systems that hold card data. The step is done when one inventory lists each system, data category, purpose and flow, and both teams have signed off on it.

2. Test scope reduction before relying on it

   Review any encryption, tokenization or hashing design against the PCI SSC guidance before treating it as a scope reducer. Encrypting cardholder data with strong cryptography meets Requirement 3.5.1, but encryption alone does not take the data out of PCI DSS scope. Hashed PAN moved to a separate environment stops being cardholder data there, yet the systems that perform the hashing stay in scope. Record which systems remain in scope and why. The step is done when the scope decision is written down and the QSA has reviewed the approach.

3. Set encryption and pseudonymization decisions for both regimes

   Choose the cryptographic controls, key management arrangements and any pseudonymization design once, then check each choice against both sets of obligations. Article 32(1) of the GDPR names pseudonymisation and encryption among measures appropriate to the risk, alongside ongoing confidentiality, integrity, availability and resilience, and regular testing of effectiveness. PCI DSS sets its own requirements for cryptography and key management. Document each decision with the requirement it satisfies in each framework, so one design record serves both reviews. The step is done when the design record maps every control to the relevant GDPR and PCI DSS provision.

4. Align one incident response process to both clocks

   Build a single incident procedure that triages events touching card data, personal data or both. It should include the GDPR notification path to the supervisory authority within 72 hours of becoming aware of a notifiable breach (Article 33(1)), along with the separate payment brand and acquirer reporting steps that PCI DSS programs require. Assign decision owners, define evidence capture and test the procedure with a tabletop exercise. The step is done when the exercise has produced a timeline and each reporting path has a named owner. Confirm the payment brand and acquirer notification requirements with them directly.

5. Choose the defined or customized approach with the QSA

   PCI DSS v4.x lets an entity meet each requirement through the defined approach or, for entities with robust security and risk management, the customized approach, which meets a stated objective in a different way. The 51 future-dated requirements became effective on 31 March 2025, so they are no longer optional best practices. Decide which approach applies to each requirement and document the reasoning, then confirm the chosen approach with your QSA before testing begins. The step is done when the QSA has accepted the approach for each requirement in writing.

6. Build the shared evidence library

   Collect configuration exports, access reviews, logs, vulnerability results, policies and test results once, tagging each item with the PCI DSS requirement and the GDPR article it supports. Where a SOC 2 or SOC 3 report exists, the QSA may reuse that evidence after independently reviewing it, which can reduce duplicated work. The library should be controlled, dated and owned. The step is done when every evidence item has both tags and an owner, and the gaps list is reviewed by both teams.

7. Prepare the ROC or SAQ and the GDPR records

   Prepare the PCI DSS assessment on the official ROC or SAQ template, with the Attestation of Compliance issued through the assessor or your own process. Separately, maintain the GDPR records of processing and the security documentation the controller must be able to demonstrate. Cross-reference both from the shared library so each statement traces to one evidence item. Remember that a PCI AOC is not a GDPR certificate, and the GDPR requires no attestation. The step is done when both documents cite the same evidence set and the records of processing match the card data flows in the inventory.

Common questions before hiring outside help on GDPR and PCI DSS