PCI compliance means meeting the Payment Card Industry Data Security Standard (PCI DSS) – a set of 12 security requirements defined by the PCI Security Standards Council (PCI SSC) to protect cardholder data during processing, transmission, and storage.
PCI DSS applies to every entity that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD) – including merchants, payment processors, acquirers, issuers, and service providers.
The standard is organized into six control objectives covering network security, data protection, vulnerability management, access controls, monitoring, and security policy.
PCI compliance is enforced contractually by the five founding card brands – Visa, Mastercard, American Express, Discover, and JCB – through acquiring banks, not by government regulation.
Merchants are classified into four levels based on annual transaction volume, each with different validation requirements ranging from Self-Assessment Questionnaires (SAQs) to on-site assessments by a Qualified Security Assessor (QSA).
Non-compliance penalties include fines from card brands, increased transaction fees, and potential loss of card processing privileges. Tokenization can reduce PCI audit scope by up to 90% by removing cardholder data from merchant environments entirely.
PCI stands for Payment Card Industry. PCI DSS stands for Payment Card Industry Data Security Standard.
The PCI meaning in the compliance context refers to the ecosystem of standards, councils, and programmes designed to protect payment card data. The PCI DSS meaning specifically refers to the 12-requirement security standard that governs how cardholder data is handled.
The standard was created to unify the separate security programmes that each card brand operated independently before 2004. Version 1.0 of PCI DSS was released in December 2004, and the standard has evolved through multiple revisions since. The most recent – PCI DSS 4.0 – was published in March 2022, with the supplementary 4.0.1 revision following in 2024.
For organisations managing payment data alongside PII and PHI, the intersections between PCI, HIPAA, and GDPR create compounding compliance obligations. A patient paying a hospital co-pay with a credit card creates a record that is simultaneously PII, PHI, and PCI data.
PCI DSS applies to every entity that stores, processes, or transmits cardholder data. This includes merchants of all sizes, payment processors, payment gateways, hosting providers, and any third-party service provider with access to cardholder data environments.
The scope is broad. A small e-commerce shop processing 500 transactions per year has PCI obligations, as does a multinational retailer processing millions. The difference lies in the validation method – not whether PCI compliance applies.
Third-party service providers that store, process, or transmit cardholder data – or that have access to customers' cardholder data environments – are also subject to PCI DSS. This includes SaaS platforms, cloud hosting providers, payment software vendors, and managed service providers.
PCI DSS classifies merchants into four levels based on annual transaction volume. Each level determines the type of compliance validation required.
Transaction volume thresholds vary by card brand. Visa, Mastercard, and Discover each define their own tier boundaries. An acquiring bank or card brand can also manually elevate an organization to a higher reporting level at its discretion – typically after a data breach or compliance failure.
Level 1 merchants must engage a Qualified Security Assessor (QSA) for an on-site assessment. Levels 2 through 4 can typically self-assess using the appropriate SAQ. Understanding which SAQ type applies to your business determines the scope of your compliance effort.
Service providers have a separate two-level classification. Level 1 service providers process over 300,000 transactions annually and require an annual ROC by a QSA. Level 2 service providers process fewer than 300,000 and complete an annual SAQ.
PCI DSS is organized into six control objectives containing 12 specific requirements. These requirements define the security controls every compliant organization must implement.
The six control objectives are: build and maintain a secure network and systems, protect cardholder data, maintain a vulnerability management programme, implement strong access control measures, regularly monitor and test networks, and maintain an information security policy.
The 12 PCI compliance requirements under PCI DSS 4.0 are:
Each requirement contains sub-requirements and testing procedures. PCI DSS 4.0 introduced over 60 new sub-requirements, including Requirement 6.4.3 and 11.6.1 for e-skimming protection on payment pages – a response to the growing threat of script-based attacks against e-commerce checkout flows.
Requirement 3 – protecting stored cardholder data – is where data protection method selection matters most. Encrypted data remains in PCI scope because the mathematical relationship between plaintext and ciphertext is reversible. Tokenized data can be removed from scope because tokens have no mathematical relationship to the original cardholder data.
PCI DSS defines two categories of payment account data that fall within PCI compliance scope.
Cardholder data (CHD) includes the primary account number (PAN), cardholder name, expiration date, and service code. The PAN is the defining element – if a record contains a PAN, it is cardholder data and subject to PCI DSS.
Sensitive authentication data (SAD) includes full track data (magnetic stripe or chip equivalent), the card security code (CVV2/CVC2/CID), and PINs or PIN blocks. SAD must never be stored after authorization, even if encrypted.
The distinction between CHD and SAD drives how organizations design their cardholder data environments. Data discovery tools identify where CHD and SAD exist across databases, file shares, logs, and application layers – including locations your security team may not know about.
PCI scope refers to the systems, processes, and people that store, process, transmit, or could impact the security of cardholder data. Every system in scope must meet PCI DSS requirements.
The challenge is that PCI scope expands with every system that touches cardholder data. A CRM that stores PANs, a logging system that captures card numbers in debug mode, a backup server with unencrypted database dumps – all of these are in scope. Larger scope means more systems to secure, more controls to validate, and higher audit costs.
Scope reduction is the most effective strategy for simplifying PCI compliance. The goal is to minimise the number of systems that interact with cardholder data.
Tokenization is the most powerful scope reduction technique. It replaces PANs with tokens that have no mathematical relationship to the original data. Systems that store only tokens – and cannot access the token vault or detokenisation service – can be treated as out of PCI scope per the PCI SSC Tokenization Guidelines.
This is the critical distinction. Under PCI DSS, encrypted PANs remain in scope because the data can be recovered if the encryption key is compromised. Tokenized PANs leave scope because there is nothing to recover – the tokens are valueless without access to the vault.
In practice, tokenization can reduce PCI audit scope by 70–90%, enabling merchants to migrate from SAQ D (the most comprehensive questionnaire) to SAQ A or SAQ A-EP – dramatically reducing the number of controls they must validate.
PCI compliance validation depends on your merchant level and how you handle cardholder data.
Self-Assessment Questionnaires (SAQs) are the validation method for most merchants. There are multiple SAQ types – SAQ A for merchants that fully outsource payment processing, SAQ A-EP for e-commerce merchants that partially outsource, SAQ B for imprint-only or standalone terminal merchants, SAQ C for merchants with payment applications connected to the internet, and SAQ D for all other merchants.
The SAQ type determines which PCI DSS requirements apply to your assessment. SAQ A contains approximately 22 requirements. SAQ D contains all 300+ requirements. The difference in compliance burden between the two is substantial – which is why scope reduction through tokenization is a strategic priority for enterprises.
Qualified Security Assessors (QSAs) are independent security professionals certified by the PCI SSC to conduct on-site PCI DSS assessments. Level 1 merchants and Level 1 service providers must engage a QSA for their annual assessment.
An Attestation of Compliance (AOC) is the summary document confirming that an organization has completed its PCI DSS assessment.
A Report on Compliance (ROC) is the detailed report that breaks down how each requirement is met. For details on AOC vs ROC, see the attestation guide.
PCI DSS 4.0 – published in March 2022 with the 4.0.1 revision in 2024 – represents the most significant update to the standard since its inception. The transition deadline for full enforcement of new requirements was 31 March 2025.
The most consequential changes fall into four categories.
Requirements 6.4.3 and 11.6.1 mandate that merchants protect payment pages against script-based attacks – specifically e-skimming.
Merchants must manage and authorize all scripts loaded on payment pages and implement tamper-detection mechanisms. This responds directly to attacks like Magecart, where malicious JavaScript injected into checkout pages captured cardholder data in real time.
Multi-factor authentication (MFA) requirements expanded beyond administrative access. PCI DSS 4.0 requires MFA for all access to the cardholder data environment – not just remote access. This closes a longstanding gap where internal users with network proximity could access CHD with a single authentication factor.
The "customized approach" is a new validation methodology. It allows organizations to meet the intent of a PCI DSS requirement using alternative controls – provided they can demonstrate equivalent or greater security. This gives mature security programmes flexibility while maintaining the standard's protective intent.
Targeted risk analysis is now required for several controls where organizations define their own implementation frequency – such as log review intervals and vulnerability scan cadences.
Organizations must document the rationale and have it approved by management with accountability for PCI DSS compliance.
Less than 50% of organizations maintain full PCI compliance year over year, according to Verizon's Payment Security Report. The requirement is not a one-time achievement – it is an ongoing operational discipline.
Scope creep is the most common challenge. New applications, cloud migrations, and third-party integrations introduce cardholder data into systems that were previously out of scope. Without continuous data discovery, PCI scope expands silently.
Legacy systems present unique difficulties. Mainframe environments, older payment terminals, and legacy databases often lack the security controls required by PCI DSS – yet they continue to process or store cardholder data. Modernizing legacy security without disrupting operations is a significant undertaking.
The volume of sub-requirements is a practical obstacle. SAQ D contains over 300 individual requirements. For organizations without dedicated compliance teams, tracking progress across all controls – and maintaining evidence of compliance – requires significant investment in process and tooling.
Moreover, PCI compliance does not equal security. Meeting every PCI DSS requirement at the point of assessment does not guarantee protection against a sophisticated attack. PCI DSS sets a baseline.
Organizations that treat compliance as a ceiling rather than a floor leave gaps that data-centric security controls – tokenization, masking, real-time monitoring – are designed to close.
PCI DSS is not enforced by government agencies. It is enforced by card brands through acquiring banks.
Fines for non-compliance range from $5,000 to $100,000 per month, issued by card brands to the acquiring bank, which passes the penalty to the non-compliant merchant. These fines escalate with the duration of non-compliance and the severity of the violation.
In the event of a cardholder data breach, the consequences escalate. The breached organization faces forensic investigation costs, customer notification obligations, credit monitoring expenses, and potential legal liability.
IBM's Cost of a Data Breach Report 2025 puts the global average breach cost at $4.88 million. Payment card breaches typically exceed this average due to card brand penalties and card reissuance costs.
Card brands can also restrict or terminate an organization's ability to accept card payments – effectively shutting down a revenue channel. Compliance is not optional if you accept cards.
The only strategic question is how to achieve it efficiently. Data security management frameworks that incorporate tokenization from the outset reduce both compliance cost and breach exposure.
Tokenization is the single most effective technique for reducing PCI compliance scope and cost.
When cardholder data enters your environment, tokenization replaces the PAN with a randomly generated token before it reaches your systems. The token retains the format of a card number – enabling applications to function normally – but contains no recoverable cardholder data.
The original PAN is stored in a PCI DSS-validated token vault operated by the tokenization provider. Your systems never see, store, or process the real cardholder data. In the event of a breach, attackers get tokens – valueless data with no path back to the original PAN.
This architecture has three consequences for PCI compliance.
First, it reduces the cardholder data environment (CDE) to the tokenization gateway and vault only – everything downstream operates on tokens and can be treated as out of scope. Second, it enables migration from SAQ D to SAQ A – reducing the number of applicable PCI DSS requirements from 300+ to approximately 22.
Third, it addresses Requirement 3 (protect stored cardholder data) by ensuring that no stored data in your environment is actual cardholder data.
Encryption also protects cardholder data, but encrypted PANs remain in PCI scope. The PCI SSC Tokenization Guidelines explicitly draw this distinction: systems storing encrypted PANs are in scope; systems storing only vaulted tokens – where the token has no mathematical relationship to the original PAN – can be removed from scope.
PCI compliance scope is the primary cost driver. Every system that touches cardholder data must meet every applicable PCI DSS requirement. The fewer systems in scope, the lower the cost – and the faster the path to compliance.
DataStealth reduces PCI scope at the source. The platform tokenizes cardholder data in-line – before it reaches your systems – replacing PANs with format-preserving tokens that are valueless to attackers. Applications continue functioning normally; audit scope shrinks to the tokenization gateway. No agents. No code changes.
Data discovery and classification identify where cardholder data exists across cloud, SaaS, on-premises, and legacy environments – including the shadow data locations your team may not know about. E-skimming protection addresses PCI DSS 4.0 Requirements 6.4.3 and 11.6.1 with continuous monitoring of payment page scripts.
