Go Back Up

PCI-DSS v4.0.1 Is Fully in Effect and Your Checkout Page May Already Be Non-Compliant

Jun 18, 2026 2:37:37 PM Richard Mendoza 18 min read

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: 

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.

Why PCI-DSS v4.0.1 Exists: The Threat It Was Built to Address

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.

269 million card records were exposed via dark and clear web sources in 2024

What Requirements 6.4.3 and 11.6.1 Actually Require

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.

The SAQ A Misconception

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.

What Non-Compliance Actually Costs

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.

months four through six, the penalty escalates to $25,000 to $50,000 per month for non-compliance with PCI-DSS

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.

Case Study: Hanna Andersson

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. 

A Note on Franchise and Multi-Location Retailers

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

What Your Organization Needs to Have in Place

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.

  • A complete script inventory for every payment page. The inventory must document each script by name, owner, purpose, and the date it was last reviewed. It must exist as a written record, not a mental model or informal understanding.
  • An authorization mechanism for each script. Your organization must have a documented process for approving scripts before they load on payment pages and for confirming that the scripts that loaded match the scripts that were approved.
  • An integrity check for each script. Subresource Integrity attributes, Content Security Policy headers, or a dedicated client-side protection platform are the primary technical approaches. Each has implementation considerations that depend on how your checkout page is structured.
  • A tamper-detection mechanism on your payment pages. The mechanism must check page content and HTTP headers for unauthorized changes, generate alerts when changes are detected, and operate at a minimum frequency of every seven days.
  • MFA for all access to your Cardholder Data Environment. PCI-DSS v4.0.1 requires multi-factor authentication for all access into the CDE, applying to internal employees and third-party vendors alike.
  • Quarterly internal vulnerability scans and annual penetration testing. Both must cover the full scope of your CDE perimeter.

The TL;DR

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.

Ready to Assess Your PCI-DSS v4.0.1 Posture?

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.

YOU MAY NEED TO KNOW

Frequently Asked Questions

What is PCI-DSS v4.0.1 and does it apply to my small retail business?

PCI-DSS, which stands for Payment Card Industry Data Security Standard, applies to every organization that stores, processes, or transmits payment card data, regardless of size or annual transaction volume.

Technically, a merchant is not directly fined for non-compliance, but their payment processors and card brands like Visa and Mastercard are, and in most cases the payment processor automatically passes the fines to the merchant in violation.

If your business accepts credit or debit cards, online or in person, PCI-DSS v4.0.1 applies to you. The transition period from v3.2.1 ended on March 31, 2024, and the final set of future-dated requirements became fully enforceable on March 31, 2025.

What is new in PCI-DSS v4.0.1 that was not required before?

The most significant additions are Requirements 6.4.3 and 11.6.1, which address payment page script security and tamper detection. These were previously listed as best practices and became mandatory on March 31, 2025. Requirement 8.4.2, which mandates MFA for all access to the Cardholder Data Environment, was also strengthened.

Requirement 11 has shifted focus toward continuous monitoring, now requiring internal vulnerability scans at least once every 90 days and annual penetration testing that covers the entire CDE perimeter. Collectively, these changes reflect the PCI SSC's response to a significant escalation in e-skimming and Magecart-style attacks targeting small and mid-sized merchants.

What is an e-skimming or Magecart attack and why should retailers care?

An e-skimming attack involves an attacker injecting malicious JavaScript into a retailer's checkout page. Once in place, the script runs invisibly in a customer's browser, capturing payment card details as they are entered and transmitting them to an attacker-controlled server. The retailer's backend systems typically show no indication that anything has occurred.

In 2024 alone, 269 million card records were exposed across more than 11,000 infected e-commerce domains, representing a nearly 300% year-over-year increase. 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.

What does PCI-DSS Requirement 6.4.3 specifically require retailers to do?

Requirement 6.4.3 requires that every JavaScript running on your payment page within a customer's browser be authorized, have an integrity check confirming it has not been tampered with, and appear in a written inventory that documents each script's name, owner, purpose, and justification. This applies to every script that loads on the payment page, including analytics tags, chat widgets, advertising pixels, and any scripts loaded through a tag manager. Each one must be individually reviewed, approved, and documented.

What does PCI-DSS Requirement 11.6.1 require and how do retailers satisfy it?

Requirement 11.6.1 requires that a change or tamper-detection mechanism be deployed on payment pages. The mechanism must monitor page content and HTTP security headers for unauthorized modifications and generate alerts when changes are detected. The minimum check frequency is at least once every seven days, though organizations can document a Targeted Risk Analysis to justify an alternative schedule. Technical approaches that satisfy this requirement include Content Security Policy headers, Subresource Integrity attributes on individual scripts, and dedicated client-side security monitoring platforms.

Do I still need to comply with Requirements 6.4.3 and 11.6.1 if I use a hosted checkout like Stripe or PayPal?

Yes. The PCI SSC clarified that removing Requirements 6.4.3 and 11.6.1 from SAQ A eligibility does not remove or diminish the underlying requirements of PCI DSS. Merchants using hosted or iframe-based payment solutions must confirm as an SAQ A eligibility criterion 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 at all, making that confirmation accurately requires you to have completed the script inventory and authorization work those requirements demand.

What are the financial penalties for PCI-DSS non-compliance for a small or mid-sized retailer?

Non-compliance leads to recurring monthly penalties that increase over time. During the first three months, 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 data breach occurs alongside non-compliance, breach penalties are assessed at $50 to $90 per compromised record. A breach affecting 5,000 customers produces up to $450,000 in per-record penalties before legal fees, mandatory forensic investigation costs, and customer remediation are added.

How does PCI-DSS compliance work differently for franchise retailers and multi-location businesses?

Each location or franchise unit that independently stores, processes, or transmits cardholder data maintains its own PCI-DSS compliance obligations. A franchise agreement does not transfer the compliance responsibility of individual franchisees to the franchisor. Each unit's payment systems, whether in-store POS terminals or a location-specific online ordering platform, must satisfy the full requirements of PCI-DSS v4.0.1.

Individual franchise owners frequently assume the corporate franchise relationship includes their PCI coverage. That assumption is almost never correct. Multi-location retailers and franchise operators should conduct a compliance scope assessment across every unit as a starting point.

How do I know what PCI-DSS compliance level my retail business falls under?

How do I know what PCI-DSS compliance level my retail business falls under?

PCI-DSS compliance validation requirements are tiered based on annual transaction volume. Level 1 merchants process more than six million card transactions per year and must undergo an annual on-site QSA assessment. Level 2 merchants process one million to six million transactions annually and must complete an annual Self-Assessment Questionnaire. Level 3 merchants process 20,000 to one million e-commerce transactions, and Level 4 merchants process fewer than 20,000 e-commerce transactions or up to one million total card transactions annually.

Smaller businesses classified as Level 4 merchants, processing under 20,000 card transactions per year, will typically pay fines closer to $5,000 per month at the low end of the penalty range. Most small and mid-sized retailers fall into Level 3 or Level 4, but all four levels must comply with the same technical requirements under PCI-DSS v4.0.1.

What should a small retailer do first if they have not yet assessed their PCI-DSS v4.0.1 compliance posture?

A gap assessment against the full v4.0.1 requirements is the appropriate starting point. The assessment identifies which controls are currently in place, which are partially implemented, and which are entirely absent. For most small and mid-sized retailers, the highest-priority gaps will fall in the areas newest to the standard: the script inventory and authorization program under Requirement 6.4.3, the tamper detection mechanism under Requirement 11.6.1, and the expanded MFA requirements under Requirement 8.4.2.

The gap assessment produces a prioritized remediation roadmap that sequences the work based on risk and assessment timing. Waiting until your next SAQ filing to discover these gaps means discovering them under time pressure with penalties potentially already accumulating.

How does working with an MSP or MSSP help a retail business achieve and maintain PCI-DSS compliance?

A qualified MSP or MSSP with retail compliance experience provides the technical implementation, ongoing monitoring, and documentation infrastructure that most small retailers lack internally. Specifically, an MSP or MSSP supporting PCI-DSS v4.0.1 compliance should be able to conduct a gap assessment against the full standard, implement and document the script inventory and authorization program for payment pages, deploy and configure the tamper-detection mechanism for Requirement 11.6.1, enforce and document MFA across the Cardholder Data Environment, manage quarterly vulnerability scanning and annual penetration testing, and maintain the evidence packages required for SAQ filing or QSA assessment.

Not all managed service providers have the compliance expertise to deliver these services at the depth the standard requires. Look for a provider with documented experience supporting retail compliance environments and familiarity with the specific technical controls introduced in v4.0.

What is the difference between PCI-DSS compliance and actual payment security, and does one guarantee the other?

Compliance with PCI-DSS v4.0.1 does not guarantee that your organization will never experience a payment card breach. The standard establishes a mandatory security floor; it does not cover every possible attack vector or eliminate all risk.

What compliance does provide is a documented, tested, and maintained security program that significantly reduces your exposure to the most common attack categories, including the e-skimming attacks Requirements 6.4.3 and 11.6.1 were specifically designed to address. It also determines your liability position when a breach does occur. An organization that can demonstrate compliance at the time of a breach is in a materially different legal and financial position than one that cannot. For small retailers, the practical value of compliance is both the risk reduction it produces and the financial protection it provides.

Richard Mendoza

Richard is the Director of vCISO services with CompassMSP. He has over twenty-five years of experience as an Information Security professional with hands-on experience in engineering process and information security, and IT audit disciplines. With a wide-ranging knowledge as a Systems Engineer, Information Security Officer, and Senior Auditor, Richard has expertise in managing internal and external audits focused on reducing overall risk exposure and infrastructure redundancy for organizations.

Navigate What’s Next

Get new insights, practical guides, and timely resources delivered to your inbox.