Who is accountable for cookie compliance when third-party vendors place tracking cookies on a site?

Why cookie compliance remains a shared accountability

Cookie compliance does not sit with the vendor alone just because the tracking tag, SDK, or script comes from a third party. The site operator controls the user-facing site, decides which vendors are allowed to load, and is the party most able to enforce consent, notices, and technical blocking. The vendor may supply the mechanism, but the operator still owns the control environment.

That distinction matters because accountability follows control, not convenience. If a tag manager, ad network, or analytics provider drops cookies before consent, uses a different purpose than disclosed, or changes behaviour over time, the site operator is still expected to detect and govern that outcome. For that reason, cookie governance belongs with both procurement and web governance, not only legal review.

What shared control means in practice

Shared control means each party has a different role in the compliance chain. The vendor should disclose cookie purpose, duration, and dependency accurately; the operator should inventory the vendor, classify the cookie, and decide whether it may run. In practice, the operator also needs to make sure the consent banner, preference centre, and tag deployment logic match the actual scripts on the page.

Operators should assume that third-party behaviour can change without notice, especially when marketing teams add new tags or product teams update embedded services. A compliant site therefore needs ongoing scanning of cookies and network calls, review of vendor changes, and a way to suspend a tag quickly when it no longer matches the declared purpose. Third-Party, B2B and Contractor Access Guide is useful here because the same ownership discipline applies to external parties that operate inside your trust boundary.

Why third-party cookies create governance and trust risk

Third-party tracking cookies create exposure because the organisation can lose sight of what is actually being set in the browser, especially when multiple vendors chain through the same tag manager or ad platform. That can lead to consent gaps, incomplete notices, and inconsistent retention or sharing practices. The risk is not only regulatory, it is also trust erosion when visitors discover data collection they were not clearly told about.

Failure mechanism: a vendor script, embedded pixel, or tag manager update adds or changes cookies after deployment, and the operator does not detect the drift quickly enough to block it or refresh disclosures. Impact: the site may be collecting or sharing tracking data outside the approved purpose, creating exposure under privacy law, increasing audit findings, and undermining user trust in the site’s controls.

Where the vendor relationship is especially complex, cookie compliance should be treated like any other third-party control area. IAM and IGA Basics helps frame the ownership model: the question is not who supplied the code, but who is responsible for approving, reviewing, and revoking access to the execution path that sets the cookie. OWASP Non-Human Identity Top 10 is also relevant because many browser-side vendors rely on long-lived tokens, integrations, and privileged access patterns that deserve lifecycle control.

How to assign accountability without creating gaps

Assign one business owner for the site’s cookie programme, then separate execution responsibilities across privacy, security, engineering, and procurement. The owner should be able to answer four questions: which cookies run, why they run, whether consent is needed before they run, and how the site will detect unauthorised changes. Without those answers, vendors can become a blind spot rather than a managed dependency.

What to verify: confirm that your consent tooling blocks non-essential cookies before opt-in, that the cookie inventory matches live site behaviour, and that vendor contracts require timely disclosure of script changes. If a vendor cannot support that evidence, treat the integration as higher risk until it can be revalidated.

Practitioner takeaway: do not let “third-party” become a way to outsource accountability; the operator must own the approved cookie state, because only the operator can enforce it across notices, consent, and runtime controls.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CSA Cloud Controls Matrix sets the technical controls, while ISO/IEC 27001:2022 and GDPR define the regulatory obligations.

Framework	Control / Reference	Relevance
ISO/IEC 27001:2022	A.5.19 — Information security in supplier relationships	Third-party cookies are a supplier control issue on the operator's site.
Recommendation — Review supplier cookie behavior and contract terms before allowing tracking scripts.
GDPR	Article 5 — Principles relating to processing of personal data	Tracking cookies often process personal data and must follow purpose, minimization, and transparency principles.
	Article 25 — Data protection by design and by default	Consent gating and cookie blocking are design obligations for a website deploying trackers.
Recommendation — Align cookie use to lawful purpose, minimization, and transparent disclosures. Build consent and default-blocking into the site before any non-essential cookie loads.
CSA Cloud Controls Matrix	DSP — Data Security & Privacy	Cookie governance is a data privacy control area in cloud-delivered web services.
Recommendation — Map cookie categories and sharing paths to privacy controls and retention rules.

#1 Authority in NHI Education, Research and Advisory, empowering organizations to tackle the critical risks posed by Non-Human Identities (NHIs), including AI Agents.