PCI DSS 4.0 reads like a security team's problem, not a conversion team's problem. That framing is wrong for one specific rule. Requirement 6.4.3 forces every merchant to produce a full inventory of every script running on the payment page, with a written justification for each one. Most checkout pages have never had that audit done. Once you do it, you tend to find a pile of analytics snippets, chat widgets and old A/B testing tags nobody remembers adding, quietly slowing down the page that has the most influence on whether a sale completes.
PCI DSS 4.0 Requirement 6.4.3 requires an inventory, authorization and written justification for every script on your payment page, and Requirement 11.6.1 requires weekly change detection. Both became mandatory on March 31, 2025, and 2026 is the assessment cycle catching merchants who deferred the work. Doing the audit properly is also one of the fastest ways to find and remove the third-party scripts slowing down your checkout.
What PCI DSS 4.0 actually requires on payment pages
Two requirements matter most for checkout pages, and both became mandatory on March 31, 2025. Requirement 6.4.3 covers script management: an inventory of every script that executes in the customer's browser on the payment page, confirmation that each one is authorized, a method to verify its integrity, and a written justification for why it needs to be there at all. Requirement 11.6.1 covers change detection: a technical mechanism that can spot and alert on unauthorized modifications to the payment page's scripts and content, checked at a minimum weekly, with continuous monitoring preferred.
The scope is wider than most teams assume. It covers first-party code you wrote yourself, inline scripts including tag manager bootstraps, and every third and fourth-party script that loads on the page, meaning your own analytics tag counts, and so does a script that a third-party tool you installed pulls in from its own vendor behind the scenes.
Why 2026 is the year this actually bites
The deadline already passed. What makes 2026 the pressure point is the assessment cycle. Merchants who last validated compliance under the older PCI DSS 3.2.1 standard, or who validated under 4.0 in 2024 but never fully implemented the future-dated requirements, are due for reassessment now, and this is widely flagged as the most common audit failure point in the current cycle. "We are still catching up" stops working as an answer once your assessor is looking at a 2026 date on the report.
| Requirement | What it demands | Deadline |
|---|---|---|
| 6.4.3 | Inventory, authorization, integrity check and written justification for every payment page script | Mandatory since March 31, 2025 |
| 11.6.1 | Technical detection of unauthorized changes to page scripts or content, minimum weekly | Mandatory since March 31, 2025 |
| Assessment reality | 2026 audits are where deferred or partial 2024 implementations fail | Ongoing through 2026 assessment cycles |
Why this is a conversion problem, not just a compliance one
Checkout pages accumulate scripts the way a garage accumulates boxes. A heatmap tool added for a project that ended two years ago. Three overlapping analytics pixels because nobody wanted to be the one who removed the wrong tag. A chat widget the support team stopped using after switching platforms. Every one of those is render-blocking or execution-blocking weight sitting on the single page in your funnel where speed matters most. Page speed has a well-documented, direct effect on checkout completion, and a script audit forced by a compliance deadline is, in practice, one of the more thorough performance audits most checkout pages will ever get.
Do not treat the 6.4.3 inventory as a checkbox exercise handed to whoever owns compliance. Pull in whoever owns conversion too, and turn the inventory into a removal list, not just a documentation list. Every script that survives the audit should also survive the question "is this earning its place on the page that closes the sale."
How to start the audit this week
- Open your payment page in a browser, check the network tab, and list every script that loads: file name, origin, and what it appears to do.
- For each script, find an internal owner. If nobody can name one, that is already a strong signal it is a removal candidate, not just a documentation gap.
- Get a one-line written justification for every script that stays: what it does, why it is necessary specifically on the payment page, and who approved it.
- Remove everything without an owner or a justification, then re-test the checkout flow end to end before you consider the pass complete.
- Put a change-detection or file integrity monitoring tool in place that checks the page at least weekly, so the next unauthorized script gets caught in days, not discovered a year later during the next audit.
- Re-run a page speed test before and after. The delta is usually the easiest checkout speed win you will find all year, and it comes free with a compliance task you already had to do.
Where responsibility sits on hosted checkouts
Platforms like Shopify absorb a meaningful share of PCI scope for their hosted checkout pages, which is one real advantage of not running a fully custom payment flow. That coverage has limits. Any script you add through a theme, an app, or a tag manager container still sits inside your responsibility, not the platform's. Confirm in writing exactly what your platform covers before assuming the 6.4.3 inventory is someone else's job, and treat the checkout speed work in our page speed and checkout conversion guide and checkout form field cut list as companion reading, since a leaner script inventory and a leaner form are the same underlying discipline.
Frequently asked questions
What does PCI DSS 4.0 require for payment pages?
Requirement 6.4.3 requires merchants to maintain an inventory of every script that runs on the payment page, confirm each one is authorized, and record a written justification for why it needs to be there. Requirement 11.6.1 requires a technical mechanism that detects and alerts on unauthorized changes to that page, checked at least weekly.
When did these PCI DSS 4.0 requirements become mandatory?
Every future-dated requirement in PCI DSS 4.0, including 6.4.3 and 11.6.1, became mandatory on March 31, 2025. 2026 matters because it is the assessment cycle where merchants who deferred the work, or who only partially implemented it in 2024, are most likely to fail their next audit.
Does this apply to third-party scripts like analytics and chat widgets?
Yes. The requirement scopes to every script that loads and executes in the customer's browser on the payment page, including first-party code, inline scripts, tag manager bootstraps, and any third or fourth-party script such as analytics, chat, heatmap or personalization tools.
How does a PCI script audit connect to conversion rate?
Most checkout pages accumulate scripts over years with nobody removing old ones. A forced inventory surfaces exactly which scripts are still needed, and cutting the ones that are not is one of the highest-leverage checkout speed improvements available, since page load speed has a direct, measurable effect on checkout completion.
What is the fastest way to start complying?
List every script currently loading on your payment page using your browser's network tab or a script-discovery tool, get a business owner and justification for each one, remove anything nobody can justify, and put a change-detection or file integrity monitoring tool in place that checks the page at least weekly.
Who is responsible for PCI DSS compliance on a Shopify or hosted checkout?
Platforms like Shopify handle a large share of PCI compliance for their hosted checkout, but any custom script you add through a theme, app or tag manager still falls inside your scope. Confirm with your platform exactly what they cover and what remains your responsibility before assuming you are fully covered.
The takeaway
Treat the PCI DSS 4.0 script inventory as two projects wearing one deadline: a compliance requirement and a checkout speed audit you were probably overdue for anyway. Assign it jointly to whoever owns security and whoever owns conversion, remove what nobody can justify, and you will likely leave the process with a faster checkout page as well as a cleaner audit.