LGPD's 10 Legal Bases: What Developers Actually Need to Know
Every LGPD implementation I've reviewed makes the same mistake: the developer picks "consent" as the legal basis for everything because it's the only one they've heard of. Brazil's data protection law defines 10 legal bases for processing personal data, and choosing the wrong one doesn't just create legal risk — it creates architectural debt that compounds with every feature you ship.
Why developers need to care about legal bases
LGPD Article 7 lists 10 legal bases that authorize processing personal data. Each one imposes different obligations: what you must document, what rights the user can exercise, and what your system architecture must support. If you build a consent withdrawal flow for data you're processing under "legal obligation," you've wasted engineering time on a feature that doesn't apply. If you skip the consent withdrawal flow for data that does require consent, you've shipped a compliance violation.
DPO2U's dpo2u/lgpd/v1 schema captures the legal basis as the consent_mechanism field — but the schema is only as good as the developer's understanding of what goes in that field.
The 10 legal bases, ranked by developer relevance
Tier 1: You'll use these constantly
1. Consent (Art. 7, I) — The user explicitly agrees to specific data processing.
The requirements are strict: consent must be free (no coercion), informed (clear about what's processed), unambiguous (no pre-checked boxes), and specific (per purpose, not blanket). Your system needs:
- A granular opt-in mechanism (not "agree to terms")
- Timestamped record of when consent was given
- A revocation path that actually works
- Re-consent flow when the purpose changes
When to use: Marketing, non-essential analytics, processing sensitive data, any treatment that isn't necessary for the core service.
2. Contract execution (Art. 7, V) — Processing necessary to fulfill a contract the user is party to.
If the user bought a product, you can process their shipping address to deliver it. No consent popup needed — the contract is the legal basis. But you can't use this to justify sending promotional emails about unrelated products.
When to use: E-commerce delivery, SaaS service provision, support for the contracted service.
3. Legitimate interest (Art. 7, IX) — Processing necessary for the controller's legitimate interests, provided it doesn't override the user's rights.
The most powerful and most dangerous basis. It requires a documented three-part test:
| Element | Question | Example |
|---|---|---|
| Purpose | Is the interest legitimate? | Fraud prevention — yes |
| Necessity | Is this processing required? | Transaction analysis — yes |
| Balancing | Do user rights prevail? | Impact is limited, safeguards exist — balanced |
When to use: Fraud prevention, network security, product improvement, own-brand marketing (with opt-out).
Tier 2: Context-dependent
4. Legal obligation (Art. 7, II) — Processing required by law.
Store tax records for 5 years because tax law says so. No consent needed, no deletion right applies. Document which specific law mandates the processing.
5. Public policy execution (Art. 7, III) — Processing by public entities for policy implementation.
Relevant if you're building government or public health systems. Requires a specific law or regulation as basis.
6. Research by accredited bodies (Art. 7, IV) — Processing for studies by research organizations, anonymized when possible.
Relevant for health tech, academic platforms, and clinical data systems.
Tier 3: Specialized
7-8. Exercise of rights in judicial/administrative proceedings (Art. 7, VI and VII) — Retaining data for legal defense or proceedings.
Your legal team cares about these. As a developer, implement data retention policies that support them.
9. Health protection (Art. 7, VIII) — Processing to protect life or physical safety, performed by health professionals.
Relevant for health tech applications. Requires the processor to be a qualified health entity.
10. Credit protection (Art. 7, X) — Processing by credit protection agencies.
Relevant for fintech and banking. Requires specific authorization for credit bureau queries.
The architecture implications
Each legal basis creates different system requirements:
The key insight: your data architecture should tag every piece of personal data with its legal basis. When a user exercises their right to deletion (Art. 18), the system needs to know which data falls under consent (deletable) and which falls under legal obligation (must be retained). Without this tagging, you either over-delete (violating legal obligations) or under-delete (violating LGPD).
Common mistakes
1. Consent for everything. Consent is revocable. If your core service depends on data processed under consent, a single revocation can break the user's account. Use contract execution for data essential to the service.
2. Legitimate interest without documentation. "We need this data for our business" is not a Legitimate Interest Assessment (LIA). You need the three-part test documented and stored. DPO2U's Auditor Agent checks for this automatically.
3. Pre-checked consent boxes. LGPD requires consent to be "free" — a pre-checked box is coercion by default. This is the single most common violation in Brazilian web applications.
4. Blanket consent. "By using our site, you agree to our terms" covers nothing under LGPD. Consent must be specific to each purpose and each data category.
5. Missing revocation path. If there's no functional "unsubscribe" or "delete my data" button, the consent was never valid — regardless of what the user clicked when signing up.
How DPO2U automates this
The dpo2u/lgpd/v1 schema requires consent_mechanism as a mandatory field — the system won't accept a policy submission without it. The Auditor Agent validates that the declared mechanism matches a recognized legal basis (opt-in-explicito, contrato, legitimo-interesse) and flags non-standard values for review.
This doesn't replace legal counsel. It ensures that the technical implementation matches the legal declaration — and that the mismatch is caught before it reaches production, not during an ANPD investigation.
For the full schema specification, see LGPD Kit Schema. For how attestations are verified on-chain, see About DPO2U.