PCI DSS 6.4.3 asks for three things on every payment page: an inventory of each script, a confirmation that each one is authorized, and assurance that each script's integrity holds. The inventory and the authorization record are where most teams stall. This post is only about those two artifacts — how to build them, what fields each record carries, and how to stop them from drifting out of date the week after the audit.
The control became mandatory on 2025-03-31. A spreadsheet snapshot taken once and forgotten does not satisfy it, because the thing being controlled — third-party JavaScript — changes on its own schedule. A clean inventory is a living record with an owner, a justification, and a version history per script. Get the record structure right first; the tooling decision follows from it.
For the requirement language itself, the buy-vs-build debate, and what auditors look for end to end, read the practical PCI 6.4.3 and 11.6.1 guide and the QSA assessment guide. This page stays narrow on the inventory mechanics.
What scope does the inventory have to cover?
The PCI SSC scopes 6.4.3 to the scripts loaded and executed in the consumer's browser on the payment page — both scripts from the entity's own environment and scripts loaded from third and fourth parties. Read that scope literally before you start listing. Your inventory must capture:
- First-party / same-origin scripts — your own bundles, served from your domain.
- Inline scripts — snippets pasted into the HTML template, including tag-manager bootstraps.
- Third-party scripts — analytics, A/B testing, support widgets, fraud SDKs, payment helpers.
- Fourth-party scripts — anything a third-party script loads after it runs. These never appear in a vendor contract or a tag manager.
The fourth-party layer is the one teams miss. A single analytics tag can pull in a chain of additional scripts at runtime that no one approved directly. If your inventory starts from a vendor list or a tag-manager export, that chain is invisible. Start from what the browser actually receives on the live payment page.
What fields does each inventory row need?
An inventory row is evidence. It has to answer "what is this, where did it come from, and is it the same thing it was last week" without anyone opening devtools mid-audit. The minimum useful columns:
| Field | What it records | Why a QSA wants it |
|---|---|---|
| Script URL / source | Full URL, or inline for embedded code | Identifies the asset and its origin domain |
| Party tier | First, third, or fourth party | Proves fourth-party chains are accounted for |
| Content hash | Hash of the payload actually served | Anchors integrity checks to real content, not a filename |
| First seen / last seen | When it appeared, when last observed | Flags scripts that vanished or appeared without a change record |
| Owner | Named accountable person | Traces who can justify the script |
| Business justification | Why it runs near the payment page | Satisfies the "written justification" clause |
| Data access note | What the script can read on the page | Surfaces anything touching form fields |
| Authorization status | Authorized / pending / rejected | The 6.4.3 authorization confirmation itself |
| Version history | Prior hashes with timestamps | Shows the record is maintained, not a snapshot |
The two columns that separate real evidence from a checkbox are content hash and version history. A row that lists only a URL proves the script exists. A row that pins the hash of the payload served to the browser, and keeps the prior hashes, proves you can tell when that script changed — which is the bridge between 6.4.3's inventory and 11.6.1's change detection.
What does a single authorization record look like?
Authorization is not a column you tick. It is a decision someone made and can defend. A complete record ties the script to a person, a reason, and a moment in time. Here is one row filled in as a worked example:
| Field | Value |
|---|---|
| Script source | https://cdn.example-analytics.com/v3/tag.js |
| Party tier | Third party |
| Content hash | sha256:8f2a…c91d (payload served 2026-06-15) |
| Owner | Priya N., Web Platform Lead |
| Business justification | Funnel analytics for checkout conversion reporting |
| Data access note | Reads page URL and click events; no access to card input fields |
| Authorization status | Authorized — approved 2026-06-15 |
| Version history | sha256:8f2a…c91d (2026-06-15), sha256:4b07…aa12 (2026-05-02) |
Notice the data access note. It does not just say the script is allowed — it states what the script is permitted to touch. When the next version of that tag suddenly starts reading the card input field, the gap between the note and the observed behavior is the alert. A justification without a stated boundary cannot be violated, so it can never trigger anything.
How do you keep the inventory from going stale?
The failure mode is predictable. A team builds a thorough inventory for the audit, passes, and within weeks marketing ships a new tag, a vendor pushes a v3 of their SDK, and a fourth-party dependency swaps domains. None of it lands in the spreadsheet. The inventory is now fiction, and the next assessment exposes it.
A maintainable inventory follows a loop, not a one-time build:
- Seed from live captures. Inventory what the browser receives on the production payment page, not a vendor list or a tag-manager export.
- Reduce surface. Remove scripts that do not need to run on the payment page. Fewer authorized scripts means fewer records to keep honest.
- Authorize before exposure. Assign an owner, write the justification and data-access boundary, and set status before the script ships to the payment path.
- Re-authorize on change. When a script's served payload changes hash, the prior authorization no longer covers the new content. Treat each change as a new approval decision.
- Schedule a standing review. Run a recurring review so justification text stays accurate as scripts evolve, and so nothing sits in
pendingindefinitely.
Step four is where manual processes collapse. A modern third-party tag can serve a different payload by user location, browser, or time of day. Catching every hash change by hand across every script on every load is not realistic. That is why the inventory has to be wired to a detection mechanism rather than re-typed by a human each week.
Where cside fits the inventory workflow
cside builds the inventory from the browser layer — it records the scripts that real customers' browsers actually receive, including inline and fourth-party loads that vendor lists and tag-manager exports never show. Each entry carries the source, the served payload, a content hash, and first-seen / last-seen timestamps, so the inventory reflects production rather than a stale snapshot.
On the authorization side, cside stores the owner, justification, and data-access context alongside each script, and flags when a script's served content changes so the prior authorization can be reviewed against the new payload. That turns 6.4.3 from a quarterly spreadsheet into a live record with QSA-ready exports, and feeds the change-detection evidence that 11.6.1 requires. See cside PCI Shield for the platform view.
Further reading on cside
- How to comply with PCI 6.4.3 and 11.6.1
- What QSAs should look for in 6.4.3 and 11.6.1
- PCI DSS 4.0.1 client-side compliance guide
- cside PCI Shield
As of 2026-06-18, treat this as operational guidance, not legal advice. Confirm the exact control language with your QSA, counsel, or risk owner.
