Inventory
Every script on each payment page, with a written business justification.
Authorisation
Who approved each script, and when.
Integrity
How you know each script is still the one you approved.
Detection
A mechanism that watches script contents and security headers, and the alerts it sent.
Frequency
At least weekly, or your targeted risk analysis for a different interval.
What evidence does a QSA ask for under PCI DSS 6.4.3 & 11.6.1?
For 6.4.3: your written process, an inventory of every script on each payment page with a business justification, a record that each script was authorised, and how you assure each script's integrity. For 11.6.1: proof that a change- and tamper-detection mechanism runs on your payment pages, how it is configured, the alerts it raised and who received them, and your targeted risk analysis if you check less often than weekly.
Download the checklist
The checklist below is also a spreadsheet you can fill in for each payment page: PCI DSS 6.4.3 & 11.6.1 evidence checklist (CSV). It lists each item, the testing procedure it answers, and a column for where your evidence lives.
6.4.3: what the assessor tests
6.4.3 asks you to manage every script that loads and runs in the customer's browser on a payment page: a method to confirm each one is authorised, a method to assure its integrity, and an inventory with a written justification for why each one is needed. The testing procedures, in our words:
Where it usually goes wrong: an inventory written from memory that misses the scripts vendors load (fourth parties), the same generic justification on every line, and integrity that means only "still loads from the approved domain", which does not notice a vendor's file changing at the same address.
11.6.1: what the assessor tests
11.6.1 asks for a mechanism that alerts a person to unauthorised changes to the security-impacting HTTP headers and the script contents of payment pages, as the customer's browser receives them, run at least weekly or at the frequency your targeted risk analysis sets. In our words:
See the inventory and alert record your own checkout produces, free on 1,000 page views a month.
The checklist
- A written procedure for approving, checking and removing payment-page scripts (6.4.3.a)
- A list of every page in scope: the payment page and any page that hosts or redirects to it
- An inventory per page that includes first-party, third-party and fourth-party scripts (6.4.3.b)
- A business justification per script, specific to that page (6.4.3.b)
- An approver and a date for each script (6.4.3.b)
- An integrity method per script: a payload hash, SRI, or a tool that compares contents (6.4.3.b)
- Proof the inventory matches what runs in real sessions, not only what was configured (6.4.3.b)
- The detection mechanism and the pages it monitors (11.6.1.a)
- Detection of script contents and security-impacting HTTP headers as the browser receives them (11.6.1.b)
- Alert recipients: a named person or a monitored channel, not a log nobody reads (11.6.1.b)
- A sample of alerts and what happened next (11.6.1.a)
- A targeted risk analysis if you check less often than weekly (11.6.1.c)
Why evidence comes back from the assessor
- The inventory lists the vendors you signed, not the scripts that run
- Justifications say "marketing" or "required for functionality" on every line
- No approval date, so nobody can say when a script was accepted
- Monitoring covers the scripts but not the HTTP headers, or the headers but not the scripts
- Alerts go to an address nobody watches
- 6.4.3 & 11.6.1 are presented as one record, so the assessor cannot test them separately
How Script Monitoring produces this evidence
Script Monitoring records every script that runs on your payment pages in real customer sessions, including the ones vendors load. Each script carries its justification, approver and date, each payload is hashed so a change at the same address is caught, and header changes are tracked alongside. Alerts go by email on every plan, and by webhook or S3 on Pro. Evidence packs, with 6.4.3 & 11.6.1 kept as separate records, are on every plan, Free included. If a tag is not possible, the Agentic Web Scanner (Pro) scans your pages on a schedule instead.
Sources and methodology
Requirement and testing-procedure descriptions are paraphrased from PCI DSS v4.0.1 (June 2024), published by the PCI Security Standards Council, the current version as of 7 November 2026. Requirements 6.4.3 & 11.6.1 have been mandatory since 31 March 2025. Your assessor's interpretation decides what is accepted; use this as a preparation list, not a substitute for the standard.
Ask an AI
Don’t just take our word for it
What evidence does a QSA ask for under PCI DSS 6.4.3 & 11.6.1?
Frequently asked questions
Do SAQ A merchants need this evidence?
Not in this form. Since January 2025, SAQ A replaces 6.4.3 & 11.6.1 with an eligibility criterion: you confirm your site is not susceptible to attacks from scripts that could affect your e-commerce systems. In practice the same inventory is what lets you say that with confidence.
How often must the 6.4.3 inventory be reviewed?
6.4.3 does not set an interval, but the inventory has to match the page. The practical answer is to review only what changed, as it changes. 11.6.1 detection runs at least weekly unless your risk analysis says otherwise.
Is a spreadsheet good enough as evidence?
It can be, if it is complete and current. The weak point is proving it matches what actually runs, including scripts loaded by other scripts. A record built from real sessions answers that question directly.
What is a targeted risk analysis for 11.6.1?
A documented analysis, under requirement 12.3.1, that justifies checking less often than weekly. If you check weekly or more often, you do not need one for 11.6.1.
Can one tool produce the evidence for both requirements?
Yes, as long as it keeps them as two records: the inventory, justifications and integrity for 6.4.3, and the detection configuration and alert history for 11.6.1.