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.

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 Talk to 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

GET /websites/{id}/scripts

$ curl -G https://api.centralcsp.com/v1/websites/$WEBSITE/scripts \

-H "Authorization: Bearer $CENTRALCSP_TOKEN" \

-d page=/checkout -d limit=2

{

"data": [

{

"url": "https://js.stripe.com/v3/",

"technology": "Stripe.js",

"status": "justified",

"justification": "Payment processing",

"lastSeen": "2026-07-17T08:41:19.204Z",

"cve": null

},

{

"url": "https://my-store.com/pixel-track.js",

"status": "pending",

"firstSeen": "2026-07-17T08:12:55.610Z",

"cve": null

}

],

"pagination": { "hasMore": true, "total": 14 }

}

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.

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.
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.
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.

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.

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.