Key points
• 11.6.1 focuses on detecting unauthorized page and header changes.
• A useful baseline should represent the real customer-facing checkout flow.
• Alerts need ownership, triage, and evidence retention to be audit-ready.
What should be monitored
Teams should monitor the real payment page, important DOM changes, script changes, form behavior, and security-relevant HTTP headers.
The baseline should be reviewed when legitimate releases change the checkout experience.
How to avoid noisy monitoring
The process should separate expected release changes from unknown changes. Owners need a way to approve, explain, or investigate each deviation.
Why file integrity monitoring is not the whole answer
File integrity monitoring can detect server-side file changes, but it may miss CDN modification, dynamic injections, third-party script behavior, or the final headers and DOM delivered to the customer.
For 11.6.1, the payment page has to be treated as a customer-facing artifact: what loaded, which headers arrived, and how that differs from the approved baseline.
Triage and evidence
Detection only matters if the team can classify the event. The process should define who receives alerts, who investigates changes, how legitimate releases are recorded, and where the final evidence is stored.