Monitoring for CSP (PCI DSS 11.6.1)

Your checkout page has seventeen scripts. Marketing added three through the tag manager last quarter. Nobody owns the inventory. Someone says "we have CSP" in the audit call, and then cannot show a single alert from the last ninety days.

That is not monitoring. That is hope with a header.

PCI DSS 11.6.1 is the requirement that closes that gap. It sits next to 6.4.3 (script inventory, authorization, integrity, and justification) and asks a harder question: if something unauthorized shows up on the payment page as the customer's browser receives it, will you know, and will someone get alerted in time to act?

For mid-sized merchants, that question is practical, not academic. E-skimming does not wait for your annual ROC. It waits for a forgotten third-party script.

What 11.6.1 Actually Requires

Requirement 11.6.1 calls for a change- and tamper-detection mechanism that alerts personnel to unauthorized modification, including indicators of compromise, changes, additions, and deletions, to:

• Security-impacting HTTP headers on payment pages
• Script contents of those payment pages as received by the consumer browser

The mechanism must evaluate what the browser actually gets, and it must run at least weekly, or at a frequency defined by a targeted risk analysis under 12.3.1.

Read that carefully. Server-side file hashes alone are not enough if scripts assemble in the browser from CDNs, tag managers, and third-party widgets. The control cares about the consumer's view of the page.

Also note what it does not say: prevent every bad change forever. 11.6.1 is detection and alerting. Prevention and authorization live with 6.4.3. You need both.

CSP is useful in this story. It is not the whole story. If your plan is "we shipped a CSP header, so we're done," you will struggle when your QSA asks how you detect, alert, and respond.

Where CSP Fits, and Where It Doesn't

Content Security Policy is useful. It is not a complete 11.6.1 program by itself.

A solid CSP can:

• Limit which origins may load scripts (script-src)
• Prefer hashes or nonces over wildcards
• Report violations via report-to or report-uri

That reporting path is how CSP becomes monitoring instead of silent blocking. Without violation collection, ownership, and follow-up, CSP is just a filter nobody watches.

CSP still leaves gaps mid-market teams hit every week:

• Dynamic payment scripts that resist clean Subresource Integrity (SRI) hashes
• Tag managers that rewrite the allowlist faster than GRC can document it
• Changes to the CSP header itself, which can be an attack signal and must be monitored
• "Report-only" policies that never graduate to enforcement because nobody owned the cleanup

Treat CSP as a preventive baseline plus a signal source. Pair it with browser-perspective monitoring of scripts and security headers, alongside Subresource Integrity and a living 6.4.3 inventory. That combination maps to how QSAs are reading 6.4.3 and 11.6.1 together.

If you embed a payment processor iframe, 11.6.1 still applies to your parent page. Scripts inside the processor's embedded form are generally the processor's responsibility, but your surrounding page, tags, analytics, and widgets remain in scope.

A Practical Stack for Mid-Sized Merchants

You do not need a Fortune-500 security engineering org. You need a stack you can run every week.

1. Know your payment pages. List every URL where card data is entered or scripts can touch the payment flow, including iframes and hosted fields you still influence. Cart, checkout, confirmation, and promo checkouts all count. If marketing runs a promo checkout, it is in scope.

2. Finish the 6.4.3 homework. Inventory scripts. Authorize them. Justify business need. Apply an integrity method (SRI where it holds, approved vendor controls, or equivalent). 11.6.1 alerts are noisy and useless without a baseline of what is supposed to be there. Monitoring a mess just creates a louder mess.

3. Deploy CSP with reporting. Start report-only if you must, but set a date to enforce. Send violations to a destination someone actually reviews. Alert on unexpected script hosts and on CSP header drift.

4. Add browser-perspective change detection. Options include synthetic monitoring that fetches pages like a customer, client-side tamper detection, CDN or reverse-proxy change alerts, or a purpose-built payment-page integrity tool. Prefer live payment-flow checks over a cached server copy alone. Pick what matches your architecture, and prove it sees what the browser sees.

5. Alert people who can act. Name an owner. Define severity. Route to Slack, ticket, or on-call. A weekly PDF nobody opens is not a control. The requirement is detection plus alerting, not silent logs.

6. Evidence on a cadence. Keep samples of baselines, alerts, investigations, false-positive tuning, CSP violation summaries, and TRA rationale if you are not on a strict weekly schedule. Name an owner. Timestamp everything. Auditors ask for the mechanism and the operating proof.

Operating Cadence That Survives an Audit

Weekly is the default. If you choose a different frequency, document the targeted risk analysis: threat landscape, payment-page change rate, detection capability, and compensating factors. With frequent tag releases, weekly is a floor, not a goal.

Each cycle, ask:

• Did any new script appear on an in-scope page?
• Did any authorized script's content or source change without a change ticket?
• Did security headers (CSP, HSTS, framing controls, and peers you treat as security-impacting) drift?
• Were alerts acknowledged and closed with a disposition?

Tie script changes to change management. Marketing should not be able to drop a new analytics tag on checkout without GRC and security seeing it the same week, preferably before production. Unauthorized changes should also trigger a 6.4.3 script-control review.

Common Failure Modes

Mid-sized programs usually stumble in the same places:

• CSP with no report pipeline. Blocks (or would block) but never alerts. A header without alerts, owners, and review evidence is configuration, not monitoring.
• Inventory that is a one-time spreadsheet. Drift starts the day after the assessment.
• Server-only FIM. Misses CDN and tag-manager payloads the browser executes. Magecart-style attacks often inject scripts dynamically; if you ignore the live DOM during payment, you can miss what 11.6.1 cares about.
• Vendor "we handle PCI" assumptions. Embedded forms help, but your SAQ or ROC still needs your evidence for pages you control.
• Alerts with no owner. Detection without response is theater.
• Weekly in theory, never in practice. Teams document the cadence, then cannot show tickets or reports proving the check ran and someone reviewed results.

Fix those before you buy another dashboard.

How This Ties to Day-to-Day GRC

11.6.1 is not a one-off project. It is an operating control: inventory, detect, alert, investigate, evidence.

Keep the script inventory, exceptions, TRA, and alert tickets connected to the same compliance workflow you already use for PCI, so the control shows up in weekly work, not only in the ROC binder. Platforms like episki help when they keep requirements, owners, and evidence in one place instead of three SharePoint sites and a forgotten CSP report bucket.

What "Good Enough" Looks Like

For a mid-sized merchant, good enough usually looks like this:

• Payment pages and parent pages are identified and owned
• Scripts are inventoried and authorized under 6.4.3
• CSP is implemented thoughtfully, with reporting turned on
• A change and tamper detection mechanism compares browser-received scripts and security-impacting headers against baseline
• Alerts reach a human on a defined schedule
• Evidence of weekly (or TRA-defined) operation is retained for assessment

You can buy parts of this, build parts, or combine both. PCI guidance allows a mix. What is not acceptable is hoping a single header equals continuous assurance.

Key Takeaways

• PCI DSS 11.6.1 requires change and tamper detection and alerting for payment-page scripts and security-impacting headers as the consumer browser receives them, at least weekly or per TRA
• CSP helps constrain unauthorized loads and can feed monitoring via violation reports, but CSP alone is not a complete 11.6.1 answer
• Pair CSP with browser-perspective monitoring, a living 6.4.3 inventory, and named alert owners
• Mid-sized merchants win with a simple weekly stack and evidence, not with an unread policy header
• Common failures: no reporting, stale inventories, server-only checks, and orphaned alerts

Skimmers live in the gap between "we set a header" and "we watch what customers actually load." Close that gap on purpose.

Are you detecting unauthorized changes on payment pages the way PCI DSS 11.6.1 expects, or only shipping a CSP header? episki helps teams keep script inventories, control ownership, alert evidence, and PCI DSS workflows in one place your team will actually use. Get started free