Skip to main content
Cookie Gate
Commerce Security logo, "All 12 PCI DSS Requirements in Plain English," "Get it now for free," "Complete Survival Guide" and a button toclick to get it
Category: TCF and Vendors

Vendor as Processor

Also known as: Processor Vendor, Vendor Acting as Processor
Simply put

In data protection law, a vendor acts as a processor when it handles personal data on behalf of another organization (the controller) and follows that organization's instructions rather than deciding for itself how and why the data is used. Not every vendor is a processor; a vendor that provides goods or services does not automatically process personal data on your behalf, and the classification generally depends on what the vendor actually does with the data and on having an appropriate contract in place. Getting this classification right matters because it determines which contractual and compliance obligations apply.

Formal definition

A vendor is classified as a processor when it processes personal data on behalf of a controller and acts within that controller's documented instructions, as distinguished from a controller, which determines the purposes and means of processing. Under the GDPR framework, this classification is fact-driven: it turns on the vendor's actual role in relation to the data rather than on its label, and it generally requires a contract meeting the applicable regulatory requirements (for example, a data processing agreement under the GDPR, or a service provider contract meeting statutory terms under certain US state privacy laws such as the CCPA/CPRA). Where a vendor engages further parties to handle data on its behalf, those parties are typically treated as sub-processors, a separate but related role. This entry addresses role classification only and does not resolve the specific factual analysis of any given vendor arrangement, which depends on the processing activities, contractual terms, and applicable jurisdiction; classifications and terminology (for example 'processor' versus 'service provider') differ between the EU/UK and individual US state regimes.

Why it matters

Classifying a vendor correctly as a processor rather than a controller (or, under US state regimes, as a service provider rather than a third party) determines which contractual and compliance obligations apply to a data relationship. A vendor that merely provides goods or services does not automatically process personal data on your behalf; the classification generally turns on what the vendor actually does with the data and on whether an appropriate contract is in place. Getting this wrong can leave an organization without the documented instructions, data processing agreements, or statutory contract terms that regulators expect, and it can mislead the allocation of responsibility between the parties.

The classification is fact-driven rather than label-driven. A vendor described in a contract as a 'processor' may in practice determine the purposes and means of processing, which would make it a controller instead, changing the obligations that apply to both parties. Because a vendor can generally only be treated as a processor or service provider if it has a contract meeting the applicable regulatory requirements, an arrangement lacking such terms may not qualify at all, regardless of how the parties intended to characterize it.

Terminology and requirements differ across jurisdictions, which compounds the stakes. The EU and UK GDPR framework uses 'controller' and 'processor,' while certain US state privacy laws such as the CCPA/CPRA use terms like 'service provider' with their own statutory contract requirements. An organization operating across regimes may need to satisfy several sets of criteria for the same vendor, and the analysis of any given arrangement depends on the specific processing activities, contractual terms, and applicable law.

Who it's relevant to

Privacy officers and data protection professionals
These teams are responsible for mapping vendor relationships and assigning the correct role to each. Because classification is fact-driven and depends on what a vendor actually does with data rather than its label, they must assess processing activities and ensure appropriate contracts are in place, feeding roles and sub-processors into records such as the ROPA.
Legal counsel and contract teams
Whether a vendor qualifies as a processor or service provider generally depends on having a contract that meets applicable regulatory requirements, a data processing agreement under the GDPR, or statutory service provider terms under laws such as the CCPA/CPRA. Counsel must ensure these terms exist and reflect the vendor's actual role, and account for terminology that differs between the EU/UK and individual US state regimes.
Procurement and vendor management teams
Not every vendor that supplies goods or services processes personal data on your behalf. These teams need to identify which vendors handle personal data and under what instructions, and to track any sub-processors engaged downstream, so that role classification and contractual coverage are established before data changes hands.
Compliance and GRC teams
Vendor role classification and the sub-processors tracked against each vendor flow into risk records and processing inventories. Accurate classification supports these records, but the tools that manage them support compliance rather than replacing the legal and factual judgment required for any specific arrangement.

Inside Vendor as Processor

Processor role under the GDPR
A vendor acts as a processor when it processes personal data on behalf of, and on the documented instructions of, a controller (typically the website or app operator). The processor does not determine the purposes and means of processing for its own account. In the cookie context, this often applies to service providers that operate tracking or analytics infrastructure strictly on the client's behalf.
Distinction from controller status
Whether a vendor is a processor is a factual determination, not merely a contractual label. If the vendor determines its own purposes for the data (for example, using collected data to improve its own products or for its own advertising), it may be acting as a controller or joint controller rather than a processor, which changes the allocation of responsibilities and, in most EU jurisdictions, may require its own legal basis and transparency obligations.
Data processing agreement (DPA)
Article 28 of the GDPR generally requires a written contract or other legal act between controller and processor setting out the subject matter, duration, nature and purpose of processing, the types of personal data, categories of data subjects, and the obligations and rights of the controller. Cookie and tracking vendors engaged as processors typically fall within this requirement.
Instruction-bound processing
A processor may generally only process personal data on the controller's documented instructions, including with regard to international transfers, unless required to do otherwise by applicable law. Processing beyond those instructions may cause the vendor to be treated as a controller for that processing.
Relationship to ePrivacy consent
The processor/controller analysis under the GDPR is distinct from the ePrivacy requirement to obtain prior consent before placing or accessing cookies or similar technologies on a device. Even where a vendor is a processor, the controller generally remains responsible for ensuring valid consent (where required) is obtained before non-essential cookies, pixels, SDKs, local storage, or fingerprinting technologies are deployed. Processor status does not create or substitute for that consent.
Sub-processors and onward flows
Vendors acting as processors often engage sub-processors (for example, hosting or infrastructure providers). Under the GDPR, engaging sub-processors generally requires the controller's prior authorisation and the flow-down of equivalent data protection obligations. International transfers by the vendor or its sub-processors may trigger separate transfer safeguards.

Common questions

Answers to the questions practitioners most commonly ask about Vendor as Processor.

If a cookie vendor is our processor, does that mean they handle consent and legal responsibility on our behalf?
No. A processor acting on your instructions does not assume your controller obligations. As the controller, you generally remain responsible for establishing a valid legal basis, obtaining consent where required under the ePrivacy rules and GDPR, and ensuring transparency toward users. A processor is bound to act only on your documented instructions and to assist you, but it does not take over your accountability. Treating a vendor's processor status as a transfer of your compliance duties is a common and risky misunderstanding.
Does labeling a vendor as a 'processor' in the contract actually make them one?
Not necessarily. The classification depends on the factual reality of how the vendor handles data, in particular whether it determines the purposes and means of processing, not on the label used in an agreement. A vendor that uses the data for its own purposes, for example, to improve its own products or to build its own advertising profiles, may be acting as a controller or joint controller regardless of contractual wording. You should assess the vendor's actual role rather than rely on the contractual designation alone, and note that different data protection authorities may scrutinize these arrangements differently.
How do we determine whether a particular cookie vendor is a processor or a controller?
Review what the vendor does with the data in practice. Key questions include: does the vendor act only on your documented instructions, or does it decide the purposes and means of processing? Does it reuse the data for its own analytics, product development, or advertising? Analytics and advertising vendors in particular often process for their own purposes, which can make a controller or joint-controller analysis more appropriate. This determination is fact-specific, may be contested, and can depend on details not visible from the vendor's documentation alone, so legal review is generally advisable.
What contractual terms should be in place when a vendor genuinely acts as a processor?
Where a vendor is a processor, GDPR generally requires a data processing agreement addressing matters such as the subject matter and duration of processing, the nature and purpose, the types of data and categories of data subjects, processing only on documented instructions, confidentiality, security measures, use of sub-processors, assistance with data subject rights and security obligations, and deletion or return of data at the end of the engagement. Exact requirements and any additional national or sector-specific terms should be confirmed for your applicable jurisdiction, as scope can differ between the EU, the UK, and other regimes.
Does using a processor change who is responsible for obtaining cookie consent before tags fire?
In most EU jurisdictions the obligation to obtain prior consent for non-essential cookies and similar technologies rests with the party deploying them in the user's context, typically the website or app operator acting as controller. Engaging a processor to operate the technology does not shift that consent obligation to the vendor. You should ensure that a vendor's tags, pixels, SDKs, or scripts do not place or access information on a device before valid consent is captured, and that consent signals are communicated to the vendor. How responsibilities are allocated can differ where the vendor is found to be a controller or joint controller.
How should we handle a vendor's sub-processors and its use of data for its own purposes?
For a genuine processor relationship, your data processing agreement should address the engagement of sub-processors, including authorization and notification arrangements and the flow-down of equivalent obligations. Separately, you should confirm whether the vendor uses any data for its own purposes; if it does, that use may fall outside a pure processor role and require a different legal analysis and potentially different transparency and legal-basis arrangements. Because these facts drive the classification, they should be verified against the vendor's actual practices rather than assumed, and reassessed if the vendor's processing changes.

Common misconceptions

Labelling a vendor a processor in the contract settles the matter.
In most EU jurisdictions the roles are assessed on the factual reality of who determines the purposes and means of processing, not on the contractual designation alone. A vendor that uses the data for its own purposes may be a controller or joint controller regardless of what the agreement says.
If the vendor is a processor, it is responsible for obtaining cookie consent.
The obligation to obtain valid prior consent for non-essential cookies and similar technologies under the ePrivacy rules generally rests with the controller operating the site or app. Processor status under the GDPR is a separate question and does not shift or satisfy the ePrivacy consent obligation.
Signing a DPA with a vendor makes the arrangement compliant.
A data processing agreement is generally a necessary component under Article 28, but it does not by itself guarantee compliance. The controller still needs an appropriate legal basis, valid consent where required, adequate transfer safeguards, and ongoing oversight; the contract supports compliance but does not replace legal judgment.

Best practices

Assess the actual role of each cookie or tracking vendor based on who determines the purposes and means of processing, rather than relying on the label used in marketing materials or contracts.
Put an Article 28-compliant data processing agreement in place with each vendor genuinely acting as a processor, covering subject matter, duration, nature, purpose, data types, and controller instructions.
Keep the ePrivacy consent analysis separate from the processor determination, and ensure valid prior consent is obtained by the controller before deploying non-essential cookies, pixels, SDKs, local storage, or fingerprinting where required in the relevant jurisdiction.
Review sub-processor arrangements and international transfer mechanisms, ensuring prior authorisation and equivalent obligations flow down, and that appropriate transfer safeguards are in place.
Document and periodically re-verify each vendor's role, particularly where a vendor may use collected data for its own purposes, which could indicate controller or joint-controller status with different obligations.
Treat vendor tooling and DPAs as support for compliance rather than a guarantee of it, and obtain jurisdiction-specific legal advice where roles or requirements are contested or uncertain.
a promotional banner asking how ready are you for PCI DSS 4.0? With a call-to-action to get the checklist now.