PCI Monitor
A payment page script inventory is a current list of every script that runs on each payment page, with who approved it, why it is needed, how its integrity is assured and how it is loaded. It has to be built from what the browser actually loads, not from your source code, because tag managers and scripts that load other scripts add code you never wrote. This is the core of PCI DSS 6.4.3 and the evidence an assessor will ask to see.
What the inventory is for
You cannot authorize, check or monitor what you do not know is there. The inventory is the shared reference for three jobs: deciding what is allowed on a payment page, spotting what is not, and showing an assessor that you do both. Requirement 6.4.3 asks for an inventory of all payment page scripts with a written business or technical justification for each; see PCI DSS 6.4.3 explained.
What to record for each script
| Field | Why it is there |
|---|---|
| Where it comes from | The address (or, for an inline script, a short identifier and its hash) and the organization that supplies it. |
| How it is loaded | Directly in the page, by a tag manager, or by another script. This shows the chain of trust. |
| Pages it runs on | The steps of the payment flow where it appears. |
| Purpose and justification | The written business or technical reason it is needed on a payment page. |
| Owner | The person or team who answers for it and decides whether it is still needed. |
| Authorization | Who approved it and on what date, and the review that confirms it is still approved. |
| Integrity method | How you know it is the approved version: a Subresource Integrity hash, a CSP hash or nonce, or monitoring of its content. |
| Version or hash | The approved version or digest, so a change can be detected. |
| Status and review date | Approved, under review or removed; and when it was last reviewed. |
An example of a good justification
"Loads the payment provider's hosted-field library; required to render the card fields; supplied by the provider and pinned by an integrity hash; reviewed each time the provider announces a new version." It says what the script does, why the page needs it and how it is controlled. Compare "payments", which tells a reviewer nothing.
How to discover what really runs
- Use a real browser. Open the payment flow and look at the network and sources panels of the browser's developer tools, or use an automated browser that records every script it loads and executes. Do it for every step of the flow, not only the page with the card form.
- Follow the chain. For each script, note what it loads in turn. Tag managers and widgets often load several more.
- Capture inline scripts, which have no address: record their content or a hash.
- Cover the variations. Check the flow as a logged-in customer, as a guest, with different countries, devices and languages, and with and without the consent banner accepted, because scripts can differ.
- Use report-only to catch the rest. A Content Security Policy in report-only mode lists the sources a page really uses; see Content Security Policy for payment pages.
- Compare with your sources of truth: the code repository, the tag manager's tag list and your vendors' own lists. Differences are findings.
A one-off manual check is a start; the inventory only stays true if the discovery is repeated automatically and any difference is reviewed. See how to detect client-side tampering.
Authorising scripts, and keeping the inventory true
- Name the approver. Decide who may approve a script for a payment page (usually someone in security or engineering with knowledge of the business need), and record their decision with a date.
- Require a reason. No entry without a written justification. If nobody can write one, the script probably does not belong on the page.
- Re-approve on change. A new version, a new source or a new way of loading is a change and needs a new decision, because the approval was for the thing as it was.
- Review on a schedule. Remove entries whose purpose has ended, and confirm owners are still in post.
- Handle tag managers specially. Each tag counts as a script; see tag manager risk.
What an assessor typically asks to see
Practices vary by assessor, so ask yours. Evidence commonly requested includes the current inventory for each payment page, the written justification and approval for each script, a description of how integrity is assured and proof it works, evidence that the inventory matches what the pages load (for example a recent comparison), and records showing that changes are handled between reviews. A snapshot taken for the audit is weaker than a history that shows the process running throughout the period.
Key takeaways
- The inventory lists every script on every payment page, with source, loading method, justification, owner, approval and integrity method.
- Build it from what a real browser loads, across the whole payment flow and its variations, not from source code alone.
- Every entry needs a written reason that a reviewer can test; no reason usually means no place on the page.
- Re-approve scripts when they change, and review the list on a schedule.
- Assessors look for a living process with history, not a one-time snapshot.
Frequently asked questions
What counts as a payment page for the inventory?
The pages where card data is entered or where a payment form is embedded, and, depending on how you accept payments, pages that can affect them. PCI SSC guidance discusses this in detail; agree the list of pages with your acquirer or assessor.
How detailed does the written justification need to be?
Detailed enough that a reviewer can judge whether the script is still needed: what it does, why the payment page needs it, and who relies on it. A single word such as "analytics" is too thin.
How often should the inventory be updated?
Whenever a script changes, and checked automatically on a schedule that matches your detection frequency (at least every seven days for 11.6.1, unless a risk analysis supports another interval), with a full human review at planned intervals.
Do inline scripts belong in the inventory?
Yes. They run in the browser like any other script. Record what they do and keep a hash or a copy so a change can be seen.
References
Last reviewed: October 17, 2026
