PCI DSS requirement 11.6.1, in plain terms

PCI DSS 11.6.1 requires a change- and tamper-detection mechanism that alerts personnel to unauthorised modification of the HTTP headers and the contents of payment pages as received by the consumer browser, and that performs this evaluation at least once every seven days. It is the detection half of the client-side pair introduced in PCI DSS v4.0 and mandatory since 31 March 2025. Requirement 6.4.3 establishes what is supposed to be on the page. 11.6.1 notices when reality stops matching that. They are assessed as two separate controls with two separate pieces of evidence, which is why keeping them in one merged report is a common reason evidence gets sent back.

11.6.1 asks you to deploy a change- and tamper-detection mechanism, and it is specific about what that mechanism has to do:

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.

A payment page is assembled at runtime from parts you own and parts you rent. Tamper detection has to cope with that: the page legitimately differs between visitors, because of A/B tests, locale, consent state and logged-in status. A mechanism that alerts on every difference is noise, and a mechanism tuned until it is quiet has usually been tuned past the point of usefulness.

The workable distinction is between the page varying and the page changing. A new script origin, a changed payload hash on an approved script, a security header taking a value it has never taken before, a new outbound destination: those are changes. A different hero image for half your traffic is variance. The evidence an assessor wants is the first category, recorded with timestamps and a record of who was told.

Headers are in the requirement because weakening one is a quiet way to make an attack possible. Loosening a Content-Security-Policy, dropping X-Frame-Options, or removing HSTS changes what the browser will permit, and none of it is visible in the page body. A header change is often the first observable step of an attack rather than the attack itself.

The practical output is a weekly record of every distinct value observed per header. One value across the window means the header was stable. Two values means something changed, and the record shows what it changed to and when, which is exactly the evidence 11.6.1 is asking you to keep.

You will see this written as both PCI 11.6.1 and PCI DSS 11.6.1, and they refer to the same requirement. Seven days is a floor, not a target. An attack that runs for six days inside a weekly window is fully compliant and fully successful. The requirement allows a different frequency if you justify it through a targeted risk analysis under 12.3.1, but that is paperwork to run slower, and almost nobody wants that argument with an assessor.

Continuous monitoring removes the question. If the mechanism evaluates every session, the seven-day floor is met by a wide margin and the evidence pack can state the actual frequency instead of the minimum.

A targeted skimmer fires for a slice of traffic: one country, one card BIN, one hour. Sampling is the norm in this category, commonly 10% of sessions and sometimes as low as 1%. That is a coin flip against an attack designed to be rare.

For 11.6.1 specifically: the list of pages in scope, the headers and page properties being evaluated, the frequency, the record of changes detected in the period, and proof that personnel were alerted. That last one is the one teams forget. Detection without a recorded alert is half the control.