Third-party script risk management is the operating model for running external JavaScript as a governed program instead of an open door. The framework has six moving parts: inventory, ownership, data-access classification, change monitoring, review cadence, and evidence. Get those six working together and you can answer the only questions that matter in an incident or an audit: what runs, who owns it, what it can touch, and what changed.
Most teams have tactics without a program. They run a Content Security Policy, maybe pin a few Subresource Integrity hashes, and keep a vendor spreadsheet that went stale the day a tag manager added a fourth-party script nobody approved. This post covers the governance model those tactics plug into, the roles that run it, and the browser-side evidence cside produces to make each part real.
The six-part operating model
Each part of the framework answers a question an attacker or an assessor will ask. If any column is blank, that is your exposure.
| Pillar | The question it answers | Evidence to keep |
|---|---|---|
| Inventory | What actually executes in the browser? | Script URL, source/fourth party, first-seen date, version |
| Ownership | Who is accountable for this script? | Named owner, business justification, approval record |
| Data-access tier | What can this script read or send? | Form-field, cookie, token access; tier label |
| Change monitoring | What changed, and was it authorized? | Diffs, new destinations, alert + disposition |
| Review cadence | When was this last re-attested? | Last review date, reviewer, next-due date |
| Evidence | Can we prove all of the above? | Immutable timeline per PCI 6.4.3 / 11.6.1 |
Build the inventory from the browser, not a spreadsheet
A vendor list is not an inventory. One approved vendor can load chained scripts you never reviewed, and tag managers inject code at runtime that no server-side scan sees. Your inventory has to come from what actually executes in real users' browsers, including the fourth parties your third parties pull in.
cside builds this inventory from live browser observation: every script, its real source, when it first appeared, and what it does once it runs. That is the spine the other five pillars hang on, because you cannot assign an owner or a data tier to a script you cannot see.
Assign one owner per script, then make roles explicit with RACI
An inventory without ownership is a list of orphans. Every script needs a named human who can state its business justification and approve its changes. But "owner" alone blurs fast in an incident, so spread the work across roles with a simple RACI: who is Responsible, Accountable, Consulted, and Informed for each part of the program.
| Activity | Script owner | Engineering | Security | Privacy | Compliance |
|---|---|---|---|---|---|
| Maintain the live inventory | C | R/A | I | I | I |
| Approve a new script / justification | A | R | C | C | I |
| Classify data-access tier | C | I | C | A/R | I |
| Investigate a change alert | C | C | A/R | C | I |
| Authorize a block | A | R | C | I | I |
| Produce audit evidence | C | I | C | C | A/R |
One rule keeps it honest: every row has exactly one Accountable. When PCI DSS 6.4.3 asks you to justify and authorize each payment-page script, "who approved this" must resolve to a name, not a shrug. The RACI is what turns the inventory from a list into a program people run.
Classify data access in tiers
Not every script earns the same trust. Classify by what it can reach in the browser, then govern each tier differently. A marketing pixel that reads a checkout form is the exact pattern behind Magecart and e-skimming theft, so the classification has to be behavioral, not just by vendor reputation.
| Tier | Data the script can touch | Governance |
|---|---|---|
| Tier 1, sensitive | Payment fields, credentials, session tokens | Review every change; default-deny risky actions |
| Tier 2, personal | Form inputs, identifiable cookies | Approve access, monitor destinations |
| Tier 3, low | No PII, static assets only | Lightweight periodic review |
cside lets you set behavioral policy by script: a chat widget can render without reading the payment field next to it, and an analytics tag can run while being blocked from cookies or form inputs. That turns the tier label into an enforced rule instead of a note in a spreadsheet.
Monitor change, because approval is a moment and scripts are continuous
The dangerous gap in most programs is time. A script is approved once, then changes silently for months. Static checks miss this: a CSP only governs load origin, and an SRI hash protects a static file but breaks on the dynamic scripts most modern sites depend on, so teams drop it. Approval is a snapshot; risk is a movie.
Change monitoring closes the gap by watching runtime behavior, not just the source domain. When a Tier 1 script starts reading a field it never touched, beacons to a new destination, or its payload shifts, that is the signal. cside captures the runtime behavior, payload changes, and new network destinations, then alerts on unauthorized change. That same capture is what PCI DSS 11.6.1 expects: detect and alert on unauthorized modification of payment-page scripts and HTTP headers, at least weekly or per your risk analysis under requirement 12.3.1.
Set a review cadence tied to the data tier
Cadence keeps the program from rotting between incidents. Drive it off the tier, not the calendar alone:
- Tier 1 scripts: re-attest on every change and at least quarterly.
- Tier 2 scripts: review quarterly and on any new destination.
- Tier 3 scripts: review annually, or whenever they move up a tier.
- Any new or unapproved script: review on detection, no waiting.
A review that produces no record is a conversation, not a control. Each pass should leave a dated note: who reviewed, what they checked, and what is due next.
Rate your program against a maturity model
A framework only helps if you know where you stand on it. Use these five levels to score the program honestly, per surface. Your payment pages can sit at a different level than your marketing site, and the gap between them is usually where the risk lives.
| Level | State | What it looks like | Audit posture |
|---|---|---|---|
| 1, Ad hoc | No inventory | Scripts added by whoever, no list, no owners | Fails 6.4.3 on day one |
| 2, Documented | Static spreadsheet | Vendor list exists but goes stale; no fourth parties | Inventory exists, integrity unproven |
| 3, Owned | RACI assigned | Named owners, justifications, manual periodic review | Can show authorization, weak on change detection |
| 4, Monitored | Runtime change alerts | Behavioral monitoring, tiered policy, alerts dispositioned | Meets the intent of 11.6.1 |
| 5, Continuous | Evidence on demand | Live inventory, enforced tiers, immutable timeline exported on request | Audit-ready without a fire drill |
Most teams discover they are at Level 2 on the surface that matters most. The jump that counts is Level 3 to Level 4: moving from "we have a list and owners" to "we get alerted the moment a Tier 1 script changes behavior." That is the line between a binder and a control, and it is where browser-layer monitoring earns its place.
Keep evidence an auditor will accept
The framework only counts if you can prove it ran. For PCI DSS 4.0.1, that means an inventory with documented justification for every payment-page script (6.4.3) and a tamper-alert trail for unauthorized changes to scripts and HTTP headers (11.6.1), both mandatory since 2025-03-31. A payment processor like Stripe or Adyen does not make your own page compliant. The scripts on your checkout are still your responsibility, and a third-party iframe does not move that line.
cside keeps this as an immutable, queryable timeline: what each script is, who approved it, the data it accessed, every change, every alert, and how each was dispositioned. When the assessor asks "show me," you export a record instead of reconstructing one from memory. The browser layer matters here too: cside captures device and real-IP signals, AI-agent and bot behavior, and VPN/proxy patterns, so the evidence reflects what really ran for real users rather than what a periodic crawler happened to see. Signals are available via API, so the inventory and alerts can feed your own GRC or SIEM tooling.
Why a program beats a checklist in 2026
Automation pressure is rising on the attacker side. cside's own research found that playwright-stealth installs climbed about tenfold through 2025, which means more automated, evasive activity probing client-side surfaces (cside research report). Crawlers that scan periodically are exactly what evasive automation is built to dodge: serve clean code to the scanner, malicious payload to the real session. A static once-a-year spreadsheet cannot keep up with that; a continuous operating model with owners, tiers, and real-user change alerts can. The framework is what turns a pile of scripts into something you govern.
Further reading on cside
- Best practices for securing third-party scripts
- Top platforms for third-party script monitoring
- How to comply with PCI 6.4.3 and 11.6.1
- What is client-side security?
- cside PCI Shield
- NIS2 directive website compliance and third-party script obligations
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.
