Agency Liability: Controller or Processor for Consent?

"We just set it up, it's their site"

That's the reflex when a client's cookie banner turns out to be non-compliant and a regulator or a plaintiff starts asking questions. The agency built it, sure, but it's the client's website, the client's business, the client's problem. It's a comforting position. It's also wrong often enough to be dangerous.

Whether you're on the hook doesn't turn on whose logo is in the footer. It turns on a specific GDPR question: for the tracking you deploy on a client's site, are you a processor, a controller, or a joint controller? Get that classification wrong and you can carry liability you never priced into the engagement. This guide is the legal-structure companion to our multi-client consent operations guide, which covers the day-to-day. Here we're on the part that decides who pays when it goes wrong.

Controller, processor, and why the label decides your liability

GDPR sorts every party into a role, and the role sets the obligations.

• A controller decides the purposes and means of processing, the why and the how. Controllers carry the primary legal duties: lawful basis, consent, transparency, data-subject rights.
• A processor acts only on the controller's documented instructions. Lower direct exposure, but real obligations under a mandatory contract.
• Joint controllers jointly determine purposes and means, and they share responsibility.

The part agencies miss: the role is determined by what you actually do, not by what the contract calls you. Writing "the Agency acts as a processor" in an MSA doesn't make it true if you're the one choosing which analytics and ad platforms to deploy and why. Regulators and courts look at the reality of the decision-making. The EDPB Guidelines 07/2020 on the concepts of controller and processor are the reference here, and they're blunt about it: function over form.

You're probably both, depending on the service

Most agencies aren't one role across the board. They split by service.

When you run analytics or ad campaigns using your own tooling, methods, and audience strategy on the client's site, you're likely making purpose-and-means decisions, which points toward controller or joint controller for that activity. When you simply implement what the client specified, on the client's accounts, to the client's instructions, you look more like a processor. A single agency can be a processor for the client's first-party CRM data and a joint controller for the retargeting pixel it chose to deploy, in the same engagement.

The practical move is to inventory your services and classify each one, rather than declaring a single blanket role. "We're always just a processor" is the assumption that gets tested and fails.

Fashion ID: the bar for joint controllership is low

The case every agency embedding third-party tags should know is Fashion ID (CJEU C-40/17, decided July 29, 2019). A retailer embedded Facebook's "Like" button. The button transmitted every visitor's IP address and browser data to Facebook, whether or not they clicked it, whether or not they were logged in, whether or not they consented.

The Court of Justice held that the website operator was a joint controller with Facebook for the collection and transmission of that data. Not for what Facebook did afterward, the operator had no say in that, but for the collection-and-transmission stage it helped cause. The judgment set a deliberately low threshold: joint controllership doesn't require equal responsibility, and it doesn't even require that both parties can access the data.

Translate that to agency work. When you drop a Meta Pixel, a LinkedIn Insight Tag, or an ad vendor's script onto a client's site, and it transmits visitor data to that vendor, Fashion ID is the reason you can't assume you're a neutral installer. Embedding the tag that causes the transmission can make you a joint controller for that stage.

What the two contracts require

Each role comes with a mandatory contract, and skipping it is itself a violation.

Processor relationships need an Article 28 agreement (a DPA). It has required terms: the processor acts only on documented instructions, keeps confidentiality, secures the data, uses sub-processors only with authorization, assists with data-subject rights, and deletes or returns data at the end. No DPA, and both sides are exposed. See data processing agreements for website owners.

Joint controllers need an Article 26 arrangement. Joint controllers must agree, in a transparent arrangement, who does what, especially who handles transparency and data-subject requests, and the essence of that arrangement has to be available to the people whose data you process. And here's the sting: regardless of what the arrangement says between you, a data subject can exercise their rights against either controller. You can't contract your way out of being answerable to the individual.

The stakes aren't trivial. Breaching these controller obligations sits in the GDPR fine tier that reaches up to 10 million euros, or 2% of total worldwide annual turnover, whichever is higher.

The contract structure that actually protects you

You reduce agency exposure with paper that matches reality, not paper that wishes it away.

• A roles matrix, service by service. Spell out which party is controller, processor, or joint controller for each activity (site analytics, ad pixels, CRM sync, email). Vague blanket labels are the weak point.
• The right instrument for each role. An Article 28 DPA where you're a processor; an Article 26 arrangement where you're a joint controller. Don't paper a joint-controller reality with a processor DPA.
• Instructions in writing. As a processor, your protection is that you only acted on documented client instructions. So document them. "The client directed deployment of the following tags" is the record that keeps a processor a processor.
• Consent responsibility, named. State explicitly whose job it is to obtain and record valid consent for the tags you deploy, and confirm the client's banner actually covers them before you go live. A banner that fails is a shared problem once your tag is on the page. See why cookie banners fail compliance.
• Indemnities that follow fault. Allocate liability to the party that made the decision. If the client insisted on a tag against your advice, the contract should reflect that. If you deployed something they never approved, don't expect an indemnity to save you.

A quick decision framework

For each thing you deploy on a client site, ask: who decided this should happen, and why?

• Client specified it, on their accounts, to their spec → you're closer to processor. Get a DPA and keep the written instruction.
• You chose the platform and strategy and deployed it on their site → controller or joint controller for that activity. Get an Article 26 arrangement and make sure consent is squared away.
• You embedded a third-party tag that transmits visitor data to a vendor → Fashion ID territory. Assume joint controllership for the collection/transmission and confirm the banner blocks it pre-consent.

When you're unsure, the safer assumption is the one with more responsibility, because that's the one that makes you check consent and paperwork before the tag ships.

How CookieBeam supports agencies on this

Per-client isolation. CookieBeam manages each client's consent configuration separately under one agency account, so one client's banner, categories, and consent records don't bleed into another's. That separation is what lets you show a clean, per-controller record when someone asks.

Consent enforced before tags fire. Non-essential scripts, including the third-party pixels that put you in Fashion ID territory, stay blocked until the visitor consents. That directly addresses the collection-and-transmission stage the Court cared about.

Per-client consent logs. Every decision is recorded with timestamp and jurisdiction (consent logging and audit requirements), so if a data subject exercises rights against you as a joint controller, you can produce the evidence for that specific client.

DPA-ready. CookieBeam provides the sub-processor documentation you need for your own Article 28 chain. See DPAs with your CMP provider.

The agencies that sleep well don't assume they're always "just the implementer." They classify each service honestly, sign the instrument that role requires, and make sure consent is real before a tag they chose ever loads on a client's page.