Notifications
Clear all
Topic starter
20/08/2026 5:39 pm
TL;DR: Third-party scripts can access forms and customer data beyond their intended purpose, creating GDPR, PCI DSS, CCPA, and HIPAA exposure even when the core application is sound, according to Jscrambler. The governance problem is not just privacy compliance but controlling client-side data access, because trust and purpose limitation fail when scripts behave outside business intent.
NHIMG editorial — based on content published by Jscrambler: GDPR compliance guide and third-party script risk
By the numbers:
- Businesses can be fined up to €20 million or 4% of annual turnover under the GDPR for serious breaches.
Questions worth separating out
Q: How should organisations govern third-party scripts that can read sensitive user data?
A: Treat each embedded script as a governed runtime dependency with a defined data scope, approved destinations, and continuous monitoring.
Q: Why do third-party scripts create governance risk similar to non-human identities?
A: Third-party scripts execute inside a live session with inherited privileges, broad context, and little lifecycle oversight.
Q: How do organisations know if client-side data controls are working?
A: Look for script inventories that match production reality, stable data access scopes, and routine detection of unexpected endpoints or DOM access.
Practitioner guidance
- Build a third-party script inventory List every tag, pixel, widget, and external script that can access customer pages, then record business purpose, data access scope, owner, and review date.
- Restrict script access to intended data Apply fine-grained policies so third-party code can only touch the fields and events it genuinely needs.
- Test for client-side behaviour drift Revalidate script behaviour after every tag manager change, vendor update, or new integration.
What's in the full article
Jscrambler's full guide covers the operational detail this post intentionally leaves for the source:
- The legal and compliance mechanics behind GDPR principles, rights, and penalties for privacy teams that need policy context.
- The specific ways third-party scripts, pixels, and tags can access customer data during real user sessions.
- The vendor's operational framing for controlling client-side behaviour across privacy regulations such as GDPR, CCPA, PCI DSS v4, NIST, OWASP, and HIPAA.
- The product-level explanation of how fine-grained script controls are applied in practice.
👉 Read Jscrambler's guide to GDPR compliance and third-party script risk →
Third-party scripts and GDPR: what security teams keep missing?
Explore further
20/08/2026 6:23 pm
Third-party script governance is becoming a de facto identity problem. When a browser script can access customer data, it is operating like a delegated non-human actor with standing access to sensitive information. That access is rarely modelled with the same lifecycle discipline used for service accounts or API keys, which leaves a governance gap between intent and runtime behaviour. Practitioners should treat client-side code as a controlled identity surface, not just a web performance dependency.
A question worth separating out:
Q: Who is accountable when a third-party identity causes data exposure?
A: Accountability sits with the organisation that trusted the identity without sufficient boundaries, not just with the vendor that used it. If a third-party account was over-scoped, persistently trusted, or insufficiently monitored, the governance failure is internal. Frameworks such as NIST CSF and zero trust both expect explicit control over external access.
👉 Read our full editorial: GDPR compliance gaps persist in third-party script governance
