PCI DSS 11.6.1 evidence: what to prepare for your assessor

The six things to have ready

Each part of requirement 11.6.1 suggests a piece of evidence. The assessor decides what is sufficient for your environment, so treat this as a way to organize your evidence, and confirm the details with your assessor.

1. A description of the mechanism. What it is, where it runs (inside the page, outside your network, at a proxy), and who is responsible for it.
2. The list of payment pages it covers. Every page in scope, including checkout steps behind a login and pages that embed a provider's payment form, and who keeps the list current.
3. Proof of what it evaluates. The requirement is about the HTTP headers and the contents of payment pages as received by the consumer browser, so show that the mechanism looks at what a browser receives and not only at your source code or your server.
4. A dated history of runs. Results from every run, with dates, covering the whole period the assessment looks at.
5. A record of alerts and what happened next. Who is notified, how alerts are triaged, and the decision made for each change (authorized or not, and why).
6. The targeted risk analysis, if you do not run weekly. The requirement allows a frequency other than every seven days only if it comes from a targeted risk analysis performed according to requirement 12.3.1.

Evidence for each part of the requirement

Questions to ask yourself before the assessment

These are the places where evidence most often runs thin, as a practical checklist rather than a statement about any assessor:

• Do you keep the results, or only run the check? A mechanism with no saved history of runs is hard to demonstrate afterwards.
• Is the payment step really covered? If the payment form sits behind a login or appears mid-flow, a check of the public pages alone may not evaluate the page that matters.
• Is every alert assigned to a person? The requirement is about alerting personnel, so someone must be named, reachable and able to say what they did.
• Is the page list current? New checkout steps and new payment pages should be added when they appear.
• Did the frequency change? If you moved away from weekly, is the targeted risk analysis written down and reviewed?
• Can you show an unauthorized change being handled? A recorded example, from a test if no real change has occurred, shows the process works.

Requirement 11.6.1 has been mandatory since 31 March 2025. Keep the evidence for the whole assessment period, in a form you can export and date.

Keeping the evidence audit-ready

Decide where the proof lives before the assessment starts. A single folder or system that holds the description, the page list, the run history, the alerts and the decisions saves a scramble later. Date everything, keep who made each decision, and review the page list and the alert recipients on a schedule (for example, every quarter and after any change to the checkout).

The related PCI DSS client-side security checklist puts 6.4.3 and 11.6.1 side by side, and how to detect client-side tampering explains what the checks look for.