When a Legitimate Interest Assessment Falls Apart

A legitimate interest assessment can look perfectly respectable while quietly failing its own test. The usual warning sign is a sentence like "we need all this data to improve the service", followed by several pages explaining why the organisation would rather not change anything.

An LIA is a decision tool, not a permission slip. It should tell you whether a particular use of personal data is justified. If it only records the decision that somebody wanted, it is paperwork with better typography.

The three tests are separate for a reason

Under Article 6(1)(f) of the UK GDPR, legitimate interests requires processing to be necessary for a legitimate interest, unless the person's interests or fundamental rights and freedoms override it. The ICO breaks that into three questions: purpose, necessity and balancing.

The tests are cumulative. Passing one does not rescue a failure in another. A worthy objective does not make excessive data collection necessary, and necessary processing does not automatically win the balancing test.

• Purpose: what legitimate interest is being pursued?
• Necessity: is this use of personal data needed to achieve that interest?
• Balancing: do the person's interests, rights and freedoms override it?

The ICO describes the LIA as a way to document this reasoning, although the UK GDPR does not prescribe a particular form. Its guidance is a useful starting point for the process and the questions each stage should answer.

The ICO's practical LIA guidance also makes an important timing point: do the assessment before processing starts. Retrofitting a justification after launch is not quite the same thing.

Purpose fails when it is really a shopping list

A legitimate interest needs a specific outcome. "Business improvement", "better personalisation" and "operational efficiency" may describe a department's ambitions, but they do not explain why this processing is justified.

Imagine a company wants to retain every customer support chat forever. The proposed LIA says the purpose is "improving the product, training staff, detecting fraud and understanding customer behaviour". That is not one purpose. It is a bundle of different projects, each with different data requirements and risks.

Split the purposes before assessing them. Product research might need a sampled, redacted dataset. Fraud detection might need recent account and payment signals. Staff training might need fabricated examples. Treating all three as one interest makes the collection look inevitable when it is not.

A good purpose statement says who benefits, what outcome is expected and what would happen if the processing did not take place. It should be possible to point at a field in the database and explain which purpose needs it.

Necessity fails when the database is doing the thinking

"Necessary" does not mean absolutely indispensable, but it does require a targeted and proportionate use of personal data. The ICO says you cannot rely on legitimate interests where the same result can reasonably be achieved in a less intrusive way.

This is where many assessments become circular. The organisation chooses a design that stores everything, then argues that storing everything is necessary because the chosen design expects everything to be available. That is necessity by architecture.

Ask the awkward engineering questions:

• Can the purpose be met with fewer fields?
• Can identifiers be removed, hashed or replaced with a short-lived token?
• Can the data be sampled instead of collected continuously?
• Can aggregation happen before the data leaves the system?
• Can a shorter retention period answer the same question?

Suppose product managers need to know which support topics are increasing. They may need categories, dates and rough product versions. They probably do not need message bodies containing health information, relationship problems or account recovery details.

Quick detour: pseudonymisation is not the same as anonymisation. Replacing a name with an internal customer ID can reduce exposure, but it still leaves personal data if the organisation can reconnect the ID to a person. It is a safeguard, not a magical exit from data protection law.

Balancing fails when expectations are treated as a footnote

The balancing test asks what the processing means for the people involved. That includes their reasonable expectations, the nature of the information, the relationship with the organisation, the likely impact and the safeguards applied.

Reasonable expectations are about context, not whatever the privacy notice technically permits. Someone who contacts a support team may expect the message to be used to solve their problem. They may not expect it to be copied into a permanent employee-training archive or used to build behavioural profiles.

The more surprising the use, the more work the organisation has to do. A broad sentence in a privacy notice does not automatically make an unexpected use reasonable. Nor does the fact that the information was supplied voluntarily make every later use fair.

Look particularly closely at:

• information about health, finances, children or criminal allegations;
• monitoring that affects employment, access or reputation;
• profiling that can change what someone is offered or allowed to do;
• uses involving people with little ability to refuse;
• processing that is difficult to see, challenge or escape.

Safeguards matter, but they are not decorative mitigation. Access controls, redaction, retention limits, human review and a real objection process can reduce the impact. They cannot turn an unjustified purpose into a justified one.

An objection can expose a weak assessment

Article 21 of the UK GDPR gives people a right to object to processing based on legitimate interests, on grounds relating to their particular situation. The controller must stop unless it can demonstrate compelling legitimate grounds that override the person's interests, rights and freedoms, subject to the legal details of the particular case.

That is not the same as a universal deletion button. It is, however, a useful stress test. If the organisation cannot explain why a particular person's circumstances do not change the balance, the original assessment may have been too generic.

Direct marketing has its own objection rule, and electronic marketing can also be restricted by PECR. An LIA does not override those separate requirements. Calling something a legitimate interest does not make an unsolicited marketing message lawful.

Repair the assessment instead of defending the spreadsheet

When an LIA falls apart, the answer is usually to reduce the processing, narrow the purpose or choose another lawful basis. The answer is not to add more adjectives to the conclusion.

1. Rewrite the purpose as one concrete outcome.
2. Map each data field to that outcome and remove fields without a clear job.
3. Test realistic alternatives, including aggregation, sampling and shorter retention.
4. Describe the person's experience, not just the organisation's benefit.
5. Record the safeguards as operating controls with owners and review dates.
6. Revisit the assessment when the purpose, data, technology or context changes.

A useful final question is simple: would you still choose this processing if you had to explain it to the affected person in one honest paragraph, before collecting their data? If the explanation needs a small legal orchestra and several euphemisms, the balancing test may already have given you its answer.