PCI DSS 4.0 transition: the changes that matter to SMEs

The Shift from Point-in-Time to Continuous Compliance

PCI DSS 4.0 introduces 64 new requirements, many of which are designated as 'evolving' until 31 March 2025. This grace period is misleading; SMEs must understand that the 'Defined Approach' still requires proactive engineering to implement. For most small firms, the shift from a prescriptive 'do this' model to a flexible 'achieve this outcome' model adds complexity rather than simplicity.

The standard now places a heavy emphasis on security as a continuous process rather than an annual event. Requirement 12.1.1, for instance, now mandates that security policies and procedures are not just documented but are 'formally reviewed' annually. This means your QSA (Qualified Security Assessor) will look for proof of those reviews throughout the year, not just a stamp on a document dated the week before your audit.

E-commerce and the New Script Management Burden

E-commerce SMEs are facing the strictest new requirements under v4.0, specifically regarding the security of payment pages. Requirement 6.4.3 is a direct response to 'Magecart' style attacks, requiring entities to manage all JavaScript on the checkout page. You must now maintain a list of all scripts and provide a business justification for every single one of them.

Furthermore, Requirement 11.6.1 effectively mandates the use of a monitoring tool to detect unauthorized changes to the HTTP headers and contents of payment pages. This is a technical hurdle that many SMEs using simple plug-and-play e-commerce platforms may struggle to meet without specific third-party security headers or integrity monitoring services. We are moving toward a 'zero trust' model for the browser environment.

• Requirement 6.4.3: Manage all payment page scripts to prevent unauthorized changes.
• Requirement 11.3.2: External vulnerability scans must be performed by an ASV (Approved Scanning Vendor).
• Requirement 11.6.1: Deploy a change-and-tamper-detection mechanism for payment pages to alert on unauthorized modifications.
• Requirement 8.4.2: MFA is now required for all access into the CDE, not just remote access.

Authentication and the End of Simple Passwords

The baseline for authentication has been raised significantly in 4.0. The most pervasive change is the mandate for Multi-Factor Authentication (MFA) for all access into the Cardholder Data Environment (CDE). Under 3.2.1, this was often interpreted as only applying to remote/VPN access, but 4.0 closes that loophole—internal admin access now requires MFA too.

Password complexity has also evolved. The new minimum length is 12 characters, up from 8. For SMEs, this often necessitates a fleet-wide update to Active Directory or IAM policies. More importantly, Requirement 7.2.5 introduces a semi-annual access review. If you cannot provide a timestamped log showing that you removed 'User X' 180 days ago, you will fail your assessment. This is where manual spreadsheets usually fail.

• Review of all user accounts and access privileges at least every six months (Requirement 7.2.5).
• Multi-factor authentication (MFA) for all system components within the CDE (Requirement 8.4.2).
• Passwords must now be at least 12 characters and contain both numeric and alphabetic characters (Requirement 8.3.6).
• Transition away from 'shared accounts'—every admin must be uniquely identifiable without exception.

The Role of Targeted Risk Analysis (TRA)

A core philosophy of PCI DSS 4.0 is that the entity must take more 'ownership' of its security posture. This is evidenced by the new requirement for a 'Targeted Risk Analysis' (TRA). Under Requirement 12.3.1, if you decide to perform a certain activity 'periodically' rather than at a set frequency, you must justify that frequency with a formal, documented risk assessment.

For an SME, this means you can no longer just say 'we do this every month because that is what the auditor likes.' You must analyze the threat landscape, the vulnerability of the asset, and the impact of a breach to determine the frequency. This requires a level of GRC (Governance, Risk, and Compliance) maturity that many small firms haven't needed until now. Documenting these TRAs is a non-negotiable part of the 4.0 toolkit.

• Automate log collection from all CDE components.
• Establish a clear 'Targeted Risk Analysis' document for any periodic tasks.
• Integrate PCI checks into your monthly internal audit cycle.
• Use a centralized repository for evidence that links to specific PCI v4.0 clauses.

Preparing for Your First v4.0 Assessment

The final 12 months before the hard deadline in March 2025 should be spent on 'evidence hardening.' It is one thing to have a firewall; it is another to have a documented, approved change request for every rule in that firewall. PCI 4.0 Requirement 1.2.1 demands that configuration files are secured and changes are tracked. You need an audit trail that links the ticket to the change to the verification.

My advice to founders is to stop seeing PCI DSS as an IT task and start seeing it as a data management task. Your QSA doesn't want to hear that you are secure; they want to see the CSVs, the screenshots, and the signed approvals. If your evidence isn't organized by requirement, you will spend thousands of pounds in extra consultancy fees just for the auditor to sort through your files. Start mapping your evidence to the 4.0 controls immediately.

Frequently asked questions