11.6 Payment page change detection: requirements and evidence

What PCI DSS 11.6 payment page change detection requires in practice

Requirement 11.6.1 asks for a change- and tamper-detection mechanism that alerts personnel to unauthorized changes to payment page content and security-impacting HTTP headers as received by the consumer's browser. The check has to look at what the shopper actually receives, not only at what the server sends. A payment page is, in the PCI SSC glossary wording, a web-based user interface with one or more form elements intended to capture account data from a consumer or submit captured account data. The risk this control addresses is script injection and e-skimming, where malicious code is added to the page in the browser, card numbers are copied before encryption, and the back end never shows a change. A merchant or service provider whose checkout relies on third-party scripts, tag managers and embedded widgets has an obvious place where this can happen. The mechanism must run at least once every seven days, or at a frequency set by a targeted risk analysis under Requirement 12.3.1. The requirement became mandatory on 31 March 2025, so assessors now expect evidence of it running on a schedule, with alerts routed to named personnel and a record of how each alert was handled. Confirm with your assessor whether your risk analysis supports a longer interval, and document the reasoning. The requirement is also worded around the consumer's browser, so the monitoring must read the page and headers as rendered for a shopper, and it must cover the headers that affect security behavior, such as those governing script sources and framing. This is hard because the usual monitoring misses the threat. File integrity monitoring on the web server will not see a script that a third party loads at runtime or a tag manager that changes its configuration. Server-side logs do not show what the browser executes. Practical preparation starts with an inventory of every script and resource that runs on each payment page, including those loaded through tag managers, followed by a decision on how browser-side content will be captured and compared. Ask any provider to show how a modified third-party script triggers an alert in a test environment before you rely on it.

Which payment pages and third-party scripts fall under 11.6.1

Requirement 11.6.1 applies to payment pages, which the PCI SSC defines as web interfaces with form elements that capture or submit account data. Scoping starts by listing every page, frame and script that touches that data, then deciding which team owns each one and which SAQ or assessment path covers it.

Pages that capture account data

Start with every URL where a consumer enters card details, including checkout, payment update, donation and billing-change pages. Include pages that submit captured data to a back end even when the form sits on a different domain. For each page, record the owning team, the release process and the SAQ or ROC section that covers it. A page missed at this stage is a page no monitoring tool will watch.

Iframes and hosted fields

Hosted fields and iframes from a payment provider can keep card entry out of your own HTML, but the page that embeds them still matters. Confirm whether the parent page, the frame content or both are in your scope, and whether the provider's change monitoring covers what the consumer's browser actually renders. Ask the provider in writing which elements it monitors and which remain your responsibility.

Embedded third-party scripts

Analytics, chat, advertising and A/B testing scripts that run on a payment page can read or alter form fields in the browser. Inventory each script by domain, owner and business purpose, and note which ones load on payment steps. Any script that can run on a page with form elements is a candidate for the change detection mechanism, and each change to its source should be traceable to an approved request.

Tag managers and dynamic loading

A tag manager can add or replace scripts without a code release, so a single container change can alter a payment page. Document who can publish container versions, whether changes pass through review, and which tags fire on checkout. Test whether the monitoring mechanism detects a tag added by the manager at runtime, not only changes to the page's source files.

Security-impacting HTTP headers

Requirement 11.6.1 also covers security-impacting HTTP headers as the consumer's browser receives them. Headers such as those controlling script sources, framing and content types can weaken a payment page when altered, even though the page body is unchanged. Record the expected header set for each payment page, and confirm that the monitoring compares responses seen from the browser's side, including any CDN or proxy that rewrites them.

SAQ A eligibility and script risk

The SSC removed 11.6.1 from SAQ A in January 2025 and replaced it with an eligibility criterion that the merchant's site is not susceptible to script attacks. Merchants that relied on SAQ A should confirm with their acquirer or payment brand which SAQ applies now, and whether their pages still meet that criterion once scripts and tag managers are counted. Ask the QSA or ISA to confirm the SAQ and the owning teams in writing before the next validation cycle.

How an assessor tests 11.6.1 and what they ask for

This table walks through each step an assessor takes to test Requirement 11.6.1, from confirming the mechanism exists to sampling alerts and closing them out. Read each row as a question the assessor will ask and the evidence you should have ready before the assessment starts.

Assessor step	What the assessor checks	Evidence to prepare
Confirm the mechanism exists	A change- and tamper-detection mechanism is deployed and covers the payment pages in scope, not only a planned or pilot tool	Architecture diagram, tool configuration export, and the list of payment pages the mechanism monitors
Confirm the run frequency	The mechanism runs at least once every seven days, or at a frequency set by the targeted risk analysis under 12.3.1	Schedule configuration, scan history covering the assessment period, and the frequency decision if it differs from seven days
Inspect what is monitored	Both payment page content and security-impacting HTTP headers are compared as the consumer browser receives them	Monitored asset list showing scripts, iframes, form targets and response headers, with the method used to observe the browser view
Test coverage on changes	Newly added or third-party scripts appear in the monitored set soon after they are introduced	Change tickets for recent script additions paired with the dates they appeared in monitoring
Review alert routing	Alerts reach a monitored queue or on-call role with named owners, not an unmonitored mailbox	Routing rules, distribution list membership, and on-call roster for the period under review
Sample alerts end to end	Each sampled alert shows triage, investigation, and a documented closure or escalation decision	Alert tickets with timestamps, analyst notes, and links to the related change or incident record
Check the targeted risk analysis	If the run frequency differs from seven days, a documented targeted risk analysis supports that choice	Signed risk analysis that names the payment pages, threat factors, and the chosen frequency with its rationale
Verify the mechanism is protected	Monitoring configuration and baselines cannot be changed silently by the teams whose pages are monitored	Access list for the monitoring tool, change log for rule and baseline edits, and review records

How to implement payment page change detection step by step

This sequence takes a team from an inventory of payment pages to a tested detection mechanism that alerts named owners when payment page content or security-impacting headers change as the consumer's browser receives them. Each step ends with a record that an assessor can read.

Inventory every payment page and its sources
List each web-based page that has one or more form elements capturing or submitting account data, including iframes, embedded hosted fields and redirect pages that a consumer reaches during checkout. For each page, record every script, stylesheet, tag manager container and third-party domain it loads, plus the owner of each external source. Done means a signed inventory that the payment or e-commerce owner has reviewed, with each page and script source assigned to a named team. Confirm the list with your QSA or internal assessor, since the scope of pages depends on how your payment flow is built.
Capture a known-good baseline as the browser receives it
Fetch each payment page from a browser-like client, not only from the origin server, so the baseline reflects what consumers actually receive after CDN, proxy and tag manager processing. Record the response headers that affect security, such as content security policy, and a hash of the page content and each loaded script. Repeat the capture from more than one network location if your traffic is geographically distributed. Done means a dated baseline file for every page, reviewed and approved by someone who is not the person who built the page, and stored where the monitoring tool cannot silently overwrite it.
Choose the monitoring method and set the frequency
Select the method that will fetch each page as a consumer browser would and compare the result to the baseline. Options include a purpose-built page monitoring service, a headless browser job run on a schedule, or a file integrity tool such as Wazuh (GPL-2.0-only) on files you control, which can alert on creation, modification or deletion with details of how and when the change happened. Requirement 11.6.1 sets a maximum interval of seven days unless a targeted risk analysis under 12.3.1 sets a different frequency, so record the interval you chose and the reason. Done means a written monitoring design that names the tool, the schedule and the pages it covers.
Configure alerts to a monitored channel with named owners
Route alerts to a channel that someone watches during working hours and at least one escalation path, such as an on-call rotation, with each alert tied to a named owner for the page and a backup. Include the page, the changed element or header, the time, and the previous and current values in every alert. Confirm that alerts are delivered during a test by checking the receiving inbox or channel, not only the tool's dashboard. Done means a configuration export, a list of recipients by role, and a screenshot or log entry showing a delivered alert.
Define the response procedure for a detected change
Write a procedure that says who triages an alert, how an unexpected change is compared with an approved change record, who can roll back a page or script, and when the payment team, security team and incident response process are engaged. Define how a change is classified as authorized or unauthorized and how the decision is recorded. Include a step to reconfirm the baseline after an approved change so that future alerts remain meaningful. Done means an approved procedure, with each role named and the handoffs to change management and incident response written down.
Run a test change to prove detection
Make a controlled, documented change to a non-production or agreed test copy of a payment page, such as a harmless script addition or a header change, and confirm that the monitoring fires, the alert reaches the named owner and the response procedure starts. Then revert the change and confirm the baseline comparison reports the revert. Record the test date, the change made, the alert received and the time between the change and the alert. Done means a test record that shows detection worked end to end, which is the evidence most assessors will ask to see first.
Keep the evidence current and review the design
Store each baseline version, alert, approved change and test record in a location that is protected from edits, and set a recurring review of the page inventory, the frequency decision and the alert recipients. Repeat the test change on a schedule you define and after any significant change to the payment page or its third-party scripts. Done means a retained evidence set covering the past review cycles, plus a documented review date and owner. Because the security teams behind PCI DSS and the e-skimming guidance expect this to be ongoing, treat the sequence as a recurring control, not a one-time project.

Evidence that satisfies 11.6.1 and how to keep it current

An assessor testing 11.6.1 will look for proof that the mechanism exists, runs on schedule, watches the right pages and headers, and produces actionable alerts. The cards below cover the artifacts that prove each of those points and the routines that keep them accurate between assessments.

Monitoring configuration and scope

Keep the written and exported configuration of the change- and tamper-detection mechanism as primary evidence. It should show which payment pages and security-impacting HTTP headers are monitored, the comparison method, the alert destinations and the run frequency set to at least once every seven days. Store configuration exports under version control so the assessor can see when a setting last changed and who approved it. Ask your implementation partner or tool vendor to confirm that the export includes the browser-side checks, not only server-side file checks.

Payment page and header inventory

Maintain a dated inventory of every payment page, the form elements that capture or submit account data, and the headers monitored on each. Assessors compare this list against the payment flow in your data-flow diagrams, so a page missing from the inventory is a finding even if it was monitored. Record the owner, the script sources loaded on each page and the date each entry was last verified. Reconcile the inventory against the site map and the tag manager at each release.

Check run logs showing cadence

Retain logs from every monitoring run, including runs that found nothing. Gaps in the sequence are what assessors look for when they test the seven-day cadence, so logs should show a start time, end time, pages covered and result for each run. Set an alert for missed or failed runs so that a silent outage is caught and documented rather than discovered during the audit. If you move to a longer interval based on a targeted risk analysis, the logs must show the interval you actually ran.

Sample alerts with change details

Keep representative alerts with timestamps, the page or header affected, the previous and current values or hashes, and the identity of the user or process that made the change where the tool records it. Wazuh file integrity monitoring, for example, records how and when a monitored file changed and who changed it, which gives an assessor a traceable event. Test the alert path periodically with a controlled change on a non-production copy and keep that test record, since an alert that never fires cannot be shown to work.

Response tickets and closure records

Every alert that reflects an unauthorized change should produce a ticket that links the alert, the investigation, the decision to roll back or approve, and the closure reason. Benign changes tied to a planned release should reference the change record and the approval. Assessors sample tickets to confirm that personnel were alerted and that the response was timely and documented, so tickets should name the responders and the time each step was completed. Store the tickets in the system your incident and change processes already use.

Targeted risk analysis and keeping evidence current

If you run less often than every seven days, the targeted risk analysis under 12.3.1 is the document that justifies the frequency, and it must be approved, dated and repeated as conditions change. Between audits, schedule a review of the inventory and configuration after every release that touches payment pages, tag managers or third-party scripts, and record the review in the change log. Confirm with your QSA which evidence format they accept, and treat any gap in the logs as an incident to explain rather than an item to fill in later.

What meeting 11.6.1 costs in money and effort

This table breaks down the money and effort behind 11.6.1 by cost component, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to build a quote request and to decide which parts to keep in-house. No figures are given because none were supplied for this requirement, so confirm amounts directly with vendors, providers and assessors.

Cost component	One-time or recurring	What drives it
Monitoring tooling or licenses	Recurring	Commercial change-detection licenses often scale with the number of monitored pages or agents. Self-hosted open-source file integrity monitoring can remove license spend but still needs hosting and operations time.
Engineering time to build baselines and alert routing	One-time, then periodic	Number of payment pages, templates and hosting paths; how many security-impacting HTTP headers must be captured; whether alerts route into an existing SOC queue.
Baseline upkeep after releases	Recurring	Release frequency, number of third-party scripts loaded on payment pages, and how often tag managers or CDN configurations change. Each approved change needs a baseline update.
Response staffing for alerts	Recurring	Alert volume, the 7-day or risk-based frequency set under 12.3.1, and whether after-hours triage is required. Noisy baselines raise this cost quickly.
External testing or review	Recurring or per engagement	Scope of the browser-side review, whether a provider validates detection by altering a test page, and how often the mechanism is retested after changes.
Assessor time	Recurring, per assessment	Quality of documented baselines, alert records and response tickets. Ask the assessor what evidence they expect before the assessment starts so review time stays short.
Implementation partner preparation	One-time, optional	Written scope, number of pages and environments, and whether the partner builds the baseline, the alert routing, or both. Ask for a fixed-scope quote with deliverables listed.

How browser-side detection differs from server-side file monitoring

Server integrity checks alone do not satisfy Requirement 11.6.1, because the requirement concerns what the consumer's browser actually receives, not only what sits on the web server. A file integrity tool that confirms a checkout script has not changed on disk can still miss a skimmer injected by a third-party tag, a tampered response modified in transit, or a script loaded from an external domain at runtime. The control has to observe the page the way a shopper's browser sees it, including the security-impacting HTTP headers attached to each response. Server-side monitoring, such as the file integrity tooling covered under 11.5, addresses a different risk: unauthorized changes to files on your own hosts. You need both, and they should not be presented to an assessor as the same control.

The general approach is to capture the rendered payment page content and its response headers from a browser-like client, store a baseline of that output, and compare each later capture against it. Any difference in payment form elements, script sources, or headers such as those governing content security or script loading should raise an alert to named personnel. Practical decisions include which pages and URLs count as payment pages, which browsers and geographies the capture must reflect, whether scripts that legitimately change often need an approved allowlist with a documented reason, and what frequency the targeted risk analysis under 12.3.1 supports, within the seven-day ceiling in the requirement. Your team should own the baseline approval and alert response, even if an outside provider runs the captures.

Do not assume a tool has browser-side capability because its name suggests monitoring. Confirm with the vendor or project whether it renders pages in a browser engine or reads only server responses, whether it records headers as delivered to a client, and how it handles dynamically loaded third-party scripts. Wazuh's file integrity monitoring, for example, documents baselines of files and directories on monitored hosts, which is valuable for 11.5 but does not by its documentation describe rendering a page for a consumer. Ask for a test against a staged payment page where you inject a known script change, and confirm the alert reaches the right people within the interval you have set.

Which open-source tools support the evidence for 11.6

Wazuh, licensed under GPL-2.0-only, is the most direct fit for the server-side part of change detection. It records a baseline of checksums and attributes for monitored files and directories, then raises an alert when a user or process creates, modifies or deletes a monitored file. Scans can run on a schedule or in real time, and alerts include how and when the file changed and who made the change, which is the detail an investigator needs when a script on a payment page is altered.

Baseline of the page source: Monitor the directories that serve checkout pages, JavaScript bundles and the web server configuration that sets security headers.
Who changed what: Alerts identify the user or process behind a modification, which supports triage and the reviewer's record of each alert.
Schedule or real time: Choose a frequency that matches the interval set for your environment, and document the reasoning if it differs from a seven-day maximum.
Header and config files: Include the files that define response headers, since 11.6.1 also covers security-impacting HTTP headers.
Alert routing: Confirm that alerts reach a named responder and that acknowledgement is recorded.

Confirm with your team that Wazuh monitors the files that actually render the page, because it sees files on the host, not the browser's copy.

Where organizations fall short on payment page monitoring

Requirement 11.6.1 looks simple on paper, but most gaps sit in the surrounding process: what is being watched, who acts on alerts, and whether the run can be proven. The cards below cover the failure points an assessor is most likely to probe, each with a closing check you can run before the assessment starts.

Third-party scripts missing from the inventory

A monitoring tool can only compare what it knows to be on the page. Analytics tags, chat widgets, A/B testing snippets and payment iframes often load from domains that no one has listed, so a change to one of them never reaches the baseline. Ask who owns the list of scripts loaded by each payment page, how it is updated when a marketing team adds a tag, and whether the monitored content includes what the browser actually receives. Confirm the list against a live browser session, not only the source repository.

Baselines not refreshed after releases

A baseline captured before a planned release will flag every legitimate change as an alert, and teams then learn to ignore the noise. The opposite failure is a baseline that is re-accepted after each release without review, which quietly absorbs an unauthorized change. Check that baseline updates are tied to the change management process, that each update records who approved it and which release it belongs to, and that an unexpected difference still triggers investigation before the new baseline is accepted.

Alerts without a named owner

Detection that fires into a shared mailbox is detection that nobody acts on. Assessors look for a named role responsible for triaging each alert, a documented response path for an unauthorized change, and evidence that alerts were reviewed and closed with a reason. Confirm which team receives payment page alerts out of hours, how an alert is escalated to the incident response process, and whether the on-call rota covers the same channel the tool actually uses.

No evidence of the seven-day run

Requirement 11.6.1 requires the mechanism to run at least once every seven days, or at a frequency set by a targeted risk analysis. Many teams configure the schedule correctly but cannot show it ran, because scheduler logs roll over or results are not retained. Ask for the run history covering the full assessment period, the retention setting that keeps it, and a way to demonstrate a missed run would have raised an alert. Treat a gap in the run history as a finding, not a formality.

Longer intervals without a targeted risk analysis

Some organizations extend the monitoring interval beyond seven days without a documented basis, assuming the page changes rarely. Under Requirement 12.3.1, a longer frequency must come from a targeted risk analysis that is written down, justifies the chosen interval, and is reviewed when the payment page or its third-party scripts change. Confirm that the analysis exists, names the page and its risk factors, and is linked from the monitoring configuration so the two cannot drift apart.

Monitoring that checks only the server

Server-side file integrity monitoring confirms that the code on your hosts has not changed, but it does not show what a consumer's browser receives. A script injected through a compromised third-party tag, or a header altered by a CDN or proxy, leaves the server untouched. Ask whether the monitoring fetches the page as a browser would, inspects the rendered content and response headers, and runs from locations that reflect real consumer traffic. Confirm which of these checks your current tooling actually performs.

How much effort, time and outside help does 11.6 need?

What drives the cost and effort of meeting requirement 11.6?

The main drivers are how many payment pages you run, how often they change, how many third-party scripts load on them, and how much of the page is built in-house versus supplied by a payment provider. Each page that captures account data adds monitoring scope, and each script source adds alerts to review. Costs fall into two groups. One-time work covers inventorying pages and scripts, setting the baseline, tuning rules and writing the runbook. Recurring work covers keeping the monitored list current, reviewing alerts, and retaining evidence for the assessor. Ask any provider to split its quote along those lines so you can see which part changes as your site changes.

Can our team implement payment page change detection in-house?

Often yes, if you have engineers who can run a monitoring platform and a web team that understands how the page loads. Requirement 11.6.1 is a mechanism question, so the work is largely configuration and operations, not new development. The harder part is the scope decision: deciding which pages and headers count, how the mechanism sees content as the consumer's browser receives it, and how alerts reach a person who will act. Teams without that combination usually bring in an outside engineer for design and testing while keeping ownership of the alerts and the policy. Your assessor will still expect your own staff to demonstrate that the control works.

What does the work need from our team day to day?

Requirement 11.6.1 requires the mechanism to run at least once every seven days or at a frequency set by a targeted risk analysis, so someone must own a recurring rhythm. In practice the team needs a named owner for the monitored page inventory, an engineer who can tune rules and investigate alerts, and a responder who knows what to do when a change is unauthorized. Each change to a checkout page, tag manager or third-party script should trigger an update to the approved baseline, with a record of who approved it. Expect the workload to grow with release frequency. Confirm the alert routing and on-call coverage before the mechanism goes live.

How long does implementation usually take?

The time depends on scope more than on the tool. A single hosted checkout with few scripts is a much smaller job than a multi-brand storefront with dozens of third-party tags and several payment providers. The phases to plan for are discovery of the pages and scripts, design of the baseline and alerting, build and test, a period of alert tuning, and documented handover. We do not publish a duration because it follows from the scope you agree in writing. Ask any provider for a timeline tied to named phases and deliverables, and ask what happens if discovery finds more pages than expected.

Do SAQ A merchants still need to meet requirement 11.6?

The PCI SSC removed requirement 11.6.1 from SAQ A in January 2025 and replaced it with an eligibility criterion: the merchant's website must not be susceptible to script attacks. That means an SAQ A merchant must still show that its payment page is not exposed to the kind of script injection the criterion describes, which in practice depends on how the page is built and which scripts it loads. Confirm your current SAQ eligibility with your acquirer or the payment brands, since they decide who validates and how. Do not assume that a hosted payment form removes every obligation without checking your script inventory.

Can an outside partner run the monitoring for us?

Yes, a partner can operate the monitoring platform, maintain the baseline, and triage alerts under a written agreement. Operating the control is different from owning it. Your organization remains responsible for the policy, the decision to approve a change, and the evidence. An independent QSA or assessor tests the control and issues the report, and DeployOpen prepares systems and evidence for that assessment without issuing any report or certification. Ask who holds the alert channel, how quickly your team sees escalations, and how the provider documents each review so it can be shown to an assessor.

What should we ask for in a written quote?

A useful quote lists the scope in writing: which payment pages, which headers, which scripts and which environments are covered. It should separate one-time work from recurring support, name the deliverables, and state what the client provides, such as access, staff time and test windows. Ask for the baseline method, the alert routing design, the runbook, and the evidence the assessor will receive. Confirm how changes to scope are priced, what happens when the team adds a new script, and who is responsible for retesting after a platform upgrade. Ask the provider to state in writing what it does not cover, including assessment and report issuance.

How DeployOpen scopes and prepares 11.6 evidence

DeployOpen plans, implements and documents self-hosted open-source change and tamper detection for payment pages inside your own cloud accounts, data centers or private networks. In practice that means agreeing which payment pages, script sources and security-impacting response headers fall under 11.6, deploying the monitoring that compares them against an approved baseline, routing alerts to the people who must act on them, and writing down how each piece works. The work runs under a fixed scope agreed in writing before it starts, with deliverables and timelines set out in that document. Your organization owns its controls. It decides the check frequency, whether a targeted risk analysis under 12.3.1 justifies a different interval, who acknowledges an alert, and what happens when a change is unexpected.

The first scoping task is an inventory of every page where a consumer enters account data, including iframes, embedded third-party forms and pages that load scripts from outside your domain. Confirm that inventory with your QSA or internal assessor before any baseline is captured, because a monitored set that omits a page leaves a gap the assessor will find. DeployOpen can help prepare the baseline records, alert routing and evidence, such as alert configuration exports, sample alert and acknowledgment records, and the procedure document describing how a change is investigated. Ask any implementation partner to list those artifacts in the written scope so you can check them against what your assessor expects.

DeployOpen does not issue Reports on Compliance, Attestations of Compliance, certificates or any other audit output. Only a Qualified Security Assessor or the relevant validating body can assess 11.6 and report on it. To begin a scoping conversation, bring your payment page inventory, your current SAQ or ROC scope, and a note of any third-party scripts already in use. From those inputs, DeployOpen can state what is in and out of a proposed scope and give you a written quote. For the requirement text and the validation options, see the PCI Data Security Standard page on the PCI SSC site.

11.6 Payment page change detection