--- title: "PCI DSS 6.4.3 & 11.6.1: payment page script inventory" description: "Inventory every payment page script from real browser traffic, justify each one, alert on change, and export QSA evidence for 6.4.3 and 11.6.1. No agent." url: "https://centralcsp.com/en/platform/pci-dss/" lang: "en" --- PCI DSS 6.4.3 & 11.6.1 # Every payment page script, inventoried and justified. CentralCSP builds your script inventory from real browser traffic, records the justification 6.4.3 asks for, alerts on every change, and exports the evidence your assessor reads. Nothing new runs on your checkout. [Start free trial](https://app.centralcsp.com) [Talk to sales](https://centralcsp.com/en/contact/?topic=sales) - PCI DSS v4.0.1 Requirements 6.4.3 and 11.6.1 - Nothing on your page No agent, no proxy - Audit evidence CSV and PDF export - EU data residency France, on OVH PCI DSS v4.0.1, mandatory since 31 March 2025 ## What the assessment asks. What you hand back. Requirements 6.4.3 and 11.6.1 exist because payment page skimmers (e-skimming, Magecart, formjacking) run entirely in the visitor's browser and never touch your server logs. Here is each clause, mapped to the artifact CentralCSP produces for it. Requirement 6.4.3 asks you to manage every script loaded and executed in the consumer's browser on a payment page: confirm each one is authorized, assure its integrity, and keep an inventory with a written business or technical justification for each. Requirement 11.6.1 asks for a change and tamper detection mechanism that alerts your team to unauthorized modification of the payment page's scripts, HTTP headers and content as received by the consumer's browser, evaluated at least every seven days. | The requirement | What CentralCSP produces | Status | | --- | --- | --- | | 6.4.3 - Script inventory | An inventory of every script loaded on your payment pages, built from what real visitor browsers execute and kept current with every deploy. Not a spreadsheet that was true last quarter. | Covered | | 6.4.3 - Authorization | Each script carries an authorization status. New ones land as pending review, so nothing stays on the page unaccounted for. | Covered | | 6.4.3 - Written justification | A business or technical justification recorded per script. Rules auto-validate known patterns, so a routine hash rotation never queues for manual re-approval. | Covered | | 6.4.3 - Integrity | Script hashes tracked from real traffic. When contents change, the change lands on the timeline and your team is alerted. | Covered | | 11.6.1 - Change and tamper detection | New scripts and new origins on the payment page raise an alert the moment browsers report them: additions, changes and deletions, dated. | Covered | | 11.6.1 - Evaluation frequency | The requirement's floor is weekly. Reports flow continuously from production traffic, so evaluation never waits for a scheduled crawl. | Covered | | Assessment evidence | One export: the inventory, justifications and change history as CSV or PDF, plus an SBOM of the site's technologies and versions. | Covered | ### Your payment page, as a timeline. Every script change on the checkout becomes a dated event: a file appeared, a hash rotated, an origin showed up for the first time. When the assessor asks what changed since last year, you scroll. You do not reconstruct. - A new script file on the page - A hash that changed on a script you already run - An origin seen on the page for the first time - A script that disappeared - The change record 11.6.1 reviews expect ### Justify once. Rules absorb the noise. 6.4.3 wants a written justification for every script. Record it when the script first appears, then let auto-validation rules carry the routine: a known pattern rotating its hash revalidates itself, an unknown file stays pending until a human looks. - Written justification stored per script - Auto-validation rules for known patterns - A pending queue for anything new ### Know what your scripts are made of. CentralCSP identifies the library and version behind each script, flags known CVEs and end-of-life versions, and exports the lot as an SBOM of your site. The vulnerable jQuery on the checkout stops being a surprise finding. - Technology and version identification - CVE and end-of-life flags - SBOM export of the whole site ### The alert reaches the team that owns the page. A new script or a new origin on a payment page pings Slack, Microsoft Teams, Google Chat, Telegram or email the moment a browser reports it. Keep the notification: between assessments, it is the control demonstrably working. - New-script and new-origin alerts, built in - 6 channels including webhooks - Routed per site and per team Payment page script monitoring ## Four ways to run 6.4.3 and 11.6.1. Each of these can pass an assessment. They differ in what they see, what they add to the payment page, and what the evidence costs to produce. Comparison of approaches to PCI DSS 6.4.3 and 11.6.1 | | CentralCSP | WAF-based | Scheduled crawl | Proxy or agent | | --- | --- | --- | --- | --- | | Adds nothing to the payment page | Nothing added to the page | A dependency at the edge | Nothing added to the page | New dependency, new failure point | | Builds the inventory automatically | Automatic, from real browsers | Never executes the page | Only what the crawl reached | From its agent's sessions | | Alerts on change and tampering (11.6.1) | Continuous, from live traffic | Blind in the browser | Only at scan cadence | While its agent runs | | Provides a justification workflow (6.4.3) | Built-in auto-validation rules | Not provided | Varies by product | Varies by product | | Detects CVEs and exports an SBOM | Included, with SBOM export | Not for page scripts | Varies by product | Rarely included | | Exports audit-ready evidence | One-click CSV / PDF | Raw request logs | Usually exportable | Usually exportable | Evidence as data ## The inventory is queryable, not a screenshot. Everything the dashboard shows is on the REST API: pull the payment page inventory, justification statuses and change history into your GRC tooling, or let an agent drive it over MCP. - Full REST API with workspace API keys - CSV and PDF exports from the dashboard - Built-in MCP server for AI agents [See the API and MCP platform](https://centralcsp.com/en/platform/api-mcp/) How it works ## Ten minutes to set up. Evidence whenever it's asked. No agent, no SDK, no change to the checkout's behavior. Browsers report natively. 1. 01 - Connect ### Add one response header. Create your site in the dashboard and set the reporting header. Real visitor browsers start reporting what the payment page loads within minutes. 2. 02 - Justify ### Review the inventory once. Approve what belongs, record why, set the auto-validation rules. From then on, only genuinely new scripts ask for your attention. 3. 03 - Prove ### Export when the QSA asks. Inventory, justifications and the change timeline as CSV or PDF. The evidence matches what actually ran in browsers, so the conversation is short. The dashboard ## Your payment pages, on one screen. Inventory, justifications, changes and alerts for every payment page, behind one login. ![A script's review drawer: its origin and current hash, the written justification saved against it, and a dated history of every hash change.](https://centralcsp.com/assets/script-justification-BWUbxL1V.webp) - Every script, with its SHA-256 - Every change, dated and attributed Trusted by teams across the world Pricing ## PCI DSS features ship in the Scale plan. Payment page monitoring, the justification workflow, evidence exports and CVE detection are all part of Scale, on top of everything in Business: automated scanning, alerting, API and MCP. - Payment-page script inventory - Justification workflow and auto-validation rules - CSV and PDF evidence exports - SBOM, CVE and end-of-life flags ### Scale PCI DSS v4 evidence, at portfolio scale. €349.99 / mo - Applications 30 - Users 100 - Reports / month 10,000,000 Everything in Business, plus: - CVE detection - Payment page monitoring - PCI DSS evidence - SSO and audit log - Invoicing and procurement support [Get started](https://app.centralcsp.com/?plan=scale&billing=monthly) Further reading ## What an assessor asks for How requirements 6.4.3 and 11.6.1 read in practice, and what the evidence export contains. - [How a CSP maps to 6.4.3 and 11.6.1](https://centralcsp.com/en/blog/csp-pci-dss-v4) - [PCI DSS v4 client-side security, explained](https://centralcsp.com/en/blog/pci-dss-v4-client-side-explained) - [How the inventory is built from CSP hash reports](https://centralcsp.com/en/blog/script-inventory) - [What is in the evidence export](https://centralcsp.com/en/docs/platform/features/pci-dss/evidence-export) - [Define payment page scope with URL patterns](https://centralcsp.com/en/docs/platform/features/pci-dss/payment-pages) - [How auto-validation rules work](https://centralcsp.com/en/docs/platform/features/pci-dss/justification-rules) FAQ ## Frequently asked questions What merchants and their assessors ask us, answered. ### What does PCI DSS 6.4.3 actually require? That every script loaded and executed on your payment pages is managed three ways: a method to confirm each script is authorized, a method to assure its integrity, and an inventory of all scripts with a written business or technical justification for each. CentralCSP produces those three records from your real browser traffic. ### Is a CSP or SRI enough to satisfy 6.4.3? They cover two of the three clauses, not the third. A Content Security Policy authorizes which origins may load a script, and a hash or a nonce authorizes an exact piece of content, so a CSP is a legitimate authorization method. Subresource Integrity verifies that a static file's bytes are the ones you expect, so SRI is a legitimate integrity method. Neither produces the third thing 6.4.3 asks for: a written inventory with a business or technical justification for every script. That is a record, not a header. CentralCSP builds the inventory from the script hashes browsers report and stores the justification against each script, so the header and the paperwork come from the same source. ### How often does the 11.6.1 check have to run? The floor is at least once every seven days, or at a frequency you set through a targeted risk analysis under requirement 12.3.1. In practice that floor never becomes the binding constraint here, because the reports arrive from live production traffic rather than from a scheduled job: a script that changes on a Tuesday afternoon is evaluated when the first visitor's browser reports it, not at the next weekly run. ### What counts as a payment page? Under PCI DSS v4.0.1, any page that captures account data, and the requirements also reach the page that embeds a payment iframe. If your checkout wraps your provider's iframe, that wrapping page is in scope. Monitor it like the form itself. ### Do 6.4.3 and 11.6.1 apply to SAQ A merchants? The dividing line is the iframe. A merchant who embeds a payment form in an iframe on their own page is reachable by script on that page, so the script-susceptibility eligibility gate applies to them; a merchant who redirects the shopper entirely to a hosted payment page is not reached by it at all. SAQ A-EP merchants, whose own page affects the payment transaction, carry 6.4.3 and 11.6.1 in full with no eligibility gate to consider. Since the January 2025 revision, SAQ A no longer lists them, but its new eligibility criteria expect you to confirm your site is not susceptible to script attacks, which in practice means running the same controls or holding an attestation from your payment provider. Confirm the interpretation with your QSA; CentralCSP gives you the evidence either way. ### How much work is the justification requirement, really? The first pass is the work: approve each script on the page and record why it is there. After that, auto-validation rules absorb the routine. A known script rotating its hash revalidates itself; you only hear about files and origins that are genuinely new. ### Does 11.6.1 cover HTTP headers too? Yes. The requirement is written around the payment page as the consumer's browser receives it, which is its scripts, its HTTP headers and its content, not scripts alone. CentralCSP alerts on the script and origin side from browser reports: a new file, a rotated hash, an origin appearing for the first time. For the header side, the free security headers checker grades what a page sends today, and CSP monitoring watches the policy header over time once it is deployed. ### What evidence does my QSA actually get? A CSV or PDF export of the payment page inventory with each script's justification and authorization status, the dated change timeline, and an SBOM of technologies, versions and known CVEs. It is the artifact list assessors ask for, generated from what real browsers executed. ### Does CentralCSP add latency to the checkout, or block anything? Neither. Nothing loads on your page: browsers send reports natively through the Reporting API, so monitoring stays out of the serving path. Enforcement remains your CSP's job, which CentralCSP helps you build from the same reports. What 11.6.1 demands for payment page scripts, detection and alerting, is exactly what it does. ## Walk into the assessment with the inventory ready. Connect a payment page this afternoon; browsers start reporting within minutes. No agent to deploy, nothing added to the checkout. [Start free trial](https://app.centralcsp.com) [Talk to sales](https://centralcsp.com/en/contact/?topic=sales) --- Available in: [en](https://centralcsp.com/en/platform/pci-dss/), [fr](https://centralcsp.com/fr/platform/pci-dss/)