Assess whether Article 6(1)(f) can support a processing activity by recording the legitimate interest, necessity analysis, balancing outcome, and objection handling.
This workflow helps keep privacy notices, RoPA entries, approvals, and reassessment triggers aligned with GDPR Articles 5, 6, 13, 14, 21, and 30.
Structured answer sets in this page tree.
Cited legal and guidance references.
Use this workflow when a controller wants to rely on under Article 6(1)(f). A legitimate interests assessment (LIA) is the purpose-specific record of the interest, necessity, balance, safeguards, and decision. The Article 21 right to object lets a person challenge this processing on grounds relating to their particular situation, so the workflow must also show how the controller will receive, decide, and implement objections.
Create one LIA record per processing purpose, not one record for an entire product, department, or data platform. Article 5 requires specified, explicit, and legitimate purposes, and Article 6 requires at least one lawful basis for the processing.
Record the candidate Article 6 basis before controls are designed. If the activity depends on consent, contract, legal obligation, vital interests, public task, or special-category processing rules, do not force it into Article 6(1)(f); use this workflow only for the legitimate-interests candidate and document why other Article 6 bases were not selected. Public authorities cannot rely on Article 6(1)(f) for processing performed in the discharge of their tasks. Processing special-category data also needs a separate Article 9 condition, and criminal-conviction or offence data must meet Article 10.
The Article 6(1)(f) test should be written as three separate decisions. A valid interest alone is not enough; the processing must be necessary for that interest and must not be overridden by the data subject interests or fundamental rights and freedoms that require protection of personal data.
Keep the necessity analysis factual. Describe the minimum data, retention, recipients, automation, and access needed to meet the stated purpose, then identify any less intrusive alternatives that were accepted or rejected.
Article 21 gives data subjects the right to object, on grounds relating to their particular situation, to processing based on Article 6(1)(e) or Article 6(1)(f), including profiling based on those provisions. The LIA should therefore include the operational path for receiving, triaging, and deciding objections before the processing goes live.
For Article 6(1)(f) processing, the controller must stop processing after an objection unless it can demonstrate compelling legitimate grounds that override the data subject interests, rights, and freedoms, or the processing is needed for legal claims. Direct marketing objections require a separate stop path because Article 21 says the personal data must no longer be processed for that purpose, including profiling to the extent that it relates to direct marketing.
Treat the LIA as a live evidence record tied to the RoPA and privacy notice. Article 30 records require the purposes of processing, data-subject and personal-data categories, recipients, transfers, erasure time limits where possible, and security measures where possible; DPC guidance also identifies Article 6 legal basis as a helpful extra field.
The evidence should let a reviewer see the chain from Article 6(1)(f) to implementation: purpose, necessity, balancing, safeguards, notice text, objection handling, and owner approval. Avoid storing only a final yes or no outcome without the facts that made the decision supportable.
Move the processing through four gates: scope, assessment, implementation, and review. Do not treat approval of the written LIA as permission to launch before its conditions are implemented. The final record should identify who can move the activity through each gate and which evidence closes it.
Use one status vocabulary across the LIA, RoPA, product ticket, and privacy review. A reviewer should be able to distinguish a draft assessment from a conditional approval, a cleared launch, a paused activity, and a retired purpose without reading meeting notes.
No. The LIA records the Article 6(1)(f) analysis; it does not cure a vague purpose, failed necessity test, overriding data-subject interests, missing Article 9 or Article 10 authority, a required DPIA, or non-compliance with another applicable rule. Processing should start only after the recorded conditions and operational controls are in place.
No. If the interest can be achieved just as effectively through a less intrusive method, Article 6(1)(f)'s necessity condition is not met. Safeguards belong in the balancing and implementation analysis after necessity has been established.
Reopen it before a material change to the purpose, people, data, source, recipients, transfers, retention, profiling, monitoring, or safeguards, and when objections, complaints, incidents, audits, or product evidence undermine an assumption in the approved record.
Keep the activity blocked or narrow it to the facts and controls already approved. Record the unmet condition, owner, revised date, and decision. Do not silently convert a conditional approval into an unconditional one.
Sorena can help convert lawful-basis decisions into LIA records, RoPA fields, privacy-notice language, objection-handling steps, and reassessment triggers based on the cited GDPR sources.
Ask questions tied to cited sources about Article 6(1)(f), Article 21 objections, transparency, and RoPA evidence using the cited sources on this page.
Review your lawful-basis inventory, LIA evidence gaps, and objection-handling workflow with Sorena.
"What is my reason or justification for processing this personal data?"
"The Article 6 legal basis for processing"
"be able to demonstrate compliance"