Question 1

What does PCI DSS 6.4.3 actually require?

Accepted Answer

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.

Question 2

Is a CSP or SRI enough to satisfy 6.4.3?

Accepted Answer

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.

Question 3

How often does the 11.6.1 check have to run?

Accepted Answer

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.

Question 4

What counts as a payment page?

Accepted Answer

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.

Question 5

Do 6.4.3 and 11.6.1 apply to SAQ A merchants?

Accepted Answer

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.

Question 6

How much work is the justification requirement, really?

Accepted Answer

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.

Question 7

Does 11.6.1 cover HTTP headers too?

Accepted Answer

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.

Question 8

What evidence does my QSA actually get?

Accepted Answer

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.

Question 9

Does CentralCSP add latency to the checkout, or block anything?

Accepted Answer

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.

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

	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

Every payment page script, inventoried and justified.

What the assessment asks. What you hand back.

Your payment page, as a timeline.

Justify once. Rules absorb the noise.

Know what your scripts are made of.

The alert reaches the team that owns the page.

Four ways to run 6.4.3 and 11.6.1.

The inventory is queryable, not a screenshot.

Ten minutes to set up. Evidence whenever it's asked.

Add one response header.

Review the inventory once.

Export when the QSA asks.

Your payment pages, on one screen.

PCI DSS features ship in the Scale plan.

Scale

What an assessor asks for

Frequently asked questions

Walk into the assessment with the inventory ready.