PCI DSS 11.6.1 explained: change- and tamper-detection for payment pages

What the requirement says, in plain words

This is a paraphrase; the exact wording is in PCI DSS v4.0.1, in the PCI SSC document library. Requirement 11.6.1 asks for a mechanism that does three things:

1. Alerts personnel to unauthorized modification of the HTTP headers and of the contents of payment pages. That includes indicators of compromise, changes, additions and deletions.
2. Evaluates what the consumer's browser receives. The headers and the payment pages are evaluated as they are received by the consumer browser, not as they exist in your source repository or on the server.
3. Runs on a schedule: at least once every seven days, or periodically at the frequency defined in the entity's targeted risk analysis, performed according to requirement 12.3.1.

Where requirement 6.4.3 defines what is allowed on the page, 11.6.1 notices when the page stops matching it. For the background, see why the PCI SSC created these requirements.

Why "as received by the consumer browser" matters

A page can change between your server and the customer: a content delivery network, a tag manager, a third-party script or a compromised plugin can add or alter code on the way or at runtime. A check of the repository or the origin server would miss all of that. Evaluating what the browser receives is the only view that includes everything the customer's browser will run. The same logic applies to HTTP headers such as the Content Security Policy, which can be removed or weakened by a change in a proxy, a CDN or the server configuration. See HTTP security headers for payment pages.

Meeting the requirement in practice

Approaches to the mechanism

The standard does not prescribe a tool. Approaches discussed in industry guidance include:

• External synthetic monitoring: a real browser visits the payment pages from outside your network and records the scripts, content and headers it receives.
• A script embedded in the page that reports what runs in real visitors' browsers.
• A reverse proxy or CDN feature that watches the content passing through it.

Each has strengths and gaps. An embedded script runs in the same place an attacker's script does; external monitoring sees what its own browser sees and may not reproduce a script that only targets certain visitors; a proxy sees traffic that passes through it but not what other scripts do inside the browser. Be ready to explain to your assessor how your approach, or combination of approaches, meets the intent.

Frequency and the targeted risk analysis

Weekly is the baseline. If you choose a different frequency, requirement 12.3.1 expects a documented targeted risk analysis that supports it, and a review of that analysis at least once every twelve months. Many organizations simply check more often than weekly, because a skimmer that runs for a week can cost a great deal.

What happens after an alert

The requirement is about alerting personnel, so someone must be named, notified and ready to act. Decide in advance how an alert is triaged (was the change authorized?), who investigates, how long you give yourself, and how it is recorded. See how to detect client-side tampering for a vendor-neutral process.

Evidence to keep

• a description of the mechanism and what it evaluates (headers and payment page content);
• the schedule, or the risk analysis that justifies another frequency;
• a history of runs, results and alerts;
• the investigation and decision recorded for each change.