Key points
• Evidence should reflect the payment page as the customer browser receives it, not only source code in a repository.
• For 6.4.3, the evidence should cover inventory, authorization, integrity, and business justification.
• For 11.6.1, the evidence should show monitored pages, headers, change detection, frequency, and alert handling.
1. Define the scope
The first artifact is the list of payment pages and pages that influence the security of the e-commerce payment flow. This matters when checkout includes multiple steps, modals, embedded payment forms, or external scripts.
2. Build the executable script inventory
Requirement 6.4.3 needs more than a list of URLs. The inventory should record the source, owner, purpose, provider type, authorization status, and business justification for every relevant script.
3. Show the page and header baseline
For 11.6.1, teams need to show what the customer browser actually received: DOM, connected scripts, security-relevant headers, third-party calls, and detected differences from the approved baseline.
4. Add the response process
A QSA and an internal security team need to see the process behind detection: who receives the signal, who classifies it, how quickly the change is handled, where history is retained, and how remediation is confirmed.
5. Prepare an executive summary
Leadership usually needs a short summary: which pages are monitored, how many scripts are under control, which risks were found, what has already been fixed, and what remains before production rollout.
Practical steps
1
Define the payment pages and checkout flow in scope.
2
Export the live script inventory with owners and business reasons.
3
Capture the page, DOM, script, and header baseline.
4
Document alert handling, remediation, and evidence retention.
5
Prepare a concise summary for security leadership and QSA review.