PCI DSS Compliance Standards

The Payment Card Industry Data Security Standard (PCI DSS) establishes the technical and operational requirements that organizations must satisfy when storing, processing, or transmitting payment card data. Governed by the PCI Security Standards Council (PCI SSC), the standard applies across merchants, processors, acquirers, issuers, and service providers globally. Non-compliance exposes organizations to contractual fines from card brands, increased transaction fees, and mandatory forensic audits following a breach.

Definition and scope

PCI DSS is a contractual security standard published by the PCI Security Standards Council, a body founded in 2006 by American Express, Discover, JCB International, Mastercard, and Visa. The current version, PCI DSS v4.0, became the sole active standard on March 31, 2024, with PCI DSS 3.2.1 officially retired on that date (PCI SSC, PCI DSS v4.0 Resource Hub).

Scope is defined by the presence of cardholder data (CHD) or sensitive authentication data (SAD) within a network environment. The cardholder data environment (CDE) encompasses all system components that store, process, or transmit CHD or SAD, plus any component that could impact the security of those systems. Scope reduction through network segmentation is explicitly recognized: organizations that effectively isolate the CDE from out-of-scope systems may reduce the number of controls subject to assessment.

The standard organizes 12 top-level requirements across 6 control objectives:

Install and maintain network security controls
Apply secure configurations to all system components
Protect stored account data
Protect cardholder data with strong cryptography during transmission over open, public networks
Protect all systems and networks from malicious software
Develop and maintain secure systems and software
Restrict access to system components and cardholder data by business need to know
Identify users and authenticate access to system components
Restrict physical access to cardholder data
Log and monitor all access to system components and cardholder data
Test security of systems and networks regularly
Support information security with organizational policies and programs

PCI DSS v4.0 introduced 64 new requirements relative to v3.2.1, with 13 of those designated as best practices until March 31, 2025, after which they became mandatory (PCI SSC Summary of Changes, PCI DSS v3.2.1 to v4.0).

How it works

Compliance is validated through a tiered assessment model based on transaction volume. Card brands, not PCI SSC itself, set the merchant level thresholds, but the most widely cited framework from Visa and Mastercard defines four merchant levels:

Level 1: Merchants processing more than 6 million Visa or Mastercard transactions annually — required to undergo an annual on-site assessment by a Qualified Security Assessor (QSA) and quarterly network scans by an Approved Scanning Vendor (ASV).
Level 2: 1 to 6 million transactions annually — annual Self-Assessment Questionnaire (SAQ) plus quarterly ASV scans.
Level 3: 20,000 to 1 million e-commerce transactions annually — SAQ plus quarterly scans.
Level 4: Fewer than 20,000 e-commerce or up to 1 million other transactions — SAQ, with scan requirements at acquirer discretion.

Assessment artifacts produced include the Report on Compliance (ROC) for Level 1 entities, Attestations of Compliance (AOC), and the applicable SAQ variant. Eight distinct SAQ types exist (SAQ A through SAQ D), each calibrated to a specific merchant acceptance channel and integration model. SAQ A, for example, applies to card-not-present merchants that have fully outsourced all cardholder data functions to PCI DSS–compliant third parties.

For organizations operating in regulated environments that overlap with federal frameworks, PCI DSS assessments frequently run in parallel with NIST SP 800-53 control reviews, as the two share substantive overlap in access control, audit logging, and cryptographic requirements.

Common scenarios

E-commerce merchants using hosted payment pages: A merchant that redirects cardholders entirely to a third-party payment processor's hosted page may qualify for SAQ A, provided no CHD flows through or is stored on the merchant's servers. This represents the lowest-burden compliance pathway.

Brick-and-mortar retailers with integrated POS systems: Physical merchants using point-of-sale terminals integrated into their internal networks face broader CDE scope. Network segmentation between the POS environment and general business systems is a common remediation step to reduce applicable control count.

Service providers handling cardholder data on behalf of multiple clients: Third-party processors and SaaS payment platforms must comply as service providers, typically at the highest assessment tier. These entities are subject to the full requirement set under SAQ D for Service Providers or a QSA-led ROC. The intersection with cybersecurity third-party risk compliance is direct: downstream merchants must verify their service providers appear on Visa's or Mastercard's published lists of compliant providers.

Cloud-hosted cardholder environments: Shared responsibility models in cloud deployments require explicit documentation of which PCI DSS requirements the cloud service provider satisfies versus those retained by the customer. PCI SSC publishes a dedicated Cloud Computing Guidelines supplement addressing this delineation.

Decision boundaries

The primary compliance decision point is whether cardholder data or sensitive authentication data enters the organization's environment at all. Organizations with zero direct CHD contact — because all payment functions are handled by a compliant third party — face minimal PCI DSS obligations, though contractual accountability to their acquirer persists.

The distinction between merchant and service provider classifications carries material consequence: service providers face additional requirements under PCI DSS v4.0, including Requirements 12.9.1 and 12.9.2, which mandate that service providers formally acknowledge their responsibility for the security of cardholder data they handle on behalf of customers.

Scope creep is the dominant operational risk. An IT system initially classified as out-of-scope becomes in-scope the moment it can communicate with CDE components without validated segmentation controls. Annual scoping reviews are a mandatory element of Requirement 12.5.2 under PCI DSS v4.0. For organizations maintaining parallel compliance postures, the cybersecurity compliance frameworks reference structure provides a comparative view of how PCI DSS scope logic maps against other regulatory regimes.

References

Explore This Site

Services & Options Cybersecurity: Standards Overview Regulations & Safety Regulatory References Tools & Calculators Password Strength Calculator