--- title: "PCI DSS 6.4.3 & 11.6.1 script inventory for payment pages" description: "Inventory every payment page script from real browser traffic, justify each one, get change alerts, and export the evidence your PCI DSS assessment asks for." url: "https://next.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.next.centralcsp.com) [Talk to sales](https://next.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 The requirements ## What the assessment asks. What you hand back. Requirements 6.4.3 and 11.6.1 are mandatory at every assessment since March 31, 2025. Here is each clause, mapped to the artifact CentralCSP produces for it. | 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. - Additions, changes and removals, dated - Per-page history for every payment page - 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 - 5 channels plus webhooks - Routed per site and per team Approaches ## Three 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 | Proxy or agent | | --- | --- | --- | --- | | Adds nothing to the payment page | Yes: Nothing added to the page | Partially: A dependency at the edge | No: New dependency, new failure point | | Builds the inventory automatically | Yes: Automatic, from real browsers | No: Never executes the page | Partially: From its agent's sessions | | Alerts on change and tampering (11.6.1) | Yes: Continuous, from live traffic | No: Blind in the browser | Yes: While its agent runs | | Provides a justification workflow (6.4.3) | Yes: Built-in auto-validation rules | No: Not provided | Partially: Varies by product | | Detects CVEs and exports an SBOM | Yes: Included, with SBOM export | No: Not for page scripts | No: Rarely included | | Exports audit-ready evidence | Yes: One-click CSV / PDF | No: Raw request logs | Partially: 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 scoped tokens - CSV and PDF exports from the dashboard - Built-in MCP server for AI agents [See the API and MCP platform](https://next.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. MyEndpoint.report.centralcsp.com 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. 6.4.3 11.6.1 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. ![The CentralCSP dashboard: live reports and the script inventory of a payment page.](https://next.centralcsp.com/assets/hero-dashboard-KiR2e_Kc.webp) - Live reports from real visitors - Script inventory per payment page - Instant new-script alerts - Auditor-ready PCI evidence Trusted by teams across the world 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. ### 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? 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. ### 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.next.centralcsp.com) [Talk to sales](https://next.centralcsp.com/en/contact/?topic=sales) --- Available in: [en](https://next.centralcsp.com/en/platform/pci-dss/), [fr](https://next.centralcsp.com/fr/platform/pci-dss/)