Payment card data is among the most targeted categories of information in any financial system. If your organisation stores, processes, or transmits payment card transactions, the Payment Card Industry Data Security Standard (PCI DSS) defines exactly what PCI protected information you are responsible for securing — and the rules are more precise than most compliance teams expect. This post sets out the two categories of PCI data, how they differ, where they overlap with other data types, and what PCI DSS v4.0 requires you to do with each.
What “PCI Protected Information” Actually Means
PCI protected information refers specifically to the data associated with payment card transactions that falls within the scope of the PCI DSS; cardholder data refers to payment-card-related sensitive information governed by PCI standards and maintained by the PCI Security Standards Council (PCI SSC). The PCI SSC was established by the five major card brands — Visa, Mastercard, American Express, Discover, and JCB — to create a common framework for protecting payment account data across every participant in the payment chain.
The standard divides protected information into two distinct categories: Cardholder Data (CHD) and Sensitive Authentication Data (SAD). These categories have different rules for storage, transmission, and access. The PCI SSC was created by major credit card companies, including Visa, Mastercard, American Express, Discover, and JCB, to support that shared security framework. Treating them as a single undifferentiated category is one of the more common compliance gaps organisations encounter when beginning a PCI DSS programme.
The Two Categories of PCI Data
Cardholder Data (CHD): What You Can Store, With Controls
Cardholder Data is the information printed or encoded on a payment card that identifies the account and its holder. Under PCI DSS Requirement 3, the following elements constitute CHD:
- Primary Account Number (PAN): The 13 to 19-digit number on the front of the card. This is the core protected element. All other CHD items are only in scope when stored or transmitted alongside the PAN.
- Cardholder name: The name associated with the account.
- Expiration date: The month and year the card expires.
- Service code: The three or four-digit value encoded on the magnetic stripe that indicates how the card can be used — for example, whether it is valid internationally.
You may store CHD after authorisation, but only with appropriate technical controls: for primary account numbers, stored cardholder data must be made data unreadable with strong encryption such as AES-256, truncation, or hashing, alongside strict access controls, audit logging, and documented retention and deletion policies. Protecting encrypted cardholder data also requires tight control of encryption keys and cryptographic keys. These measures help protect sensitive cardholder data and credit card data, rather than leaving it exposed in a readable form.
Sensitive Authentication Data (SAD): What You Must Never Store
Sensitive Authentication Data is a separate and more restricted category. It consists of security-related information used to authenticate the cardholder or authorise the transaction, making it especially sensitive cardholder data used only for authentication. Once a transaction has been authorised, SAD must not be stored — under any circumstances, in any form.
The SAD elements are:
- Full track data: The complete contents of the magnetic stripe or equivalent chip data, which contains everything needed to clone a card.
- Card verification codes: The three or four-digit codes printed on cards — referred to as CVV2 (Visa), CVC2 (Mastercard), CID (American Express), or CAV2 (JCB). These are specifically designed to verify that the person making a transaction has physical possession of the card.
- PINs and PIN blocks: The Personal Identification Number and its encrypted form used in debit and chip-and-PIN transactions.
The rationale for the absolute prohibition on storing SAD is straightforward: these data points serve their purpose at the moment of authentication. Retaining them afterwards increases the risk of stolen data and other security breaches, while creating a liability with no corresponding business need. Regulators and card brands have made this a bright-line rule in every version of PCI DSS.
How PCI Data Overlaps with PII (and Why It Matters Under GDPR)
PCI protected information is a subset of the broader category of Personally Identifiable Information (PII). PII covers any data that can be used to identify an individual — names, addresses, email addresses, national ID numbers, and so on. PCI data overlaps with PII because the cardholder’s name and, in some contexts, their billing address are both cardholder data and personal data under general data protection law.
For organisations operating in the European Union or processing the data of EU residents, this overlap has direct consequences. The cardholder name and associated billing information you handle as part of a payment transaction is also personal data within the meaning of the General Data Protection Regulation (GDPR). This means PCI DSS compliance and GDPR compliance are not alternatives — they run in parallel and must both be satisfied for the same data.
In practice, this means your data map needs to account for both frameworks simultaneously. A field in your database that contains a PAN is subject to PCI DSS encryption requirements. If it also contains a name, it is subject to GDPR principles of data minimisation and purpose limitation. The failure mode is treating these as separate compliance workstreams when they are examining the same record.
Who Must Protect PCI Data
Any organisation that stores, processes, or transmits cardholder data is in scope for PCI DSS. This includes merchants and service providers of all sizes, payment processors, acquiring banks, card issuers, and third parties that handle CHD on behalf of those entities, especially where payment processing and online transactions are involved.
Any entity that stores, processes, or transmits cardholder data must be PCI DSS compliant, with reporting obligations that vary by merchant level.
For financial institutions specifically, the scope question is rarely whether PCI DSS applies — it almost always does — but how broadly it applies across the organisation’s systems. Retail organisations handling card payments face a similar scope challenge: the Cardholder Data Environment (CDE) can expand rapidly if card data flows are not carefully mapped and contained.
Compliance is mandatory. The obligation is enforced through contracts between acquiring banks and the card brands, and pci dss compliance validation typically requires formal compliance validation through mechanisms such as the self assessment questionnaire or, where applicable, review by an internal security assessor, with some payment brands also setting their own compliance programs. Non-compliance can result in data breaches, reputational damage, fines of up to $100,000 per month, increased transaction fees, termination by the bank, placement on the Merchant Alert to Control High-Risk (MATCH) list, and, after a breach, a higher compliance level with stricter requirements and costs.
The Cardholder Data Environment (CDE): Why Scope Matters
The Cardholder Data Environment (CDE) encompasses all people, processes, and technologies that store, process, or transmit CHD, as well as all systems connected to or that could affect the security of those systems.
Why does scope matter so much? Because every system within the CDE must comply with all applicable PCI DSS requirements — all 12 requirements and their sub-requirements in v4.0. A large CDE means a large compliance programme. The single most effective tool for controlling the size and cost of PCI compliance is scope reduction: removing card data from systems that do not need it, segmenting the network so that the CDE is isolated, and using tokenisation or third-party payment processors to handle the actual card data processing.
Organisations that have not documented their CDE clearly will generally either over-scope their compliance programme — spending time and resource on systems that do not need to be assessed — or under-scope it, which creates audit findings and potential liability.
What PCI DSS v4.0 Requires You to Do With This Data
PCI DSS v4.0, which became the sole active standard on 31 March 2024, organises its requirements into 12 top-level controls grouped under six objectives in the current pci dss version. The requirements most directly governing PCI protected information are:
Requirement 3 — Protect stored account data. This requirement governs what CHD you may retain, for how long, and how it must be protected. The PAN must be rendered unreadable in storage using strong cryptography. SAD must not be retained after authorisation. Documented data retention and disposal policies are required, and organisations should limit access to sensitive information and sensitive data so only authorized personnel can access retained account data.
Requirement 4 — Protect cardholder data with strong cryptography during transmission over open, public networks. Any CHD transmitted over the internet, wireless networks, or other open networks must be encrypted using current, accepted cryptographic protocols, including when systems handle remote access scenarios where applicable. Transmitting PANs in unencrypted email or messaging is explicitly prohibited, and remote access should be secured with multi factor authentication.
Requirement 7 — Restrict access to system components and cardholder data by business need to know. Access to CHD must be limited to those with a documented business need. strong access control measures, including role-based access controls, formal access authorisation processes, and multi factor authentication, are required to limit access appropriately and protect sensitive data.
Physical access to systems, media, and paper records in the CDE must also be restricted, and teams should monitor access to those areas.
Requirement 10 — Log and monitor all access to system components and cardholder data. All access events in the CDE must be logged, and logs must be reviewed through regular monitoring of key security controls. v4.0 introduced more prescriptive requirements around automated log analysis and alert thresholds.
PCI DSS also expects a vulnerability management program, ideally a robust vulnerability management program, with proactive measures such as patching, regular vulnerability scans, penetration testing, and controls against malicious software.
These four requirements are not the entirety of PCI DSS, but they are the requirements that most directly address what happens to PCI protected information once it enters your environment. Compliance with the pci dss standard is continuous rather than a one-time project and helps prevent data breaches.
Frequently Asked Questions
What information is protected under PCI DSS?
PCI DSS protects two categories of data, and this payment data includes both Cardholder Data (CHD) and Sensitive Authentication Data (SAD). The first is Cardholder Data (CHD), which includes the Primary Account Number (PAN), cardholder name, expiration date, and service code. The second is Sensitive Authentication Data (SAD), which includes full magnetic stripe data, card verification codes (CVV, CVC, CID), and PINs. CHD may be stored under strict controls, but SAD must never be stored after a transaction is authorised.
What is the difference between PCI data and PII?
PII is a broad category covering any data that can identify an individual, such as names, addresses, and email addresses. PCI data is a narrower, specialised category covering information associated with payment card transactions. PCI data overlaps with PII because it contains identifiers like the cardholder’s name, but it is governed by PCI DSS rather than — or in addition to — general data protection law such as GDPR.
What data cannot be stored under PCI DSS?
PCI DSS prohibits storing Sensitive Authentication Data (SAD) after transaction authorisation to reduce the risk of data breaches. This includes full magnetic stripe or chip data, card verification codes (CVV2, CVC2, CID, CAV2), and PIN or encrypted PIN blocks. These data points exist to authenticate the cardholder at the point of transaction; retaining them after that point creates unnecessary risk and is explicitly prohibited under PCI DSS Requirement 3.
Who must comply with PCI DSS?
PCI DSS applies to all organisations that store, process, or transmit cardholder data. This includes merchants of all sizes, payment processors, card issuers, acquirers, and any third-party service providers that handle cardholder data on behalf of those entities, covering merchants and service providers involved in payment processing. Compliance is mandatory and enforced by the major card brands through contracts with acquiring banks.
Understanding the boundaries of PCI protected information is the necessary foundation for any PCI DSS compliance programme. The distinction between what can be stored with appropriate controls and what must never be stored at all is not a technicality — it is the structural principle the entire standard is built around. Getting that distinction right, and mapping it accurately onto your systems, is where compliance work begins.
How Copla Supports PCI DSS Compliance Programmes
We work with financial institutions and payment service providers to build PCI DSS compliance programmes that are proportionate to the organisation’s scope and transaction environment. The engagement starts with an onboarding workshop to define the CDE accurately — mapping data flows, identifying where CHD enters and leaves the environment, and flagging SAD retention risks before they become audit findings.
From there, we populate your risk and asset registers in the Copla platform and generate the policy and procedure documentation your assessor will expect to see under Requirements 3, 4, 7, and 10. Control implementation is tracked against the full v4.0 requirement set, with consultancy support at each stage. Support can also include pci dss compliance validation readiness, including evidence preparation for a QSA or self-assessment where appropriate. Where an external QSA (Qualified Security Assessor) assessment is required, we work alongside your assessor to keep the process on track, with ongoing review of your security controls so the programme remains aligned with the PCI DSS standard.
Schedule a call with Copla to walk through how this would look for your team.
