Skip to main content
The state of ai impact assessment
Should You Verify Consent Yourself?Supervisory Authorities & Enforcement
7 min readFor Legal & Compliance Teams

Should You Verify Consent Yourself?

You're an ad tech company. A publisher sends you bid requests containing user identifiers and behavioral signals. The publisher claims it has consent. Do you process that data based on their word, or do you verify the lawful basis yourself?

Norway's Datatilsynet just answered that question with a 92 million NOK fine (approximately $9.6 million) against Xandr. The authority found that Xandr processed data associated with Grindr users between July 2018 and April 2020 without establishing its own valid lawful basis. Xandr assumed Grindr had obtained consent but didn't verify it. That assumption cost them.

This wasn't a controller making a mistake with its own users. This was an intermediary in the advertising supply chain failing to independently establish why it could lawfully process personal data, especially when that data could reveal sexual orientation under Article 9.

The Decision You're Facing

When you receive personal data from an upstream partner (a publisher, data provider, or another intermediary), you must decide:

Do I process this data based on the upstream party's claimed lawful basis, or do I establish my own independent lawful basis?

Your answer determines whether you're compliant with Articles 6 and 9, and whether you're exposed to enforcement risk if the upstream party's consent mechanism fails.

Key Factors That Affect Your Choice

Nature of the data: If the data could reveal special category information under Article 9 (health, sexual orientation, political views), you face heightened obligations. Grindr's case involved an LGBTQ+ dating app where user presence alone could reveal sexual orientation. That triggers Article 9's stricter requirements beyond ordinary Article 6 compliance.

Your role in the processing chain: Are you a processor acting on documented instructions, or are you a controller determining your own purposes? If you're deciding which advertisers see which users, you're likely a controller. Controllers can't outsource their Article 5(2) accountability by claiming they trusted someone else's consent.

Visibility into upstream consent mechanisms: Can you inspect the actual consent interface shown to users? Can you verify timestamp records, granular consent choices, and withdrawal mechanisms? Or are you accepting a contractual representation that "consent exists" without technical verification?

Regulatory precedent in your jurisdiction: Datatilsynet isn't alone. The Irish DPC, CNIL, and other supervisory authorities have signaled that intermediaries can't hide behind upstream consent claims when processing special category data or making independent decisions about data use.

Path A: Verify Consent Independently

Choose this path when:

  • You're processing special category data under Article 9
  • You're making your own decisions about how to use the data (you're a controller, not just a processor)
  • The upstream party cannot provide technical proof of valid consent
  • You're operating in jurisdictions where supervisory authorities have enforced against intermediaries (Norway, France, Austria)
  • Your contract with the upstream party doesn't include detailed representations about consent mechanisms, or you can't audit those representations

What this looks like in practice:

You build technical controls that inspect consent signals before processing. If you receive a bid request, you check for a consent string (like a Transparency and Consent Framework string) that documents which vendors the user consented to and for which purposes. If your company isn't listed, or if the purpose doesn't match your intended processing, you don't process that data.

You document your own lawful basis in your Article 30 records. You don't write "we rely on Publisher X's consent." You write "we process under Article 6(1)(a) based on consent we verify through [specific technical mechanism]" or "we process under Article 6(1)(f) based on our legitimate interests assessment dated [date], which concluded [specific balancing outcome]."

You conduct your own legitimate interests assessment if you're not relying on consent. That assessment must account for the reasonable expectations of users who shared data with the upstream party. A user who signed up for a dating app reasonably expects their data will be used to show them relevant matches. Do they reasonably expect their sexual orientation to be shared with dozens of advertising intermediaries? Your assessment must address that gap.

The Compliance Cost:

This path requires engineering resources to build verification systems. It requires legal resources to draft legitimate interests assessments. It may reduce the volume of data you can process because some upstream consent will fail verification.

But it also means you're not inheriting someone else's compliance failure.

Path B: Rely on Upstream Lawful Basis as a Processor

Choose this path when:

  • You're genuinely acting as a processor under Article 28, not making your own decisions about data use
  • You have a written processing agreement that documents the controller's instructions
  • The controller has provided you with specific, documented instructions about what data to process and for which purposes
  • You're not making independent decisions about which users to target or which data points to use

What this looks like in practice:

You don't determine purposes. A publisher (the controller) tells you: "Process user identifier X for the purpose of delivering ad creative Y to fulfill our contract with Advertiser Z." You execute that instruction. You don't decide which users are interesting or which behavioral signals to analyze.

Your Article 30 records list you as a processor. Your contract with the controller includes Article 28(3) mandatory clauses: the subject matter and duration of processing, the nature and purpose, the type of personal data, the categories of data subjects, and your obligations regarding security and sub-processors.

You don't establish your own lawful basis because you're not the one determining why the processing happens. The controller already did that.

The Limitation:

Most advertising technology companies don't actually fit this model. If you're running an ad exchange, a demand-side platform, or a data management platform where you make decisions about which impressions to bid on or which audience segments to create, you're a controller. You can't claim processor status just because you're in the middle of a supply chain.

The Xandr case illustrates this. Advertising intermediaries often believe they're just passing data through, but if you're making decisions that affect which users see which ads, you're determining purposes. That makes you a controller with independent compliance obligations.

Path C: Establish Legitimate Interests as a Controller

Choose this path when:

  • You're a controller but consent verification isn't technically feasible
  • You can demonstrate a legitimate interest that doesn't override users' rights
  • The data isn't special category under Article 9 (or you have an Article 9(2) exception)
  • You can show users wouldn't reasonably object to your processing

What this looks like in practice:

You conduct a three-part legitimate interests assessment under Article 6(1)(f): identify your legitimate interest, demonstrate the processing is necessary for that interest, and balance your interest against the user's rights and freedoms.

For advertising, your legitimate interest might be "funding our service through contextual advertising" or "providing relevant ad experiences that support publisher revenue." The necessity test requires showing you can't achieve that interest through less intrusive means. The legitimate interests assessment requires considering whether users would reasonably expect this processing given how they interacted with the upstream service.

You document this assessment and make it available to supervisory authorities. You provide clear transparency information to users, even if they didn't interact with your service directly. You honor objection requests under Article 21.

The Catch:

Legitimate interests don't work for special category data unless you fit an Article 9(2) exception. The Xandr case involved data that could reveal sexual orientation. Article 9(1) prohibits processing such data, and Article 6(1)(f) legitimate interests isn't listed in Article 9(2) as an exception. That's why Xandr couldn't fall back on "we had a legitimate interest in advertising."

Summary Matrix

Factor Verify Consent Act as Processor Legitimate Interests
Your role Controller making decisions Processor following instructions Controller making decisions
Data type Any, including Article 9 Any, per controller's instructions Article 6 only (not Article 9)
Technical lift High (build verification) Low (execute instructions) Medium (conduct assessment)
Legal documentation Consent verification records Article 28 agreement Legitimate interests assessment
Risk if upstream fails Lower (you verified independently) Lower (controller is accountable) Medium (you own the lawful basis)
Regulatory acceptance High (Datatilsynet expects this) High (if genuinely a processor) Medium (depends on balancing outcome)

The Xandr fine, initiated by a complaint from Austrian nonprofit Noyb in January 2020, makes the stakes clear. If you're processing data associated with users you never directly interacted with, you can't assume the upstream party handled consent correctly. Microsoft acquired Xandr in 2022, years after the violations occurred between July 2018 and April 2020, but inherited the enforcement action anyway.

Your decision tree starts with an honest assessment: are you actually a processor, or are you a controller trying to avoid controller obligations? If you're a controller, the next question is whether you're processing special category data. If yes, consent verification isn't optional, it's the only path that satisfies Article 9. If no, you have more flexibility, but you still need a documented lawful basis that accounts for users' reasonable expectations.

The companies that get this wrong are the ones that never asked the question in the first place.

Promotional banner for the Pentest Readiness checklist download

You Might Also Like