Legitimate interests under GDPR: prove the balance before you process

Legitimate interests under GDPR: prove the balance before you process

A practical GDPR guide to the three-condition legitimate-interests test, the LIA record, and the design choices that make or break Article 6(1)(f).

A product team wants to send purchase-history offers to existing customers. Security wants to share order details with a fraud vendor. Analytics wants to reuse support-ticket text to train an internal ranking model.
Each request arrives with the same legal shortcut: "We have a legitimate interest."
Under the GDPR, that phrase is only the start of the analysis. Article 6(1)(f) lets a controller process personal data when the processing is necessary for legitimate interests pursued by the controller or a third party, except where the data subject's interests or fundamental rights and freedoms override those interests, especially where the person is a child. Public authorities cannot rely on Article 6(1)(f) when they process data in the performance of their tasks. 1
The European Data Protection Board treats that rule as three cumulative conditions. The controller must identify a legitimate interest, show that the processing is necessary for that interest, and show that the person's interests, rights, and freedoms do not take precedence. The assessment belongs before the processing starts, and the controller should document it. 2

The boundary is a three-condition test

Article 6(1) lists six lawful bases. Legitimate interests is one of them, and the GDPR ranks none above the others. The EDPB requires a careful assessment before reliance on Article 6(1)(f), warns against treating the basis as an open door when another basis fails, and warns against stretching it to avoid more specific legal requirements. 2
The Court of Justice of the European Union and the EDPB break the provision into three conditions that all must hold:
ConditionWhat the controller must establishWhat usually fails
Legitimate interestA lawful, precisely stated, present interest of the controller or a named third partyVague labels such as "business interest," "engagement," or "improve the experience"
NecessityThe processing is a targeted way to pursue that interest, and less restrictive means would not achieve it just as effectivelyCollecting extra fields, continuous monitoring, or broad reuse because the chosen product design prefers them
BalancingThe person's interests, rights, and freedoms do not override the interest, after reasonable expectations, impact, and safeguards are weighedUnexpected reuse, sensitive data, weak transparency, or high impact with thin justification
The table follows the three cumulative conditions in the EDPB's Article 6(1)(f) guidelines. 2
Recital 47 adds the operational cues reviewers use every day. A relevant relationship, such as a client or employment relationship, can support the analysis. Reasonable expectations at the time and in the context of collection matter. Processing strictly necessary for fraud prevention can count as a legitimate interest. Direct marketing may be carried out for a legitimate interest. Recitals 48 and 49 add intra-group administrative transfers and network and information security as further examples. Those examples only help with the first condition. They do not finish necessity or balancing. 1
The UK Information Commissioner's Office organises the same three conditions as a purpose test, a necessity test, and a balancing test, and calls the documented outcome a legitimate interests assessment (LIA). The UK GDPR text matches the structure of Article 6(1)(f), but ICO material is UK guidance. The EU GDPR remains the governing text for an EU assessment. The UK also maintains a separate "recognised legitimate interest" basis for listed purposes; that UK basis sits outside EU Article 6(1)(f). 3

Condition 1: name a real interest

An interest is legitimate only when it is lawful, clearly and precisely articulated, and real at the time of processing. The EDPB distinguishes the broader interest from the narrower processing purpose. The purpose is what the controller will do with the data. The interest is the stake or benefit that purpose serves. 2
Write the interest in operational language:
  • "Recover unpaid invoices through a debt-collection agency"
  • "Stop repeat account-creation by previously banned users"
  • "Send postal product offers to existing customers who bought in the last 12 months"
  • "Detect invoice-fraud patterns by sharing order fields with a fraud-screening provider"
Avoid labels that name no outcome:
  • "legitimate business interests"
  • "improve user experience"
  • "build community"
  • "measure content performance"
An EDPB Support Pool of Experts case digest of one-stop-shop decisions shows how often step 1 fails in enforcement. Controllers that could not specify the interest behind cookie-based profiling, or that described interests only as "building community" or "engagement," failed the first condition and often failed transparency at the same time. Vague purposes also block people from testing necessity or objecting in a meaningful way. 4
The interest may belong to a third party. The controller still has to identify that third party and apply the same precision. A private company generally cannot borrow a public authority's crime-prevention interest as its own free-standing justification when that interest is unrelated to the company's activities. 4
If the interest itself is unlawful—spam that breaches electronic marketing rules, for example—the first condition fails and the later conditions cannot repair it. 3

Condition 2: necessity is a design test

"Necessary" means a targeted and proportionate way to pursue the stated interest. The EDPB asks whether the legitimate interest can reasonably be achieved just as effectively by other means that are less restrictive of the person's rights and freedoms, taking Article 5(1) principles such as data minimisation into account. If those means exist, Article 6(1)(f) leaves the more intrusive design without a basis. 2
The ICO puts the same idea in review questions: will the processing actually help achieve the purpose; is it proportionate; can the purpose be achieved without the data, with less data, or through a less intrusive method? 5
Necessity failures in the case digest are concrete:
  • Photographing hotel guests for fraud control when surname and room checks or signatures could work
  • Collecting a phone number for customer service or fraud checks when email would work
  • Retaining biometric identifiers for every closed account to prevent ban evasion when a narrower check at the point of a later block would work
  • Behavioural advertising designs that had realistic less intrusive alternatives 4
A reviewer can force the design question early. Ask the team to name one less intrusive alternative they rejected, and why that alternative would not achieve the stated interest just as effectively. If the only answer is "that is not our product model," the necessity record is incomplete.

Condition 3: balance impact, expectations, and safeguards

Even a lawful interest pursued through necessary processing can fail the balance. The controller must weigh the person's interests, fundamental rights, and freedoms against the interest pursued. The GDPR highlights children. Recital 47 highlights reasonable expectations based on the relationship with the controller and the context of collection. 11
The EDPB groups the balancing factors into four practical bundles:
  1. The person's interests and rights. These include privacy and data protection, and also financial, social, and personal interests, freedom of expression, non-discrimination, property, and physical or mental integrity.
  2. Impact. Look at the nature of the data, the context and scale of processing, vulnerability of the people affected, and further consequences such as exclusion, reputational harm, financial loss, loss of service, safety risks, or chilling effects.
  3. Reasonable expectations. Base the test on the relationship, the context of collection, what people were told, how long ago the data were collected, and whether the reuse is new or innovative. Common industry practice alone does not prove expectation.
  4. Safeguards that go beyond ordinary GDPR compliance. Extra measures can change the balance, but only if they actually reduce the impact. After adopting them, the controller repeats the balance. 2
Reasonable expectations often decide close cases. Supervisory authorities have rejected legitimate interests where consumers could not expect commercial prospecting from brokered contact data, where antivirus users could not expect browsing-history analytics and onward sale, and where marketplace users could not expect secret "shadow blocking." By contrast, a customer buying on invoice can often reasonably expect anti-fraud checks, even when the privacy notice names recipients imperfectly. 4
Safeguards that change the balance look like operating controls:
  • Collect fewer fields or shorten retention
  • Restrict access and logging
  • Offer a clear opt-out for non-marketing processing where that fits the use
  • Give people a route to challenge an adverse score or rating
  • Separate a high-impact action from automated output with meaningful review
An Estonian one-stop-shop decision on ride-hailing passenger ratings shows the positive pattern. After rebuilding its analysis, the controller explained the rating process, limited who could see ratings and for how long, told passengers about consequences and challenge rights, and put human review around automated suspensions. The supervisory authority accepted legitimate interests once those measures were real. 4

A decision screen for product and procurement reviews

A DPO or product reviewer can test a proposed use in this order.
  1. Write the processing action. State the data fields, source, recipients, retention, and the decision or communication that follows. "Personalization" is too vague to test.
  2. State the interest and who holds it. Name the controller interest or the specific third-party interest, the benefit, and the harm if the processing does not happen.
  3. Check whether another basis fits better. Contract may fit processing that is objectively necessary to deliver what the person requested. Legal obligation fits a duty imposed by law. Consent fits a genuine free choice, especially where electronic marketing or terminal access rules already require consent. Public authorities performing their tasks cannot use Article 6(1)(f). 1
  4. Run the purpose test. Confirm the interest is lawful, precise, and present.
  5. Run the necessity test. Record the less restrictive alternatives considered and why they fail. Cut fields, recipients, or retention that the interest does not require.
  6. Run the balancing test. Record the relationship with the person, what the person was told, expected impact, child or vulnerability factors, and safeguards that go beyond baseline compliance.
  7. Check special category data and high risk. Article 6(1)(f) does not replace Article 9. If the use is likely high risk, complete a DPIA. An LIA can trigger that deeper assessment; a DPIA can also carry the legitimate-interests analysis in more detail. 5
  8. Build transparency and objection routes before launch. Tell people the lawful basis and the interests pursued. For direct marketing, prepare an immediate stop. For other legitimate-interests processing, prepare the Article 21 compelling-grounds analysis path. 6
  9. Set re-review triggers. Reopen the LIA when the purpose, data, recipients, model, audience, retention, or impact changes.
Direct marketing needs an extra legal layer. Recital 47 says marketing may be a legitimate interest, but the ePrivacy rules and national implementations still govern cookies, terminal access, and many electronic marketing messages. A GDPR legitimate-interests analysis leaves those consent requirements in force. 12

Rights that travel with the basis

When processing rests on Article 6(1)(f), Articles 13 and 14 require the controller to tell people the legitimate interests pursued. That disclosure has to be specific enough for a person to understand the stake being claimed. 1
Article 21 gives people the right to object, on grounds relating to their particular situation, to processing based on legitimate interests, including profiling. The controller must stop unless it demonstrates compelling legitimate grounds that override the person's interests, rights, and freedoms, or grounds related to legal claims. For direct marketing, including profiling related to direct marketing, the stop is absolute. 1
The ICO stresses that "compelling legitimate grounds" after an objection is a stronger showing than repeating the original balancing test. The controller should address the person's stated reasons. Choosing legitimate interests only to block data portability is itself a balancing problem; portability applies when the basis is consent or contract. 6
If the purpose changes, the controller still needs purpose limitation analysis. A fresh LIA helps show both that legitimate interests can support the new use on its own merits and that the new use is compatible where compatibility is required. 6

Common shortcuts and their repairs

ShortcutWhat remains unresolvedRepair
"We have a business interest, so Article 6(1)(f) applies."Is the interest precise, present, and lawful?Rewrite the interest as a concrete outcome held by the controller or a named third party.
"Recital 47 mentions marketing / fraud / security."Did necessity and balancing still pass for this design?Keep the recital as purpose support only, then complete the other two conditions.
"The privacy notice mentions legitimate interests."Can a reasonable person expect this use from the relationship and context?Test expectations against collection context, prior use, and actual impact; improve notice only as one factor.
"The vendor says the tool relies on legitimate interests."Did this controller assess its own purposes, recipients, and deployed configuration?Run the three conditions on the live workflow and contract scope.
"No less intrusive option fits our product."Is the interest defined around the product model instead of the outcome?Redefine the interest as the outcome, then compare designs that achieve that outcome.
"People can object later, so the balance is fine."Did the original processing already fail expectations or create high impact?Build safeguards and expectation alignment before launch; treat objection handling as a separate duty.
"We will switch to legitimate interests if consent fails."Was the basis identified and communicated from the start?Select and disclose the basis before processing; avoid after-the-fact switches except where a carefully justified change is possible and transparent. 4
"The LIA template is filled in."Does the record contain evidence for each condition?Require rejected alternatives, expectation evidence, impact analysis, and safeguard owners.

The reviewer record

An LIA is the accountability record for Article 6(1)(f). The GDPR leaves the form open. The ICO still expects controllers to keep an audit trail of the three-part test because accountability requires the controller to show why the basis applies. 25
Keep these fields for each processing activity that relies on legitimate interests:
  • Processing action: systems, data fields, sources, recipients, retention, and the decision or communication produced
  • Interest: precise interest, holder (controller or named third party), benefits, and consequence if the processing does not occur
  • Purpose test outcome: why the interest is lawful, present, and specific
  • Necessity test outcome: why the processing helps achieve the interest; less restrictive alternatives considered and rejected; data-minimisation cuts made
  • Balancing test outcome: relationship and reasonable expectations; nature of the data; impact and likelihood; child or vulnerability factors; safeguards beyond baseline compliance; final override judgment
  • Transparency: the wording used to describe the interests; where people see it; when it was last updated
  • Rights handling: objection channel; direct-marketing stop if relevant; compelling-grounds process owner; link to erasure, access, and restriction handling
  • Adjacent controls: Article 9 or criminal-data conditions if any; DPIA reference; ePrivacy or sector rules; vendor instructions
  • Review triggers: purpose change, new data or recipients, model or threshold change, complaint patterns, objection volume, incident, or regulatory development
  • Decision: rely / redesign / choose another basis / do not process, with owner and date
The decisive record is the chain from a named interest to a designed processing path to a reasoned balance. A filled template that only restates "we have a legitimate interest in running our business" leaves the same gap the enforcement cases keep finding. A record that shows the rejected alternatives, the expectation analysis, and the safeguards that actually operate gives the organisation a basis for approving the use, defending an objection, or deciding that another lawful basis—or no processing—is the honest answer.

This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.

Related content

More from this channel