Who is accountable for third-party website scripts that collect analytics or sales intelligence?

The site operator remains accountable for deciding which scripts run, what they collect, and whether their use matches the published policy. Third-party providers may supply the tooling, but the organisation hosting the site owns the governance decision. That includes disclosure, consent handling, script review, and ensuring tracking aligns with internal privacy commitments.

Why This Matters for Security Teams

Third-party scripts are not a narrow marketing choice. They are code running with the site operator’s authority, often able to observe clicks, form inputs, page content, and referral data. That makes the operator accountable for the decision to load the script, the data it can access, and whether the script’s behaviour matches the published notice and consent model. NHI Mgmt Group has shown how broadly external identities and integrations expand risk, including that 92% of organisations expose NHIs to third parties, raising supply chain concerns in practice.

This issue is easy to underestimate because the vendor may provide the tag, pixel, or SDK, but the hosting organisation controls placement, scope, and retention. Security teams should treat scripts as governed dependencies, not harmless analytics helpers. The same logic appears in supply-chain incidents such as The 52 NHI breaches Report, where delegated access and hidden integrations created downstream exposure. Controls also align with OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls, which both emphasise governance, inventory, and access restriction. In practice, many security teams discover script over-collection only after a privacy complaint, regulator inquiry, or browser-side telemetry review.

How It Works in Practice

Accountability starts with ownership of the decision, then moves to technical enforcement. The operator should maintain an inventory of every third-party script, tag, and browser-side collector, including purpose, data fields accessed, destination domains, and approval owner. That inventory should be linked to the privacy notice, consent state, and any legitimate-interest assessment or internal policy exception.

Practically, this means reviewing scripts before deployment, limiting them to the minimum domains required, and validating that they do not read more page context than intended. Security and privacy teams should also use content security policy, subresource integrity where feasible, and change control for tag managers. For higher-risk collectors, the operator should require vendor attestations, renewal review, and periodic verification that the script still matches the approved use case. Where analytics or sales intelligence tools rely on session replay, form capture, or enrichment, the data path must be explicit and monitored.

For governance, it helps to treat the browser as an execution environment with its own identity and trust boundaries. The hosting organisation remains accountable even when a provider processes the data, because the operator chose to embed that code and expose users to it. This mirrors the control logic in Klue OAuth Supply Chain Breach and Reviewdog GitHub Action supply chain attack, where delegated tooling created obligations the downstream organisation still had to manage. These controls tend to break down when scripts are injected through unmanaged tag managers because ownership, change review, and revocation become opaque.

Common Variations and Edge Cases

Tighter script governance often increases operational overhead, requiring organisations to balance marketing agility against privacy, security, and compliance constraints. The standard answer is clear for first-party sites, but edge cases can complicate the decision. In current guidance, the operator is still accountable when a third party sets cookies, performs fingerprinting, or enriches visitor data from the browser, because the operator enabled the collection. There is no universal standard for every partner arrangement yet, so legal, privacy, and security teams need a shared approval model.

One common exception is a hosted sales or analytics platform where the organisation only embeds a vendor-hosted widget. Even then, accountability does not disappear. The operator still owns disclosure, consent capture, and whether the widget’s behaviour is consistent with the stated purpose. Another edge case is region-specific privacy law, where data retention, international transfer, or consent requirements may differ from the vendor’s default settings. For these cases, the safest approach is to document whether the script is essential, optional, or prohibited by policy, and to require removal if it cannot be bounded.

For deeper context on why embedded tooling and hidden integrations become governance failures, Shai Hulud npm malware campaign is a useful analogue. The real-world lesson is that third-party code in the browser is rarely just code, and accountability stays with the site operator even when the vendor wrote the script.

Related resources from NHI Mgmt Group

• Who is accountable when third-party OAuth connections create NHI visibility gaps?
• Who is accountable for governing third-party, non-employee, and machine access in public sector cloud environments?
• Who is accountable for container image compliance when third-party images are used across cloud workloads?
• Who is accountable when public sector organisations adopt third-party email security controls?