PCI DSS 11.6.1 requires a change and tamper detection mechanism that alerts staff to unauthorized changes to the HTTP headers and contents of payment pages as received by the consumer's browser. It runs at least every seven days or at a frequency set by your targeted risk analysis. It complements 6.4.3 on script management. This is not legal advice.
Definitions
Payment page: the page a consumer uses to enter payment details.
Change and tamper detection: a way to notice that what the browser receives differs from what you intended, including additions, changes and deletions.
What the text says
The SAQ D wording for 11.6.1: the mechanism alerts personnel to unauthorized modification, including indicators of compromise, changes, additions and deletions, to the HTTP headers and contents of payment pages as received by the consumer browser. It evaluates the received header and page, and performs those functions at least once every seven days or periodically at a frequency from your targeted risk analysis under 12.3.1.
The note clarifies the intent is not that you install software in consumers' browsers, but that you use techniques to prevent and detect unexpected script activity.
6.4.3 versus 11.6.1
| 6.4.3 | 11.6.1 | |
|---|---|---|
| Focus | Managing scripts | Detecting changes |
| Core ask | Authorize each script, assure integrity, keep an inventory with justification | Alert on unauthorized changes to page content and headers |
| Includes third and fourth party scripts | Yes | Detects what the browser receives |
| Cadence | Ongoing management | At least every seven days, or per risk analysis |
Both were recommended practices until 31 March 2025 and are required for assessment after that date, per the SAQ D notes. For SAQ A eligibility, see our post on embedded payment forms.
Steps to implement
- Inventory every script on each payment page and why it is there (6.4.3).
- Capture a known good baseline of page content and headers.
- Compare what the browser receives against the baseline on a schedule.
- Route alerts to a named owner with a response procedure.
- Document the interval choice, and the risk analysis if it is longer than seven days.
- Keep logs of runs and responses.
Quick check
Do I need a browser plugin for my customers?
No. The note says the intent is not to install software in consumers' browsers.
Can I check less often than every seven days?
The text allows a frequency set by a documented targeted risk analysis under 12.3.1.
On Safeguard: SBOM and dependency scanning covers the packages in your own front end build, which feeds the script inventory. It is not a runtime page monitor. Try the free scan at gold.safeguard.sh/scan.
Sources
Wording is from v4.0. Confirm in the current version.
Last reviewed: 19 October 2026.
