How to decide between a DPIA and an LIA, when a processing activity needs both, and how to run a controlled assessment workflow with defensible evidence.
Topics: DPIA, LIA, Legitimate Interests, Privacy Assessments, GDPR
A new processing activity can require both a DPIA and an LIA, but for entirely different reasons. The practical challenge in the DPIA versus LIA decision is not selecting the shorter document. It is establishing the lawful basis for processing, identifying whether individuals face a high risk, and retaining evidence that each decision was made deliberately.
For privacy, legal and risk teams, the distinction affects more than documentation. It determines who needs to contribute, what controls must be put in place before launch, and whether a project can proceed as designed. Treating either assessment as a generic compliance form creates gaps that become difficult to explain during an audit, incident investigation or regulator enquiry.
DPIA versus LIA: the core distinction
A Data Protection Impact Assessment, or DPIA, is a risk assessment required under Article 35 of the UK GDPR and GDPR where processing is likely to result in a high risk to individuals’ rights and freedoms. Its purpose is to identify, assess and reduce those risks before the processing begins.
A Legitimate Interests Assessment, or LIA, supports reliance on legitimate interests as a lawful basis under Article 6(1)(f). It tests whether the organisation has a legitimate purpose, whether the processing is necessary for that purpose, and whether that interest is outweighed by the individual’s rights and interests.
Put simply, an LIA answers: “Can we rely on legitimate interests for this processing?” A DPIA answers: “What could go wrong for people, and have we reduced the risk sufficiently?”
The two assessments can overlap in their evidence, particularly where a processing activity uses personal data at scale, involves profiling or affects vulnerable individuals. They are not interchangeable. A completed LIA does not demonstrate that high risks have been assessed and mitigated. A DPIA does not, by itself, establish that legitimate interests is the correct lawful basis.
When a DPIA is required
A DPIA is mandatory when planned processing is likely to create a high risk. The assessment should be completed early enough to influence the design, rather than after systems, suppliers and commercial commitments have already been selected.
Indicators commonly include systematic profiling or automated decision-making with significant effects; large-scale use of special category or criminal offence data; systematic monitoring of public areas; matching datasets from different sources; processing children’s data; innovative technology; and activities that prevent individuals exercising a right or accessing a service. Supervisory authority guidance may also identify processing types that require a DPIA in a particular jurisdiction.
Context matters. A customer analytics initiative may not automatically require a DPIA merely because it involves behavioural data. But combining detailed usage data, location information, third-party enrichment and automated segmentation could materially increase the risk profile. The assessment must consider the nature, scope, context and purpose of the actual processing - not rely on a label such as “analytics”.
A DPIA should document the processing operation, necessity and proportionality, risks to individuals, planned controls and residual risk. Where high residual risk remains and the organisation cannot reduce it, prior consultation with the relevant supervisory authority may be required before proceeding.
When an LIA is the right assessment
An LIA is appropriate where the organisation proposes to rely on legitimate interests. It is frequently relevant to fraud prevention, network security, internal administration, certain business-to-business marketing activities, service improvement and supplier management. None of these purposes automatically pass the test.
The assessment has three connected stages. First, identify a clear and lawful legitimate interest. A vague reference to commercial benefit is not enough. Secondly, show that the proposed processing is necessary - in other words, there is no less intrusive reasonable way to achieve the same purpose. Finally, carry out the balancing test: consider the nature of the data, individuals’ reasonable expectations, the relationship with the organisation, possible impacts and available safeguards.
For example, using limited account activity data to detect suspicious access may be necessary for security and broadly expected by users. That does not justify retaining detailed behavioural records indefinitely or repurposing them for unrelated commercial profiling. Purpose limitation, data minimisation, retention controls, transparency and an effective right to object can all affect the outcome of the balancing test.
An LIA should be revisited when the processing changes. A lawful basis conclusion made for a defined customer communications programme may no longer stand when data sources, targeting methods, recipients or retention periods expand.
Situations where both assessments apply
The question is often not DPIA or LIA, but whether both are required. Consider an organisation introducing an AI-supported system to identify potential employee misconduct from communications and access logs. It may wish to rely on legitimate interests to protect its operations and investigate wrongdoing. That calls for an LIA.
The same activity may involve systematic monitoring, potentially sensitive inferences, power imbalance in the employment relationship and significant consequences for individuals. Those factors can trigger a DPIA. The DPIA then examines how the system works in practice, whether human review is meaningful, what errors or bias might occur, how access is controlled, and how long data is retained.
The sequence matters. Establish the proposed lawful basis and the purpose first, then assess whether the overall processing is likely to present a high risk. In practice, teams may run the assessments in parallel because evidence gathered for one will inform the other. The resulting records should remain distinct, with clear ownership and approvals.
Common errors that weaken accountability
The most persistent error is using a DPIA as a catch-all approval form. A DPIA is not a project sign-off, a security questionnaire or a substitute for a Record of Processing Activities. It should expose real privacy risks and document decisions about their treatment.
The reverse problem occurs when organisations treat an LIA as a short statement that their interests are legitimate. The balancing test requires an individual-centred analysis. It needs evidence of reasonable expectations and potential effects, not simply a statement that the organisation benefits from the activity.
Other weaknesses are operational. Teams may complete an assessment once, store it in an isolated folder and fail to revisit it when a supplier changes, an AI model is introduced, data is reused, or the processing expands into another jurisdiction. They may also assign privacy teams sole responsibility for assessments that require input from security, product, HR, procurement, legal and business owners.
These failures usually originate in fragmented governance. A spreadsheet may record the decision, while supporting vendor information, data flows, technical controls, retention schedules and approval evidence sit elsewhere. The record becomes difficult to maintain and harder to defend.
Building a controlled assessment workflow
A workable process begins with a structured intake. Require project owners to describe the purpose, data categories, affected individuals, systems, suppliers, locations, intended lawful basis, retention period and any automated decision-making. This enables an initial triage: does the activity require an LIA, a DPIA, both, or neither?
For an LIA, route the assessment to the accountable business owner and privacy or legal reviewer. Require a specific purpose statement, necessity analysis, balancing assessment, safeguards and review date. For a DPIA, involve the DPO or privacy lead early and assign risk owners for each mitigation. Controls should be tracked to completion rather than recorded as future intentions.
The assessment should also connect to adjacent governance records. A new supplier should link to the vendor or third-party risk assessment and contract review. A new processing purpose should update the ROPA. An AI-enabled use case should connect to the AI system registry and its EU AI Act risk classification. If an incident exposes a weakness in a control, the breach and incident management record should feed back into the relevant DPIA review.
For organisations that need help standing up that operating model, Formiti's privacy operations and governance services provide assessment design, DPO support and multi-jurisdictional programme delivery.
This connected model turns assessments into operational controls rather than static documents. Privacy360 provides that structure across DPIAs, LIAs, ROPA, supplier reviews, AI oversight and evidence collection, allowing teams to retain a clear decision trail without relying on disconnected records.
What good evidence looks like
A defensible record does not need excessive legal language. It needs enough detail to show that the organisation understood the processing, evaluated realistic impacts and made accountable choices. Decision-makers, consultation dates, outstanding actions, approval conditions and review triggers should be visible.
For multi-jurisdictional organisations, this includes recording where local requirements or guidance alter the analysis. The GDPR and UK GDPR provide a common foundation, but operations involving Swiss nFADP, Thailand PDPA or other applicable regimes may require additional checks. A central process should accommodate these variations without producing a separate, inconsistent methodology for every business unit.
The strongest test is practical: if a project owner changes, a regulator asks questions, or an incident occurs six months later, can the organisation reconstruct why the processing was approved and prove that safeguards were implemented? If the answer depends on informal knowledge or a departed colleague’s inbox, the process needs more control.
A DPIA and an LIA are decisions that should remain alive for as long as the processing does. Build them into change management, connect them to the systems that evidence delivery, and they become a reliable part of governance rather than a hurdle at project launch.