PCI DSS Compliance: A Complete Guide for 2026

Payment card security compliance changed shape in 2025. PCI DSS v4.0.1 is now the only valid version of the standard, and as of 31 March 2025, every requirement it contains — including a set of provisions that were originally future-dated — is mandatory. There is no longer a “we’ll get to that requirement later” grace period. If your organization stores, processes, or transmits cardholder data, this is the standard you are held to today, in full.

This guide covers what PCI DSS actually requires, who it applies to, how compliance levels are assigned, and how the assessment process works — the practical mechanics, not just the acronym.

What PCI DSS Covers and Who Must Comply

PCI DSS (Payment Card Industry Data Security Standard) is a security standard maintained by the PCI Security Standards Council, a body created by the major card brands — Visa, Mastercard, American Express, Discover, and JCB. It is important to be precise about what that means: PCI DSS is not a government regulation. It is a contractual requirement, enforced through your merchant agreement with your acquiring bank and, ultimately, through the card brands themselves. Non-compliance does not bring a government fine — it brings contractual penalties, higher transaction fees, and in serious cases the loss of your ability to accept card payments at all.

The standard applies to any entity that stores, processes, or transmits cardholder data (the primary account number, and in some flows the cardholder name, expiration date, and service code) or sensitive authentication data (full magnetic stripe data, CVV/CVC codes, PINs). That scope is broad by design:

• Merchants of any size that accept card payments, online or in person.
• Payment processors and gateways that route or handle transactions on a merchant’s behalf.
• Service providers that store, process, or transmit cardholder data for another organization — this includes many SaaS platforms, hosting providers, and call centers that touch card data incidentally.
• Their vendors and sub-processors, if cardholder data flows through them.

A common and costly mistake is assuming that outsourcing payment processing to a third party (Stripe, Adyen, a hosted checkout page) removes you from scope entirely. It reduces scope — often substantially — but it rarely eliminates it. If your systems ever touch, store, or influence the handling of cardholder data, you retain some PCI DSS obligation, even if it is a lighter-weight SAQ.

The 12 Requirements at a Glance

PCI DSS organizes its controls into 12 top-level requirements, grouped into six control objectives. The requirement numbers have stayed consistent across versions, which is why practitioners still refer to “Requirement 3” or “Requirement 11” as shorthand years after the standard has otherwise changed underneath them.

1. Install and maintain network security controls — firewalls and equivalent controls between untrusted networks and the cardholder data environment (CDE).
2. Apply secure configurations to all system components — no vendor-default passwords or unnecessary services.
3. Protect stored account data — encryption, truncation, masking, or tokenization of stored cardholder data; strict limits on retention.
4. Protect cardholder data with strong cryptography during transmission over open, public networks.
5. Protect all systems and networks from malicious software — anti-malware controls, kept current.
6. Develop and maintain secure systems and software — secure development practices, including protections for payment pages and scripts against tampering (a requirement significantly strengthened in v4.0.1 in response to e-skimming attacks).
7. Restrict access to system components and cardholder data by business need to know — least privilege as a baseline, not an aspiration.
8. Identify users and authenticate access to system components — including multi-factor authentication requirements that expanded meaningfully under v4.0.1.
9. Restrict physical access to cardholder data — physical security controls for media, devices, and facilities.
10. Log and monitor all access to system components and cardholder data — centralized, reviewed logging, with v4.0.1 pushing toward automated log review rather than manual spot checks.
11. Test the security of systems and networks regularly — vulnerability scanning (including mandatory quarterly external scans by an Approved Scanning Vendor), and penetration testing.
12. Support information security with organizational policies and programs — the governance layer: documented policy, risk assessment, incident response, and a formal security awareness program.

Version 4.0.1 did not renumber or replace these 12 requirements — the headline change is underneath them. There are now roughly 500 sub-requirements across the 12 domains, and the new material clusters around six themes: payment page and script integrity (Requirement 6), stronger authentication (Requirement 8), automated log review (Requirement 10), more rigorous vulnerability management (Requirement 11), tighter scope-definition discipline, and a shift toward formalized, ongoing risk analysis rather than a once-a-year checklist exercise.

Compliance Levels by Transaction Volume

Not every organization in scope for PCI DSS is validated the same way. The card brands assign a merchant level based on annual transaction volume across all channels, and that level determines how rigorously — and how independently — compliance must be validated.

Two caveats matter more than the table itself. First, your acquiring bank has the final say on your level and validation requirements — the thresholds above are the common industry framing, but an acquirer can require stricter validation than volume alone would suggest, particularly after a breach. Second, all levels can be required to run quarterly external vulnerability scans through an Approved Scanning Vendor (ASV), regardless of whether the rest of validation is a self-assessment or a full audit. Volume determines the depth of the audit; it does not exempt anyone from ongoing technical testing.

The Assessment Process (SAQ vs QSA)

The two validation paths differ in who performs the assessment and how much independent scrutiny it carries.

Self-Assessment Questionnaire (SAQ). This is the path for most Level 2–4 merchants. It is a structured questionnaire — there are multiple SAQ types (A, A-EP, B, C, D, and others) depending on how your organization handles cardholder data, and choosing the wrong SAQ type is one of the most common compliance mistakes. A fully outsourced, hosted-checkout e-commerce merchant with no cardholder data touching its own systems might qualify for the lightest SAQ type; a merchant that processes card data directly on its own servers will land on the most comprehensive one. The SAQ is self-validated — your organization attests to its own compliance — but that does not make it optional or low-stakes: a false attestation carries real contractual and reputational risk if a breach later reveals the attestation was inaccurate.

Qualified Security Assessor (QSA) assessment. Level 1 merchants (and some Level 2 merchants, depending on the card brand and acquirer) require an independent, formal assessment conducted by a QSA — an individual certified by the PCI Security Standards Council to perform PCI DSS assessments. The QSA reviews evidence, tests controls, and produces a Report on Compliance (ROC), a much more detailed document than an SAQ attestation. Some organizations with the internal expertise and independence can instead complete an Internal Security Assessor (ISA)-led assessment, but this is the exception rather than the rule.

A structural point that is easy to miss: PCI DSS v4.0.1 explicitly frames compliance as continuous, not annual. The assessment — SAQ or ROC — is a point-in-time snapshot, but the underlying expectation is that controls are operating and documented year-round. “We assembled the evidence the week before the audit” is precisely the pattern the standard is designed to catch and increasingly does, through requirements like automated (rather than manual, periodic) log review.

PCI DSS Alongside ISO 27001 or SOC 2

Organizations that already carry an ISO 27001 certification or a SOC 2 report often ask whether PCI DSS is redundant on top of that work. It is not redundant, but it is substantially reusable.

The overlap is real: all three frameworks expect a documented risk assessment process, formal access control, security logging and monitoring, incident response procedures, and oversight of third-party vendors. If your ISO 27001 Information Security Management System (ISMS) or your SOC 2 control environment is mature, a meaningful share of that evidence — policies, risk registers, access review records, vendor due-diligence documentation — maps directly onto PCI DSS Requirement 12 (organizational policy) and Requirement 7/8 (access and authentication).

Where PCI DSS diverges is specificity. ISO 27001 and SOC 2 are largely control-objective frameworks: they tell you what outcome to achieve and leave the technical implementation to you. PCI DSS is far more prescriptive about the how for anything touching cardholder data — specific encryption requirements for stored data, mandatory network segmentation for the cardholder data environment, quarterly external scanning cadence, and detailed rules about what can and cannot be stored (full magnetic stripe data and CVV codes, for example, can never be stored post-authorization, full stop). An organization should treat PCI DSS as a card-data-scoped overlay on top of a broader compliance program, mapped against frameworks like GDPR, ISO 27001, and SOC 2 in a multi-framework governance program, rather than a separate program built from scratch.

The Practical Takeaway

Three things matter more than memorizing the requirement numbers. First, know your actual cardholder data footprint — most organizations either overestimate their scope (and pay for controls they do not need) or underestimate it (and carry undocumented risk) because nobody has mapped where card data actually flows. Second, treat validation as a snapshot of a program that runs continuously, not a project that starts a month before the deadline. Third, if you already run ISO 27001 or SOC 2, build PCI DSS as an addition to that governance structure rather than a parallel one — the redundant effort of maintaining two disconnected compliance programs is where most of the wasted cost in this space actually comes from.

This guide reflects PCI DSS v4.0.1, the current and only active version of the standard as of this writing. PCI DSS requirements, SAQ eligibility criteria, and validation thresholds are set and updated by the PCI Security Standards Council and the individual card brands — always confirm current requirements against the PCI Security Standards Council and your acquiring bank before making compliance decisions.