Home › Blog › LGPD for SaaS

LGPD for SaaS: the practical compliance checklist (Brazil's data law)

October 12, 2026 · ~9 min read

LGPD (Lei 13.709/2018) is Brazil's data-protection law — its equivalent of the GDPR. If your SaaS has users in Brazil, it applies, wherever your company sits. For a small SaaS, compliance isn't a legal tome: it's a handful of decisions and a few features in code. Here's the practical checklist, from a builder's point of view.

1. Have a legal basis for each piece of data

LGPD (art. 7) requires a legal basis for every processing activity. For a SaaS, almost everything falls under three: performance of a contract (the data the service needs to work), consent (marketing, non-essential trackers) and legitimate interest (e.g. fraud prevention, used carefully). The rule of thumb: don't store a data point without knowing which basis supports it.

2. Collect the minimum

The necessity principle: only collect what the service actually uses. Every "might be handy someday" field is risk with no upside. Less data stored = less exposure in a breach and less to explain later.

3. A transparent Privacy Policy

The data subject has the right to know what you collect, why, for how long, and who you share it with. A clear policy (not a generic copied template) covers this. List your sub-processors (next item) and the data-protection contact.

4. Data-subject rights — and the delete button

Art. 18 gives the user the right to access, correct, port and erase their data, plus revoke consent. In practice, your code has to be able to export and delete a person's data on demand — really delete, not just "deactivate".

// ✅ real deletion: remove the subject and linked data
await db.tx(async t => {
  await t.sessions.deleteMany({ userId });
  await t.orders.anonymize({ userId });   // keep what tax law requires, anonymized
  await t.users.delete({ id: userId });
});

Mind item 6: deleting from the main table but leaving a copy in cache, logs, eternal backups or an open bucket is not deletion.

5. Cookie and tracker consent

Non-essential cookies (analytics, ad pixels) need prior consent — opt-in, not opt-out. A banner that merely notifies isn't enough: the tracker only fires after acceptance, and declining must be as easy as accepting. What's essential for the service (session, security) doesn't require consent.

6. Retention and disposal

Data isn't meant to be kept "forever". Set a retention period per data type and delete/anonymize at the end — including in backups and logs. Automating expiry prevents the silent pile-up that turns into liability.

7. Security is a legal duty (arts. 46 and 48)

This is the item that ties LGPD to the rest of your code. Art. 46 requires adequate security measures; art. 48 requires notifying incidents to the ANPD (the authority) and to data subjects when there's risk. In plain terms: a leak via broken multi-tenant isolation, an open Firebase rule or disabled Supabase RLS isn't just a bug — it's a reportable data incident, with deadlines and exposure. Weak security is non-compliance.

8. Sub-processors and international transfer

Stripe, Firebase/Supabase, Vercel, your email provider — each is a processor handling data on your behalf, and several sit outside Brazil (art. 33, international transfer). You need to list them in the policy and ensure their contract offers the safeguards. It's not a blocker; it's transparency.

9. Data-protection officer and contact channel

LGPD (art. 41) asks for an encarregado (DPO) — the person/channel that receives data-subject requests and talks to the ANPD. For a small SaaS, that can be you, with a contact email published in the policy.