PCI DSS Reference

The Payment Card Industry Data Security Standard (PCI DSS) is a contractual security framework governing how organizations store, process, and transmit payment card data. Administered by the PCI Security Standards Council (PCI SSC), the standard applies to every entity in the payment card ecosystem — merchants, processors, acquirers, issuers, and service providers. Non-compliance exposes organizations to fines, card brand penalties, and the loss of card acceptance privileges. This page describes the standard's structure, classification system, operational mechanics, and the boundaries that distinguish it from adjacent regulatory regimes.

Definition and scope

PCI DSS defines a minimum baseline of security controls for any organization that handles cardholder data (CHD) or sensitive authentication data (SAD). The standard is maintained and published by the PCI Security Standards Council (PCI SSC), a body founded in 2006 by American Express, Discover, JCB International, Mastercard, and Visa. The current version is PCI DSS v4.0, published in March 2022, with a transition deadline from v3.2.1 that concluded in March 2024 (PCI SSC, PCI DSS v4.0 Resource Hub).

The standard's scope is defined by the cardholder data environment (CDE): any system component that stores, processes, or transmits CHD or SAD, plus any system that connects to or could affect the security of those components. CHD includes the primary account number (PAN), cardholder name, expiration date, and service code. SAD includes full track data, card verification values (CVV/CVC), and PINs — none of which may be stored after authorization under any circumstances.

PCI DSS applies regardless of organization size or transaction volume, though compliance validation requirements scale with merchant level. The Federal Trade Commission references PCI DSS in enforcement actions involving inadequate payment security, and several state attorneys general have cited the standard in data breach litigation contexts, though PCI DSS itself is a contractual obligation enforced by the card brands rather than a federal statute.

How it works

PCI DSS v4.0 is organized into 12 principal requirements grouped under 6 control objectives:

  1. Install and maintain network security controls — firewalls, routers, and segmentation controls protecting the CDE.
  2. Apply secure configurations to all system components — elimination of default credentials and unnecessary services.
  3. Protect stored account data — encryption, masking, and prohibition on SAD retention post-authorization.
  4. Protect cardholder data with strong cryptography during transmission — TLS 1.2 or higher is required for data in transit over open networks.
  5. Protect all systems and networks from malicious software — anti-malware controls on all applicable components.
  6. Develop and maintain secure systems and software — vulnerability management and secure development lifecycle (SDLC) practices.
  7. Restrict access to system components and cardholder data by business need to know — role-based access control (RBAC) principles.
  8. Identify users and authenticate access to system components — multi-factor authentication (MFA) is required for all access into the CDE as of PCI DSS v4.0 (PCI SSC, Requirement 8.4).
  9. Restrict physical access to cardholder data — controls governing physical media, data center access, and point-of-interaction (POI) devices.
  10. Log and monitor all access to system components and cardholder data — audit log retention for a minimum of 12 months, with 3 months immediately available.
  11. Test security of systems and networks regularly — penetration testing, vulnerability scanning, and intrusion detection.
  12. Support information security with organizational policies and programs — documented security policies reviewed at least once per 12 months.

Compliance is validated through one of three mechanisms depending on merchant or service provider level: a Self-Assessment Questionnaire (SAQ), an internal audit using the Report on Compliance (ROC) template, or an on-site assessment conducted by a Qualified Security Assessor (QSA) — a certification administered by PCI SSC.

Common scenarios

Merchant card acceptance: A retail merchant processing card-present transactions via a point-of-sale (POS) terminal scoped under PCI DSS must assess whether the terminal is listed on the PCI SSC's Validated Payment Terminals list, and confirm that the network segment hosting the POS is isolated from general business systems.

E-commerce and card-not-present: Online merchants that redirect customers to a third-party payment page may qualify for SAQ A, the most limited self-assessment form, provided no CHD touches the merchant's own servers. Merchants that host their own payment forms face a significantly expanded scope and typically require an SAQ D or full QSA engagement.

Service providers: A cloud hosting company, managed security service provider (MSSP), or payment gateway that stores, processes, or transmits CHD on behalf of other entities qualifies as a service provider under PCI SSC definitions and faces Level 1 validation requirements above 300,000 transactions annually — including an annual ROC and quarterly network scans by an Approved Scanning Vendor (ASV).

Organizations navigating compliance assessments can cross-reference Digital Security Listings to identify qualified assessment and scanning providers within the PCI SSC ecosystem.

Decision boundaries

PCI DSS is frequently confused with or compared against other security and privacy frameworks. Three boundaries are operationally significant:

PCI DSS vs. HIPAA Security Rule: HIPAA (45 CFR Part 164) governs protected health information (PHI) in healthcare contexts. A hospital that accepts card payments must satisfy both frameworks independently — HIPAA does not substitute for PCI DSS, and PCI DSS compliance does not satisfy HIPAA obligations.

PCI DSS vs. NIST CSF: The NIST Cybersecurity Framework (CSF) is a voluntary risk management framework applicable across all sectors. PCI DSS is a prescriptive, mandatory contractual standard with specific technical controls. Organizations may map PCI DSS controls to NIST CSF categories for enterprise reporting purposes, but NIST CSF alignment does not constitute PCI DSS compliance.

PCI DSS vs. SOC 2: A SOC 2 audit, governed by the American Institute of Certified Public Accountants (AICPA) Trust Services Criteria, evaluates controls over security, availability, processing integrity, confidentiality, and privacy for service organizations. SOC 2 Type II reports are evidence of a control environment, not PCI DSS compliance. Card brands do not accept SOC 2 reports in lieu of PCI DSS validation.

The Digital Security Authority directory purpose and scope provides additional context on how compliance frameworks are classified within this reference network. Professionals seeking QSA or ASV firms can begin at Digital Security Listings for sector-structured firm categories. Background on navigating these resources is available at How to Use This Digital Security Resource.

References

Read Next

Digital Security Listings Coverage spans the full range of service categories recognized under the NIST Cybersecurity Framework — from managed detection... Digital Security Directory: Purpose and Scope This page defines the directory's inclusion criteria, classification logic, geographic scope, and navigation structure. How to Use This Digital Security Resource This page describes how the directory is organized, how content is classified and verified, and how different professional...