PCI DSS 4.0 Compliance: The Complete Guide for 2026

#The guide we wish existed when we started running PCI engagements

Two years into running PCI DSS 4.0 readiness engagements, I've read every official PCI Security Standards Council document, most of the Verizon Data Breach Investigations Report's PCI commentary, and a depressing number of QSA blog posts that were clearly written to fill a content calendar. Almost none of what I've read is useful to a merchant actually trying to get compliant.

The official docs are comprehensive and unreadable. The QSA blogs are full of good intentions and marketing dilution. The Council's FAQs answer the wrong questions. What a merchant actually needs is a single document that answers: what does 4.0 really require, what's the order of operations, and what's going to blow up in my first QSA meeting.

This is that document. It's long. PCI DSS 4.0 is 360 pages of official spec and another 280 pages of Customized Approach guidance. You get the cliff notes, written by people who audit against this framework for a living.

#Who this is for

You're reading the right post if any of these describe you.

• You take card payments directly. E-commerce, POS, mail-order, phone-order.
• You're a SaaS vendor that handles, stores, or transmits cardholder data for customers.
• You're a payment processor, payment facilitator, or independent software vendor in the payments space.
• You were compliant under PCI DSS 3.2.1 and your QSA just told you the 4.0 gap analysis is going to surprise you.
• You had a breach. Your assessor is insisting on a "PCI Forensic Investigator" engagement and you want to understand what they're about to find.
• You're building a new payments product and want to skip the "refactor to pass PCI" phase by designing it right the first time.

You're reading the wrong post if your business outsources all card handling to Stripe/Braintree/Adyen with zero card data ever touching your infrastructure. In that case PCI is mostly a procurement checkbox and a SAQ A. This guide goes deeper than you need.

#The 30-second summary

1. PCI DSS 4.0 is mandatory as of March 31, 2025. Transition window closed. 3.2.1 is officially retired.
2. 4.0 adds 64 new sub-requirements, tightens 53 existing ones, and introduces the Customized Approach as an alternative compliance path for mature programs.
3. Payment page script integrity (requirement 6.4.3 + 11.6.1) is the single most commonly failed control in 2026 assessments. If you run an e-commerce site, read that section first.
4. Targeted risk analyses are now mandatory for a dozen specific controls. The generic "annual risk assessment" doesn't satisfy them.
5. Penetration testing requirements got sharper. Segmentation validation specifically called out. Retesting after significant change now explicit.
6. MFA expanded beyond privileged users. "Any access to the CDE" triggers it.
7. Service provider obligations are now stricter than merchant obligations in several areas. If you're a service provider, you have more work.

Those seven points are the summary. The rest of this post unpacks each one.

#The levels and why they still matter

PCI DSS 4.0 still defines four merchant levels based on transaction volume.

• Level 1. More than 6 million Visa/Mastercard transactions per year. Requires annual on-site audit by a Qualified Security Assessor (QSA) producing a Report on Compliance (ROC).
• Level 2. 1-6 million transactions. Allows self-assessment but annual ASV scans and quarterly reviews are required. In practice most Level 2 merchants hire a QSA anyway because their acquirer requires it.
• Level 3. 20K-1M transactions. Self-assessment via Self-Assessment Questionnaire (SAQ). Annual.
• Level 4. Under 20K transactions. SAQ, but often less rigorous enforcement. Don't confuse "less enforced" with "not required."

Service providers have their own levels based on how many accounts they touch on behalf of merchants. Level 1 service providers are Level 1 regardless of their own transaction volume.

The level matters because it determines what evidence you have to produce. A Level 1 ROC is a multi-hundred-page document that takes months to assemble. A SAQ A is a short questionnaire you can complete in an afternoon. Misidentifying your level costs either money (doing too much) or compliance (doing too little and getting fined).

If you're unsure of your level, ask your acquiring bank. Not your processor, not Stripe. The acquirer assigns levels and their classification is binding.

#The twelve requirements at a glance

PCI DSS 4.0 preserves the twelve-requirement structure from every prior version. You've probably seen this list. Skip if you're familiar.

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.
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.

The structure hasn't changed in 20 years. The sub-requirements under each one are where the version-to-version changes live.

#What changed in 4.0 vs 3.2.1

The full change list is 64 new sub-requirements plus 53 clarified or strengthened ones. The ones that actually matter in practice fall into nine categories.

#1. Payment page script integrity (6.4.3 + 11.6.1)

The single most impactful change for e-commerce merchants. Every script that runs on a payment page, or on any page that accepts cardholder data, must be:

• Authorized. There's a documented approval process for adding scripts.
• Inventoried. You have a current list of every script on the page, with purpose.
• Integrity-verified. You have a technical mechanism that detects if any script has changed. Subresource Integrity (SRI) hashes, Content Security Policy, or a dedicated monitoring product.

This was added to address Magecart-style web skimming. Attackers inject malicious JavaScript into checkout pages and exfiltrate card data as customers type. It's been the top e-commerce breach pattern since 2015.

The most common failure on audit: merchant has 30 third-party scripts (analytics, tag manager, chat widget, retargeting pixel, review widget, A/B test tool, 20 more) and no mechanism to detect unauthorized changes to any of them. Each script is a Magecart attack surface.

Fix options, ranked by operational weight:

1. SRI hashes on every third-party script. Cheapest. Requires a CI pipeline step to regenerate hashes on script updates. Breaks if the third-party rolls out a new version and you don't know.
2. Strict Content Security Policy. \script-src\ locked to specific origins, no \unsafe-inline\, no \unsafe-eval\. Combined with CSP reporting to catch violations. Harder to deploy on legacy e-commerce platforms.
3. Dedicated script monitor. Jscrambler, Feroot, Sansec, or equivalent. Runs in the browser, detects unauthorized script changes in real time, alerts the security team. This is the approach most Level 1 merchants land on.
4. Rip out third-party scripts. The nuclear option. Bring analytics/tagging/etc. in-house. Works but takes months.

Most merchants we help pursue a hybrid: SRI where trivially possible, dedicated monitor for the 5-10 high-risk scripts, CSP in report-only mode while they clean up the chaos.

#2. Customized Approach

Entirely new in 4.0. Previously every PCI requirement was either met exactly or not met. 4.0 introduces a second path: if you can demonstrate that your alternative control achieves the same security outcome, you can argue the "Customized Approach" and pass on technical grounds.

The catch: the Customized Approach requires a fully documented Targeted Risk Analysis justifying each customized control, continuous assurance that the custom control keeps working, and a mature QSA partnership that's willing to assess it.

In practice, Customized Approach is for organizations with sophisticated security programs that genuinely have better controls than the Defined Approach specifies. A startup asking "can we use Customized Approach to skip annual pentesting" is going to get laughed out of the assessment.

If you're considering Customized Approach for any requirement, get your QSA's opinion before investing in the documentation. They need to be willing to assess it.

#3. Targeted Risk Analysis (12.3.1)

4.0 requires a Targeted Risk Analysis to be documented for each of the following control decisions:

• Frequency of operational security tasks (if different from Defined Approach)
• Specific CVV handling scenarios in pre-authorization
• Use of removable electronic media
• Scope of MFA (beyond the minimum required)
• Cryptographic protocol selection (beyond current NIST guidance)
• Anti-malware approach
• Scope of logs
• Software development practices
• Penetration testing scope and frequency

Each TRA must document what the risk is, why the chosen control mitigates it, how you monitor effectiveness, and how you reassess. A generic "we did a risk assessment in Q2" doesn't satisfy these. They're targeted, specific, and tied to a control decision.

The merchants that pass with grace have a template library. One template per TRA, filled in with the specifics for their environment. The merchants that fail spend three weeks writing TRAs during the assessment while the QSA holds everything else in a pending state.

#4. Pentesting (11.4)

Annual internal and external penetration testing was already a requirement in 3.2.1. 4.0 tightens the language:

• Segmentation controls must be validated via pentest. You can no longer claim segmentation without proving an attacker can't cross it.
• Retesting required after any "significant change" to in-scope systems. "Significant change" gets a specific definition. Network topology, access control, or system component changes.
• Pentests must address all vulnerabilities identified in the prior test or show compensating controls. You can't just run the same test year after year and ignore the findings.

Scope always matters. An internal pentest covers the CDE (cardholder data environment) and connected systems. External covers the public attack surface of the CDE. If your CDE is tightly segmented, external pentest scope is small. If it's not segmented (and we see this a lot), external pentest scope is your entire public infrastructure.

#5. MFA expansion (8.4)

3.2.1 required MFA for remote access into the CDE and for all administrative access. 4.0 expands this to "any access into the CDE by any account."

Practically, this means:

• Developer access to CDE systems for debugging. MFA required.
• DBA access to CDE databases. MFA required.
• Service accounts that programmatically touch the CDE. Now need to use strong authentication (client certs, OAuth with client credentials, API keys stored in a vault). Not traditional MFA, but the equivalent control is required.
• Network operations center staff accessing in-scope systems for monitoring. MFA required.

Phishing-resistant MFA (FIDO2 hardware keys, platform authenticators) is recommended but not mandated. SMS-based MFA is explicitly discouraged and will attract QSA scrutiny if you're using it for privileged access.

#6. Disk encryption for removable media (3.4.1)

Removable electronic media containing cardholder data must be encrypted with strong cryptography. Includes backup tapes, USB drives, portable drives, anything you'd carry out of the building.

Sounds obvious. Still missing on a lot of audits. Tape backup infrastructure especially, where the backup tapes live in an off-site rotation and nobody's checked whether the encryption is enabled in a decade.

#7. Phishing-resistant authentication for email (5.4)

New requirement. Anti-phishing mechanisms must be in place to protect against phishing attacks. Interpretation varies by QSA but most read it as:

• Email filtering that scans attachments and links
• User training program with measurable outcomes
• DMARC with \p=reject\ or \p=quarantine\ on the email domain

If you don't have DMARC at quarantine or reject on your corporate domain, this is a finding.

#8. Password changes (8.3.6 + 8.3.9)

4.0 updates the password policy requirements:

• Minimum length 12 characters (was 7 in 3.2.1).
• Passwords must be changed on suspicion of compromise, not on a fixed schedule.
• Lockout after no more than 10 invalid attempts.
• Multi-use of the previous four passwords forbidden.

The minimum length change is the one that bites. A lot of legacy systems can't enforce 12-character passwords without application changes.

#9. Vendor password management (8.2.2)

Accounts used for interactive login to systems by vendors and third parties require MFA and password rotation after each use. No more shared vendor accounts with static passwords.

#The high-pain controls in 2026 assessments

Based on engagements we ran through 2025 and Q1 2026, these are the requirements that caused the most grief:

#Requirement 6.4.3 (payment page scripts) — by a wide margin

We covered this above. It's the number one audit failure.

#Requirement 11.6.1 (payment page change detection)

Related but distinct from 6.4.3. You need a mechanism that alerts on any unauthorized change to HTTP headers or content on payment pages. This typically requires the same script monitor that 6.4.3 needs, but the alerting + response workflow is an added burden.

#Requirement 12.10.4 (incident response training)

The IR plan must be tested and personnel must be trained. A plan on a shared drive that nobody's read isn't going to pass. QSAs increasingly ask for training attendance records and tabletop exercise readouts.

#Requirement 12.6.3 (security awareness with phishing metrics)

Annual security awareness training has been a requirement for years. 4.0 expects documented outcomes. What percentage of staff completed, what the phishing simulation results were, how the program is improving. Generic "everyone watched the video" doesn't satisfy.

#Requirement 3.4.1 + 3.5.1 (cryptographic key management)

Stored cardholder data must be cryptographically protected and the keys must be managed properly. Key custodian duties assigned, key lifecycle documented, key rotation scheduled, keys split if strong. A lot of merchants have encrypted storage but the key management is hand-wavey.

#Requirement 10.5 (log protection)

Logs must be protected from tampering. A centralized SIEM with immutable storage satisfies this. Logs written to the same server that generates them do not.

#The order of operations

If you're building a PCI program from scratch, this is the sequence we walk clients through. Roughly 12-18 months end-to-end for a mid-market organization.

Phase 1 (months 1-3). Scope and baseline.

• Scope the Cardholder Data Environment. Draw the boundary on a network diagram, confirm what's in, what's out, and what's connected.
• Network segmentation. If the CDE isn't segmented from the rest of your corporate network, that's the biggest single reduction in audit surface you can make. Segmentation reduces scope.
• ASV scanning. Get an Approved Scanning Vendor running quarterly external scans of the CDE. Fix the criticals before anything else.
• Inventory. System components, software, third parties, data flows.
• Baseline SAQ or gap assessment against 4.0 controls. Know where you are.

Phase 2 (months 4-8). Technical control implementation.

• 6.4.3 + 11.6.1 payment page script integrity (if e-commerce)
• 3.4.1 + 3.5.1 stored data encryption + key management
• 8.4 MFA expansion
• 10.5 log centralization + protection
• 11.4 internal pentest
• 1.2 network segmentation validation

Phase 3 (months 9-12). Policy, training, governance.

• All required policies documented
• Targeted Risk Analyses for 12.3.1 items
• Incident response plan + tabletop
• Security awareness program with measurable outcomes
• Vendor management program

Phase 4 (months 13-18). Audit prep + execution.

• Internal audit dry run
• Evidence gathering
• QSA engagement (if Level 1) or SAQ (if self-assessing)
• Remediation of assessment findings
• Final ROC or SAQ

The timeline compresses if you have a mature security program already. Extends if you're starting from zero.

#The budget framework

Pure compliance costs (excluding underlying infrastructure):

• Level 1 merchant, fresh to PCI. $150K-$400K year one. QSA engagement ($75K-$150K), pentest ($20K-$50K), script integrity tool ($15K-$40K/year), policy work ($20K-$60K), consulting ($20K-$100K). Ongoing: $120K-$250K per year.
• Level 2 merchant. $50K-$150K year one. QSA + SAQ guidance often combined. Pentest + SAQ attestation annually. Ongoing: $30K-$80K per year.
• Level 3/4 merchant. $10K-$40K year one depending on complexity. Mostly SAQ completion cost + ASV scans + basic pentest.

These are hard numbers from real engagements. A QSA quoting you $15K for a Level 1 ROC is either lying to win the business or about to do the work badly.

#What to ask your QSA before you sign

Most merchants don't know how to evaluate a QSA. The questions that matter:

• How many Level 1 ROCs has your firm produced in the last three years?
• Who specifically from your firm will be our assigned assessor, and can I see their CV?
• What's your firm's posture on Customized Approach assessments?
• Do you use a standard evidence request template, and can I see it?
• What's your SLA on responding to evidence questions during the assessment?
• What percentage of your client ROCs have zero material findings on first pass?
• How do you handle scope disputes? Have you ever had a finding overturned by the PCI Council on appeal?

QSAs who can't answer those questions quickly should be a red flag.

#The PCI Forensic Investigation trap

If you have a breach, your acquirer will likely require a PCI Forensic Investigator (PFI) engagement. This is a different animal than a QSA. A PFI investigates the breach to determine scope and root cause, and their report gets filed with the card brands.

PFI findings can be brutal. The report will detail every gap between your attested PCI posture and the actual state of your environment at the time of the breach. Every gap is ammunition for card brand fines, acquirer termination, and (if you're big enough) class action lawsuits.

The best defense against a bad PFI report is consistent honesty in your SAQ/ROC. Every lie or shortcut in your compliance documentation becomes exhibit A when the PFI investigates.

#Common QSA-killing mistakes

From watching clients succeed and fail at PCI audits:

• Scoping too narrowly. Pretending the CDE doesn't include systems that actually touch cardholder data. QSAs find this in the network diagram review.
• Ignoring connected systems. The CDE is in scope, and so is any system that connects to it. People forget the jump host or the admin workstation.
• Having policies without evidence of execution. Policies that say you do quarterly access reviews, with no artifacts showing any review was done.
• Treating PCI as an annual event. 4.0 specifically calls out continuous compliance. An annual snapshot doesn't pass.
• Letting the QSA manage the process. You're responsible for the program. The QSA assesses it. Flipping that dynamic produces bad outcomes.

#Tools we deploy on most PCI engagements

The stack we see work at mid-market scale:

• Script integrity. Jscrambler or Feroot for the high-risk pages. SRI + CSP for the rest.
• SIEM. Splunk Enterprise, Elastic, or Microsoft Sentinel with immutable archive tier. Datadog works for smaller shops.
• Vulnerability management. Qualys or Tenable.io for ASV. Wiz or Lacework for cloud configuration.
• Log retention. 1 year online, 2 years archived, per PCI 10.7.
• Pentest. Annual external + internal. We run these; if we're not your QSA, any qualified testing firm works.
• Segmentation testing. Same pentest scope, explicit test of segmentation boundaries.
• Data discovery. Spirion, BigID, or Varonis scan for PAN (primary account numbers) in unexpected places. A shocking amount of cardholder data lives in tickets, emails, and shared drives.

#Closing

PCI DSS 4.0 is more work than 3.2.1 was. It's also more effective. The controls it adds are the ones that actually block the breach patterns the card brands have been tracking for the last five years. If you go through a full 4.0 compliance pass and implement the controls meaningfully (not just on paper), your real-world security posture materially improves.

The alternative is non-compliance, which means fines, acquirer termination, or a breach you don't recover from. None of those are cheaper than the compliance program.

If you need help running a PCI DSS 4.0 readiness assessment, implementing 6.4.3 + 11.6.1 payment page script integrity, or preparing for a QSA engagement, we run these engagements as our core compliance service. Valtik Studios has done 4.0 readiness work for merchants and service providers across retail, SaaS, and fintech.

Reach us at valtikstudios.com.