What a legitimate interest assessment involves and who signs it off
When a customer, contract or regulator asks for documented legitimate interest reasoning, the first thing to know is that the GDPR requires no audit, attestation or certificate for a *legitimate interest assessment* (LIA). The controller owns the assessment and its outcome, and it must be able to show its reasoning to a supervisory authority on request. No supplied fact gives a price or duration for preparing one, so the cost to plan for is internal time, legal review and, where the processing touches the DPO's remit, DPO advice. Ask whoever is making the request which document they expect, who must approve it, and how often it must be revisited, because those answers set the effort.
An outside auditor or certification body does not issue the LIA, and a certificate under Article 42 would not replace it. An implementation partner can help by mapping the processing, collecting the technical facts the balancing test depends on (what data is collected, how long it is kept, who can access it, and what safeguards apply), and turning those facts into a draft for the controller's team. The partner prepares the evidence; the controller's accountable owner, usually the privacy lead with legal sign-off, decides whether the interest is legitimate and whether the balance favors the controller. Confirm in writing which person holds that decision and where the signed record is stored.
Plan for effort that recurs. An LIA is not a one-time form: it should be reviewed when the processing changes, when a new data source or sub-processor is added, or when data subjects raise objections. Each review repeats part of the balancing work, so the cost depends on how many activities rely on legitimate interests and how often their systems change. Ask any consultant to separate the one-time drafting of each LIA from the periodic review, and to name who in your organization must attend the sign-off meeting.
Who is paid for what when you document an LIA
This table compares the cost components of documenting a legitimate interest assessment, who is paid for each, and whether the cost is one-time or recurring. Use it to scope internal effort against outside help, and to know what to request in a written quote before work starts.
| Cost component | Who is paid | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Business owner time | Your own staff who define the processing purpose and benefit | One-time, then recurring at each review | Number of processing activities relying on legitimate interests and how clearly each purpose is already written down |
| Privacy lead and DPO time | Your privacy lead or the designated DPO, who checks necessity and the balancing test | One-time, then recurring when processing changes | Whether the DPO already holds the record of processing, and how often new uses of data are proposed |
| External privacy counsel | An outside lawyer, only if the balancing test is contested or a regulator may review it | Occasional, tied to a specific dispute or new high-risk use | Novelty of the processing, sensitivity of the data, and whether the balancing outcome is borderline |
| Implementation partner work | A technical partner who prepares logs, configuration evidence and the processing inventory the LIA relies on | One-time setup, then recurring evidence refresh | Number of systems in scope, how much logging already exists, and whether data flows are documented |
| Tooling and storage | Software vendors or hosting costs for records, logs and version-controlled assessments | Recurring licence or hosting, plus one-time setup | Whether you reuse existing governance tools or need a new register for assessments |
| Review and change triggers | Internal staff and any partner called in to re-test evidence | Recurring | Frequency of product changes, new sub-processors, new data sources and new objection requests |
How to document the three EDPB conditions
EDPB Guidelines 1/2024 on legitimate interest, published for public consultation in October 2024, set a three-part test. Each condition needs its own written evidence, and the three are cumulative, so a gap in any one of them means the legitimate interest assessment fails.
Lawful, articulated, real and present interest
Write down the specific interest the controller or a third party pursues, in terms precise enough to test. The interest must be lawful, clearly articulated and real and present, not speculative. For example, a statement that the company will improve security is too vague, while a statement that the company must detect credential stuffing against its customer login service today is testable. Check that the purpose statement matches what the system actually does.
Necessity of the processing
Show that the processing is necessary for the interest, meaning no less intrusive way achieves the same result. Record the alternatives you considered, such as aggregated logs, pseudonymised identifiers or shorter retention, and why each was rejected. Engineering evidence helps here: a design note comparing the data fields actually needed against those collected.
Balancing test against data subject interests
Weigh the controller's interest against the interests, rights and freedoms of the people affected. Record the reasonable expectations of data subjects based on their relationship with the controller, as recital 47 requires, the nature of the data, and the likely impact. The outcome must show the individual's interests do not override the interest. Reassess when the processing changes, such as when new profiling is added.
Safeguards that tip the balance
List the measures that reduce impact on individuals, such as pseudonymisation, access restrictions, short retention, the right to object and clear notice. Each safeguard should map to a configured control that you can show an assessor, for example a log retention setting or an access review record. Safeguards written but never implemented do not support the balancing outcome.
Sign-off and review record
Record who performed the assessment, who approved it, the date, and the trigger for review. Keep the data protection officer's input on file where one has been designated. Confirm with your legal or privacy team how often your organization reviews each assessment and what triggers an earlier review, since the regulation sets no fixed interval.
How reasonable expectations and the recital examples shape the balancing test
Recital 47 and Recital 49 tell the controller what the balancing test is weighing and which purposes the legislators already treat as legitimate. Recital 47 requires the reasonable expectations of data subjects, based on their relationship with the controller, to be weighed. It also states that processing strictly necessary for preventing fraud constitutes a legitimate interest. Recital 49 goes further for information security: processing personal data to the extent strictly necessary and proportionate for network and information security, including by providers of security technologies and services, is a legitimate interest. The recital gives examples such as preventing unauthorised access, malicious code distribution and denial of service attacks. Recitals do not replace the balancing test, but they tell the assessor where the balance usually lands for security processing and why the expectation question still has to be answered for each log source.
In practice, the security team should record each log source as a separate line in the LIA: what it captures (for example, authentication events, source IP addresses, endpoint process records or API request metadata), the security purpose it serves, the retention period, and who can query it. For each line, the team should explain why a narrower set would not meet the purpose. (Illustrative: dropping source IP addresses from authentication logs may remove the only practical way to correlate credential stuffing across accounts, so the narrower set fails the necessity condition.) Confirm the detail with the security lead and the DPO rather than assuming the Recital 49 wording covers every field.
Reasonable expectations are judged on the relationship, and the EDPB small business guide illustrates the contrast. In its example (illustrative for this page), a bookshop that wants to use customers' past purchases to recommend other books cannot rely on contract necessity, so it needs consent or, depending on the circumstances, legitimate interest. The same reasoning applies to security monitoring. Employees signing in to a corporate system generally expect that authentication events are logged, while a customer who only browses a public site may not expect detailed behavioural profiling. The assessment should state those expectations explicitly, and the notice should describe the monitoring so that the expectation is actually reasonable.
How to write and maintain an LIA step by step
This sequence turns a vague idea to rely on legitimate interest into a dated, approved assessment that shows the three EDPB conditions were tested, and that stays current as the processing changes.
Scope the processing activity precisely
Name the processing operation, the purpose, the categories of personal data, the data subjects, the systems and the parties involved, including any processors or sub-processors. Write it as one activity that can be assessed, not a broad system name. The output is a scope note that the record of processing and the LIA both refer to. The step is complete when a reader outside the project can tell exactly what data is processed, for whom and why.
Write the purpose statement
Describe the interest the controller pursues in specific terms, such as preventing unauthorised access to a customer portal or stopping a fraudulent payment pattern. Check that the interest is lawful, clearly articulated, and real and present rather than speculative. Record who benefits, whether that is the organization, customers or third parties, because the EDPB's first condition asks for an interest that exists now. The output is a short purpose statement that a supervisory authority could read on its own.
Document the necessity test and alternatives
Explain why the processing is necessary to achieve the stated interest and why the same result cannot be reached with less personal data, a different method or consent. List the alternatives you considered, such as pseudonymised logs, shorter retention or aggregated reporting, and state why each was rejected or adopted. Recital 49 limits network and information security processing to what is strictly necessary and proportionate, so record that scope explicitly. The output is a necessity note with alternatives, and the step closes when each data element can be linked to a need.
Record the balancing test and expectations
Describe the data subjects' relationship with the controller and what they would reasonably expect, as Recital 47 requires. Assess the impact on them, including any profiling, monitoring or effects on vulnerable groups, and weigh it against the interest. Then list the safeguards that reduce impact, such as minimisation, access restrictions, short retention, transparency in the privacy notice and a route to object. The output is a balancing record that shows the reasoning, not only the conclusion.
Reach and sign the decision
State whether the controller may rely on Article 6(1)(f) for this activity, with the conditions that apply and any residual concerns. Name the accountable owner and the approver, usually the business owner with DPO advice recorded, and date the decision. Where the outcome is negative, record the alternative lawful basis or the decision to stop the processing. The step is complete when the signed record exists and the team that runs the system has received the conditions to follow.
Connect the decision to transparency and rights
Confirm that privacy notices describe reliance on legitimate interest and the interest pursued, and that the team can handle an objection under Article 21(1). Explain to the engineering owner that the controller must stop processing on objection unless it shows compelling grounds or needs the data for legal claims. Note that portability under Article 20 does not apply to processing based on legitimate interest. The output is a short list of configured rights handling steps tied to the assessment.
Store the assessment and set review triggers
Keep the signed LIA with the record of processing and make it retrievable for supervisory authority requests. Define review triggers: a change in purpose, new data categories, a new processor or sub-processor, a new recipient country, profiling, a significant incident, or a change in the reasonable expectations of users. Assign an owner to watch each trigger. The LIA is not submitted to an auditor by default, but auditors may ask for it, so the output is a versioned file with a change log.
Re-run the assessment when triggers fire
When a trigger occurs, reopen the affected steps rather than the whole document, update the purpose, necessity, balancing and decision entries, and obtain a fresh approval. Record what changed and why in the version history, and check that privacy notices and objection handling still match. Vendor changes deserve particular attention, because a new processor can alter the data flows the balancing test relied on. The step is complete when the version history shows that the current processing is the one assessed.
Legitimate interest, consent or contract: which basis to document
This table compares the three lawful bases most often considered for a processing activity: legitimate interest, consent and contract necessity. Read each row across to see when the option fits, what evidence it needs and where it typically fails. The main takeaway is that contract necessity covers only what the contract genuinely requires, so purposes beyond the core service usually need another basis.
| Basis | When it fits | Evidence to document | Where it usually fails |
|---|---|---|---|
| Legitimate interest (Article 6(1)(f)) | A clearly articulated interest, such as fraud prevention or network security, where the processing is necessary for it and the individual's interests do not override it | A written LIA covering the three EDPB conditions: the interest, necessity and the balancing test, plus the reasonable expectations of data subjects | The balancing test is skipped or the interest is described too vaguely to test |
| Legitimate interest: objection workflow | Any processing relying on Article 6(1)(f), including profiling | A process to stop processing on objection unless compelling grounds are demonstrated, with a record of each decision | Objections are logged but not routed to a decision, or systems keep processing after an objection |
| Consent | Purposes the individual can freely choose, such as optional marketing or the bookshop recommendation example where legitimate interest is not the chosen route | Proof of the consent given, what the person was told, the version of the notice and the time of the choice | Consent is bundled with the service or withdrawal is harder than giving consent |
| Consent: withdrawal mechanics | Wherever consent is the basis, withdrawal must be as easy as giving it | Withdrawal records, a propagation step to every system and processor, and evidence processing stopped | Withdrawn consent still feeds analytics, backups or processor copies |
| Contract necessity (Article 6(1)(b)) | Only where the processing is objectively necessary to perform the contract with the individual | A mapping of each processing step to a core service element the contract describes | Purposes such as product improvement or recommendations are treated as part of the contract |
| Contract necessity: the bookshop example | Illustrative: a bookshop that wants to recommend other books from past purchases cannot rely on contract necessity | A documented test showing the purpose is not essential to the sale itself | Teams assume a purchase creates a contract that covers every later use of the data |
| Choosing between bases | Pick one basis per purpose before collection starts, based on the purpose and relationship | A record of the basis chosen and the reason, kept with the record of processing | Basis is changed after the fact to fit a new use of data |
Who owns the LIA, who prepares evidence and who checks it
The controller owns the legitimate interest assessment and the decision to rely on Article 6(1)(f). In practice the business owner who wants the processing defines the interest and why it matters, and the privacy lead runs the three-part test, records the reasoning and signs off the outcome. Only the controller can decide that the balance favors processing, so no vendor or consultant can make that call on its behalf.
- Business owner: States the purpose, the interest pursued and what would be lost without the processing, in plain language.
- Privacy lead: Holds the LIA as a dated record, applies the EDPB's three cumulative conditions and documents the balancing outcome.
- Accountable executive: Approves reliance on legitimate interests where the processing is sensitive or the risk to individuals is high.
- Review owner: Schedules reassessment when the purpose, data or systems change.
- Records link: Ties each LIA to the matching entry in the record of processing activities.
Before the assessment is signed, confirm that a named person can explain the reasoning to a supervisory authority without relying on a consultant's wording.
An implementation partner such as DeployOpen can prepare the technical facts that the balancing test depends on. These include which systems hold the data, what is logged, who can access it, how long records are kept and what security measures are configured. The partner documents these facts for review. It does not decide whether the interest is legitimate, whether processing is necessary or how the balance is struck.
- System inventory: Maps where the personal data sits, including self-hosted platforms inside the client's own infrastructure.
- Configuration evidence: Exports access control settings, retention parameters and logging configuration that the assessment can cite.
- Security measures: Documents controls such as those supporting network security or fraud detection, so the necessity argument rests on verified facts.
- Change records: Keeps dated notes when the platform or data flows change, so reviews start from accurate information.
- Handover pack: Delivers the evidence in a form the privacy lead and reviewer can check line by line.
Agree in the written scope exactly which facts the partner will produce and confirm that the controller's staff, not the partner, sign the assessment.
An external reviewer, such as privacy counsel or an outsourced data protection officer, advises and challenges the assessment. The reviewer tests whether the interest is clearly stated, whether the processing is truly necessary and whether the balancing test would survive a regulator's questions. Where the DPO is involved, the GDPR expects the DPO to be consulted on the assessment, but the DPO's advice does not transfer responsibility to the DPO.
- Challenge of necessity: Asks whether a less intrusive method would achieve the same aim.
- Test of expectations: Checks whether individuals would reasonably expect this use, given their relationship with the controller.
- Objection handling: Confirms how an objection under Article 21(1) would be processed and what compelling grounds would be needed.
- Documentation review: Reads the LIA as a regulator would, looking for gaps and unsupported claims.
- Independence note: Records any conflict between the reviewer's other work and the outcome.
No certificate is required for an LIA, and no auditor or certification body issues one for it. If a reviewer offers a certificate or report on the assessment, ask which body issued it and under what standard.
Questions buyers ask before they document a legitimate interest assessment
Does an auditor or regulator have to review our legitimate interest assessment?
No law requires an external auditor to review a legitimate interest assessment, and the GDPR does not issue audit reports or certificates for it. The controller owns the assessment and must be able to show a supervisory authority, on request, that it weighed the three conditions and the individual's interests. Independent review is a choice you make for assurance, for a contract, or because a regulator later asks questions. If you want outside eyes, a data protection lawyer, a DPO or an independent assessor can review the reasoning, but their review does not transfer responsibility from your organization.
Is a legitimate interest assessment template enough to meet the requirement?
A template helps you structure the work, but it cannot do the reasoning for you. The assessment has to name the specific interest, explain why the processing is necessary for that purpose, and show a balancing test tied to the actual data, people and systems involved. A template filled in with generic wording tends to fail when a regulator reads it, because it does not show the decision was made for this processing. Use a template as the frame, then add the facts about your data flows, the people affected and the safeguards you chose.
How much staff time does a legitimate interest assessment take, and should we hire counsel?
The effort depends on how many processing activities rely on legitimate interest and how complex each one is. Staff time goes to the business owner describing the purpose, engineers explaining the data flows and retention, and the privacy or legal lead writing and challenging the balancing test. Counsel is worth considering when the processing involves special category data, profiling, children, AI training, or a contested balance of interests. Ask any firm for a fixed-scope quote listing the number of assessments, the review rounds and what is included in the final document.
How long does a legitimate interest assessment take to complete?
No reliable duration applies across organizations, so treat any timeline as something to confirm for your own environment. The main drivers are how well the purpose is already documented, how quickly the owner can explain the data and its retention, whether engineers can confirm where data is stored and who accesses it, and how many stakeholders must sign off. Assessments for simple, well-understood operations, such as network security logging, usually move faster than novel analytics or AI features. Ask any provider to state the assumptions behind its schedule and what would extend it.
What do the business owner and engineers need to provide for the assessment?
The assessment depends on facts that only the people running the processing can supply. The business owner needs to articulate the purpose, the benefit to the organization and any wider benefit, and what would happen if the processing stopped. Engineers need to confirm the following:
- The categories of personal data and where each one flows
- Which systems, processors and sub-processors touch it, and in which countries
- Retention periods and how deletion or anonymisation actually works
- Safeguards already in place, such as access control, logging and pseudonymisation
If these facts are unclear, the balancing test will be weak, because it has to rest on what the system really does.
Can our own team carry out the legitimate interest assessment without outside help?
Yes, many organizations complete these assessments internally, provided someone has the authority to make the call and the skills to weigh the interests fairly. The team needs a clear owner, a method based on the three conditions, access to engineers who understand the data, and a record that is kept current when processing changes. Outside help is most useful for scoping, challenging a draft, or building a repeatable process across many activities. DeployOpen plans and implements self-hosted open-source platforms in your own infrastructure and prepares the technical evidence behind your assessments, but the controller owns the decision, and only an independent auditor or certification body issues reports or certificates.
How DeployOpen prepares the systems and evidence behind an LIA
DeployOpen does not write your legitimate interest assessment or decide your lawful basis, because that judgment stays with your organization and its data protection function. We prepare the systems, logs, controls and documentation that let your team record each interest, its necessity and the balancing outcome with evidence behind it.
How we scope
- Written scope names each processing activity that relies on Article 6(1)(f) and the systems that carry it
- Scope lists the data categories, data subjects and processors involved in each assessment
- Scope states which controls, logs and records we will prepare and which ones your team keeps
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
How we build
- We configure self-hosted platforms so data minimization and access limits match the stated interest
- We set up logging and retention settings that support the necessity and proportionality arguments
- We implement objection handling workflows so Article 21 requests can be recorded and actioned in the systems
- We run security testing on the processing environment to confirm the safeguards described in the assessment
How we hand over
- We deliver a documented record of each configuration, data flow and control tied to the assessment
- We provide a step-by-step runbook describing how to recheck the balancing test when the processing changes
- We transfer administration access and knowledge to your team so the evidence stays current after handover
- We confirm with your legal and data protection staff which conclusions remain their decision
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial scope completes
- Retainers can cover periodic review of the systems behind each legitimate interest as the processing evolves
- Changes to a platform or a new data source can be scoped as a written change to the existing agreement
- Questions about regulator guidance or cross-border enforcement should be confirmed with your counsel or supervisory authority
