Keep PCI DSS requirements passing even as your CDE evolves

What is PCI DSS?

The Payment Card Industry Data Security Standard -- universally known as PCI DSS -- is the global baseline for protecting payment card data. Any organization that stores, processes, or transmits cardholder data is expected to meet PCI DSS, from a mom-and-pop e-commerce store to a Fortune 500 retailer and every payment processor in between. PCI DSS exists because card data is one of the most monetizable targets on the internet, and a single breach can expose millions of account numbers, trigger steep fines, and end businesses. PCI DSS translates decades of hard-won lessons into a prescriptive framework that security, engineering, and finance teams can operationalize.

PCI DSS is maintained by the Payment Card Industry Security Standards Council (PCI SSC), an independent standards body founded in 2006 by the five major payment brands: Visa, Mastercard, American Express, Discover, and JCB. The PCI SSC writes and publishes the standard, accredits assessors and scanning vendors, and runs supporting programs such as PA-DSS (now replaced by the PCI Secure Software Standard) and P2PE. While the PCI SSC owns the standard itself, it does not enforce PCI DSS. Enforcement is delegated to the card brands, which in turn push obligations down through acquiring banks and payment processors to merchants and service providers. In practice, your acquirer is the entity that tells you which PCI DSS validation path you owe and what happens if you fail it.

PCI DSS emerged from a patchwork of brand-specific programs in the early 2000s, including Visa's Cardholder Information Security Program (CISP) and Mastercard's Site Data Protection (SDP). PCI DSS v1.0 launched in December 2004. PCI DSS v2.0 arrived in 2010, v3.0 in 2013, v3.1 in 2015, v3.2 in 2016, v3.2.1 in 2018, and the long-anticipated PCI DSS v4.0 in March 2022, followed by v4.0.1 clarifications in June 2024. Organizations have until March 31, 2025 to fully meet the new "future-dated" PCI DSS v4.0 requirements. Each revision tightens controls around emerging threats: phishing-resistant authentication, e-commerce script tampering, automated log review, and customized approaches for mature security programs.

The 12 PCI DSS requirements

PCI DSS organizes technical and operational controls across twelve core requirements grouped into six objectives. The full set of PCI DSS requirements is detailed on the PCI DSS requirements page; at a glance they are:

1. Install and maintain network security controls -- firewalls and equivalent controls around the cardholder data environment.
2. Apply secure configurations to all system components -- hardening standards, default credential elimination, and secure build baselines.
3. Protect stored account data -- encryption, truncation, hashing, or tokenization of the PAN and prohibition on storing sensitive authentication data.
4. Protect cardholder data with strong cryptography during transmission over open, public networks.
5. Protect all systems and networks from malicious software -- anti-malware on in-scope systems and defenses against script-based threats.
6. Develop and maintain secure systems and software -- secure SDLC, patching, and vulnerability management for in-scope systems.
7. Restrict access to system components and cardholder data by business need to know -- least-privilege role design.
8. Identify users and authenticate access to system components -- unique IDs, strong authentication, and phishing-resistant MFA.
9. Restrict physical access to cardholder data -- physical security for facilities, media, and devices.
10. Log and monitor all access to system components and cardholder data -- centralized logging, daily review, and tamper protection.
11. Test security of systems and networks regularly -- ASV scans, internal scans, pen tests, and segmentation validation.
12. Support information security with organizational policies and programs -- governance, awareness, incident response, and third-party oversight.

Each PCI DSS requirement is broken into numbered sub-requirements with explicit testing procedures that an assessor follows line by line. The "defined approach" dictates specific controls; PCI DSS v4.0 also introduces a "customized approach" where mature organizations can meet a requirement's objective through alternative controls, documented in a controls matrix and targeted risk analysis.

PCI DSS v4.0 changes

PCI DSS v4.0 is the largest revision in more than a decade. Its headline shifts include a customized-approach validation path, mandatory multi-factor authentication for all access into the CDE, expanded requirements to detect and respond to e-commerce script tampering, targeted risk analyses replacing prescriptive frequencies, and stronger expectations for continuous security rather than point-in-time compliance. Several of the most material v4.0 controls became mandatory on March 31, 2025 after a two-year grace period. The full changelog, new testing procedures, and a migration checklist are covered in the PCI DSS v4.0 changes guide.

Merchant compliance levels 1-4

Every merchant is assigned to one of four PCI DSS compliance levels based on annual card transaction volume across all channels. PCI DSS Level 1 covers merchants processing more than 6 million transactions per year and requires a formal Report on Compliance (ROC) signed by a QSA. Level 2 covers 1-6 million transactions. Level 3 covers 20,000 to 1 million e-commerce transactions. Level 4 covers everything below those thresholds. Service providers have their own two-level structure. Your acquiring bank can also assign you a higher PCI DSS level at its discretion -- particularly after a breach. The PCI DSS compliance levels page breaks down every threshold by card brand and the validation path each level owes.

Self-Assessment Questionnaires (SAQs)

Merchants and service providers that are not required to complete a full PCI DSS Report on Compliance validate using a Self-Assessment Questionnaire, or SAQ. The PCI SSC publishes nine SAQ types, each tailored to a specific acceptance channel and technology profile:

• SAQ A -- card-not-present merchants that fully outsource all cardholder data functions.
• SAQ A-EP -- e-commerce merchants that partially outsource payment processing but host pages that could affect payment page security.
• SAQ B -- merchants using only imprint machines or standalone dial-out terminals.
• SAQ B-IP -- merchants using only standalone IP-connected POI devices.
• SAQ C-VT -- merchants entering transactions into a virtual payment terminal.
• SAQ C -- merchants with payment application systems connected to the internet.
• SAQ P2PE -- merchants using PCI-listed point-to-point encryption solutions.
• SAQ D for Merchants and SAQ D for Service Providers -- the catch-all SAQs for entities that store cardholder data or do not qualify for a simpler SAQ.

Eligibility is narrow and precise. Picking the wrong SAQ is one of the most common PCI DSS mistakes -- and one that an acquiring bank or breach investigation can expose instantly. The SAQ reference and the SAQ types explained page walk through each SAQ's eligibility, question count, and typical pitfalls.

Cardholder data environment (CDE) and scoping

Every PCI DSS program begins with scoping. The cardholder data environment, or CDE, is the set of people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data, plus any system component that is connected to or could impact the security of those components. Determining what is in PCI scope is the single highest-leverage activity in a PCI DSS program -- it drives how many controls apply, how much evidence you collect, and how much your QSA engagement costs.

PCI DSS scoping has three categories: CDE systems that directly handle card data; connected-to systems that can route traffic to the CDE, authenticate CDE users, or otherwise interact with CDE components; and security-impacting systems that could affect CDE security even without direct connectivity (think SIEM, patch management, or anti-malware consoles). All three categories are in scope for PCI DSS.

Document your CDE with an annotated network diagram and a data-flow diagram for every payment channel. PCI DSS v4.0 makes these diagrams a requirement, not a nice-to-have, and your assessor will test them during every assessment.

Scope reduction strategies

Because PCI DSS obligations scale with the CDE, shrinking the CDE is the fastest way to cut PCI DSS cost and risk. Effective PCI DSS scope reduction typically combines four levers: strong network segmentation that isolates the CDE onto dedicated VLANs with tightly controlled firewall rules; tokenization that replaces stored PANs with non-sensitive surrogates; PCI-listed point-to-point encryption (P2PE) that removes in-store networks from PCI scope; and outsourcing card capture to a validated service provider so your systems never touch real card data. Layered correctly, these strategies can reduce a PCI DSS assessment from hundreds of in-scope systems to a handful.

Key PCI DSS roles: QSAs, ASVs, and ISAs

Three accredited roles support every PCI DSS program:

• Qualified Security Assessors (QSAs) -- individuals and firms certified by the PCI SSC to perform on-site PCI DSS assessments, produce the ROC, and sign the Attestation of Compliance. Selecting the right QSA shapes your PCI DSS experience for years; the QSA selection guide covers how to evaluate firms, cost drivers, and red flags.
• Approved Scanning Vendors (ASVs) -- PCI SSC-approved firms that run the quarterly external vulnerability scans required by PCI DSS Requirement 11.3.2. The ASV program guide covers vendor selection, scanning cadence, passing thresholds, and remediation workflows.
• Internal Security Assessors (ISAs) -- employees who have completed PCI SSC training and can complete certain internal PCI DSS assessments or support a QSA engagement. ISAs are a cost-effective way to build PCI DSS capability inside large programs.

Penetration testing (Requirement 11.4) sits alongside ASV scanning and is a frequent source of PCI DSS findings. The PCI DSS penetration testing guide covers internal vs external scope, segmentation testing, and frequency.

Penalties for non-compliance

PCI DSS is not law, but non-compliance carries material financial consequences. Acquirers can levy fines of $5,000 to $100,000 per month for PCI DSS violations, pass fines down to merchants, raise transaction fees, or revoke payment processing privileges outright. After a confirmed breach of card data, a merchant typically faces a forensic PFI investigation, card brand fines, assessments for fraud losses, reissuance costs for compromised cards, and mandatory Level 1 PCI DSS validation going forward. Regulators and state attorneys general may also get involved, and the organization almost always faces litigation. In short, PCI DSS fines are rarely the largest line item -- the true cost of a breach is reputational damage, customer churn, and the fully loaded cost of breach response.

PCI DSS vs other frameworks

PCI DSS is narrower and more prescriptive than most security frameworks. ISO 27001 is a management-system standard focused on the process of running an ISMS; it tells you how to manage risk but does not specify controls the way PCI DSS does. SOC 2 is an attestation framework where you define your own controls against the Trust Services Criteria; PCI DSS prescribes them. HIPAA and HITECH cover protected health information, not cardholder data. NIST CSF and NIST SP 800-53 offer control catalogues and risk management guidance that many organizations map into their PCI DSS program, especially under the v4.0 customized approach. PCI DSS is also one of the few frameworks with ongoing external validation -- ASV scans every quarter, penetration tests at least annually, and a full assessment every year. For businesses in the finance industry or running e-commerce platforms, PCI DSS almost always becomes the binding constraint that the rest of the security program organizes around.

Getting PCI compliant

A typical path to PCI DSS compliance looks like this:

1. Define scope -- inventory every place card data lives, moves, or could move. Produce annotated network and data-flow diagrams.
2. Reduce scope -- apply segmentation, tokenization, P2PE, and outsourcing to shrink the CDE before assessment.
3. Select your validation path -- confirm your PCI DSS level with your acquirer and determine whether you owe a ROC or an SAQ.
4. Gap assess -- map your current controls to every applicable PCI DSS requirement and prioritize remediation.
5. Remediate and document -- close gaps, write the policies and procedures PCI DSS expects, and stand up the logging, monitoring, scanning, and testing programs.
6. Engage your QSA or ASV -- commission the ASV scans, book the penetration test, and (for Level 1) schedule your QSA engagement early enough to allow remediation cycles.
7. Validate and attest -- produce the ROC or SAQ plus Attestation of Compliance, and submit to your acquirer on the required cadence.
8. Operate continuously -- PCI DSS v4.0 expects continuous monitoring, targeted risk analyses, and evidence that controls stay effective between assessments.

episki automates the bulk of the evidence collection, control testing, and QSA collaboration work so your PCI DSS program is audit-ready year-round instead of scrambling at the end of each cycle. If you are starting a new PCI DSS program or rebuilding an existing one, episki can shorten your path from scoping through Report on Compliance.