Who is accountable when a third-party tag leaks customer data?

Why This Matters for Security Teams

When a third-party tag leaks customer data, the failure is rarely just technical. It is usually a governance problem hidden inside marketing, product, or analytics workflows, where a script is approved without a clear owner, scoped access, or documented purpose. That means accountability can extend across security, privacy, legal, and the business function that requested the tag. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports the idea that data use must be controlled, reviewed, and evidenced, not assumed safe because it came from a trusted supplier.

The practical risk is that tags often operate with broad browser visibility, can collect more than intended, and may quietly transmit data to multiple endpoints. Security teams often focus on the vendor contract while missing the actual runtime behaviour of the tag, which is where leakage happens. That gap becomes more serious when the tag captures account identifiers, payment details, or consent state, because those fields can create regulatory and breach notification obligations. The relevant issue is not whether the provider wrote the code, but whether the organisation approved the collection, understood the blast radius, and continued to supervise it after deployment. In practice, many security teams encounter tag misuse only after customer complaints or forensic review has already exposed the data flow.

How It Works in Practice

Accountability for a leaking tag should be assigned through clear ownership of the full lifecycle: business justification, approval, implementation, monitoring, and retirement. A third-party script is not a one-time purchase. It is an active integration that can change behaviour as the provider updates the code, the consent state changes, or the website loads new dependencies. That is why organisations need both contractual controls and technical controls. The contract matters, but it does not replace runtime governance.

Practitioners should treat the tag as a non-human actor with scoped permissions and observable behaviour, especially when it can access personal data, session data, or payment fields. The OWASP Non-Human Identity Top 10 is useful here because it highlights the broader problem of unmanaged machine-to-machine trust, even when the “identity” is a script rather than a service account. In that framing, the organisation remains accountable for the tag’s secret handling, token use, and data reach.

• Define one named business owner and one technical owner for each tag.
• Limit collection to the minimum fields required for the stated purpose.
• Block the tag until consent, purpose, and destination controls are verified.
• Monitor outbound requests, data elements, and vendor changes continuously.
• Remove the tag quickly if purpose drift or unexpected destinations appear.

Security logging, privacy review, and change management should converge on the same evidence trail so that investigations can show who approved the tag, what it was allowed to access, and what monitoring existed. This is especially important because AI-assisted attackers are increasingly using legitimate tooling, browser channels, and trusted integrations to blend in with normal activity, as described in Anthropic — first AI-orchestrated cyber espionage campaign report. These controls tend to break down in heavily decentralised marketing environments because tags are deployed by non-security teams faster than they are reviewed.

Common Variations and Edge Cases

Tighter tag governance often increases release friction and can slow marketing or product experimentation, so organisations must balance agility against privacy and security assurance. There is no universal standard for every tagging scenario yet, especially when customer journeys rely on multiple analytics, advertising, and personalisation services. Current guidance suggests that accountability should follow control, meaning the organisation that selected and enabled the tag remains responsible even if the vendor wrote the code.

Edge cases appear when data is pseudonymous, when the tag is managed through a tag manager, or when a processor subcontracts to another service. In those situations, the core question is still whether the business knew what data could be exposed and whether it could prove proportionate supervision. If the tag touched payment flows, regulated sectors may also trigger stricter evidencing requirements, incident response timing, and supplier assurance. Where consent is inconsistent across jurisdictions, the organisation may need separate policies for regional traffic rather than a single global rule. For teams building a stronger control baseline, the NIST privacy and security control families remain the most defensible starting point for approval, monitoring, and audit evidence. If a tag sits outside the normal ownership model, accountability usually becomes contested only after the leak is already public.

Related resources from NHI Mgmt Group

• Who is accountable when a third-party token exposes customer data?
• Who is accountable when a third-party script exposes customer payment data?
• Who is accountable when a third-party verification provider mishandles identity data?
• Who is accountable when third-party access to personal data persists too long?