Key takeaways

Legitimate interests is one of the lawful bases in Article 6(1) of the GDPR. It can support some personal-data processing, but only after a careful, documented assessment. It is not a universal alternative to consent.

Updated: 29 August 2026 · Last reviewed: 29 August 2026

For cookies and similar technologies, ask a different question first: does the activity store information on, or access information from, a visitor's device? If it does, the ePrivacy rule implemented in the relevant country normally requires prior consent unless it is necessary to carry a communication or is strictly necessary for the service the visitor requested. A GDPR legitimate-interest assessment does not remove that separate device-access requirement.

That means a legitimate-interest toggle in a preference centre may relate to later GDPR processing in a particular ad-tech framework; it does not, by itself, authorise non-essential device storage or access. Where an Article 5(3) exception or verified national exemption means a consent mechanism is not required for a particular operation, information duties under national law and GDPR transparency and lawful-basis requirements can still apply. Work through both legal regimes and the countries you serve. If consent is the appropriate route, obtain it before the relevant non-essential device operation and make withdrawal straightforward.

Two legal questions, in sequence

  1. Question one

    Does the activity store information on, or access information from, a device?

    Assess the applicable national ePrivacy implementation and the technology’s actual behaviour. If Article 5(3) is engaged, consider whether either narrow concept is relevant: solely carrying a communication, or strict necessity for a service the visitor explicitly requested.

    Do not substitute labels for facts. “Analytics,” “essential,” or “legitimate interest” does not by itself answer the device-access question.
  2. Question two

    Does later activity process personal data?

    Where GDPR applies, identify the processing, roles, purpose, recipients, retention, transparency duties, and an appropriate Article 6 lawful basis. Legitimate interests requires its own interest, necessity, and balancing assessment.

    Keep the paths distinct. A GDPR lawful-basis analysis does not itself answer the earlier device-storage or access question.
Review note: national law, regulator guidance, configuration, and the facts of each operation may change the analysis. An LIA records reasoning; it is not an automated approval or a banner-bypass mechanism.
Illustrative review path only. It does not decide whether a technology is exempt, whether consent is required, or whether legitimate interests is available for any processing.

The short answer to “can I use legitimate interests for cookies?”

Usually, no—not as a shortcut around the cookie-consent requirement.

The confusion is understandable. A website owner sees Article 6 of the GDPR list six possible lawful bases for processing personal data. Consent is only one of them. Article 6(1)(f) also permits processing where it is necessary for the controller's or a third party's legitimate interests, except where those interests are overridden by the interests or fundamental rights and freedoms of the individual.

But a tracker can raise more than one legal question. A marketing pixel may access the browser, create or read an identifier, transmit information, and feed later audience-building or measurement. The GDPR lawful basis is important for personal-data processing. Yet the initial act of storing or accessing information on a device is commonly governed by the ePrivacy framework as implemented nationally.

Article 5(3) of the ePrivacy Directive sets the familiar starting point: the user must receive clear and comprehensive information and have given consent before information is stored on, or accessed from, their terminal equipment. Its exceptions cover storage or access solely to carry a communication over an electronic communications network, or where strictly necessary to provide an information-society service explicitly requested by the user.

“We have a business reason for analytics” is not the same as “strictly necessary for the service the visitor requested.” Nor does a positive result under Article 6(1)(f) make the ePrivacy question disappear.

Use the two-door test

For an EU-facing site, treat this as two doors. The order matters.

Door one: device storage or access under ePrivacy rules

First identify whether the technology stores information on the device or reads information already there. The label does not decide this. Cookies are the best-known example, but browser storage, pixels that read identifiers, SDK identifiers, and fingerprinting techniques can also require assessment.

If there is device storage or access, identify the national ePrivacy rule that applies and whether an exception is genuinely available. For a typical non-essential analytics, advertising, social-media, personalisation, or session-recording technology, consent is the practical starting point. It should be obtained before the technology runs.

The “strictly necessary” exception is functional and narrow. It can cover examples such as an authentication session, shopping-cart memory, a security measure, load balancing, or a record of the visitor's cookie choice, when needed for the requested service. It does not turn a commercial preference into necessity. Advertising, cross-site measurement, and audience creation ordinarily need much more than an assertion that they help fund or improve a website.

Door two: GDPR personal-data processing

Then assess the personal-data processing. If an IP address, online identifier, account data, or information linked to a person is processed, GDPR obligations apply alongside the ePrivacy rules. The controller needs an Article 6 lawful basis, transparency information, appropriate retention, security, and the other applicable GDPR measures.

Consent may be the GDPR basis for processing tied to non-essential tracking. Legitimate interests can sometimes be the GDPR basis for a separate processing operation—for example, proportionate security monitoring or responding to an individual request—provided the Article 6(1)(f) test is met. The answer depends on the actual purpose, data, expectations, safeguards, and impact, not on a category label in a consent platform.

In Opinion 5/2019, the European Data Protection Board explained the interplay between the ePrivacy Directive and GDPR, including the competence of data-protection authorities. In practice, do not use a GDPR basis as a way to sidestep the more specific device-access rule.

What Article 6(1)(f) really requires

Legitimate interests is not a box to tick because consent may reduce marketing reach. Article 6(1)(f) has three connected parts:

  1. Identify a legitimate interest. It must be real, present, and lawful. The GDPR does not provide a fixed list.
  2. Show necessity. Ask whether the processing is necessary for that interest and whether a less intrusive, reasonably effective way exists.
  3. Balance the interests. Weigh the controller's or third party's interest against the individual's interests, rights, and freedoms. If the individual's side prevails, Article 6(1)(f) is unavailable.

The controller must be able to demonstrate its assessment under GDPR accountability principles. Many organisations capture this in a legitimate interests assessment (LIA). An LIA is useful evidence of reasoning; it is not approval from a regulator and it cannot create an ePrivacy exemption.

A practical LIA structure

For each distinct processing purpose, document the following:

Question What to record
What is the interest? The specific operational interest, who has it, and why it is lawful.
Is processing necessary? The data used, why it helps, and realistic less intrusive alternatives considered.
What will people reasonably expect? Their relationship with you, what they were told, and whether the use is surprising.
What is the impact? Potential privacy, discrimination, profiling, exclusion, or loss-of-control effects.
Which safeguards reduce the impact? Data minimisation, short retention, access controls, pseudonymisation, and an effective objection route.
What is the conclusion? Why the interest is not overridden, who approved it, and when it will be reviewed.

Do not reuse one broad LIA for every vendor, purpose, and country. A basic server-security log and a cross-site advertising profile present different necessity and impact questions. If you materially change the purpose, data sources, recipients, or technology, revisit the assessment.

Consent under the GDPR must be freely given, specific, informed, and unambiguous. It must be demonstrable, and withdrawing it must be as easy as giving it. For a website, that calls for clear information and a choice that is put into effect technically—not merely a banner that appears after trackers have loaded.

Legitimate interests has a different structure. It does not require an affirmative “yes,” but it does require the three-part Article 6(1)(f) analysis and an Article 21 right to object. The controller must tell people about the legitimate interests pursued, generally through its privacy information.

There is an important practical distinction:

  • Withdrawal of consent: a person takes back permission. The controller must stop the consent-based processing unless another lawful basis applies to a distinct operation.
  • Objection to legitimate interests: a person objects to processing based on Article 6(1)(e) or (f). The controller must stop unless it demonstrates compelling legitimate grounds that override the person's interests, rights, and freedoms, or the processing is for legal claims.

For direct marketing, Article 21 is stronger. A person may object at any time to processing of personal data for direct-marketing purposes, including related profiling, and the data must no longer be processed for those purposes. Recital 47 says processing for direct-marketing purposes may be regarded as carried out for a legitimate interest. It is not a blanket finding that every marketing use passes Article 6(1)(f), and it does not displace ePrivacy marketing and device-access rules.

In other words, Recital 47 is a starting point for analysis, not a permission slip for advertising cookies or unsolicited electronic marketing.

Consent is not automatically the safest basis. It is inappropriate where people cannot freely refuse without a real disadvantage, or where the organisation cannot genuinely offer a meaningful choice. Public authorities, employers, and organisations in other imbalanced relationships should examine this especially carefully.

Consent also makes little sense for a processing activity that is necessary to perform a contract with the visitor, to meet a legal obligation, or to protect against an immediate security threat, where another GDPR basis correctly describes the purpose. Choosing consent where it cannot be freely given creates a fragile basis and can confuse the person about their rights.

This does not create a route to place non-essential tracking technology. Separate the questions:

  • Is there a valid GDPR basis for the personal-data processing?
  • Is consent required before device storage or access under the applicable ePrivacy implementation?
  • Are there additional rules for electronic direct marketing in the relevant country?

A small business may have legitimate interests in keeping its systems secure, preventing fraud, maintaining service quality, or making limited improvements. It should still assess the specific processing and ensure that tags or identifiers used to pursue that interest do not trigger a separate consent requirement.

Some consent-management interfaces show both “consent” and “legitimate interest” purposes. This can be part of an industry framework designed to communicate GDPR processing bases between participants. It does not mean every purpose listed under legitimate interests may set a cookie before a choice.

Review the interface and its technical behaviour separately:

  1. Which vendors, scripts, cookies, storage calls, and embeds run before the visitor acts?
  2. Which activity is claimed to be strictly necessary, and why is it necessary for the requested service?
  3. Which later personal-data processing uses consent, legitimate interests, or another GDPR basis?
  4. Can visitors find and exercise the relevant right—withdrawal for consent, objection for legitimate interests—without unnecessary friction?
  5. Do the policy, banner, vendor list, and actual tag configuration say the same thing?

The Court of Justice of the European Union's IAB Europe ruling illustrates why legal roles, data flows, and accountability need careful analysis. It clarified, among other matters, that TC String information can be personal data and that IAB Europe can be a joint controller for certain processing connected with the creation and use of that string. The ruling does not establish that every website using a framework has the same facts or outcome. It does show that labels and framework participation do not eliminate the need to examine the processing.

Analytics: where the answer can be more nuanced

Analytics is often the reason a business asks about legitimate interests. The business wants basic traffic information, not behavioural advertising. That distinction matters, but it does not automatically produce a cookie exemption.

Start with the technology. A genuinely cookieless, non-fingerprinting measurement setup may avoid the particular device-storage/access question. It may still process personal data, so the GDPR analysis remains. Configuration matters: “privacy-friendly” is not a legal category.

Some national authorities describe narrow exemptions for limited audience measurement under their national ePrivacy implementation. Conditions can concern first-party operation, limited purposes, short retention, absence of cross-site tracking, restricted sharing, and the ability to object. France's CNIL, for example, publishes conditions and a list of exempt audience-measurement solutions. Dutch guidance also addresses analytical cookies and privacy-friendly configurations. These are national approaches with detailed conditions, not an EU-wide exemption you can assume travels with your visitors.

Standard analytics deployments can involve cookies, device identifiers, data sharing, advertising features, or other uses that fall outside an exemption. Do not rely on product branding, a “server-side” label, or a vendor's general marketing claim. Map what your configuration actually does.

Sending events through your own server can change architecture, security controls, and what third parties receive directly from the browser. It does not automatically make tracking necessary, anonymous, exempt, or consent-free. If a browser still stores or reads identifiers, or the server receives data for non-essential measurement or advertising, assess both doors again.

For a useful technical starting point, see our guide to auditing website cookies. Check the first page load in a clean browser session, then test after acceptance and rejection. A scanner can help find technologies and timing issues, but its results are diagnostic only; they do not determine whether a legal basis or exemption applies.

A decision path for a small-business website

Use this process for each tracker, embed, or category. It is a review method, not legal advice or a declaration of compliance.

List scripts from your website, tag manager, plugins, checkout provider, chat tool, video host, social widgets, analytics, and advertising platforms. Include cookies, local storage, pixels, and browser identifiers. Record the pages on which they load and the recipients.

Run a free cookie scan if you need a starting inventory. Then confirm the findings with your developer or provider documentation. Scan results can reveal a problem worth investigating; they cannot certify that your website complies with every applicable rule.

2. Test the no-choice state

In a fresh browser profile, visit the pages that matter: homepage, checkout, campaign landing pages, and pages with embeds. Before clicking the banner, observe storage, requests, and scripts. If a non-essential device-storage or access operation occurs before the required consent, a legitimate-interest statement in a policy does not cure that separate issue. Investigate whether the operation is within an Article 5(3) exception or a verified national exemption before reaching a conclusion.

3. Apply the ePrivacy question

For each technology that accesses or stores device information, ask first whether it is solely for carrying a communication or strictly necessary for a service the visitor explicitly requested. Document the actual service and function. If neither exception clearly applies, plan for prior consent unless a carefully verified national exemption applies.

Read what the ePrivacy Directive means for cookies for the underlying framework, and use our cookie consent decision guide to structure the broader review.

4. Apply the GDPR question

Identify personal data, controller and processor roles, recipients, purpose, retention, and the Article 6 basis for each processing operation. If relying on Article 6(1)(f), complete and retain an LIA. Tell people about the legitimate interests pursued and provide a simple way to object where applicable.

5. Implement and test the choice

Where consent is required, block non-essential technologies until the visitor makes a valid choice. Test refusal as carefully as acceptance, including on mobile. A visitor who withdraws consent should be able to do so easily, and the site should honour the change. See how to block cookies before consent for the implementation questions to raise with your team.

Common mistakes to avoid

Revenue, reporting, conversion optimisation, and advertising may be important business activities. The strict-necessity test asks whether the technology is necessary for the service the individual explicitly requested. Those are different standards.

Treating a vendor's default configuration as an exemption

Features, data routes, and defaults change. Review the configuration you actually use, including tag-manager settings and embedded third-party content. Re-check after a marketing campaign, redesign, new plugin, or vendor change.

Combining every activity under one lawful basis

One customer journey can contain distinct processing operations. Contract performance for an order, fraud prevention, consented analytics, and direct marketing may call for different analyses. A single sentence saying “we use legitimate interests” rarely explains enough.

Forgetting country and audience differences

The ePrivacy Directive is implemented through national law, and supervisory guidance can differ. The UK has its own Privacy and Electronic Communications Regulations alongside UK GDPR. If you serve multiple markets, avoid copying a country-specific analytics position into every jurisdiction. Our cookie consent by country guide can help you identify questions for local review.

A proportionate next step

You do not need to solve every theoretical issue before improving the basics. Start by finding what runs before a visitor chooses, separating essential functionality from analytics and marketing, and documenting why each item is there. Then review the GDPR basis and ePrivacy position with advice appropriate to your jurisdictions where the answer is unclear.

If your review shows non-essential trackers loading before a choice, address the technical implementation first. If you need a consent-management workflow, compare the options and see ConsentEase pricing. The goal is a repeatable process that helps your team discover and control tracking—not a promise that software alone settles every legal question.

Sources