Legitimate Interest: The Most Powerful and Most Dangerous LGPD Legal Basis
Of the 10 legal bases in LGPD Article 7, legitimate interest is the one that gets companies fined. Not because it's invalid — it's arguably the most versatile basis for data processing — but because it's the only one that requires a documented justification before you start processing. Most companies skip the documentation and hope nobody asks. The ANPD always asks.
What legitimate interest actually means
Legitimate interest (Art. 7, IX) allows you to process personal data when it's necessary to serve the legitimate interests of the controller or a third party — provided those interests don't override the fundamental rights and freedoms of the data subject.
That last clause is where every misapplication lives. "We need your browsing history to improve our product" might be legitimate. "We need your browsing history to sell to advertisers" is not. The difference isn't in the data — it's in the balance between your interest and the user's rights.
The three-element test
Before invoking legitimate interest, you must pass a three-part test. This isn't a suggestion — it's a regulatory requirement that the ANPD will ask for during any investigation.
Element 1: Legitimate purpose
Is the interest real, concrete, and lawful? "Fraud prevention" is legitimate. "We want more data" is not. The purpose must be specific enough to evaluate — vague statements like "business improvement" don't qualify.
Element 2: Necessity
Is data processing actually required to achieve the purpose? Could you achieve the same result with less data or no data? If you can detect fraud using transaction patterns alone, collecting browsing history for fraud prevention fails the necessity test.
Element 3: Balancing
This is where legitimate interest lives or dies. Even if your purpose is legitimate and the processing is necessary, the user's rights might still prevail.
| Factor | Tips toward controller | Tips toward data subject |
|---|---|---|
| Data sensitivity | Non-sensitive, aggregated | Sensitive, individual-level |
| User expectation | Reasonable (e.g., security logs) | Unexpected (e.g., profiling) |
| Impact | Minimal, reversible | Significant, hard to undo |
| Safeguards | Encryption, access controls, opt-out | None implemented |
| Relationship | Direct customer | No prior relationship |
The balancing test must be documented in a Legitimate Interest Assessment (LIA). This document is your evidence of compliance. Without it, your legitimate interest claim is legally indefensible — even if the processing itself is perfectly reasonable.
When legitimate interest works
Fraud prevention. A financial institution analyzes transaction patterns to detect suspicious activity. The purpose is legitimate (protecting the institution and its clients), the processing is necessary (fraud detection requires data analysis), and the balance favors the controller (the impact on users is limited, safeguards are robust, and users expect their bank to prevent fraud).
Network security. A company monitors network access logs to detect cyberattacks. The purpose is legitimate, the processing is necessary, and users have a reasonable expectation that their employer monitors corporate network activity.
Own-brand marketing. A retailer emails customers about products similar to past purchases. The purpose is legitimate (promoting relevant products), but only if:
- The customer can easily opt out
- The marketing is for the controller's own products (not third-party)
- The relationship is direct (the customer already bought something)
When legitimate interest fails
Third-party data sales. Selling user data to advertisers is not a legitimate interest of the controller — it's a commercial interest that directly harms the data subject's privacy. Use consent instead.
Sensitive data processing. LGPD generally requires explicit consent for sensitive data (health, biometrics, religion, political opinion). Legitimate interest is almost never appropriate here.
Children's data. Processing children's data under legitimate interest faces an extremely high bar for the balancing test. Default to verifiable parental consent.
No opt-out mechanism. If you invoke legitimate interest but provide no way for users to object, you've undermined the balancing test. Art. 18 guarantees the right to object to processing under legitimate interest.
Legitimate interest vs. consent
The choice isn't about convenience — it's about which basis is architecturally correct for the processing:
| Dimension | Consent | Legitimate interest |
|---|---|---|
| Revocable | Yes — user can withdraw anytime | Objectable — user can object, but controller can refuse if justified |
| Documentation | Record of when/how consent given | LIA with three-part test |
| Pre-condition | User must actively opt in | Controller must document justification |
| Failure mode | User revokes → must stop processing | ANPD investigates → must produce LIA |
| Best for | Marketing, non-essential features | Security, fraud prevention, core operations |
The critical difference: consent puts the burden on the user (they must act to opt in). Legitimate interest puts the burden on the controller (you must document why the processing is justified). If your compliance strategy depends on users not revoking consent, you've built on sand.
How this maps to DPO2U
DPO2U's Auditor Agent validates the consent_mechanism field in the dpo2u/lgpd/v1 schema. When a company declares legitimo-interesse as their basis, the Auditor checks for the presence of a corresponding LIA document in the IPFS-stored artifacts. A legitimate interest claim without a documented LIA receives a lower compliance score — because the claim is legally vulnerable without the documentation to back it.
This is automated compliance verification doing what human auditors do manually: asking "where's the LIA?" and downscoring when the answer is "we didn't write one."
The three-element test isn't bureaucracy. It's the difference between a legal basis and a legal liability. Document the purpose, prove the necessity, balance the interests, and store the LIA where an auditor — human or autonomous — can find it.
For the complete schema validation rules, see LGPD Kit Schema. For how automated compliance verification works end-to-end, see From PDF to Proof.