Understanding PCI DSS 11.6.1: Detecting Changes to Payment Pages

E-skimming attacks change what a customer's browser receives on a payment page, usually by adding or altering a script that copies card details as they are typed. Nothing on the server has to change for it to work, which is why server-side checks can miss it. Requirement 11.6.1 is the standard's answer: watch the page as the browser receives it, and raise an alert when it changes without authorisation. This article covers what it requires, who it applies to, how often it runs, and the techniques the standard names.

What 11.6.1 requires

A change- and tamper-detection mechanism must:

• alert personnel to unauthorised modification, including indicators of compromise, changes, additions and deletions, to the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser;
• be configured to evaluate the received HTTP headers and payment pages;
• run at least weekly, or at a frequency the entity sets in a targeted risk analysis performed under 12.3.1.

Two things in that wording matter. It is about what the browser receives, not the files on the server. And v4.0.1 narrowed the target to security-impacting headers and script contents, so a mechanism that alerts on every text or image change is doing more than the requirement asks.

The customised approach objective states the outcome: skimming code or techniques cannot be added to payment pages as received by the browser without a timely alert, and anti-skimming measures cannot be removed without a prompt alert.

How an assessor tests it

The testing procedures have the assessor examine system settings, the monitored payment pages and the results of monitoring; check the configuration against every element above; and confirm the mechanism runs weekly or at the defined frequency. If the frequency is the entity's own, the assessor examines the targeted risk analysis behind it.

That risk analysis is not a formality. 12.3.1 requires it to identify the assets being protected, the threat, the factors that affect likelihood and impact, and a justification for the chosen frequency, and to be reviewed at least once every 12 months. It can justify a frequency other than weekly in either direction, but it has to show why.

Who it applies to

11.6.1 was future-dated in v4.0 and has been assessed since 31 March 2025. It applies to an entity assessed against the full standard, and to merchants on SAQ A-EP or SAQ D.

It is no longer an SAQ A requirement. On 30 January 2025 the Council announced that 6.4.3, 11.6.1 and the targeted risk analysis supporting 11.6.1 were being removed from SAQ A, and an eligibility criterion added instead: the merchant confirms its site is not susceptible to attacks from scripts that could affect its e-commerce systems. The Council's FAQ 1588 says that criterion applies only to merchants whose page embeds the provider's form, such as an iframe, and that one way to meet it is with techniques such as those in 6.4.3 and 11.6.1. How iframes simplify PCI DSS compliance covers it in full.

The applicability notes settle the iframe question for entities assessed against 11.6.1: the requirement applies to the entity's own page that includes a provider's embedded payment form, but not to the scripts inside the provider's frame, which are the provider's to manage. The entity should expect evidence from the provider that it meets the requirement for those, under its own assessment and 12.9. The notes also say the requirement does not mean installing software on customers' devices.

How it fits with 6.4.3

6.4.3 manages the scripts: every payment page script is authorised, its integrity is assured, and it is recorded in an inventory with a justification. 11.6.1 detects when what the browser receives stops matching that. One without the other leaves a gap: an inventory nobody checks against the live page, or alerts about changes nobody can judge because there is no record of what was authorised.

The techniques the standard names

The guidance to 11.6.1 lists mechanisms that could be combined, and says the list is not exhaustive and that no single one is necessarily a full detection and reporting mechanism:

• Content Security Policy reporting. Violations of the page's CSP can be reported with the report-to or report-uri directives, and a change to the CSP itself can indicate tampering.
• External monitoring, also called synthetic user monitoring: a system requests the page, analyses what it receives, and alerts on changes to its JavaScript.
• A tamper-detection script embedded in the page that alerts on, and can block, malicious script behaviour.
• Reverse proxies and content delivery networks that detect changes in scripts and alert.

The guidance adds that these are often subscription or cloud services, and can also be built in-house.

A CSP with reporting might start like this, with the report endpoint collecting what the browser blocked:

Content-Security-Policy: script-src 'self' https://scripts.provider.example;
  object-src 'none'; base-uri 'self';
  report-to csp-endpoint

Making the alerts useful

• Tie it to change control. An authorised release should update the baseline, so the next alert means something. Script changes by third parties, such as a tag manager or an analytics provider, need the same route into your inventory.
• Decide who answers an alert, and how fast, before the first one arrives. 12.10.5 requires the incident response plan to cover monitoring and responding to alerts from the payment page change- and tamper-detection mechanism.
• Watch the headers that protect the page, such as the CSP and HSTS. Removing a protective header is one of the changes the customised approach objective is written to catch.
• Keep the evidence: which pages are monitored, the configuration, the results over the period, and what was done about each alert.