PCI DSS 4.0 for Online Merchants: What Actually Changed and How to Prepare

The transition from PCI DSS 3.2.1 to 4.0 has been one of the most significant shifts in card security compliance in a decade. With 3.2.1 fully retired and many future-dated 4.0 requirements now in force, online merchants can no longer treat the upgrade as a paperwork exercise. This post walks through the changes that matter most for e-commerce and offers a realistic path to readiness.

Why 4.0 Is Different in Spirit

Earlier versions of PCI DSS were largely prescriptive: do exactly what the requirement says. Version 4.0 keeps that model but adds a customized approach that lets mature organizations meet a control objective using alternative methods, provided they document the risk analysis. For most small and mid-sized merchants the defined approach remains the sensible choice, but it helps to understand that the standard now emphasizes outcomes over checkboxes.

Client-Side Script Protection

The most talked-about additions are requirements 6.4.3 and 11.6.1, which target the payment page itself. Attackers increasingly skim card data by injecting malicious JavaScript into checkout pages, a technique known as e-skimming.

• 6.4.3 requires you to inventory and authorize every script that loads on the payment page and confirm its integrity.
• 11.6.1 requires a change-and-tamper detection mechanism that alerts you when the security-impacting content of the payment page is modified.

Practically, this means maintaining a script inventory, using Subresource Integrity or Content Security Policy where possible, and deploying monitoring that flags unexpected changes to your checkout.

Stronger Authentication Expectations

Version 4.0 expands multi-factor authentication so it is required for all access into the cardholder data environment, not just remote or administrative access. Password requirements also tightened, with minimum length moving to 12 characters where systems support it. If your team still shares logins for a hosting panel or gateway dashboard, that practice needs to end.

Targeted Risk Analysis

Several requirements now let you set your own frequency for a recurring activity, but only if you perform a documented targeted risk analysis justifying that frequency. This gives flexibility but adds a documentation burden. Build a simple template now so each analysis is consistent and defensible during an assessment.

A Practical Readiness Checklist

• Confirm which SAQ type applies to you; many merchants using a redirect or iframe qualify for SAQ A, which still carries new script-monitoring expectations.
• Build and maintain a payment-page script inventory.
• Enable MFA across all administrative and CDE access.
• Review password and account-lockout settings against the new minimums.
• Create reusable templates for targeted risk analyses.

Treat Compliance as Continuous

One theme runs through the entire 4.0 update: security controls are expected to operate continuously, not just at assessment time. Requirements around logging, vulnerability scanning, and access review all assume you are performing them on a defined cadence and can prove it. Assign clear ownership for each recurring task, automate evidence collection where you can, and keep a running record so that your next assessment is a matter of gathering what you already have rather than reconstructing a year of activity under pressure.

Conclusion

PCI DSS 4.0 rewards merchants who treat security as an ongoing operational discipline rather than an annual scramble. Start with the client-side script requirements, since they address one of the most active threats to online checkout, then work outward to authentication and documentation. A steady, well-documented program is far easier to sustain than a last-minute rush before your next assessment, and it produces a security posture that genuinely protects your customers rather than one that merely satisfies a checklist.