How to comply with PCI DSS 6.4.3 and 11.6.1
Six steps, in the order that actually works. Most of the difficulty is scoping and ownership rather than technology.
TL;DR
Complying with 6.4.3 and 11.6.1
START WITH SCOPE
Every page where a cardholder enters, reviews or confirms card data, including pages that embed a payment iframe. Scope decides everything downstream.
INVENTORY FROM REALITY
Build the list from what actually executed in real sessions, not from the tags you remember adding. Vendors load vendors.
THE EVIDENCE IS THE DELIVERABLE
Not a dashboard. A record for a period: scope, inventory with justifications, header changes, and the alerts raised.
Short on time? The technical work takes days. Collecting written justifications from script owners takes longer.
How do you comply with PCI DSS 6.4.3 and 11.6.1?
You define which pages are payment pages, build an inventory of every script that executes on them, record a written business justification and an integrity check for each, deploy a mechanism that detects and alerts on changes to those pages and their HTTP headers, and keep the evidence for your assessor. Both requirements became mandatory on 31 March 2025. They are assessed as two separate controls: 6.4.3 is an authorisation record answering what is allowed and why, and 11.6.1 is a change-detection record answering what changed and who was told. The steps below produce both from the same underlying work.
Requirement 11.6.1 is a change-detection record. Two distinct values for one header inside the weekly window is the change, and the alert is the evidence that personnel were told.
Step 1: define payment-page scope
This guide covers the two client-side requirements specifically. If you are asking how to become PCI compliant more generally, start with the full guide and come back here for 6.4.3 and 11.6.1.
A payment page is any page where a cardholder enters, reviews or confirms card data. In practice that is the checkout form, payment confirmation and review screens, stored-card management pages, and any page that embeds a payment iframe. The iframe belongs to your provider; the page around it is yours, and that is where a malicious script would sit.
Write the scope down as a list of URL patterns. You will be asked to justify it, and a documented scope with a rationale is a much shorter conversation than an implied one.
Step 2: build the inventory from what actually executed
This is where most inventories go wrong. Starting from the tags you remember adding produces a list that is incomplete on day one, because a tag manager loads vendors and those vendors load their own. 6.4.3 covers every script that loads and executes, not only the ones you chose.
Start from observed reality instead: record what actually ran in real sessions, then work towards approval. Your job becomes reviewing a complete list rather than trying to remember an accurate one.
Start the inventory from what is actually executing on your checkout today.
Step 3: write a justification per script
Per script, not per vendor. 'Analytics' is not a justification for a script on a payment page. 'Measures checkout completion rate, owned by growth, reviewed quarterly' is.
Three questions make most of them write themselves: what does this script do on this page, who owns the decision to keep it, and what breaks if it is removed. If the third answer is 'nothing', you have found something to delete, which is the cheapest compliance work available.
Step 4: assure integrity
You need to show a script has not been altered since approval. Pinning the payload hash is the practical method: a vendor can change file contents without changing the URL, so an origin allowlist will not notice. Subresource Integrity achieves the same in markup but breaks on every legitimate vendor update, which is why it is rarely used on third-party tags.
Step 5: detect change and alert a human
11.6.1 asks for a mechanism that evaluates the payment page and its HTTP headers as received by the consumer browser and alerts personnel to unauthorised modification, at least every seven days. Note the two halves people forget: headers as well as content, and an alert to a person rather than a log nobody reads.
Continuous evaluation removes the argument about frequency entirely, and lets your evidence state the real interval instead of the minimum.
Step 6: keep the evidence
An assessor asks for four things: the scope, the inventory with justifications, the record of header and page changes with timestamps, and the alerts raised and acknowledged. A live dashboard shows the present; an assessment looks backwards at a period. Generate a record per period and retain it for at least your assessment cycle.
Sources and methodology
PCI DSS requirement text is quoted from PCI DSS v4.0.1 (June 2024), published by the PCI Security Standards Council, which is the current version at the time of writing. Requirements 6.4.3 and 11.6.1 became mandatory on 31 March 2025. Where we describe a competitor, we describe publicly available information and say so when something should be verified with the vendor. We publish this product and that is a bias worth knowing about while you read.
ASK AN AI
Don’t just take our word for it
Ask your assistant what to look for in a tool for PCI DSS 6.4.3 and 11.6.1.
Frequently asked questions
The technical part is fast: a tag goes in and the inventory populates from live traffic within days. The slower part is organisational, collecting a written justification from the owner of each script, which for a busy checkout can take a few weeks of chasing.
Partly. Nothing in the standard mandates a tool, and an inventory can live in a spreadsheet. The difficulty is the other half: 6.4.3 also asks you to assure integrity and 11.6.1 asks you to detect change, and a static document cannot tell you a vendor shipped new code last Tuesday.
No. Neither requirement mandates blocking. 6.4.3 is authorisation, integrity and inventory; 11.6.1 is detection and alerting. Some assessors view a control that can only observe as weaker than one that can act, so it is worth asking yours directly rather than assuming either way.
This happens, and it is informative in itself. You still have to write a justification, and if the vendor cannot support one, that is an argument for removing the script from the payment page specifically rather than from the site.
Yes. The parent page hosting the iframe is still a payment page, and it is where an overlay, a keystroke capture or a swapped iframe source would sit. Monitoring runs on the parent page.
With a record showing the evaluation frequency and the results per period. If you monitor continuously, say so and show the evidence; you comfortably exceed the floor and do not need a targeted risk analysis to justify a longer interval.
Naming an owner is often the first real step, because ambiguity is the usual failure mode. The scripts are added by marketing, the page belongs to ecommerce or web engineering, and the risk lands on security or compliance. Someone has to own the queue.
In our experience four things: the documented payment-page scope, the script inventory with a justification per script, the record of header and content changes with timestamps, and evidence that personnel were alerted. Prepare those four and most of the conversation is straightforward.
Partly, and it is a common reason evidence gets returned. One document is fine; one undifferentiated report is not. Keep the authorisation record and the change-detection record distinct inside it, because the assessor tests them as two separate controls.
This does happen, and the inventory is often how it is found. Treat it as an incident: preserve the payload as evidence, determine the exposure window from your records, and follow your incident response and breach notification obligations. Do not simply delete it, because the payload is what tells you what it collected.
Yes, it is allowed. PCI DSS names the control, not a product, and the techniques can be run by you or by a third party. A workable setup is a strict CSP with reporting, SRI on static scripts, an inventory with a written justification per script, and a scheduled headless browser such as Playwright or Puppeteer that loads each payment page at least weekly, records every script hash and security header, compares them with an approved baseline and alerts a named person. The cost is upkeep and evidence: scripts injected by a tag manager, or only for some visitors, are easy to miss from one crawler, and you have to keep the records an assessor will ask for.
Related articles
PCI DSS
PCI DSS compliance: a practical guide for 2026
What the standard covers, what changed in v4.0.1, and where the two client-side requirements fit.
PCI DSS
PCI DSS 4.0.1 requirements: what changed and when
The changes that matter, the dates that already passed, and the two requirements most teams missed.
PCI DSS
SAQ A and the script requirements: who is exempt
The January 2025 carve-out is narrower than most people think. Here is what it actually says.
PCI DSS
PCI compliance cost: where the client-side line item lands
What drives the bill, which costs are one-off, and how the 6.4.3 and 11.6.1 line compares.
See every script on your own checkout.
Install the tag, mark your payment pages, and watch the inventory fill in. Free forever on 1,000 page views a month, no credit card.
Free forever plan. No credit card.