Common Legitimate Interests Assessments Mistakes SaaS Teams Still Make

The most common mistake with legitimate interests assessments is treating the outcome as obvious before the assessment starts. Article 6(1)(f) GDPR can be useful for SaaS teams, but it is not a shortcut around lawful-basis analysis. The team still has to identify a legitimate interest, show that the processing is necessary, and assess whether the interests, rights, or freedoms of the person override that interest.

For SaaS companies, the operational risk is usually not that nobody has heard of an LIA. The risk is that the LIA appears too late, sits in a legal folder, uses vague language, or fails to change how the product, logs, vendors, retention, notices, and access controls actually work.

The mistakes below show up in product analytics, fraud prevention, account security, B2B contact handling, support operations, enrichment, AI-assisted workflows, and internal monitoring. Fixing them makes legitimate interests easier to defend and easier for delivery teams to run.

Mistake 1: Treating Legitimate Interests as the Flexible Default

Legitimate interests is flexible, but flexibility is not the same as default status. The EDPB guidance frames Article 6(1)(f) around cumulative conditions: a legitimate interest, necessity for that interest, and a balance that does not favour the data subject's interests or fundamental rights and freedoms. Skipping straight to "we have a business interest" misses the legal test.

This mistake often happens when consent feels inconvenient, contract does not quite fit, or a team wants to avoid changing the user experience. That is backwards. The right lawful basis should follow the processing context, not the easiest implementation path.

The practical fix is to require a short basis-selection step before the LIA. Ask whether contract, legal obligation, consent, vital interests, public task, or another basis is more appropriate. If legitimate interests remains the candidate, record why. That record helps later when customers, auditors, or privacy reviewers ask why the team did not use consent or contract.

Mistake 2: Writing a Purpose That Is Too Broad

A broad purpose makes the rest of the assessment weak. "Improve the product," "support customers," "run analytics," and "protect the platform" may describe business themes, but they do not let reviewers test necessity or balance.

The purpose should describe the actual activity. For example, "use aggregated onboarding event counts to identify where account administrators abandon setup" is easier to assess than "improve onboarding." "Process login metadata for 30 days to detect credential stuffing and suspicious access attempts" is stronger than "security monitoring."

Specificity also helps engineering. A narrow purpose can translate into event names, fields, retention settings, access groups, and dashboard limits. A vague purpose usually becomes overcollection because nobody knows where the boundary is.

Mistake 3: Skipping the Necessity Test

Necessity is where many SaaS LIAs become thin. Teams describe the business reason for processing but do not show why the chosen data use is necessary for that reason. Under Article 6(1)(f), the processing must be necessary for the legitimate interest pursued. It is not enough that the data would be helpful.

The assessment should test less intrusive options. Could the team use aggregate metrics instead of user-level events? Could it shorten log retention? Could it remove free-text content? Could it use pseudonymised identifiers, sampled logs, narrower vendor access, or role-based dashboards? Could the first launch run with a smaller dataset and review expansion later?

This step should produce evidence, not just a sentence. Record the alternatives considered and the decision. If the team chooses identifiable processing, explain why aggregate or less intrusive approaches would not meet the purpose. This is one reason data minimisation for SaaS and LIA work should be connected.

Mistake 4: Ignoring Reasonable Expectations

Recital 47 points teams toward reasonable expectations based on the relationship between the person and the controller. This is where many product teams underestimate privacy risk. Users may expect basic account-security logging. They may not expect detailed behavioural monitoring, model training on support content, broad internal dashboards, or enrichment from third-party sources.

Reasonable expectations depend on context. A customer administrator, end user, employee, prospect, support requester, and billing contact may have different expectations even inside the same SaaS product. The fact that data exists in the system does not mean every internal reuse is expected.

The practical fix is to document the relationship, collection context, notice language, user-facing controls, and likely surprise. If the processing would surprise a reasonable person in that context, the team needs stronger safeguards, a different design, clearer notice, or a different lawful basis.

Mistake 5: Treating Safeguards as Promises Instead of Tasks

An LIA often says that risk is reduced through limited access, short retention, aggregation, pseudonymisation, opt-out controls, notice updates, or vendor restrictions. Those safeguards matter only if they become implemented controls.

The mistake is approving the assessment while leaving safeguards as narrative. A sentence that says "access will be limited" is weaker than a linked access group, owner, approval record, and review date. A promise of 90-day retention is weaker than a configuration, ticket, or deletion job the team can show.

Build a habit of converting every safeguard into an implementation task or evidence link. Product may need to change defaults. Engineering may need to remove fields or shorten logs. Security may need to restrict a group. Legal may need to update the privacy notice. Compliance may need to store the record. This is where data protection by design and default becomes operational rather than theoretical.

Mistake 6: Starting the LIA After the Feature Is Built

Late LIAs create weak decisions. Once the data model, vendor integration, dashboard, or model workflow already exists, the assessment becomes a negotiation over whether the team can keep what it built. That pressure makes it harder to choose the least intrusive design.

The LIA should start when the team still has choices. It belongs in product intake, launch review, vendor review, analytics intake, security monitoring changes, and AI workflow review. The first trigger does not need to be complex. A simple question such as "Are we considering legitimate interests for personal data processing?" can route the work early.

This also reduces delivery friction. Early review can narrow a data set before engineering invests in it. Late review often creates rework, launch delay, customer-review anxiety, and messy exceptions. This is why privacy impact reviews should start in product planning, not after launch.

Mistake 7: Forgetting ePrivacy, Marketing, and Local Rules

A legitimate interests analysis under GDPR does not automatically solve every privacy or communications issue. Cookies, tracking technologies, direct marketing, electronic communications, and national rules may require separate analysis. A team can have a plausible Article 6(1)(f) argument and still need consent or another step under ePrivacy-style rules.

This mistake shows up in product analytics, lifecycle marketing, B2B contact enrichment, and retargeting. Teams document a GDPR lawful basis but skip the separate channel, tracking, or local-law question.

The fix is to add a short adjacent-rules check. Ask whether the activity involves cookies or similar technologies, direct electronic marketing, sensitive categories, employment monitoring, children, regulated sectors, or international transfers. If yes, route the issue to the right policy owner instead of pretending the LIA answers everything.

Mistake 8: Not Recording Negative or Conditional Decisions

Teams often record approvals but lose the more useful decisions: no, not on legitimate interests; yes, but only after safeguards; or not yet, because more facts are needed. These decisions are valuable evidence. They show that the workflow can stop or reshape processing rather than simply approve it.

Conditional decisions need tracking. If the team can proceed only after notice language is updated, retention is shortened, an opt-out is added, or user-level data is replaced with aggregate metrics, the LIA should stay open until those tasks are complete.

Negative decisions should also be searchable. If one team decides that a certain enrichment source is too surprising or that consent is needed for a tracking use case, future teams should not repeat the same debate from scratch.

Mistake 9: Letting Old LIAs Drift

SaaS products change continuously. A processing activity approved for one purpose can expand through new dashboards, longer retention, new vendors, support automation, AI features, exports, or broader internal access. The original balancing test may no longer reflect the real processing.

Every LIA should have review triggers. Reopen it when the purpose changes, new data categories are added, retention increases, new vendors touch the data, access broadens, a model is introduced, users receive a materially different experience, or the privacy notice no longer matches reality.

Also set a cadence. Lower-risk stable processing may be reviewed annually. Security monitoring, fraud prevention, enrichment, AI-assisted support, and user-level analytics may need more frequent review or review at major release points.

Mistake 10: Storing the Record Away From Evidence

An LIA that lives in isolation is hard to use. During enterprise security reviews, audits, and regulator questions, teams need the decision plus the supporting evidence: product brief, data-flow notes, vendor review, access configuration, retention controls, notice updates, DPIA screening, risk acceptance, and implementation tickets.

Store the LIA where operational teams can find it. Link it to the product or vendor record, the launch checklist, the control map, and the customer evidence workspace. The record does not need to be long, but it should point to proof.

This also reinforces why GDPR is not just cookie banners. Legitimate interests is not a policy-only issue. It touches architecture, data minimisation, access, customer commitments, and evidence quality.

Example: Analytics Request Done Poorly and Well

A poor LIA says: "We have a legitimate interest in improving the product. We will process user analytics. Risk is low. Approved." That record does not explain the purpose, necessity, expected user reaction, safeguards, retention, access, or alternatives.

A stronger version says: "Product wants to understand where account administrators abandon onboarding. The first release will use aggregated step counts, not user-level behavioural dashboards. Diagnostic logs will retain identifiers for 30 days only for troubleshooting. Access is limited to product analytics and platform engineering. The team rejected broad event capture because aggregate metrics answer the current question. Review is required before any user-level analysis or enrichment."

The second record is not much longer, but it is far more useful. It gives engineering boundaries, gives compliance evidence, and gives legal a basis for review. It also creates a reusable pattern that later teams can adapt without treating every analytics request as new territory.

FAQ

What should teams understand about Legitimate Interests Assessments?

Teams should understand that an LIA is a decision workflow, not a label. It should test purpose, necessity, balance, safeguards, ownership, and review triggers for a specific processing activity.

Why does Legitimate Interests Assessments matter in practice?

It matters because it helps SaaS teams make lawful-basis decisions early enough to influence product design, vendor choices, retention, access, notices, and customer-review answers.

What is the biggest mistake teams make with Legitimate Interests Assessments?

The biggest mistake is treating legitimate interests as the easy default. A defensible LIA should show why that basis fits the specific processing and how the team reduced the impact on people.

Sources

• European Union, General Data Protection Regulation, Article 6 and Recital 47.
• European Data Protection Board, Guidelines 1/2024 on processing of personal data based on Article 6(1)(f) GDPR.
• Information Commissioner's Office, detailed guidance on legitimate interests, updated 23 March 2026.