PCI DSS Compliance Standards

The Payment Card Industry Data Security Standard (PCI DSS) establishes the technical and operational requirements that any organization storing, processing, or transmitting payment card data must satisfy to remain eligible to handle card transactions. Administered by the PCI Security Standards Council (PCI SSC), the standard applies across merchant categories, payment processors, service providers, and acquirers operating within card brand networks including Visa, Mastercard, American Express, Discover, and JCB. Non-compliance exposes organizations to fines, card brand penalties, and potential loss of card acceptance privileges. This page describes the standard's scope, its structural framework, the scenarios in which it applies, and the boundaries that determine which requirements bind a given organization.

Definition and scope

PCI DSS is a contractual and technical standard published by the PCI Security Standards Council, a body founded in 2006 by the five major card brands. The standard is not a US federal statute, but card network participation agreements make compliance effectively mandatory for any entity that accepts, processes, stores, or transmits cardholder data (CHD) or sensitive authentication data (SAD).

Cardholder data includes the primary account number (PAN), cardholder name, expiration date, and service code. Sensitive authentication data includes full magnetic stripe data, chip equivalents, PINs, and CVV/CVC values. Organizations that handle only tokenized or truncated PANs — where the full number is never received — may fall outside certain scope boundaries, a determination governed by the PCI SSC's Tokenization Guidelines.

PCI DSS version 4.0, released by the PCI SSC in March 2022, replaced version 3.2.1 and introduced a customized implementation approach alongside the traditional defined approach, allowing organizations to demonstrate equivalent security controls that achieve the intent of a requirement rather than its exact prescriptive form (PCI DSS v4.0, PCI SSC).

Scope is determined by the cardholder data environment (CDE): all system components, people, and processes that store, process, or transmit CHD or SAD, plus all connected or security-impacting systems. Reducing CDE scope through network segmentation, tokenization, or point-to-point encryption (P2PE) is a recognized compliance strategy that can reduce the number of applicable controls.

How it works

PCI DSS is organized into 12 principal requirements grouped under 6 control objectives. Compliance is validated through a process that varies by merchant or service provider level.

The 12 PCI DSS requirements (v4.0) are:

Validation is performed by a Qualified Security Assessor (QSA) for higher-risk entities, or via a Self-Assessment Questionnaire (SAQ) for lower-volume merchants. There are 9 distinct SAQ types (SAQ A through SAQ D, plus variants), each designed for a specific merchant profile — for example, SAQ A applies to card-not-present merchants that have fully outsourced all cardholder data functions, while SAQ D applies to all merchants not covered by another SAQ type and represents the broadest control set (PCI SSC SAQ Instructions).

Merchant levels are set by individual card brands. Visa, for instance, defines Level 1 merchants as those processing more than 6 million Visa transactions annually, requiring an annual on-site assessment by a QSA and a quarterly network scan by an Approved Scanning Vendor (ASV) (Visa Merchant Levels).

Common scenarios

E-commerce retailers redirect customers to a hosted payment page operated by a PCI-compliant payment gateway. If no CHD enters the merchant's environment, the merchant may qualify for SAQ A, the lowest-burden validation path. However, JavaScript skimming attacks on the merchant's website can re-expand scope even when no server stores card data — a risk addressed explicitly in PCI DSS v4.0 Requirement 6.4.3.

Healthcare and hospitality organizations operating physical point-of-sale environments typically use validated point-to-point encryption (P2PE) solutions verified on the PCI SSC P2PE Solutions provider network. A validated P2PE deployment can reduce a merchant's SAQ from SAQ D (over 300 controls) to SAQ P2PE (approximately 35 controls).

Payment processors and service providers classified as Level 1 undergo annual Report on Compliance (ROC) assessments conducted by a QSA and must appear on card brand lists of compliant service providers. A service provider that stores, processes, or transmits CHD on behalf of more than one client carries a distinct compliance obligation separate from the merchants it serves.

For organizations navigating the broader cybersecurity compliance landscape, PCI DSS intersects with frameworks described in the Cyber Compliance Standards Overview, particularly where organizations must align card data security with federal or sectoral requirements simultaneously.

Decision boundaries

The primary decision boundary in PCI DSS is scope: whether an organization's systems, people, or processes touch the CDE directly, are connected to it, or are entirely isolated from it. Incorrectly scoping the CDE is the most common source of compliance gaps identified during QSA assessments.

Comparison: Defined Approach vs. Customized Approach (v4.0)

Organizations that outsource all payment functions to a third-party processor do not eliminate compliance obligations — they inherit a responsibility to confirm that the third party maintains valid PCI DSS compliance and appears on an active card brand service provider registry.

The distinction between merchant and service provider determines assessment type. A cloud infrastructure provider that hosts a merchant's payment application is classified as a service provider under PCI DSS scope if it can impact the security of the CDE, regardless of whether it directly processes card data.

PCI DSS compliance does not satisfy the requirements of other applicable cybersecurity frameworks. An organization subject to the NIST Cybersecurity Framework or sectoral standards must treat PCI DSS as a parallel obligation, not a substitute. Understanding the limitations of cyber compliance frameworks is essential when mapping PCI DSS controls to enterprise risk management programs.