Who is accountable when third-party scripts leak personal data?

The organisation that deploys the script remains accountable for how data is collected and transmitted, even if the vendor supplies the code. Privacy, security, and digital product owners should share responsibility for approval, monitoring, and revocation. In regulated environments, that accountability also extends to demonstrating field-level control and consent enforcement.

Why This Matters for Security Teams

Third-party scripts can collect form fields, session data, device details, and other personal data before a privacy team ever reviews the integration. That makes accountability a governance issue, not just a procurement issue. The deploying organisation decides whether the script is permitted, where it runs, what data it can touch, and how quickly it is removed when risk changes. NIST’s control model in NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it ties data protection to operational control ownership rather than vendor assurances.

Teams often underestimate how easily a benign marketing tag, analytics pixel, chat widget, or consent tool can expand into a data-exposure path. The issue is not only exfiltration; it is also unauthorised collection, weak consent enforcement, and loss of visibility into downstream transmission. In privacy and security reviews, the question is less “who wrote the code” and more “who allowed it to execute with access to personal data.” In practice, many security teams encounter third-party script leakage only after a complaint, audit finding, or browser-side incident investigation has already exposed the gap.

How It Works in Practice

Accountability should be assigned across the full lifecycle of the script, from approval through monitoring and revocation. The business owner usually justifies the use case, security validates technical risk, privacy confirms lawful basis and disclosure obligations, and engineering enforces the implementation. That shared model matters because third-party scripts often run with the same browser privileges as the first-party application, which means they can observe inputs, modify content, and relay data externally.

Practitioners should think in terms of control points:

• Inventory every script, tag, SDK, and embedded widget that can access personal data.
• Define which fields, pages, or events the script is allowed to observe.
• Review consent logic and make sure collection stops when consent is absent or withdrawn.
• Limit script execution paths through allowlisting, subresource integrity, and tight deployment review.
• Monitor for drift, version changes, and unexpected destinations or parameters.

Identity and secrets governance also matter when scripts use API keys, tokens, or other machine credentials to forward data. That is where the NHI perspective becomes relevant, because a script can behave like a non-human identity with access and transmission authority. The OWASP Non-Human Identity Top 10 is useful for treating these integrations as managed access paths rather than passive code snippets. Current guidance suggests aligning script review with data mapping, consent enforcement, and continuous verification rather than relying on a one-time legal approval. These controls tend to break down in fast-moving front-end release pipelines because scripts are frequently added outside normal change windows and are not re-reviewed after vendor updates.

Common Variations and Edge Cases

Tighter script governance often increases release overhead, requiring organisations to balance user experience and marketing agility against privacy risk and auditability. That tradeoff becomes sharper when teams depend on ad-tech, experimentation platforms, or embedded support tools that change frequently and may inject additional dependencies.

There is no universal standard for this yet on the exact division of liability between controller, processor, and subprocessor in every deployment model, so legal interpretation still matters. Under the EU General Data Protection Regulation (GDPR), organisations still need to show lawful processing, purpose limitation, and appropriate technical controls even when a third party supplies the script. Where scripts act autonomously or are coupled with AI features, the risk profile can resemble agentic tooling more than conventional web code, and current guidance suggests treating that as a higher-risk integration. The Anthropic report on the first AI-orchestrated cyber espionage campaign also underscores how autonomous tooling can amplify access and exfiltration when controls are weak.

Edge cases also appear in single-page apps, embedded identity journeys, and consent banners that themselves load tracking code. In those environments, a script can leak personal data while simultaneously asserting that consent has been captured, which creates a false sense of compliance. Organisations should be especially cautious where scripts can read identity attributes, payment details, or authentication flows, because those events often blend security, privacy, and fraud concerns into a single control failure.

Related resources from NHI Mgmt Group

• Who is accountable when third-party access to personal data persists too long?
• Who is accountable when a third party accesses personal data outside policy?
• Who is accountable when personal data is exposed through a processor or third-party workflow?
• Who is accountable when a third-party verification provider mishandles identity data?