PCI DSS Cybersecurity Requirements Reference

The Payment Card Industry Data Security Standard (PCI DSS) is the primary technical and operational framework governing how organizations store, process, and transmit payment card data. Administered by the PCI Security Standards Council, the standard applies to any entity that handles cardholder data — from global payment processors to small retail merchants. Non-compliance exposes organizations to fines, card brand penalties, and mandatory forensic investigations following a breach.

Definition and scope

PCI DSS is a private-sector regulatory framework established in 2004 by five major card brands — Visa, Mastercard, American Express, Discover, and JCB — through the formation of the PCI Security Standards Council (PCI SSC). The current version, PCI DSS v4.0, was released in March 2022 (PCI SSC, PCI DSS v4.0) and became the sole active version as of March 31, 2024, following the retirement of v3.2.1.

Scope is determined by the cardholder data environment (CDE): any system component that stores, processes, or transmits cardholder data or sensitive authentication data, or that connects to such systems. Scope reduction through network segmentation is a recognized compliance strategy — isolating the CDE from other infrastructure limits which assets must meet full PCI DSS controls.

The standard classifies merchants into four levels based on annual transaction volume:

  1. Level 1 — more than 6 million Visa or Mastercard transactions per year; requires an annual on-site assessment by a Qualified Security Assessor (QSA) and a quarterly network scan by an Approved Scanning Vendor (ASV).
  2. Level 2 — 1 million to 6 million transactions; requires an annual Self-Assessment Questionnaire (SAQ) and quarterly ASV scans.
  3. Level 3 — 20,000 to 1 million e-commerce transactions; requires an SAQ and quarterly ASV scans.
  4. Level 4 — fewer than 20,000 e-commerce or up to 1 million other transactions; requirements set by the acquiring bank.

Service providers — including cloud hosts, managed security providers, and payment gateways — are classified separately into Level 1 (more than 300,000 transactions annually) and Level 2 (fewer than 300,000).

How it works

PCI DSS v4.0 is organized into 12 principal requirements grouped under six control objectives. These requirements map directly onto technical and administrative controls that must be implemented, documented, and validated.

The 12 requirements:

  1. Install and maintain network security controls
  2. Apply secure configurations to all system components
  3. Protect stored account data
  4. Protect cardholder data with strong cryptography during transmission over open networks
  5. Protect all systems and networks from malicious software
  6. Develop and maintain secure systems and software
  7. Restrict access to system components and cardholder data by business need to know
  8. Identify users and authenticate access to system components
  9. Restrict physical access to cardholder data
  10. Log and monitor all access to system components and cardholder data
  11. Test security of systems and networks regularly
  12. Support information security with organizational policies and programs

Requirement 11 directly drives demand for penetration testing firms and vulnerability assessment providers, specifying internal penetration testing at least annually and after significant infrastructure changes. Requirement 10 creates logging and monitoring obligations that align with security operations center providers operating continuous log review capabilities.

PCI DSS v4.0 introduced a customized approach alongside the traditional defined approach. Under the customized approach, organizations may implement alternative controls that meet the stated objective of each requirement, provided they document the methodology and validate it through a QSA. This allows mature security programs to align PCI controls with existing enterprise frameworks such as the NIST Cybersecurity Framework.

Common scenarios

E-commerce merchants using third-party payment pages: A merchant that redirects all payment processing to a third-party hosted payment page and stores no cardholder data may qualify for SAQ A, the shortest self-assessment form with 22 requirements. Eligibility depends on complete outsourcing — any server-side script that affects the payment page behavior disqualifies SAQ A eligibility under PCI SSC guidance.

Hospitality and retail point-of-sale environments: Physical POS terminals handling magnetic stripe, chip, and contactless payments fall under SAQ B or SAQ B-IP depending on whether the terminals are IP-connected. These environments require careful scoping of all connected network segments and often engage risk and compliance consultants to determine which systems fall within CDE boundaries.

Cloud-hosted cardholder data: Migrating CDE workloads to public cloud infrastructure does not transfer PCI DSS responsibility to the cloud provider. Responsibility is shared according to the cloud service model (IaaS, PaaS, SaaS), and cloud providers may hold their own Attestation of Compliance (AOC) covering the infrastructure layer only. Cloud security providers specializing in PCI DSS environments help organizations map inherited controls against residual compliance obligations.

Service provider chains: An entity that contracts with a subprocessor that handles cardholder data on its behalf must maintain agreements under PCI DSS Requirement 12.8 ensuring those third parties also comply. This third-party obligation connects PCI DSS directly to broader third-party risk management programs.

Decision boundaries

PCI DSS compliance does not constitute a government regulatory mandate in the same sense as statutes enforced by federal agencies. Enforcement flows through the card brands and acquiring banks — non-compliant entities face fines assessed by Visa and Mastercard, increased transaction fees, and potential loss of card acceptance privileges, not direct federal civil penalties.

PCI DSS and HIPAA operate in parallel where healthcare payment processing occurs — a medical provider processing card payments must satisfy both frameworks independently, as HIPAA's Security Rule (45 CFR §§ 164.302–164.318) and PCI DSS share control categories (access management, encryption, audit logging) but have distinct scoping rules and validation mechanisms. The HIPAA cybersecurity requirements framework governs protected health information independently of payment card data.

PCI DSS v4.0 also diverges from SOC 2 compliance in structure: SOC 2 is an attestation standard based on Trust Service Criteria that produces an auditor's opinion report, while PCI DSS produces either a Report on Compliance (ROC) or a completed SAQ — prescriptive checklists rather than principles-based criteria.

Organizations subject to CMMC compliance requirements for federal contracting must manage PCI DSS as a separate, commercially driven obligation that does not satisfy CMMC control domains.

References

Explore This Site

Regulations & Safety Regulatory References Tools & Calculators Password Strength Calculator