Vigilant
Just explore Start now

Payments Glossary · Risk & Compliance

PCI Requirement 11.6.1

Also called 11.6.1, payment page tamper detection

Requires a change and tamper detection mechanism on payment pages that alerts on unauthorized modification, evaluated at least weekly.

What it is

Requirement 11.6.1 of PCI DSS v4.0 and v4.0.1 requires deploying a change and tamper detection mechanism for payment pages that alerts personnel to unauthorized modification of the HTTP headers and the content of the page as received by the consumer's browser, with the mechanism evaluated at least every seven days or at a frequency defined by a targeted risk analysis. It became mandatory March 31, 2025. The key phrase is as received by the consumer's browser. Server-side file integrity monitoring does not satisfy it, because the attack it targets often never touches your server: a compromised third-party script, a hijacked tag manager, or a malicious browser-level injection changes what the customer sees without changing anything on your host. Where 6.4.3 governs what you authorize onto the page, 11.6.1 governs detecting what actually happened on it. The two are companions and were introduced together for the same reason: Magecart-style e-skimming. As with 6.4.3, 11.6.1 was removed from SAQ A itself in v4.0.1, replaced by the eligibility criterion about script susceptibility. Merchants using a full redirect or fully outsourced payment page do not trigger that criterion. Merchants using embedded fields or iframes must either implement the techniques or hold written confirmation from a PCI DSS compliant processor.

Why it matters to your business

For most Southwest Florida small businesses with a website, the cheapest correct answer to 11.6.1 is architectural, not commercial: move to a fully redirected checkout, or get your processor's written attestation for its embedded form. Either removes the need to buy monitoring. Buy tooling only if you genuinely control a custom checkout page. This is education, not legal advice. Whether your specific validation path is acceptable is a question for your acquirer and, where liability is at issue, your attorney.

Where it gets contested

This is the requirement client-side security vendors were built for, and the marketing runs well ahead of the obligation. A single-location retailer with a redirect checkout does not need a monitoring subscription, and being sold one is not compliance, it is spend. At the same time, dismissing it entirely is wrong. The threat model is real and has produced some of the largest card breaches of the last decade, and the merchants hit hardest were often the ones certain they were fully outsourced because the card fields were in someone else's iframe. The unresolved space is proportionality for very small merchants. The standard permits a targeted risk analysis to justify a frequency other than weekly, but performing a defensible targeted risk analysis is itself a documentation exercise most small merchants will never do. In practice the field splits into merchants who buy tooling, merchants who redirect and step out of scope, and merchants who answer the questionnaire optimistically.

How to check it yourself

Ask your web developer one question: if someone modified the JavaScript delivered to a customer's browser on our checkout page tomorrow, what would tell us, and how fast? If the honest answer is nothing, you do not have a 11.6.1 mechanism.

Receipts

Claims above that are checkable, with where to check them. Published so you do not have to take anyone's word for it.