Skip to main content
green gradient background, "The Future of Application Security Is Already Here." and a read the report button.
Category: TCF and Vendors

Vendor

Also known as: Supplier, Provider, Seller, Third-party vendor
Simply put

A vendor is a party in a supply chain that provides goods or services to a company or to consumers. In the cookie consent context, the term is commonly used to refer to the external companies whose cookies, pixels, or tracking technologies a website relies on, though the evidence provided here describes the general commercial meaning rather than a consent-specific one.

Formal definition

In its general commercial and accounting sense, a vendor (also called a supplier, provider, or seller) is a person or enterprise that contributes goods or services within a supply chain, whether by manufacturing, distributing, or reselling to businesses or consumers. The evidence supplied supports only this general definition and does not establish a specialized meaning within cookie consent or data protection frameworks; readers should note that in consent management practice the word is often applied to third parties whose tracking technologies require handling under applicable law, but that usage is out of scope of the sources cited here and would require additional authoritative evidence to define precisely.

Why it matters

The term vendor appears constantly in cookie consent and data protection discussions, where it is frequently used to describe the external companies whose cookies, pixels, SDKs, or other tracking technologies a website loads. However, the evidence available here supports only the general commercial and accounting meaning of the word: a party in a supply chain that supplies goods or services to businesses or consumers. Readers should be aware that the widely used consent-management sense of vendor is not established by the sources cited and would require additional authoritative material to define precisely.

This distinction matters because precision about roles and parties is central to sound compliance decisions. When practitioners refer to third-party vendors in a cookie context, they are typically pointing to entities whose technologies may place or access information on a user's device and may process personal data as a result, which can engage both the ePrivacy rules on device access and the GDPR rules on personal data processing in EU jurisdictions. Conflating the general commercial vendor with a specifically defined consent-management role risks papering over questions that actually depend on the technical behavior of each third party and the applicable legal framework.

Because the specialized usage is out of scope of the evidence provided, this entry does not attempt to assign vendors specific obligations, roles such as controller or processor, or consent-handling duties. Those determinations vary between the EU, the UK, and individual US state regimes and depend on facts not covered here. Treat the term as a general label unless a more specific, evidence-backed definition is supplied.

Who it's relevant to

Privacy officers and data protection professionals
Those managing third-party relationships need clarity on what a vendor is in general commercial terms before assessing any consent or data protection implications. This entry supports only the general meaning; the consent-specific role of a vendor would need to be determined against the applicable framework and the actual behavior of each third party.
Legal counsel
Counsel drafting or reviewing contracts and compliance documentation should note that the general commercial definition of vendor does not by itself carry data protection consequences. Whether a given vendor's technologies engage ePrivacy device-access rules or GDPR processing obligations depends on facts and jurisdiction not addressed by this entry.
Web developers and technical implementers
Developers who integrate external cookies, pixels, SDKs, or similar technologies commonly refer to those providers as vendors. This entry confirms the general commercial meaning of the term but does not define how such vendors should be classified or handled within a consent management setup, which requires further evidence and legal input.
Marketing and compliance teams
Teams selecting and managing advertising and analytics suppliers use vendor to describe those partners. The general definition here helps standardize terminology, but decisions about consent handling for a vendor's tracking technologies fall outside this entry's scope and vary between the EU, the UK, and US state regimes.

Inside Vendor

Third-party vendor
In the cookie consent context, a vendor is typically an external party (for example an analytics provider, advertising network, or tag/SDK supplier) whose technologies may place cookies or similar identifiers on, or access information from, a user's device. Under EU law such placing and access is generally governed by the ePrivacy Directive as implemented nationally, while any subsequent processing of personal data by the vendor falls under the GDPR.
Data protection role
A vendor may act as a processor (acting on the site operator's instructions) or as an independent or joint controller, depending on the facts. This distinction affects the contractual arrangements and responsibilities under the GDPR and is not determined by the vendor label alone.
Consent dependency
Where a vendor's technology is not strictly necessary (for example analytics, advertising, or non-essential functional purposes), prior consent that is freely given, specific, informed, and unambiguous is typically required in most EU jurisdictions before the vendor's cookies, pixels, local storage, SDKs, or fingerprinting techniques are activated. Requirements differ under other regimes, such as US state laws that often rely on opt-out.
Vendor lists within CMPs and frameworks
Consent management platforms (CMPs) and frameworks such as the IAB Transparency and Consent Framework (TCF) maintain vendor lists that identify the parties whose processing users are asked to consent to or object to. These lists support transparency and signalling but do not by themselves guarantee legal compliance.
Purposes and technologies used
A vendor entry generally describes the purposes for which the vendor processes data and the technologies it relies on. Because pixels, local storage, SDKs, and fingerprinting fall within the same consent rules as cookies in the EU, these should be disclosed even where no literal cookie is set.

Common questions

Answers to the questions practitioners most commonly ask about Vendor.

Does listing a vendor in our cookie banner make us compliant with our obligations toward that vendor?
No. Listing a vendor and disclosing its purposes is one component of transparency, but it does not by itself satisfy your legal obligations. Under the GDPR, you generally still need an appropriate legal basis for any personal data processing, a data processing agreement or equivalent arrangement where the vendor acts as a processor, and valid prior consent under the ePrivacy Directive (as nationally implemented) before non-exempt cookies or similar technologies are placed. A CMP that enumerates vendors supports compliance but does not replace these legal and contractual steps, and the exact requirements vary by jurisdiction.
If a vendor participates in the IAB Transparency and Consent Framework (TCF), does that guarantee the vendor is compliant?
No. Participation in the TCF, or registration on a framework's vendor list, indicates that a vendor has agreed to certain technical and policy specifications, but it does not guarantee that the vendor's actual processing is lawful or that your own use of it is compliant. Frameworks can help standardize how consent signals are communicated, yet regulatory scrutiny of such frameworks has occurred in some EU jurisdictions, and enforcement positions continue to evolve. Framework membership is not a substitute for your own legal assessment of each vendor.
How do we determine whether a vendor is acting as a processor or a controller?
This turns on who determines the purposes and means of the processing rather than on any label the vendor applies to itself. A vendor that processes personal data only on your documented instructions generally acts as a processor, whereas a vendor that uses the data for its own purposes may be a controller or joint controller. The distinction affects which contractual arrangements and legal bases apply. Because this is a fact-specific analysis and characterizations can be contested, it typically requires review of the vendor's actual data practices and contracts rather than reliance on its self-description.
What information should we collect about a vendor before enabling it in our CMP?
In most EU jurisdictions it is common to gather the vendor's identity, the specific purposes for which it processes data, the categories of technologies it uses (cookies, pixels, local storage, SDKs, or similar), retention periods, whether it acts as processor or controller, and any onward data transfers. This supports the informed element of valid consent and your transparency obligations. Requirements and expected detail can differ across the EU, the UK, and individual US states, so the appropriate scope of information should be confirmed against the applicable regime.
How should we handle a vendor that drops cookies or similar technologies before consent is given?
Under the ePrivacy Directive as implemented in most EU jurisdictions, non-exempt cookies and similar technologies should generally not be placed until valid prior consent is obtained, so a vendor firing before consent can create a compliance gap even if the vendor is otherwise disclosed. Practical steps often include technically gating vendor tags or SDKs behind the consent signal and testing that they do not load prematurely. Because enforcement and technical implementation practices vary, this should be verified against the applicable rules and your own testing rather than assumed.
What records should we keep about the vendors we use for consent purposes?
Consent record-keeping generally involves being able to demonstrate what a user was told and what they agreed to, which can include the set of vendors and purposes presented at the time consent was collected. Keeping a versioned history of your vendor list and the associated disclosures helps support accountability, since vendors and their purposes change over time. The precise record-keeping obligations depend on the applicable framework, and a CMP's logs support but do not by themselves establish that consent was validly obtained.

Common misconceptions

If a vendor is labelled a processor, the site operator has no further consent responsibilities.
The processor or controller status affects contractual and accountability obligations under the GDPR, but it does not remove the need for a valid legal basis. In most EU jurisdictions the operator that deploys a non-essential vendor technology remains responsible for obtaining prior consent for the placing of and access to information on the device, and the vendor's precise role must be assessed on the facts.
Listing a vendor in a CMP or the IAB TCF automatically makes its data collection lawful.
Vendor lists and frameworks support transparency and consent signalling, but they do not replace legal judgment. Consent must still meet the applicable standard, and inclusion in a list does not guarantee that any particular vendor's processing is compliant across the EU, the UK, or individual US states.
A vendor that uses pixels or SDKs rather than cookies falls outside consent rules.
In the EU, similar technologies such as pixels, local storage, SDKs, and fingerprinting are generally treated the same way as cookies when they involve placing or accessing information on a user's device, so a vendor relying on them for non-essential purposes typically still requires consent.

Best practices

Maintain an up-to-date inventory of all vendors whose technologies place or access information on users' devices, including those using pixels, local storage, SDKs, or fingerprinting rather than literal cookies.
Assess each vendor's data protection role (processor, controller, or joint controller) on the facts and put appropriate contractual arrangements in place under the GDPR rather than relying on the vendor label.
Categorise each vendor's cookies and technologies by purpose so that strictly necessary items can be distinguished from analytics, advertising, and non-essential functional items that generally require prior consent in most EU jurisdictions.
Ensure non-essential vendor technologies are blocked until valid consent is obtained where EU rules apply, and configure opt-out mechanisms, including recognition of Global Privacy Control signals where relevant, for regimes that rely on opt-out.
Disclose vendors, their purposes, and the technologies they use transparently, and keep consent logs or records to support accountability, while remembering that a CMP or the IAB TCF supports compliance but does not guarantee it.
Confirm the geographic and legal scope that applies to each deployment, since vendor consent obligations differ across the EU, the UK, and individual US states, and reassess as regulatory guidance evolves.
Application Security Isn’t Optional Anymore.