When Legitimate Interests Assessments Applies and What to Do Next

A legitimate interests assessment applies when a SaaS team wants to rely on legitimate interests as the lawful basis for a specific processing activity. The practical question is not "can we write legitimate interests in the privacy notice?" The question is whether the team has identified a real interest, shown that the processing is necessary for that interest, balanced it against the rights and freedoms of the people affected, and recorded the safeguards that make the decision defensible.

Article 6(1)(f) GDPR allows processing where it is necessary for the legitimate interests pursued by the controller or a third party, unless the interests or fundamental rights and freedoms of the data subject override those interests. Recital 47 points teams toward reasonable expectations, the relationship between the person and the controller, fraud prevention, and direct marketing as context that may be relevant. The EDPB and ICO both frame this as a structured assessment, not a shortcut around consent or contract.

For SaaS teams, the next step is to turn the assessment into an operating workflow: define the trigger, name the owner, describe the processing activity, run the purpose, necessity, and balancing tests, document the decision, and connect any safeguards to implementation evidence.

If you need the broader basis first, see the lawful basis guide. If the assessment touches product design, it should also connect to data protection by design and default, privacy impact reviews during product planning, and data minimisation.

When the assessment applies

An LIA applies when the business is considering legitimate interests for personal-data processing. It should usually happen before the processing starts, not after the feature is already live. If the workflow already exists, the team should still document the reasoning, but it should treat the missing assessment as a remediation item rather than normal practice.

Common SaaS triggers include account-security monitoring, fraud prevention, abuse detection, product reliability analytics, customer-success workflows, support-ticket analysis, limited B2B marketing, internal administration, vendor integrations, retention changes, and AI-assisted review of operational records. These activities can be legitimate in the ordinary sense and still fail the GDPR test if the processing is too broad, too surprising, poorly explained, or not actually necessary.

The assessment also applies when an existing workflow changes. A team may have assessed support-ticket handling for customer service, but not for training an internal classifier. A security log may have been justified for incident response, but not for long-term behavioral analytics. A CRM workflow may have been assessed for service communication, but not for cross-sell campaigns. The moment the purpose, data, audience, vendor, retention period, or user expectation changes, the old answer may no longer be enough.

When it may not be the right path

Legitimate interests is not the right answer merely because consent is inconvenient or contract feels narrow. If another lawful basis fits the activity better, start there. If special category data, children's data, employee monitoring, intrusive profiling, automated decisions, or unexpected secondary use is involved, the assessment needs more care and may point away from Article 6(1)(f).

An LIA also does not replace a data protection impact assessment. If the processing is likely to create high risk for people, the team may need a DPIA as well. In practice, the LIA can feed the DPIA, but it should not be used as a lighter substitute when the risk profile calls for deeper analysis.

What to do next

Start by naming the processing activity narrowly. "Improve the platform" is too broad. "Use aggregated support-ticket themes to prioritize documentation updates" is a workable activity. "Detect suspicious login behavior to protect customer accounts" is clearer than "security monitoring." A narrow description helps the team test necessity and user expectations instead of arguing over a vague purpose.

Next, write the legitimate interest in plain language. The interest should be lawful, specific, real, and present. It should explain who benefits and why the processing supports that benefit. For example, protecting accounts from takeover, keeping the service reliable, preventing fraud, or responding to customer support requests can be easier to assess than a general claim of business efficiency.

Then test necessity. Ask whether personal data is actually needed for the purpose and whether a less intrusive route would work. Can the team aggregate the data? Can it shorten retention? Can it reduce fields? Can it pseudonymise records? Can it limit access? If a less intrusive approach achieves the same purpose, the original design is harder to defend.

After that, run the balancing test. Consider the nature of the data, the relationship with the user, how the data was collected, whether the person would reasonably expect the processing, the possible impact, the scale of processing, the sensitivity of the context, and whether vulnerable people may be affected. Safeguards matter here, but they need to be real controls, not optimistic language.

Finally, record the decision and link it to evidence. A useful record includes the owner, activity, purpose, interest, data categories, data subjects, systems, vendors, alternatives considered, balancing factors, safeguards, privacy notice impact, retention, approval, and review trigger. The record should be close enough to the product, security, vendor, or compliance workflow that the team can find it during a customer review.

Evidence that makes the answer credible

Strong evidence is usually simple. It may include a data-flow note, product ticket, vendor review, privacy notice update, access-control screenshot, retention rule, DPIA screening, risk acceptance, suppression control, or implementation ticket. The point is to show that the assessment changed or confirmed the operating reality.

For example, if the LIA depends on short retention, link the retention configuration. If it depends on limited access, link the access model. If it depends on notice, link the privacy notice update. If it depends on aggregation, show where aggregation happens. Without that evidence, the LIA becomes a memo about a system the business may not actually operate.

The record should also make the review trigger visible to the teams that can change the workflow. Product should know when a feature change reopens the assessment. Security should know when a logging or monitoring change changes the balance. Operations should know when a new vendor, export, or retention rule needs review. Compliance should not be the only team that remembers the assessment exists.

Common mistakes

The first mistake is starting with the desired basis instead of the processing activity. Teams sometimes decide that legitimate interests sounds flexible and then work backward. That produces weak records because the purpose, necessity, and balance were never tested honestly.

The second mistake is using broad interests. "Business operations" and "product improvement" can hide many different activities. A reviewer should be able to understand the interest without joining the original meeting.

The third mistake is ignoring reasonable expectations. A user may expect security monitoring or service reliability logging. The same user may not expect broad enrichment, long retention, cross-context reuse, or AI analysis of support conversations. Expectation is not the only factor, but it is often where SaaS teams discover the biggest gap.

The fourth mistake is treating safeguards as promises. If the balancing test relies on role-based access, opt-out handling, short retention, aggregation, notice, or human review, those controls need owners and proof.

The fifth mistake is forgetting review triggers. An LIA should be reopened when the purpose changes, data categories expand, a new vendor joins, retention grows, a new AI use appears, or the audience changes.

FAQ

What is the practical purpose of legitimate interests assessments?

The practical purpose is to turn Article 6(1)(f) into a documented operating decision. The team should know what interest it is pursuing, why personal data is necessary, why the balance is fair, and which safeguards must stay in place.

When does legitimate interests assessments apply to SaaS teams?

It applies when a SaaS team wants to rely on legitimate interests for a personal-data workflow, such as security monitoring, fraud prevention, service analytics, support operations, limited B2B outreach, or internal administration.

What should teams document or change first?

Start with the processing activity, purpose, interest, necessity reasoning, balancing factors, safeguards, owner, approval, and review trigger. Then connect the decision to implementation evidence so the assessment can be defended later.

Sources

• General Data Protection Regulation, Article 6 and Recital 47
• EDPB: Guidelines 1/2024 on processing based on Article 6(1)(f)
• ICO: How do we apply legitimate interests in practice?