The transition period for PCI-DSS v4.0 officially ended on March 31, 2025. Every requirement that was previously listed as a “future-dated best practice” is now a mandatory, assessable control.
PCI SSC confirmed that v4.0.1 did not change the March 31, 2025, effective date for these newer requirements. There is no extension. There is no grace period still in progress. The standard is in full effect, and payment card brands, acquiring banks, and QSAs are assessing against it right now.
In this Article:
Why PCI-DSS v4.0.1 Exists: The Threat It Was Built to Address
For small and mid-sized retailers, the most consequential changes in v4.0.1 are two requirements that most SMB merchants have never heard of: Requirements 6.4.3 and 11.6.1. Together, they address a specific and growing attack category called e-skimming, and together they affect every business that accepts card payments online, including businesses that use hosted checkout solutions and assumed they were covered.
The shift from PCI-DSS v3.2.1 to v4.0 was not routine housekeeping. The Payment Card Industry Security Standards Council rewrote significant portions of the standard specifically to address a threat that the previous version was not built to catch: malicious JavaScript injected into payment pages to steal cardholder data in real time.
The attack category is called Magecart, or e-skimming. Attackers inject small JavaScript files into a retailer's checkout page, either directly or through a compromised third-party tool the retailer uses. Once in place, the script runs silently in a customer's browser, capturing payment card details as they are typed and transmitting them to an attacker-controlled server. The merchant's backend systems show no sign of the breach. The cardholder receives no alert. The data is gone before the transaction completes.
According to Recorded Future's Fraud Intelligence Report, 269 million card records were exposed via dark and clear web sources in 2024, with more than 11,000 unique e-commerce domains infected, representing a nearly 300% year-over-year increase.
Magecart attacks surged 103% within just six months during 2024 and 2025, making it one of the fastest-growing threats to online commerce.
Small and mid-sized retailers are disproportionately targeted because they tend to have weaker monitoring and more unvetted third-party scripts on their payment pages than larger enterprises. A small to mid-sized e-commerce retailer breached by a Magecart attack may see a significant decrease in online sales, as consumers lose trust in smaller web retailers that cannot demonstrate adequate protection.
These two requirements work together. Requirement 6.4.3 governs script authorization and inventory. Requirement 11.6.1 governs tamper detection and monitoring.
Under Requirement 6.4.3, every JavaScript that loads and executes on your payment page within a customer's browser must meet three conditions. First, the script must be authorized, meaning your organization has a documented record confirming it is approved for use. Second, the script must have an integrity check that verifies it has not been modified since authorization. Third, your organization must maintain a written inventory of all scripts with a documented justification for why each one is necessary.
The practical complexity here is significant for any retailer using a tag manager.
In early 2025, Magecart actors exploited Google Tag Manager to inject skimmers into Magento-based sites, making detection especially challenging. Every tag loaded through Google Tag Manager or any equivalent tool must be individually inventoried and authorized. The tag manager does not satisfy the requirement on behalf of the scripts it loads.
Under Requirement 11.6.1, covered merchants must deploy a tamper-detection or change-detection mechanism on their payment pages. The mechanism must generate alerts when unauthorized modifications occur to page content or HTTP headers. The required minimum check frequency is at least once every seven days, or per a documented Targeted Risk Analysis if your organization has justified an alternative schedule.
Many small online retailers qualify for Self-Assessment Questionnaire A, the simplified compliance validation pathway available to merchants who outsource all payment processing to a PCI-compliant third-party provider. The common assumption is that using a hosted payment page or iframe solution, such as those provided by Stripe, Square, or PayPal, means Requirements 6.4.3 and 11.6.1 do not apply.
That assumption is wrong, and the PCI SSC has been explicit about it.
The PCI SSC moved the removal of Requirements 6.4.3 and 11.6.1 from the SAQ A category to a new eligibility criterion. The PCI SSC also clarified that these changes do not remove or diminish the requirements of PCI DSS. Under the updated SAQ A eligibility rules, merchants must confirm that their site is not susceptible to attacks from scripts that could affect their e-commerce systems. If your checkout page loads any third-party scripts, even analytics tools, chat widgets, or advertising pixels, that confirmation is not straightforward to make.
For most small retailers with anything beyond a completely bare checkout page, this means the compliance work required to satisfy 6.4.3 and 11.6.1 still needs to happen. The SAQ A pathway does not eliminate it.
PCI-DSS fines are not issued by the PCI Security Standards Council directly. The card brands establish the penalty structure, and acquiring banks enforce it through merchant agreements. The practical result is that penalties flow from card brands to acquiring banks to payment processors and ultimately to the merchant responsible for the violation.
Non-compliance does not result in a single fine. It leads to recurring monthly penalties that increase over time. During the first three months of non-compliance, fines range from $5,000 to $10,000 per month. From months four through six, the penalty escalates to $25,000 to $50,000 per month. Beyond six months, fines can reach $100,000 per month.
When a breach occurs on top of a non-compliance finding, the cost structure expands significantly. Breach penalties are assessed at $50 to $90 per compromised record. A breach affecting 10,000 customers produces between $500,000 and $900,000 in per-record penalties alone, before legal costs, forensic investigation fees, mandatory third-party audits, and customer remediation expenses.
Retailers face breach costs averaging $3.48 million, making retail one of the most financially exposed industries under PCI-DSS.
According to IBM's Cost of a Data Breach Report, 60% of small businesses close within six months of a cyber attack. For a business with fewer than 500 employees, the monthly escalation structure does not represent a difficult quarter. At $100,000 per month beyond six months of non-compliance, it represents an existential threat.
|
|
Hanna Andersson | Magecart Breach via Third-Party Platform | $400,000 CCPA Settlement Hanna Andersson is a children's clothing retailer, not a major enterprise. The company operates in the mid-market segment with a direct-to-consumer e-commerce model that relies on a third-party platform for checkout functionality. A Magecart attack compromised Hanna Andersson's e-commerce platform through its provider, Salesforce Commerce Cloud. The breach affected approximately 200,000 customers and led to the first class action settlement under the California Consumer Privacy Act, with the company agreeing to pay $400,000 and implement enhanced security measures. The attack vector was not a sophisticated intrusion into proprietary systems. Malicious code reached the checkout page through a third-party platform the company trusted and relied upon. Standard server-side security controls would not have caught it. Two lessons apply directly to any SMB retailer: first, using a reputable third-party e-commerce platform does not transfer compliance responsibility to that platform. Second, a $400,000 settlement was the outcome for a company with substantial legal resources. A smaller retailer facing the same fact pattern would likely face worse financial terms. |
For retailers operating multiple locations or franchise units, the compliance challenge multiplies in proportion to the number of cardholder data environments in scope. Each location that processes payments independently maintains its own PCI-DSS compliance obligations, regardless of the franchise relationship above it.
Franchise agreements often address brand standards, operating procedures, and financial reporting. They rarely provide adequate guidance on how individual franchisees should manage PCI compliance at the unit level. The result is that individual franchise owners frequently operate under a false sense of security, believing the franchisor has handled their compliance obligations on their behalf. Each entity that stores, processes, or transmits cardholder data carries its own compliance responsibility.
CompassMSP works with retail and franchise businesses specifically on this challenge. You can learn more about how we approach compliance for this segment at compassmsp.com/industries/retail-franchise.
Related Article: 15 Outsourced IT services for multi-location Offices
A PCI-DSS v4.0.1 compliance program for a small or mid-sized retailer is not a theoretical exercise. The following are the specific deliverables your next assessment will look for.
PCI-DSS v4.0.1 has been fully mandatory since March 31, 2025. The threat it was designed to address, Magecart-style e-skimming attacks, surged 103% in six months during 2024 and 2025. The penalties for non-compliance escalate monthly and reach levels that are genuinely business-ending for small and mid-sized retailers. And the most consequential new requirements, the ones addressing script authorization and payment page monitoring, are the ones most merchants have not addressed.
The retailers who will navigate this well are the ones who treat the March 2025 effective date as a real deadline rather than a future concern. For those who have not yet assessed their posture against the full v4.0.1 requirements, the most important step is understanding exactly where the gaps are before the next assessment finds them first.
PCI-DSS v4.0.1 is in full effect. The requirements affecting your checkout page are mandatory, they are being assessed, and the penalties for gaps escalate every month they go unaddressed. If your organization has not yet confirmed compliance with Requirements 6.4.3 and 11.6.1, a gap assessment is where this process starts.
CompassMSP works with small and mid-sized retail and franchise businesses on PCI-DSS compliance, payment security, and the broader cybersecurity programs that keep customer data protected and businesses operational.
Explore our Retail and Franchise compliance services | Subscribe to The Fine Print
Compliance news across retail and six other regulated industries, free and quarterly. Written by the CompassMSP compliance team.