How to run LIA assessments with operational control: three-part decision record, necessity testing, balancing test and connected governance across ROPA and DPIA.
Topics: Legitimate Interests, LIA, GDPR, Privacy Operations, Privacy Governance
A legitimate interests assessment should not begin with a template. It should begin with the processing activity: what data is being used, for whose benefit, and whether the proposed use is genuinely necessary. Organisations learning how to run LIA assessments often focus on completing the three-part test, but the more durable objective is to create a decision record that remains defensible when the processing, risk profile, supplier landscape or regulatory expectations change.
An LIA is not a substitute for a lawful basis decision made in isolation. It is the structured evidence behind relying on legitimate interests under the GDPR or UK GDPR. For privacy teams managing hundreds of processing activities across jurisdictions, the assessment needs clear ownership, consistent thresholds and a reliable connection to records of processing, vendor reviews, data protection impact assessments and contract controls.
When an LIA is the right assessment
Legitimate interests can be an appropriate lawful basis where an organisation, or a third party, has a legitimate purpose and the processing is necessary to achieve it without overriding the rights and freedoms of individuals. It is commonly considered for fraud prevention, network security, certain business-to-business relationship management, internal administration and carefully designed analytics.
It is not a default basis for processing that is simply useful or commercially attractive. Public authorities have restricted scope when performing their public tasks, and certain activities may be better supported by a different lawful basis. Where special category data or criminal offence data is involved, an Article 6 lawful basis alone is insufficient. The organisation must also identify and document the relevant additional condition.
The practical trigger is simple: run an LIA before the processing starts or materially changes. Do not wait for a complaint, a data subject access request or an audit to expose that the legal basis was selected without supporting analysis. A new profiling activity, expanded audience, new data source, longer retention period or supplier change can all alter the original balance.
How to run LIA assessments: use a three-part decision record
The familiar purpose, necessity and balancing tests are effective only when each section captures decisions, evidence and accountable owners. A short statement that a business interest exists is not enough. The record should show how the organisation reached its conclusion.
1. Define the purpose and legitimate interest
Start with a plain-language description of the processing. State the business or third-party interest, the individuals affected, the data categories, recipients, locations, retention period and intended outcome. This forces the assessment to address a defined activity rather than a broad programme label such as "customer analytics".
Then test whether the interest is lawful, specific and real. Reducing account fraud may be legitimate. Improving cyber security may be legitimate. Promoting services to existing business contacts may be legitimate in some circumstances. The interest must be more than a preference for collecting or retaining data indefinitely.
Record the evidence supporting the purpose. This may include a security threat assessment, operational requirement, contractual context, customer need or documented risk decision. Evidence matters because it distinguishes a considered interest from a retrospective justification.
2. Test necessity, not convenience
The necessity test asks whether the processing is a proportionate way to achieve the stated interest. It does not demand that there is literally no other method. It does require the organisation to consider reasonably available, less intrusive alternatives.
For example, a fraud team may need behavioural signals to identify suspicious account activity. It should still assess whether all proposed signals are required, whether data can be pseudonymised, whether monitoring can be limited to higher-risk events and whether retention can be shortened. If the same outcome can be delivered with materially less personal data, the broader processing is difficult to justify.
This section should capture the alternatives considered and why they were rejected or adopted. It is also where privacy engineering controls belong: minimisation, access restrictions, aggregation, role-based permissions and retention rules are not afterthoughts. They demonstrate that the organisation has designed the processing around necessity.
3. Carry out a meaningful balancing test
The balancing test is the critical point. Assess the likely impact on individuals, not only the organisation's intended benefit. Consider whether people would reasonably expect the processing in the context of their relationship with the organisation; whether the data is sensitive by nature or circumstance; whether children or other vulnerable groups are involved; and whether the activity includes tracking, profiling, matching or automated decision-making.
Context can change the answer. A security log used to protect an employee-facing system may be expected and low impact when access is tightly controlled. Combining that same log with location data, productivity monitoring and extensive retention may create a different level of intrusion. The assessment must reflect what the organisation actually does, rather than relying on the benign label attached to the programme.
Identify safeguards that reduce the impact, then decide whether they are sufficient. Useful safeguards include clear privacy information, accessible objection routes, opt-out controls where appropriate, pseudonymisation, strict retention, segregated datasets, human review and heightened access monitoring. Safeguards should be assigned to owners and linked to operational controls, not left as future intentions.
Build LIA governance around the assessment
A well-written LIA can still fail operationally if nobody knows who approves it, where it is stored or when it should be reviewed. Establish a workflow that makes responsibility visible across privacy, legal, security, product, procurement and business teams.
At a minimum, the workflow should capture four controls:
- A named business owner who explains the purpose and confirms how the processing operates in practice.
- Privacy or legal review for higher-risk, novel or cross-border processing.
- Required actions, control owners and target dates before processing goes live.
- Approval, version history and a scheduled review date tied to material change triggers.
Risk-based escalation is more useful than treating every LIA identically. A limited internal contact-management activity may need a proportionate review. An assessment involving large-scale profiling, vulnerable individuals, sensitive datasets, new AI-enabled decision support or unexpected data matching should receive more scrutiny and may require a DPIA as well. Where internal capacity is stretched, Formiti's privacy and AI governance consulting services provide senior practitioner support for LIA framework design, escalation criteria and outsourced DPO capacity.
An LIA and a DPIA serve different purposes. The LIA tests legitimate interests as a lawful basis. A DPIA assesses and manages high risks to individuals arising from processing. In some cases, both are necessary. Keeping the two assessments connected prevents duplicate fact-finding and makes it easier to identify when a change in risk invalidates the original LIA conclusion.
Connect LIAs to the wider privacy operating model
The most common weakness is the isolated document. An LIA saved in a shared folder does not automatically update the ROPA, inform the privacy notice, trigger supplier due diligence or create evidence that controls were implemented.
Treat the LIA as a connected governance record. Its data categories, purposes, lawful basis, recipients and retention decisions should align with the relevant ROPA entry. Where a vendor processes data on the organisation's behalf, the assessment should reference the vendor risk assessment and contractual controls. Where the activity supports an AI system, the LIA should connect to the AI system registry, its intended use and relevant risk classification.
This connected approach is particularly valuable in multinational organisations. The core processing facts can be managed centrally, while local teams assess jurisdictional requirements, notices, data transfer arrangements and operational variations. It reduces inconsistent decisions without pretending that every jurisdiction has identical rules. For programmes that need external challenge or accelerated maturity, Formiti consulting services support framework design, gap analysis and cross-jurisdictional privacy operating models.
Privacy360 supports this operating model by bringing LIAs, DPIAs, ROPA, vendor assessments, contract review, incident management and AI governance records into one controlled environment. The value is not merely faster form completion. It is traceability: a change to a processing activity can be routed to the records, owners and controls that need review.
Maintain the assessment after approval
Approval is a point in the lifecycle, not the end of it. Set review dates that reflect risk, and add event-based triggers for changes to purpose, data categories, population, technology, data recipients, retention or safeguards. A new supplier sub-processor, a move from basic reporting to profiling, or deployment of an AI capability can all require reassessment.
Teams should also test whether the documented controls are working. If individuals are exercising their right to object, if access logs show broader use than intended, or if a business team cannot explain the processing consistently, the LIA may no longer reflect reality. Evidence collection should be part of routine governance rather than an exercise conducted only under pressure.
The strongest LIA process makes lawful basis decisions visible, repeatable and reviewable. When each assessment is connected to the systems, people and controls behind the processing, privacy teams can support legitimate business activity without losing sight of the individuals affected.