PCI DSS 4.0: The March 2025 Mandate That's Still Biting E-Commerce

Why this still matters in 2026

The PCI Security Standards Council released PCI DSS 4.0 in March 2022. The industry got a three-year transition window. March 31, 2025 was the hard deadline after which 4.0 compliance became mandatory for every organization that stores, processes, or transmits payment card data.

One year after the deadline, a lot of merchants are still out of compliance. QSAs are assessing stricter than the transition period let merchants get away with. Payment processors — Visa, Mastercard, Amex, Discover — are issuing non-compliance notices at a pace we haven't seen since the original PCI DSS rollout in 2006. And merchants are discovering that the things they were grandfathered on during the 3.2.1 regime no longer fly.

If you run an e-commerce site, a payment platform, a SaaS business that handles card data, a retail business with a point-of-sale system, or any fintech that touches card transactions, this post is for you. It covers what actually changed, what's biting merchants in assessments right now, and how to get your program where it needs to be.

The high-level picture: 4.0 vs 3.2.1

PCI DSS has always had 12 high-level requirements organized into six "goals." 4.0 preserves this structure. The requirements are:

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
8. Identify users and authenticate access
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

What changed structurally in 4.0:

• More sub-requirements. 4.0 has ~260+ sub-requirements versus 3.2.1's ~230.
• "Customized Approach" option allowing merchants to implement alternative controls if they can demonstrate equivalent security. This is new and widely misunderstood.
• Annual scope confirmation. Merchants must annually document and confirm what systems are in scope.
• Much more emphasis on targeted risk analyses. Where 3.2.1 accepted general risk assessments, 4.0 requires specific targeted analyses for specific control decisions.
• Greater testing rigor. Penetration testing, vulnerability scanning, and authenticated scanning requirements are all tightened.

The specific changes that are causing the most pain in 2026 compliance assessments:

The requirements biting merchants hardest

Requirement 6.4.3 — Payment page script integrity

This is the single most commonly failed requirement in 2026. Every script on any payment page (or page that accepts card data) must be:

• Authorized (there must be a documented process approving each script)
• Integrity-verified (tools like SRI hashes, CSP nonces, or third-party solutions that continuously verify script integrity)
• Documented (inventory of all scripts with purpose)

Why it's hard: most e-commerce merchants have 20-50 third-party scripts on their pages — analytics, tag managers, chat widgets, A/B testing tools, retargeting pixels, review widgets. Each one needs to be inventoried, approved, and integrity-protected.

Why it was added: the Magecart / web-skimming attack pattern, where attackers inject malicious JavaScript into checkout pages and exfiltrate card data as customers type it. Magecart attacks have plagued e-commerce since ~2015 and remain a primary breach vector.

The fix:

• Inventory every script. Chrome DevTools, dedicated tools like Feroot, Jscrambler, or Sansec can help.
• Implement Subresource Integrity (SRI) hashes for every third-party script
• Deploy a CSP (Content Security Policy) with strict script-src restrictions
• Use a script-monitoring solution — continuous monitoring for unauthorized script changes
• Document the approval process for adding or modifying scripts

This alone is a multi-week project for most e-commerce merchants.

Requirement 8.3.6 — MFA for all non-console access

Previously, MFA was required for remote access to the cardholder data environment (CDE). In 4.0, MFA is required for all non-console access into the CDE — not just remote, but any non-console access, including from within the corporate network.

Why it's hard: many merchants had internal "trusted network" access to their CDE where a single authenticated session on the corporate network gave broad access without additional MFA. 4.0 requires MFA at the CDE boundary regardless of where you came from.

The fix: deploy MFA at every CDE entry point. Prefer hardware-based MFA (FIDO2/WebAuthn) over TOTP or SMS. Ensure service accounts also have appropriate authentication (this often means moving away from static passwords for service accounts toward ephemeral credentials).

Requirement 8.4.2 — MFA for all non-console access, including internal

Related to 8.3.6 but specifically about the breadth. The previous version accepted "MFA for administrative access" as the scope. 4.0 expanded this to essentially all access to the CDE beyond direct console access.

The practical implication: your PCI DSS scope needs to be clearly delineated, and the CDE boundary needs actual enforcement. Loose scope definitions from the 3.2.1 era — "the whole corporate network is in scope because we have some CDE systems on it" — now create enormous MFA deployment burden.

The fix: tighten network segmentation. Get the CDE boundary as small as possible through VLAN isolation, firewall rules, and dedicated jump hosts. Then enforce MFA at that much smaller boundary.

Requirement 11.3.1 / 11.4 — Testing requirements

External vulnerability scans every 3 months, internal scans every 3 months, both after significant changes. These are carryovers from 3.2.1, but the documentation requirements are tighter in 4.0. Your QSA will ask for the scan reports and evidence of remediation.

Penetration testing at least annually and after significant changes. 4.0 is more explicit about what "significant changes" means and requires that pentest methodology include:

• Network-layer and application-layer testing
• Segmentation testing (confirming your CDE segmentation actually works)
• Testing by qualified internal resources or a qualified third party
• Remediation verification — re-test after fixing findings

Requirement 12.3.3 — Targeted risk analyses

This is new in 4.0 and widely misunderstood. Several specific requirements now allow the merchant to define their own frequency or implementation details IF a documented targeted risk analysis justifies the choice.

Example: requirement 10.4.2 requires reviewing certain log types periodically. The merchant can define "periodic" — but must document a targeted risk analysis justifying the chosen interval.

Why it's hard: merchants are used to prescriptive requirements. 4.0 introduced flexibility, but the flexibility requires documented reasoning. QSAs assess the risk analyses and will push back if they're perfunctory.

The fix: build targeted risk analysis capability as an ongoing program activity. Not a one-time document.

Requirement 5.3.2 — Anti-malware technical solutions

Anti-malware needs to be deployed on all systems commonly affected by malware. Previously, merchants could argue "our systems aren't commonly affected" for Linux, macOS, or specialized systems and skip anti-malware. 4.0 narrows that exception substantially.

The fix: deploy anti-malware or equivalent endpoint protection on every system in the CDE, including Linux servers and macOS workstations.

Requirement 3.7 — Key management

Cryptographic key management requirements are substantially expanded. Key custodians, documented key-management procedures, key destruction records, dual-control for critical keys — all more explicit in 4.0.

Why it's hard: many merchants had informal key management practices. 4.0 requires formal documentation.

Requirement 12.10 — Incident response plan testing

Annual testing of the incident response plan was always a requirement. 4.0 is stricter about documentation of the testing, lessons learned, and plan updates. "We had a meeting and talked through scenarios" isn't sufficient — a documented tabletop exercise with attendees, scenario, outcomes, and action items is.

The Customized Approach

One of the most confusing 4.0 changes is the introduction of the "Customized Approach." Merchants can implement alternative controls if they demonstrate equivalent security to the standard requirement.

In practice:

• Eligible requirements are flagged in the PCI DSS 4.0 document.
• Customized control documentation must include the business objective, how the custom control meets the objective, and a targeted risk analysis demonstrating equivalent risk reduction.
• Validation requires more work during assessment — QSAs must understand and validate the custom control.

Most merchants should NOT use Customized Approach unless they have specific technical or business reasons. It's more documentation, more QSA engagement, and potentially more audit risk. The standard prescriptive requirements are the safer path for most organizations.

What's coming in 2026-2027

The PCI SSC has signaled the direction of future updates:

• Increasingly specific Magecart / web-skimming protections in payment pages
• Tighter cloud-native control expectations (more alignment with NIST 800-53 and ISO 27001)
• Greater emphasis on supply chain security for merchants using payment service providers
• Potential requirement for continuous monitoring rather than periodic scans
• Evolving guidance on tokenization, P2PE, and vaulted storage alternatives

Merchants that passed 4.0 assessments by strictly meeting letter-of-requirements may find themselves scrambling for future updates. Merchants that built robust security programs (with 4.0 as one expression of a broader posture) will adapt easily.

Common merchant patterns in 2026

Based on observed compliance assessments this past year:

The "we always passed 3.2.1" merchant

Typical profile: mid-sized e-commerce merchant, Level 2 or Level 3. Passed PCI 3.2.1 for years. Now failing 4.0 on requirement 6.4.3 (script integrity), 11.4 (pentest scope), 12.3.3 (targeted risk analyses), and 5.3.2 (anti-malware coverage).

Action plan:

• Commit to a 6-month remediation timeline
• Engage a third-party to help with script inventory and CSP/SRI deployment
• Schedule a fresh penetration test scoped to 4.0 requirements
• Develop targeted risk analysis templates and workflow
• Extend anti-malware to previously-excluded systems

The "we use a payment processor, so we don't need PCI" merchant

Typical profile: smaller merchant who believed Stripe, Square, or Shopify handled PCI compliance. Still had PCI scope because of how the payment integration was implemented.

Common issues:

• Redirect-style integrations that don't fully transfer PCI scope
• Self-hosted forms that inadvertently touch card data
• Stored refund or recurring-billing data that creates scope
• Employees with access to cardholder data through customer support systems

Action plan:

• Reassess the integration pattern with the processor's technical team
• If possible, migrate to a fully-tokenized integration that minimizes scope
• Complete the appropriate Self-Assessment Questionnaire (SAQ)
• If scope remains, engage a QSA for guidance

The "we're a SaaS business, PCI is our customer's problem" merchant

Typical profile: SaaS company that processes payments via Stripe or similar, believes they're outside PCI scope.

Reality: any system that stores, processes, or transmits cardholder data is in scope. Many SaaS applications touch card data more than they realize (displaying the last-4, handling refunds, managing subscriptions, integrating with customer support that sees card details).

Action plan:

• Do a data-flow analysis of card information through your systems
• Identify actual PCI scope (often narrower than assumed, sometimes broader)
• Complete the appropriate SAQ based on integration pattern
• Document the scope reasoning in a formal scoping document

The "enterprise that passed SOC 2" merchant

Typical profile: mid-to-large company with robust SOC 2 Type 2 program. Assumed SOC 2 covered most of PCI.

Reality: SOC 2 and PCI DSS have significant overlap but are not equivalent. PCI DSS has much more specific technical requirements around cardholder data protection, key management, and card-specific logging. A SOC 2 program needs PCI-specific augmentation.

Action plan:

• Leverage SOC 2 evidence where applicable (much of the documentation can be reused)
• Identify PCI-specific gaps (card data flow, key management, anti-malware scope, script integrity)
• Supplement the SOC 2 program rather than building a separate PCI program

Getting compliant

The pragmatic 90-day plan for a merchant who's behind:

Days 1-14: assessment

• Hire a QSA or QSA-adjacent consultant for a gap assessment
• Document current compliance state vs 4.0 requirements
• Categorize gaps: "easy wins," "major remediation," "architectural changes"

Days 15-45: quick wins

• Script inventory and documentation (req 6.4.3)
• Extend MFA coverage (req 8.3.6, 8.4.2)
• Document targeted risk analyses for the relevant controls
• Update incident response plan and schedule tabletop exercise
• Verify penetration testing is scheduled with a qualified provider

Days 46-75: major remediation

• Deploy CSP and SRI for script integrity
• Enhance anti-malware coverage
• Formalize key management procedures
• Tighten network segmentation where needed

Days 76-90: validation

• Complete updated SAQ or engage QSA for Report on Compliance (ROC) depending on level
• Complete penetration test and remediate findings
• Complete final documentation package
• Pass QSA assessment

This plan works for Level 3 and Level 4 merchants. Level 1 merchants with complex environments need more time; plan for 6 months minimum.

For payment platforms and fintechs

If you're building a payment platform (accepting cards, processing transactions, storing card data), your PCI DSS 4.0 posture is existentially important. Non-compliance can mean:

• Immediate payment processor action (loss of processing privileges)
• Increased per-transaction fees
• Higher reserve requirements
• Regulatory action in multiple jurisdictions
• Civil liability in data breach scenarios

Fintech companies should build PCI compliance into their platform from day one, not bolt it on after growth. Common fintech compliance patterns:

• Strict PCI scope minimization through tokenization at the earliest possible point
• Level 1 Service Provider certification if you're white-labeling payments for other businesses
• Annual PCI DSS attestation shared with customers as part of vendor management
• Dedicated PCI program manager responsible for ongoing compliance

What Valtik does in this space

Valtik provides PCI DSS 4.0 preparation, penetration testing, and gap assessment services for merchants and payment platforms. Our engagements:

• PCI DSS 4.0 readiness assessment — gap analysis against your current program, remediation roadmap, estimated effort
• Penetration testing scoped to PCI 4.0 requirements — network-layer, application-layer, and segmentation testing with deliverables that satisfy QSA scrutiny
• Script integrity program deployment — Req 6.4.3 implementation with ongoing monitoring
• QSA liaison — working alongside your QSA during the formal assessment

If you're a merchant, processor, or fintech preparing for a PCI DSS 4.0 assessment in the next 12 months and haven't started, the time to start is now. Reach out via https://valtikstudios.com for scoping.

Sources

1. [PCI DSS v4.0 Summary of Changes](https://www.pcisecuritystandards.org/documents/PCI-DSS-v4_0-Summary-of-Changes.pdf)
2. [PCI DSS v4.0 Full Standard](https://www.pcisecuritystandards.org/document_library/)
3. [PCI DSS Quick Reference Guide v4.0](https://www.pcisecuritystandards.org/documents/PCI-DSS-v4-0-QRG.pdf)
4. [PCI SSC Prioritized Approach for PCI DSS 4.0](https://www.pcisecuritystandards.org/)
5. [Visa PCI DSS 4.0 Compliance Update](https://www.visa.com/)
6. [Mastercard Site Data Protection Program](https://www.mastercard.us/en-us.html)
7. [Magecart / Web Skimming Threat Analysis — RiskIQ / Microsoft](https://www.riskiq.com/)
8. [Content Security Policy Level 3 — W3C](https://www.w3.org/TR/CSP3/)
9. [Subresource Integrity — W3C](https://www.w3.org/TR/SRI/)
10. [PCI Security Standards Council FAQ](https://www.pcisecuritystandards.org/faqs/)