PCI DSS 11.6.1 asks for one thing: a mechanism that spots unauthorised changes to your payment page and its HTTP headers as the customer’s browser receives them, and tells a person about it. That is the whole requirement. Not a dashboard, not a named product, not real-time blocking.
Most pages written about it explain the standard in standards language and then point at a licence to buy. This one assumes you have been told by your acquirer or QSA that you must satisfy it, that you have no security budget, and that you would rather spend a developer afternoon than four figures a year. Six workable options follow, with what each one costs you in maintenance and what an assessor will accept as evidence.
What PCI DSS 11.6.1 actually asks for
The requirement has three moving parts.
- A change and tamper detection mechanism that alerts personnel to unauthorised modification (including additions and deletions) to the HTTP response headers and the content of payment pages, as received by the consumer browser.
- The mechanism is configured to evaluate those received headers and pages.
- The check runs at least once every seven days, or at a frequency justified by a targeted risk analysis performed to all the elements of Requirement 12.3.1.
Two phrases do the work. “As received by the consumer browser”rules out monitoring only the files on your server. “Alert personnel”rules out a log nobody reads. The current text is in PCI DSS v4.0.1, available free from the PCI Security Standards Council document library.
The date matters more than the wording. Requirements 6.4.3 and 11.6.1 were future-dated best practices under v4.0 and became mandatory on 31 March 2025. An assessment after that date treats a missing mechanism as a finding, not a plan.
What the standard does not say
No tool is named. No vendor is implied. There is no requirement for continuous or real-time monitoring, no requirement for a hosted console, and no requirement that the mechanism be bought rather than built. A scheduled script that fetches your payment page, compares it with an approved baseline and emails a named person is inside the letter of the requirement, provided it covers headers as well as content and provided somebody acts on the alert.
Why 6.4.3 comes with it
Requirement 6.4.3 covers the scripts themselves: every script loaded and executed in the consumer browser on a payment page must be authorised, its integrity assured, and held in an inventory with a written justification for why it is needed. Detection without an inventory is noise, because you cannot say whether a change is unauthorised if nothing records what was authorised. Build both in the same piece of work. The groundwork is set out in more detail in this breakdown of what 6.4.3 and 11.6.1 ask of your payment page.
Whether 11.6.1 applies to you: SAQ level, iframes and shared responsibility
In January 2025 the Council published a revised SAQ A that removed 6.4.3 and 11.6.1 from the form, and added an eligibility condition instead: the merchant confirms its site is not susceptible to attacks from scripts that could affect the e-commerce environment. Read plainly, that is not an exemption. It is a statement you have to be able to defend, and defending it looks very like the work the two requirements describe. Check the current SAQ A against your own setup, and ask your acquirer what they expect, because acquirers may require more than the form does.
The shape of your integration decides how much is yours. A full redirect to the provider’s own domain moves the card form off your site entirely. Hosted payment fields embedded in your checkout do not: the inputs sit inside the provider’s iframe, but the page framing that iframe is still your template, still loads your scripts, and can still be covered with a convincing fake form drawn on top. Your provider’s responsibility matrix will say they cover the iframe content. The page around it is yours.
The common misreading is assuming the gateway’s PCI certificate covers your checkout template. It covers their service. If you are working through SAQ A eligibility, the script side of that argument is laid out in this guide to proving SAQ A eligibility when your checkout loads scripts.
Six cheap ways to satisfy PCI DSS 11.6.1
1. A scheduled hash and DOM diff of the rendered page and headers
Run a headless browser on a schedule (a cron job, or a free-tier CI workflow such as GitHub Actions) that loads your payment page, captures the response headers, lists every script URL the browser actually requested, normalises the HTML and hashes it. Commit the baseline. On any difference, email or Slack a named person with the diff attached, and keep the run log.
- Cost: a developer day to build, near zero to run.
- Maintenance: normalising nonces, CSRF tokens and cache-busting query strings, or the diff cries wolf every run.
- Evidence: strong. Version-controlled baselines, timestamped run logs and alert emails are exactly the audit trail assessors ask for.
- Limit: a weekly snapshot misses a skimmer injected and pulled between runs. If the job is cheap, run it daily.
2. Content Security Policy in enforce mode with a live reporting endpoint
An enforced policy stops scripts from origins you have not approved and, with a reporting endpoint configured, generates a record each time something tries. Those reports are your alert trail for unexpected script origins. The rollout pattern is report-only for a fortnight to find the legitimate traffic, then enforce, with reporting kept live permanently. A practical starting policy is given in this working CSP setup for a checkout page, and the reporting directives are documented in Mozilla’s CSP reference.
- Cost: free, plus somewhere to receive reports (a small serverless function will do).
- Maintenance: browser extensions generate a great deal of junk in the report stream. Filter before alerting, or nobody will read it.
- Evidence: good as a blocking control, partial as detection. Keep the policy, its change history and the report samples.
- Limit: a policy cannot see a malicious change inside a first-party file it already trusts, or data sent to an allowed origin.
3. Subresource Integrity hash-pinning on third-party scripts
Add an integrity attribute carrying the hash of the exact file you approved. If the file changes by one byte, the browser refuses to execute it. Genuinely cheap and genuinely effective against a tampered supplier file, as described in this piece on pinning the scripts you cannot control.
- Cost: free.
- Maintenance: real. The day a supplier rotates their file, the script stops loading. That is the correct security outcome and a support ticket in the same hour, so appoint an owner and agree a change process before pinning anything on a live checkout.
- Evidence: good for the integrity half of 6.4.3; it alone does not satisfy 11.6.1, because a blocked script does not alert anyone by itself.
- Limit: unpinnable against deliberately dynamic files. Tag managers and most analytics loaders change constantly by design.
4. Platform or CDN features you are already paying for
Before buying anything, check the plan you hold. Shopify controls its own hosted checkout and has steadily narrowed what merchant code can run there. Some CDNs ship client-side script monitoring and header change alerts inside paid tiers, Cloudflare’s Page Shield among them, with the more useful detection on the higher plans. Confirm what your current plan includes rather than what the marketing page implies, and ask whether the feature inspects the rendered page or only the files at origin.
- Cost: nothing extra if it is bundled.
- Maintenance: low, mostly tuning alert thresholds.
- Evidence: usually exportable reports, which assessors like.
- Limit: you inherit the vendor’s definition of a change, and bundled features move between tiers. Re-check at renewal.
5. Hosted payment fields or a full redirect, to shrink what must be monitored
The cheapest compliance work is work you delete. Moving card entry into provider-hosted fields, or out to the provider’s domain entirely, takes the inputs out of reach of any script on your page. Most UK gateways offer both. The reasoning is set out in this note on hosted payment fields as the cheapest way to remove skimming risk.
- Cost: integration time, no licence.
- Maintenance: low once live.
- Evidence: the integration diagram plus the provider’s responsibility matrix.
- Limit: it reduces the monitored surface, it does not remove the obligation. The framing page is still yours and still needs 11.6.1 coverage.
6. A paid client-side monitoring service
Commercial tooling watches the page continuously from real browser sessions, flags new script origins and outbound requests, and produces the evidence pack without you writing any code. Pricing is usually per site or per volume of page views, so get a current quote rather than trusting a figure in an article.
- Cost: a recurring licence.
- Maintenance: alert triage, which is the part people underestimate.
- Evidence: the strongest of the six, assuming you can show somebody responded to the alerts.
- When it is justified: many third-party scripts you cannot remove, several suppliers pushing changes without notice, no internal developer, or transaction values high enough that a fortnight of undetected skimming costs more than a year of licence.
Choosing between them
Four factors decide it. How many third-party scripts the payment page loads. How often those suppliers change their files without telling you. Who is on call when an alert fires. Whether you have a developer at all.
Combining two cheap controls usually beats buying one expensive one. Detection plus a blocking layer covers more ground than either alone: an enforced policy with reporting stops the unknown origin, and the weekly diff catches the change that happens inside something already allowed. One tool that only does detection leaves the attack running until somebody reads the alert.
On evidence, screenshots fall over. An assessor is testing that the mechanism exists, is configured against the right target, runs at the stated frequency and produces an alert that a named person handled. Keep the configuration, the schedule, the alert output, and a short written record of what happened when something fired. Including the false alarms, which prove the thing is switched on.
The script inventory that makes 6.4.3 and 11.6.1 defensible
Build the inventory from the browser, not from your templates. Open the payment page with developer tools, take the full list of requested scripts, and include the ones loaded by other scripts. Tag managers, chat widgets, A/B testing, session recording and affiliate pixels all pull in code that never appears in your repository.
Record, for each one: what it does, the business justification for it being on a payment page, the owner, and who authorised it. Keep that file in version control next to the code, so a change to the inventory is a reviewed commit rather than an edit to a spreadsheet nobody has opened since the last assessment. Review it on a schedule, quarterly is sensible, so the document still matches reality when it is read by someone else.
Most merchants find money here, not in tooling. A typical checkout carries a dozen tags, and perhaps three can be justified on the page where card details are typed. A chat widget has no business there. Deleting the rest cuts the attack surface and the monitoring workload at once, and it is free.
Mistakes that fail an assessment
Monitoring the server-side file instead of the delivered page is the big one. File integrity monitoring on your web root ticks a box and misses the attack the requirement exists to catch, because skimmer code is routinely injected at the third-party script, inside the tag manager container, or at the CDN edge. None of those touches your repository.
Three incidents make the point, and they map onto the three routes any detection approach has to see. Ticketmaster UK, disclosed in June 2018, was a compromised supplier script: the skimmer arrived inside a customised chat widget from Inbenta, so no review of Ticketmaster’s own code would have found it. British Airways the same summer was injected first-party JavaScript, a modified file served from the airline’s own site, which later drew a £20m fine from the ICO in October 2020. In September 2020, Sansec reported roughly 1,900 Magento 1 stores skimmed over a single weekend through an unpatched platform. Supplier, first-party, platform. Eight further cases are compared in this review of high-profile Magecart attacks and the three routes in.
The other failures are mundane. Alerts routed to a shared inbox with no named responder and no written triage step. A policy left in report-only mode for a year and described as change detection, when report-only blocks nothing and alerts nobody. A check frequency stretched past seven days with no targeted risk analysis behind it, which for most small merchants costs more effort to document than simply running the job weekly.
What a compliant small setup looks like
Hosted payment fields from the acquirer. The checkout trimmed from about a dozen third-party scripts to two or three, each with a written justification and an owner, held in version control. An enforced Content Security Policy with a reporting endpoint that stays live as the alerting channel. A weekly scheduled fetch that renders the payment page, hashes the content and the response headers, and emails a diff to a named person. A one-page written response step saying what that person does when the diff is not empty.
That is a developer week, no licence, and it stands up to questions. If you suspect something is already wrong, start with how to tell whether your checkout has been skimmed before you build anything.
The short version
PCI DSS 11.6.1 requires detection of unauthorised change to payment page content and headers as the browser receives them, an alert to a person, and a check at least once every seven days. It has been mandatory since 31 March 2025. You can satisfy it with a cron job and a reporting endpoint. Pair it with the 6.4.3 script inventory, delete the scripts nobody can justify, and keep the logs that show somebody acted.
Frequently Asked Questions
What does PCI DSS 11.6.1 require on a payment page?
A mechanism that detects unauthorised modification, including additions and deletions, to the HTTP response headers and the content of payment pages as received by the consumer browser, and alerts personnel when it finds one. The mechanism must be configured to evaluate those received headers and pages. No specific product is named in the requirement.
Does PCI DSS 11.6.1 apply to SAQ A merchants using a payment iframe?
The revised SAQ A published by the PCI Security Standards Council in January 2025 removed 6.4.3 and 11.6.1 from the form, replacing them with an eligibility condition that the merchant confirms its site is not susceptible to script-based attacks. The page framing a provider iframe is still yours and can still be overlaid with a fake form, so that confirmation needs evidence behind it. Check the current SAQ A and ask your acquirer what they require.
Can a Content Security Policy satisfy 11.6.1 on its own?
Only partly, and only in enforce mode with a reporting endpoint feeding alerts to a named person. A policy will not see a malicious change inside a first-party file it already trusts, nor data exfiltrated to an origin you have allowed. Pair it with a scheduled diff of the rendered page and headers.
How often do the 11.6.1 checks have to run?
At least once every seven days, or at a frequency set by a targeted risk analysis performed according to all the elements of Requirement 12.3.1. If you want a longer interval, the documented analysis is mandatory, not optional. For most small merchants, running the check weekly or daily is less work than writing the justification.
What evidence should I keep to prove 11.6.1 compliance?
The mechanism’s configuration, proof of what it targets, the schedule, dated run logs, the alerts it generated, and a short record of how each alert was triaged and by whom. Version-controlled baselines and the script inventory with its authorisations complete the picture. Screenshots of a dashboard alone will not carry an assessment.