--- description: A step-by-step guide to meeting PCI DSS 4.0 Requirement 11.6.1 - continuously detecting and alerting on unauthorised change to your payment pages with Report URI. --- # PCI DSS 11.6.1 Requirement 6.4.3 gets your payment page into a known-good state. Requirement 11.6.1 keeps it there. It calls for a change- and tamper-detection mechanism that alerts on unauthorised modification of the security-impacting HTTP headers and the script contents of payment pages, as received by the consumer's browser. This guide covers meeting it with Report URI. !!! quote "PCI DSS v4.0.1, Requirement 11.6.1" A change- and tamper-detection mechanism is deployed as follows: - To alert personnel to unauthorized 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. - The mechanism is configured to evaluate the received HTTP headers and payment pages. - The mechanism functions are performed as follows: - At least weekly OR - Periodically (at the frequency defined in the entity's targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1). !!! note This is a practical implementation guide, not compliance advice. Your QSA is the authority on how Requirement 11.6.1 applies to your specific environment. ## The advised mechanisms The standard's guidance lists the techniques that satisfy this requirement, and the first two describe exactly how Report URI works. !!! quote "PCI DSS v4.0.1, Requirement 11.6.1, Guidance" Mechanisms that detect and report on changes to the headers and content of the payment page could include, but are not limited to, a combination of the following techniques: - Violations of the Content Security Policy (CSP) can be reported to the entity using the report-to or report-uri CSP directives. - Changes to the CSP itself can indicate tampering. - External monitoring by systems that request and analyze the received web pages (also known as synthetic user monitoring) can detect changes to JavaScript in payment pages and alert personnel. - Embedding tamper-resistant, tamper-detection script in the payment page can alert and block when malicious script behavior is detected. - Reverse proxies and Content Delivery Networks can detect changes in scripts and alert personnel. The guidance also notes that "the use of any one mechanism is not necessarily a full detection and reporting mechanism" — a combination is expected. Report URI implements the first two techniques directly and adds script- and data-level change detection on top: - **CSP violation reporting** via the `report-to`/`report-uri` directives — see [Capture change as it happens](#capture-change-as-it-happens). - **Detecting changes to the CSP itself** — see [Detect change to your security headers](#detect-change-to-your-security-headers). - **Detecting changes to the scripts and data flows** on the page — see [Script Watch](#detect-change-to-the-scripts-on-your-page) and [Data Watch](#detect-unexpected-data-movement). This also fits the requirement's stated intention. The Applicability Notes are explicit that the goal is not to run code on your customers: !!! quote "PCI DSS v4.0.1, Requirement 11.6.1, Applicability Notes" The intention of this requirement is not that an entity installs software in the systems or browsers of its consumers, but rather that the entity uses techniques such as those described under Examples in the Guidance column to prevent and detect unexpected script activities. Report URI works entirely through the browser's native Reporting API. There is no agent, no proxy, and no code injected into your pages or your customers' browsers. ## Capture change as it happens 11.6.1 is a detective control, so the foundation is a live signal from real browser sessions rather than a periodic scan. A Content Security Policy with a reporting endpoint provides exactly that: every time the policy is violated — an unauthorised script tries to load, or an authorised one is tampered with — the browser sends a report. This is the first technique in the guidance above. If you followed the [PCI DSS 6.4.3](/compliance/pci-dss-6-4-3/) guide you already have this in place. If not, start with the [Content Security Policy](/setup/csp/) setup guide to add a reporting endpoint to your policy. ## Detect change to the scripts on your page [Script Watch](/setup/script-watch/) monitors the scripts loaded on your payment pages and alerts you the moment one is added, modified, or removed. This is the core of the "script contents of payment pages" clause in 11.6.1 — you are notified of change rather than discovering it at your next audit. ## Detect change to your security headers [Policy Watch](/setup/policy-watch/) monitors the security-impacting HTTP headers your site actually serves — your Content Security Policy chief among them — and alerts you if the deployed policy drifts from what you authorised. An unexpected wildcard added to `script-src`, a removed directive, a header that stops being sent: Policy Watch surfaces it. This covers the "security-impacting HTTP headers" clause, and the guidance's second technique — "Changes to the CSP itself can indicate tampering." ## Detect unexpected data movement [Data Watch](/setup/data-watch/) tracks where data is being sent from your pages and flags destinations it hasn't seen before. Where Script Watch tells you a script changed, Data Watch tells you if the page starts sending data somewhere it shouldn't — the behaviour a working skimmer ultimately produces. ## Meet the frequency requirement 11.6.1 requires the detection mechanism to run at least weekly, or at a frequency set by your own targeted risk analysis under Requirement 12.3.1: !!! quote "PCI DSS v4.0.1, Requirement 11.6.1" The mechanism functions are performed as follows: - At least weekly OR - Periodically (at the frequency defined in the entity's targeted risk analysis...). Because Report URI is driven by live browser reports rather than a scheduled scan, detection is **continuous** — every affected page load is a check. That comfortably exceeds the "at least weekly" minimum, and the Customized Approach Objective the standard sets: that skimming code "cannot be added to payment pages... without a timely alert being generated." You still document your monitoring frequency for your assessor, but you are not relying on a weekly job to catch a skimmer that could be live for days in between. ## Tune your alerts Detection is only useful if the right people hear about it promptly. Every watcher has a **Config** modal (see [Configuring a Watcher](/setup/script-watch/#configuring-a-watcher)) where you can: - set an **alert threshold** so you are notified on the first new observation, or only once several accumulate; - keep **email alerts** on for your account's notification address; and - enable **webhook alerts** (Business plans and higher) to push each detection into your own systems — see [Webhooks](/integrations/webhooks/) for the payload format. ## Produce the evidence Continuous detection also produces a continuous record. The change logs, CSP violation history, and alert trail are exportable as evidence that your 11.6.1 control was in place and working over the assessment period — not just at a single moment. Webhook delivery history is also recorded in your [Audit Trail](https://report-uri.com/account/settings/). The [PCI DSS 6.4.3 & 11.6.1 evidence pack](https://report-uri.com/pci-dss-evidence-pack) shows which of these artefacts satisfy each part of this requirement. ## Start with Report URI **Already using us?** Manage your watchers from [Script Watch](https://report-uri.com/watch/script_watch/), [Policy Watch](https://report-uri.com/watch/policy_watch/), and [Data Watch](https://report-uri.com/watch/data_watch/). **New to Report URI?** These capabilities are available on a Business plan or higher, or free during your trial month — [create a free account](https://report-uri.com/register/) to get started.