PCI-DSS 4.0 Compliance: A Practical Guide for Small Merchants

PCI-DSS version 4.0 became the only active version of the standard in March 2024, with the retirement of v3.2.1. For large merchants and payment processors, the transition has been a multi-year program. For small merchants — businesses processing card payments primarily through third-party payment gateways or point-of-sale terminals — the v4.0 shift is less visible but no less consequential. Several requirements that were "future-dated" in the original v4.0 publication became mandatory in March 2025, and the implications for e-commerce merchants in particular are significant. Understanding what actually changed, what your Self-Assessment Questionnaire (SAQ) type requires, and where small merchants consistently fail assessments is essential before your next compliance cycle.

What Actually Changed in PCI-DSS 4.0

The most discussed structural change in v4.0 is the introduction of the customized approach — an alternative to the defined approach (prescriptive controls) that allows organizations to meet the intent of a requirement through compensating controls they design and document themselves. For large enterprises with complex, bespoke environments, the customized approach is valuable flexibility. For small merchants, it is largely irrelevant: the defined approach is almost always the correct path, and attempting a customized approach without a mature risk management program and experienced QSA guidance typically creates more assessment complexity than it resolves.

The changes that actually matter for small merchants are the expanded multi-factor authentication (MFA) requirements and the new web-facing script controls under Requirement 6.4.3. On MFA: v4.0 requires MFA for all access into the cardholder data environment (CDE), not just remote access — meaning that administrative console access to in-scope systems from within the network now requires MFA where it previously did not. This catches many merchants off guard because it requires changes to how administrators access payment servers, POS management consoles, and any system that stores, processes, or transmits cardholder data. Requirement 6.4.3 is new territory entirely: it requires merchants with e-commerce payment pages to maintain an inventory of all scripts loaded by the payment page, document the business justification and authorization for each script, and implement a method to confirm script integrity. This requirement was prompted by the Magecart-style web skimming attacks that have compromised payment pages at hundreds of retailers by injecting malicious JavaScript through third-party analytics, chat widgets, and tag managers — exactly the tools small e-commerce merchants routinely load on their checkout pages without tracking.

SAQ vs. Full ROC — and Where Small Merchants Consistently Fall Short

Most small merchants qualify for a Self-Assessment Questionnaire rather than a full Report on Compliance (ROC) prepared by a Qualified Security Assessor. The SAQ type that applies depends on how the merchant accepts and processes card data. SAQ A is the most limited — it applies to e-commerce merchants who have fully outsourced all payment processing to a PCI-compliant third party and whose own website does not directly receive cardholder data. SAQ A-EP covers e-commerce merchants whose website does partially redirect or load payment form elements that could affect the security of the transaction — a broader and more demanding scope. SAQ B and B-IP cover standalone POS terminal merchants. SAQ C covers merchants using payment application systems connected to the internet. The common error is misclassifying SAQ type: a merchant who loads a third-party payment iframe but also loads six analytics scripts and a chatbot on the same page may believe they qualify for SAQ A, but if those external scripts can interact with form fields on the payment page, the merchant's scope expands materially.

"Requirement 6.4.3 is not theoretical. Magecart-style skimming attacks have compromised payment pages at organizations that believed their outsourced payment processor made them safe. Every third-party script loaded on a checkout page is a potential injection point."

The gaps we see most frequently in small merchant assessments are: incomplete network segmentation documentation (or no segmentation at all, with POS systems on the same network as employee workstations and guest Wi-Fi); missing or outdated asset inventories for in-scope systems; absence of a formal vulnerability management program (meaning no documented process for applying patches to in-scope systems within defined timeframes); and the newly mandatory Requirement 6.4.3 script inventory for e-commerce merchants, which almost no small merchant has implemented without external guidance. On the MFA front, many merchants have MFA for remote access but have not extended it to all administrative access paths within the CDE.

Engaging a QSA liaison — a security partner who prepares your documentation, walks through SAQ responses with you, and manages remediation before the formal assessment — materially reduces assessment friction and the likelihood of findings that delay your compliance certificate. For small merchants, the QSA process is not frequent enough to build internal muscle memory around it, which means each cycle starts with relearning. Defense In Orbit provides PCI-DSS compliance support from initial scoping through SAQ completion and remediation tracking, with particular focus on the v4.0 requirements that are catching merchants unprepared. If your last assessment was under v3.2.1 or you have not yet addressed Requirement 6.4.3 on your e-commerce payment pages, now is the right time to close those gaps.