EU GDPR LIA Template

Open the LIA with a concrete processing activity, not a project name. The record should identify the controller, business owner, product or service, categories of personal data, categories of data subjects, recipients, retention position, related RoPA entry, and whether the activity includes children, special category data, criminal-offence data, systematic monitoring, profiling, or international transfers.

Use Article 6(1)(f) only for processing that is necessary for legitimate interests pursued by the controller or a third party and is not overridden by the data subject's interests, rights, and freedoms. If another Article 6 basis is the real reason for the processing, record that basis instead of forcing the LIA.

The purpose section should make the interest specific enough to test. Avoid broad labels such as fraud prevention, security, analytics, or product improvement unless the record explains the actual outcome sought and why this processing contributes to that outcome.

The necessity section should test whether the same purpose can reasonably be achieved with less personal data, fewer people affected, shorter retention, less intrusive matching, aggregation, anonymisation, pseudonymisation, or a different operational process.

The balancing section is the core of the LIA. It should compare the controller's or third party's interest with the likely impact on the people whose data is processed, using the real context rather than generic risk language.

Record facts that can change the outcome: the relationship with the data subject, whether the processing is expected, whether people can avoid or control it, the sensitivity of the data, the scale and frequency of processing, and the consequences if the assessment is wrong.

A pass should depend on concrete safeguards, not on optimistic wording. The template should list controls already implemented and controls required before launch, with owners and evidence links.

If processing relies on Article 6(1)(f), privacy information should identify the legitimate interests pursued. The LIA should also explain how people can object on grounds relating to their particular situation, who triages objections, and when processing must stop unless compelling legitimate grounds or legal-claims grounds apply.

The completed LIA should be understandable without reconstructing the project history. Store the assessment with the linked RoPA entry, privacy notice, data-flow diagram, vendor record, retention rule, product requirement, security-control evidence, objection-handling log, and approval trail.

Reopen the LIA when a material fact changes. Examples include a new purpose, new data category, new data-subject group, new recipient, new transfer, longer retention, new profiling logic, new monitoring scale, new child-facing context, unresolved objections, or a DPIA finding that changes the risk picture.