PCI DSS 11.6.1: A change- and tamper-detection mechanism
PCI DSS v4.0.1 control 11.6.1: the requirement in full, the 4 testing procedures an assessor uses to verify it, and the related controls in section 11.6.
Requirement 11: Test Security of Systems and Networks Regularly › Section 11.6
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).
Summary
Watch your payment pages for unauthorised changes to their scripts and security-relevant HTTP headers, and alert someone when they change, at least weekly.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 11.6.1.a | Examine system settings, monitored payment pages, and results from monitoring activities to verify the use of a change- and tamper-detection mechanism. |
| 11.6.1.b | Examine configuration settings to verify the mechanism is configured in accordance with all elements specified in this requirement. |
| 11.6.1.c | If the mechanism functions are performed at an entity-defined frequency, examine the entity’s targeted risk analysis for determining the frequency to verify the risk analysis was performed in accordance with all elements specified at Requirement 12.3.1. |
| 11.6.1.d | Examine configuration settings and interview personnel to verify the mechanism functions are performed either: • At least weekly OR • At the frequency defined in the entity’s targeted risk analysis performed for this requirement. |
Mandatory since 31 March 2025. The four procedures test the mechanism exists (a), that it is configured to evaluate both headers and page content (b), that any entity-defined frequency is backed by a targeted risk analysis under 12.3.1 (c), and that it actually runs at that frequency (d). Choosing "periodically" instead of weekly is allowed, but only if the risk analysis exists. Without it, weekly is your obligation.
What to prepare
- Evidence the mechanism is deployed and monitoring your payment pages, with the list of pages covered.
- Configuration showing it evaluates both the received HTTP headers and the script content, as received by a consumer browser.
- Alert records and their disposition, showing a human saw and acted on them.
- If you monitor less often than weekly, the targeted risk analysis that justifies the frequency, performed to 12.3.1.
How to implement it
1. Monitor what the browser receives, not what the server holds. The attack this control exists to catch injects a script between your server and the consumer, so a mechanism that diffs your own source repository will not see it. The evaluation has to be of the delivered page.
2. Cover the headers as well as the scripts. Content Security Policy, HSTS and the other security-relevant headers are in scope, and a silently weakened CSP is exactly the kind of change an attacker makes first.
3. Route alerts to somebody who will act. The procedures examine results from monitoring activities, which means alerts with no recorded disposition read as a mechanism nobody watches.
4. Pick weekly unless you have the risk analysis. The entity-defined frequency option is genuinely available, but 11.6.1.c asks to see the analysis behind it. Weekly is simpler to evidence than a risk analysis you have to repeat periodically.
Where this commonly fails
- A generic uptime or availability monitor presented as change detection, which sees the page load but not what changed in it.
- Monitoring the main checkout page but not the iframe or hosted field that actually collects the card number.
- Alerts firing into a channel nobody owns, so there is no disposition to show the assessor.
- Claiming a periodic frequency without the 12.3.1 targeted risk analysis, which turns an allowed option into a gap.
How PCIComplianceHub helps
Our Payment page header monitoring records the security-impacting response headers of each monitored payment page on every scheduled browser visit, keeps each evaluation so you can see what changed and when, and raises an alert when a header is added, altered or withdrawn.
Scope note. It covers the header half of this control from a scheduled crawler visit, not from live customer traffic. Script content is the Scripts tab of the same section, and the weekly cadence is recorded rather than enforced: a missed week is visible, and nothing chases it.
Signed in, you can retrieve your organisation's evidence for 11.6.1 as JSON: what the scanner has recorded, with the scope note above attached to it.
Related controls
This control refers to 12.3.1.
← 11.5.2 · All controls · 12.1.1 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.