Tessera
PCI DSS reference

PCI DSS 11.6.1: change and tamper detection on payment pages

What the change-detection mechanism has to evaluate, how often it has to run, and why an unbroken record of late checks does not satisfy the requirement.

Standard: PCI DSS v4.0.1 requirement 11.6.1. This is a plain-language reference, not legal advice, and it does not determine your PCI DSS compliance or which questionnaire applies to you. Your acquiring bank sets your reporting obligations.

The short checklist

  1. Deploy a mechanism that alerts personnel to unauthorized modification of payment pages.
  2. Evaluate the security-impacting HTTP headers and the page contents as received by the consumer browser.
  3. Run it at least once every seven days, or at the frequency your 12.3.1 targeted risk analysis defines.
  4. Keep the evaluation record — an alert nobody can evidence is hard to rely on later.

Two things are in scope, not one

The requirement names both the security-impacting HTTP headers and the contents of the payment page. A tool that watches scripts but ignores a Content-Security-Policy header being quietly relaxed covers half of it.

The cadence is part of the control

At least once every seven days, unless a targeted risk analysis under 12.3.1 sets a different frequency you can defend. This is the part that quietly fails: a monitor that stopped running months ago still produces a clean, unbroken history. An intact record of stale checks does not satisfy 11.6.1, so integrity of the record and currency of the record are two separate things to demonstrate.

  • Record every evaluation, including the ones that found nothing.
  • Be able to show there is no gap longer than your defined interval.
  • Be able to show the record itself was not edited after the fact.
  • Know who receives the alert, and confirm that person still works there.

'As received by the consumer browser'

That phrase is doing real work. It points at what the browser ends up with, after redirects and runtime changes — not only at what your server returned. Any tool you use, including ours, should tell you plainly which of those two it observes.

Primary source

Read the source rather than a summary of it, including this one: PCI DSS v4.0.1, requirement 11.6.1 — https://www.pcisecuritystandards.org/document_library/?class=pcidss&doc=pci_dss.

What the free check can and cannot tell you

The free check reads the HTML your server returns. It inventories script elements and observed integrity attributes, but it does not inspect HTTP response headers or fetch remote script bytes. Live 11.6.1 monitoring separately fingerprints selected response headers and referenced script contents. The free check does not run the page in a browser, and neither does live monitoring. A script injected at runtime by another script is outside what Tessera can see, and no static check can tell you whether a script is authorized — only you know that.

Reviewed August 2026. The standard and the questionnaires change; confirm against the current text before relying on anything here.

Check your checkout page for unauthorized and unverified scripts

Preview the synthetic 11.6.1 ledger before deciding whether the paid artifact fits your review.

Related