Category: Regulations and Standards
General Data Protection Regulation
Also known as: GDPR, Regulation (EU) 2016/679, EU General Data Protection Regulation
Simply put
The General Data Protection Regulation (GDPR) is a European Union law that sets rules for how organizations protect the privacy and security of personal data about individuals. It applies to organizations both inside and outside the EU that handle such data, and it took effect on May 25, 2018.
Formal definition
The GDPR is Regulation (EU) 2016/679 of the European Parliament and of the Council on the protection of natural persons with regard to the processing of personal data and on the free movement of such data. It forms part of EU data protection legislation and establishes obligations governing how organizations within and outside the EU handle the personal data of individuals. The regulation was put into effect on 25 May 2018. Note that GDPR is a general data protection law and is distinct from payment-specific standards such as PCI DSS; where both apply, organizations should confirm their obligations against the current published text of each and applicable guidance rather than assuming one satisfies the other.
Why it matters
The GDPR establishes obligations for how organizations protect the privacy and security of personal data about individuals, and its reach extends beyond the EU to organizations outside the EU that handle such data. For payment security, compliance, and fraud teams, this matters because the personal data processed during payment flows, fraud investigations, and customer onboarding can fall within the scope of the GDPR when it relates to individuals in the EU. That makes the regulation a standing consideration for any organization whose transaction or risk-management activity touches EU personal data, regardless of where the organization itself is located.
It is important to distinguish the GDPR from payment-specific standards such as PCI DSS. The GDPR is a general data protection law governing personal data broadly; PCI DSS is a payment card security standard. Where both apply, satisfying one does not automatically satisfy the other. Cardholder data protected under PCI DSS may also constitute personal data under the GDPR, but the two frameworks impose distinct obligations, use different terminology, and are maintained by different bodies. Organizations should confirm their obligations against the current published text of each and applicable guidance rather than treating compliance with one as evidence of compliance with the other.
Because the GDPR took effect on 25 May 2018 and forms part of a broader body of EU data protection legislation, teams responsible for compliance mapping should treat it as one input among several that may govern how personal data is handled, rather than the sole authority. The precise scope of any given control, and how it interacts with payment security requirements, depends on the specific processing activity and the applicable legal text.
Who it's relevant to
Compliance officers
Compliance teams need to map GDPR obligations against other frameworks that govern personal data, including payment security standards such as PCI DSS. Because the GDPR is a distinct, general data protection law, compliance with a payment standard does not by itself demonstrate GDPR compliance, and vice versa. Officers should confirm obligations against the current published text and applicable guidance for each framework.
Merchants and payment processors handling EU personal data
Organizations that process the personal data of individuals in the EU may fall within the GDPR's scope even if they are located outside the EU, because the regulation governs how organizations both within and outside the EU handle such data. Payment activity, customer onboarding, and related processing can involve personal data subject to these obligations.
Fraud analysts and risk teams
Fraud investigation and risk-scoring activities often involve processing personal data about individuals, which can bring those activities within the GDPR's scope where EU individuals' data is involved. Teams should be aware that the GDPR governs the handling of such personal data separately from payment-specific standards, and that obligations depend on the specific processing activity and the applicable legal text.
Security engineers
Engineers designing systems that store or process personal data should recognize that the GDPR imposes obligations relating to the protection of that data, distinct from payment card security controls under PCI DSS. Where both apply, the technical measures satisfying one standard may not fully address the other, so requirements should be confirmed against each applicable framework's current text.
Inside GDPR
Scope and Territorial Reach
GDPR is a European Union regulation governing the processing of personal data of individuals in the EU. It can apply to organizations outside the EU when they offer goods or services to, or monitor the behavior of, individuals in the EU. It is a distinct legal framework and should not be conflated with payment security standards such as PCI DSS, which govern the protection of cardholder data.
Personal Data
GDPR protects personal data, meaning information relating to an identified or identifiable natural person. In a payments context, cardholder data such as the PAN or cardholder name may constitute personal data under GDPR, but GDPR's definition is broader than the categories of cardholder data and sensitive authentication data defined by PCI DSS. Whether specific payment data falls under GDPR depends on whether it identifies or can identify an individual.
Lawful Basis for Processing
GDPR requires a valid lawful basis for processing personal data, such as consent, contractual necessity, legal obligation, or legitimate interests. This is a data protection concept separate from the security control requirements of PCI DSS; meeting a lawful basis under GDPR does not by itself satisfy PCI DSS obligations, and vice versa.
Data Subject Rights
GDPR grants individuals rights that may include access, rectification, erasure, restriction, portability, and objection, subject to conditions and exceptions. These rights may interact with data retention practices; note that certain payment data retention or deletion practices are also constrained by PCI DSS controls and by card brand and network rules, which are separate from GDPR.
Controllers and Processors
GDPR distinguishes data controllers, which determine the purposes and means of processing, from data processors, which process on a controller's behalf. In payment ecosystems, merchants, acquirers, processors, and service providers may occupy different roles under GDPR, and these roles are defined independently of PCI DSS entity classifications.
Security of Processing
GDPR requires appropriate technical and organizational measures to secure personal data, taking account of risk. Techniques such as encryption, tokenization, truncation, masking, and hashing may support this obligation, but each transforms or reduces data differently, and their effect on any given compliance objective depends on implementation and validation rather than on the label alone.
Breach Notification
GDPR sets obligations to notify supervisory authorities and, in some cases, affected individuals of certain personal data breaches within defined conditions. These notification duties are separate from any breach reporting obligations arising under card brand rules or contractual PCI DSS requirements.
Common questions
Answers to the questions practitioners most commonly ask about GDPR.
Does being PCI DSS compliant mean an organization is automatically GDPR compliant?
No. PCI DSS and GDPR are distinct regimes with different scopes and objectives. PCI DSS is a card brand security standard focused on protecting cardholder data and sensitive authentication data within a defined cardholder data environment. GDPR is a data protection law governing the processing of personal data of individuals in its jurisdictional scope, covering principles such as lawful basis, data subject rights, and accountability that reach well beyond payment card data. Meeting the controls expected under PCI DSS may support some GDPR security obligations, but it does not by itself satisfy GDPR's broader requirements. Organizations should assess each framework independently.
Is GDPR only about protecting payment card numbers?
No. GDPR concerns personal data broadly, which can include names, contact details, identifiers, and other information relating to an identifiable person, not only payment card data. A primary account number and associated cardholder details may constitute personal data in some contexts, but GDPR's scope extends far beyond the cardholder data and sensitive authentication data that PCI DSS is designed to address. Treating GDPR as a card-security concern alone understates its reach across an organization's processing activities.
How do GDPR obligations interact with PCI DSS data retention expectations?
The two can point in the same direction on minimizing stored data, but they are governed separately and should be reconciled deliberately. PCI DSS expects that sensitive authentication data is not retained after authorization, even when encrypted, and that stored cardholder data is limited and controlled. GDPR data minimization and storage limitation principles similarly discourage retaining personal data longer than necessary. Where card data is also personal data, organizations should confirm retention practices against the current published PCI DSS standard and their own GDPR lawful basis and retention rationale, rather than assuming one framework's approach automatically satisfies the other.
How should tokenization or truncation be evaluated when addressing both GDPR and PCI DSS objectives?
Evaluate them by what each technique actually does, not by the label. Tokenization, encryption, truncation, masking, and hashing transform or reduce data differently, and their effect on PCI DSS scope depends on implementation and validation. For GDPR, the relevant question is whether the resulting data still relates to an identifiable person and whether the technique reduces risk to data subjects. A technique that removes data from PCI DSS scope does not necessarily render data non-personal under GDPR, and organizations should assess each purpose separately.
What should teams consider when a payment security incident may also be a GDPR-relevant personal data breach?
Recognize that a single event can trigger obligations under multiple regimes with different definitions, timelines, and notification recipients. Card brand and network rules, contractual acquirer obligations, and GDPR breach notification duties may all apply and are governed independently. Because these obligations vary by region and change over time, teams should map applicable notification requirements in advance and confirm current wording and timeframes with authoritative sources rather than relying on a fixed assumption.
Who within an organization should own the overlap between GDPR and payment security controls?
Ownership typically spans multiple roles rather than sitting with a single function. Compliance officers, data protection responsibilities defined under GDPR, security engineers responsible for the cardholder data environment, and fraud and risk teams each address different parts of the picture. Because PCI DSS and GDPR are separate frameworks, coordination between these roles helps avoid gaps where one regime is assumed to cover the other. Clear documentation of which control satisfies which obligation supports both accountability under GDPR and validation against the current PCI DSS standard.
Common misconceptions
Achieving PCI DSS compliance means an organization is also GDPR compliant.
PCI DSS and GDPR are separate frameworks with different objectives. PCI DSS is intended to protect cardholder data and is governed by the PCI Security Standards Council and card brand rules, while GDPR is an EU regulation governing personal data more broadly. Meeting the security controls of PCI DSS may support certain GDPR security obligations, but it does not address GDPR requirements such as lawful basis, data subject rights, or breach notification.
Encrypting or tokenizing payment data removes it from GDPR obligations.
Encryption, tokenization, truncation, masking, and hashing transform or reduce data in different ways, and whether data remains personal data under GDPR depends on whether an individual can still be identified, directly or indirectly, given the specific implementation. These techniques may reduce risk but do not automatically place data outside GDPR's reach; the outcome depends on implementation and how the data can be re-associated with an individual.
GDPR only applies to organizations located within the European Union.
GDPR can apply to organizations established outside the EU when they offer goods or services to, or monitor the behavior of, individuals in the EU. Applicability depends on the nature of the processing activity rather than solely on where the organization is located.
Best practices
Map how personal data and payment data flow through your systems, and document which data elements may qualify as personal data under GDPR while separately tracking cardholder data and sensitive authentication data as defined by PCI DSS, since the two classifications do not align exactly.
Treat GDPR and PCI DSS as distinct programs with overlapping but non-identical requirements, and confirm each control against the current published text of the applicable framework rather than assuming that satisfying one satisfies the other.
Establish a documented lawful basis for processing payment-related personal data, and ensure retention and deletion practices reconcile GDPR data subject rights with PCI DSS storage controls and applicable card brand and network rules.
When applying encryption, tokenization, truncation, masking, or hashing to reduce risk, validate the specific implementation to determine its actual effect on identifiability and on compliance scope, rather than relying on the technique's label.
Coordinate breach response so that notification obligations under GDPR are addressed alongside, but separately from, any reporting duties arising from card brand rules or contractual PCI DSS requirements.
Clarify controller and processor roles across merchants, acquirers, processors, and service providers under GDPR, recognizing that these roles are defined independently of PCI DSS entity classifications, and reflect them in contracts and data processing agreements.