Requirement 11.6.1 of PCI DSS asks you to notice when your payment page changes. Not to know what is on it, which is requirement 6.4.3, but to be told when it stops being what it was. It has been mandatory since 31 March 2025. This page covers what the requirement asks for, what counts as a change, how often you have to look, and what the evidence needs to show.
What requirement 11.6.1 says
The requirement asks for a change and tamper detection mechanism. It has to alert your staff to unauthorized modification of two things: the security-impacting HTTP headers of your payment pages, and the content of those pages as the customer's browser receives them. It has to run at least once every seven days, or at whatever frequency you set out in a targeted risk analysis under requirement 12.3.1. The phrase that does the most work in that sentence is "as received by the consumer browser". It is not asking you to diff the files on your server. It is asking what actually arrived at the person typing in a card number. That is a different thing the moment a tag manager, a CDN, an ad platform or an injected script is involved.
Why it is a separate requirement from 6.4.3
An inventory is a document, and a document is accurate on the day it is written. Requirement 6.4.3 gets you a list of every script on the checkout with a written reason for each one, which is real work and worth doing. But the attack this pair of requirements exists to stop does not care about your list. A skimmer arrives on the checkout after the fact, usually through a supplier the page already trusts, and it does not announce itself. So 11.6.1 is the half that runs on a clock. The useful sentence is not "we have seven scripts". It is "something appeared on the checkout last Tuesday that was not there on Monday", and no filed document can produce that sentence.
What counts as a change
More than a new script tag, though that is the obvious one. A script that was there yesterday and is gone today is a change. A script at the same URL whose contents are different is a change, and it is the one that matters most, because a compromised vendor file keeps its name. A new host appearing in the list, or a new subdomain of a host you already allow, is a change. The headers count too. Losing HSTS, a Content Security Policy weakened or removed, framing protections disappearing, a certificate about to expire or one that has quietly changed issuer: those are all changes the requirement expects you to catch. Some of these will turn out to be your own marketing team, and that is fine. The requirement is that somebody sees them, not that every one is an incident.
How often you actually have to look
Seven days is the floor, not the target. The standard lets you set a different frequency through a targeted risk analysis under 12.3.1. That analysis is a real document your assessor will read. It has to identify the asset, the threat, the factors you weighed, and a review at least every twelve months. Here is the practical shape of it. Going less often than weekly means writing an analysis that justifies it, and an assessor will push on that. Going more often than weekly does not, because you are exceeding the requirement. That removes the need for the analysis entirely. A daily check is easier to defend than a weekly check plus a document arguing that weekly is enough. The real argument for daily is not compliance anyway. A skimmer that sits on your checkout for six days before anybody looks has had six days of card numbers.
What the evidence has to look like
An assessor is not going to take your word that a mechanism exists. They will ask what it looked at, when it looked, and what happened when it found something. So the record needs dates on it: when each script was first seen, not just that it is there now, and which days a check ran and reached the page. It also has to show what was raised, who saw it, and what they decided. That last part is the piece most tools leave to you and most merchants skip. A change that was detected and never triaged is worse evidence than no change at all, because it shows the alerting worked and the people did not. Keep the decision next to the finding, in words, with a date and a name on it.
The alert nobody sends
There is a failure mode worth designing against. A monitoring mechanism that only emails you when something changes is indistinguishable, from your inbox, from a monitoring mechanism that broke in March. Silence looks the same either way. This is not a hypothetical: a scan can start failing quietly because a firewall began answering instead of your server, because a certificate expired on the checking side, or because the page moved. So whatever you use, make sure it tells you it looked and found nothing, on a schedule, and make sure someone would notice if that message stopped arriving. The positive report is the one that proves the negative reports mean something.
What a WAF or a bot filter does to this
Worth knowing before you turn anything on. If your checkout sits behind Cloudflare, a WAF, or any bot management layer, an automated check may be served a challenge page or a 403 instead of your real checkout. That response is a real page with real HTML, so a naive tool will read it, find none of your scripts in it, and cheerfully report that everything is clean. It is the worst possible failure, because it looks like good news. If you are evaluating any tool for this, ask it directly what it does with a challenge response. It should tell "we read the page and nothing changed" apart from "we never saw the page". Our note on ASV scan errors behind Cloudflare covers the same class of problem on the scanning side.
Does this apply to you if you use SAQ A?
Possibly not as a numbered requirement, and probably still as work. The revised SAQ A published in January 2025 does not list 6.4.3, 11.6.1, or the 12.3.1 risk analysis that supported them. What it has instead is an eligibility criterion. To use SAQ A at all, you have to confirm two things: that every element of the payment page comes only and directly from a PCI DSS compliant provider, and that your site is not susceptible to script attacks. That is a condition you meet before the short form is available, rather than a question on it. If your customers leave your site entirely to pay, your page never renders the payment form and the question does not arise. If the payment form is embedded in your page, it does. Our SAQ selection guide walks through the decision, and your acquiring bank has the final say and can ask for more than the questionnaire does.
Building it yourself
It is a reasonable thing to build, and it is more work than it first looks. You need something that fetches the payment page on a schedule, from outside your own network. Ideally with a real browser, so you see the scripts a tag manager adds after the page starts. It has to store what it saw, not just compare against yesterday. Then you need a baseline somebody approved, a way to record a decision against each script, and alerting that goes to a person who will act on it. And you have to keep all of it long enough to cover the audit period you are assessed over. The hard parts are not the fetching. They are telling a real change from a vendor's routine release, keeping the record honest about the days the check failed, and making sure the whole thing does not quietly stop.
Or have it watched
Our payment page monitoring is built for this pair of requirements. It loads your payment pages in a real browser every day rather than weekly, so it sees what a tag manager adds after the page starts. It dates every script it finds, keeps the justification you wrote against each one, and reads the headers and certificate alongside the scripts. It emails you when something changes and emails you every week when nothing has. It records which days a scan reached the page and which days it did not, and it will not count a firewall challenge as a clean read. Every report states how much of the page that day's scan covered, so a run that saw less than the whole page says so. The output is a dated inventory and a change history you can hand to an assessor, as a spreadsheet or as a printed report.
Start by looking once
If you have never looked at what your checkout actually loads, do that before you decide what to buy or build. Our free payment page check reads your checkout page once and lists the scripts written into its HTML, along with which ones come from a domain other than yours. It needs no sign-up and it publishes nothing. It is a snapshot, so it cannot tell you what changed, but it will tell you whether there is anything on your checkout worth watching. Most people find at least one entry they cannot immediately explain, and that entry is where this work starts.