PCI DSS Cybersecurity Requirements Reference

The Payment Card Industry Data Security Standard (PCI DSS) establishes the technical and operational requirements that organizations must satisfy to protect cardholder data during storage, processing, and transmission. Maintained by the PCI Security Standards Council, the standard applies to any entity that stores, processes, or transmits payment card data — from large financial institutions to small merchants. Non-compliance exposes organizations to fines, elevated transaction fees, and potential loss of card-acceptance privileges.

Definition and scope

PCI DSS is a contractual security framework developed and maintained 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, PCI DSS v4.0, was published in March 2022 and superseded v3.2.1, which reached end-of-life in March 2024.

Scope under PCI DSS is defined by the cardholder data environment (CDE): all system components, people, and processes that store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD), plus any system that can affect the security of those components. Reducing scope — through network segmentation, tokenization, or point-to-point encryption — directly reduces compliance burden and audit surface. The standard applies across six goal categories and 12 high-level requirements, organized into 300+ individual sub-requirements in v4.0.

Merchant compliance levels are tiered by annual transaction volume. Level 1 merchants process more than 6 million transactions per year and must complete an annual Report on Compliance (ROC) conducted by a Qualified Security Assessor (QSA). Levels 2 through 4 use a Self-Assessment Questionnaire (SAQ), with the appropriate SAQ type determined by the payment channel in use. Service providers that store, process, or transmit cardholder data on behalf of others face separate, generally more stringent, validation requirements.

Professionals navigating vendor selection within this space can reference the Advanced Security Providers to identify qualified assessors and service providers operating under relevant compliance frameworks.

How it works

PCI DSS compliance operates through a structured cycle of scoping, assessment, remediation, and reporting. The 12 requirements map against six control objectives defined by the PCI SSC:

1. Build and maintain a secure network and systems — Install and maintain a firewall configuration; do not use vendor-supplied defaults for passwords or other security parameters.
2. Protect cardholder data — Protect stored cardholder data; encrypt transmission of cardholder data across open, public networks.
3. Maintain a vulnerability management program — Protect all systems against malware; develop and maintain secure systems and software.
4. Implement strong access control measures — Restrict access to system components and cardholder data by business need to know; identify and authenticate access to system components; restrict physical access to cardholder data.
5. Regularly monitor and test networks — Log and monitor all access to system components and cardholder data; test security of systems and networks regularly.
6. Maintain an information security policy — Support information security with organizational policies and programs.

Under v4.0, organizations have the option to satisfy a requirement through a "customized approach" — documenting an alternative control that meets the stated objective — in contrast to the traditional "defined approach," which prescribes specific implementation methods. This dual-path model is a structural shift from prior versions and requires documented risk analysis for each customized control.

Assessments are conducted either by an internal security assessor (ISA), a QSA, or through self-assessment. Penetration testing is required at least once per year and after significant infrastructure changes, per Requirement 11.4. Quarterly external vulnerability scans must be conducted by an Approved Scanning Vendor (ASV) verified by the PCI SSC.

The outlines how professional providers in the cybersecurity sector are classified and organized for service seekers researching qualified compliance vendors.

Common scenarios

Merchant operating a card-present retail environment: A brick-and-mortar retailer accepting chip-and-PIN transactions through a validated point-to-point encryption (P2PE) solution may qualify for SAQ P2PE, the shortest self-assessment questionnaire, with approximately 35 questions versus the 329 questions in SAQ D for merchants.

E-commerce merchant using a payment page hosted by a third party: If cardholder data entry occurs entirely on a PCI DSS-compliant third-party page and the merchant never receives raw cardholder data, the merchant may qualify for SAQ A, which covers roughly 22 requirements. If any merchant-controlled scripts run on the payment page, SAQ A-EP applies instead — a materially more demanding path addressing client-side script integrity under Requirement 6.4.3 of v4.0.

Service provider storing cardholder data for multiple clients: A service provider storing CHD on behalf of clients must validate compliance annually through either a QSA-conducted ROC or, for Level 2 service providers, an SAQ D for Service Providers. Service providers must also support their clients' compliance by documenting which PCI DSS requirements fall under the service provider's responsibility and which remain the client's obligation — formalized through the "responsibility matrix" structure.

Software vendor developing payment applications: Payment software is assessed under the PCI Software Security Framework (SSF), specifically the Secure Software Standard and the Secure Software Lifecycle (Secure SLC) Standard, both maintained by the PCI SSC. This is distinct from PCI DSS itself.

Decision boundaries

The distinction between PCI DSS and adjacent frameworks determines which assessment path applies. ISO/IEC 27001 addresses general information security management systems and does not substitute for PCI DSS in card-processing contexts. NIST SP 800-53 (csrc.nist.gov) provides federal information system controls and is frequently mapped against PCI DSS requirements but carries no standalone compliance equivalence for payment card environments.

Tokenization and encryption affect scope differently: encryption of stored data reduces risk but does not remove data from scope if the encryption keys are managed within the CDE. Tokenization that replaces the PAN with a non-reversible token can remove the token itself from scope, but the tokenization system remains in scope.

Organizations using cloud infrastructure must apply the PCI DSS Cloud Computing Guidelines to determine which controls are the cloud service provider's responsibility versus the customer's — this shared responsibility model is not assumed; it must be contractually documented.

For professionals researching how compliance services are organized and referenced within the cybersecurity sector, the Advanced Security Resource overview provides context on how this reference network is structured.