Cookie banners and Brazil's LGPD: what the law and the ANPD require from your site

Open your site in a private window. Before clicking anything, open DevTools on the Network tab and reload. If google-analytics.com, connect.facebook.net or analytics.tiktok.com shows up in the list, your cookie banner is decorative: it asks the question after the answer has already been given.

It's the most common mistake we see in the Sentinela security audit, and it's not the only one. The banner is the part of Brazil's data protection law (LGPD) that any visitor — and any regulator — can check without asking for access to anything. That's why it's worth getting right.

What the LGPD says (and what it doesn't)

The LGPD has no article called "cookies". What it has are general rules that apply to any personal data, and a tracking cookie is personal data whenever it identifies a person or makes them identifiable — which is exactly what an ad pixel is for. If you know the European GDPR, the logic will feel familiar.

The points that matter for the banner:

• Art. 7, I and art. 8 — when the legal basis is consent, it must be free, informed and unambiguous, and given before the processing.
• Art. 8, §4 — generic consent is void. "By continuing to browse you accept" doesn't cut it.
• Art. 8, §5 — the data subject can withdraw consent at any time, through a free and easy procedure.
• Art. 9 — the data subject has the right to clear information about purpose, duration and who the data is shared with.

In 2022 the ANPD (Brazil's data protection authority) published its Guidance on Cookies and Personal Data Protection (Guia Orientativo sobre Cookies e Proteção de Dados Pessoais), which translates these rules into banner terms. It isn't law, but it's how the enforcing authority reads the law — and it's the document that will be cited if someone complains about your site.

What the law does not require: a specific layout, a button color, a certified vendor. It requires the choice to be real.

What the ANPD guide asks of the banner

The guide boils down to six practices:

1. Prior blocking. Non-essential cookies are only set after consent. A banner that shows up with the pixel already fired doesn't collect consent — it records a done deal.
2. Reject on the first layer. The visitor must be able to reject non-essential cookies without digging into a sub-menu. Hiding "reject" behind "settings" is the pattern the guide flags as problematic.
3. No pre-ticked boxes. Optional categories start off. Consent is an action, not an omission.
4. Separation by purpose. Necessary, analytics, advertising, functional — the visitor chooses per category, and each one explains what it's for.
5. Accessible information. A link from the banner to the cookie policy, listing which cookies exist, whose they are and how long they last.
6. Easy withdrawal. A permanent path (footer link, floating button) to reopen preferences and change your mind.

One point worth stressing: strictly necessary cookies (session, cart, the cookie that stores the choice itself) don't depend on consent. They rest on another legal basis, and the banner should inform about them, not ask permission for them.

Reject with the same weight as accept

The ANPD guide talks about rejection on the first layer. The European reading (EDPB guidelines 03/2022 on dark patterns) goes further and treats as a defect a reject button that is faded, grey, small or shaped like a link while accept is a colored button.

The practical rule we use in audits: if a visitor in a hurry can only see one button, the choice isn't free. "Reject" needs the same fill, the same size and the same contrast as "Accept". "Customize" can be secondary — it isn't a final decision, it's a path to one.

Recording the choice (the part nobody sees)

The banner collects consent; the record is what proves it existed. If the ANPD or a data subject asks "when did this person accept advertising?", the answer has to exist:

• date and time of the decision;
• what was accepted and what was rejected, per category;
• which version of the banner was live (if the text or the categories changed, the old consent may not cover the new one);
• an identifier for the decision that isn't itself unnecessary personal data.

Storing the IP in plain text "just in case" is self-defeating: you create a personal-data database to prove you respect personal data. A hash solves the proof problem without creating the other one.

The five mistakes that show up most

From what we see in audits, in order of frequency:

1. Tracker before consent. GA4, Meta Pixel or TikTok loading on the first request. The banner exists, but the script doesn't wait for it.
2. "Accept or nothing" banner. Only one button, or reject buried on the second level.
3. Consent that changes nothing. The visitor rejects and the scripts load anyway — the banner stores the choice, but nobody wired the choice to tag loading.
4. No way back. After accepting, there's nowhere to change your mind.
5. Generic cookie policy. Copied text that doesn't list the cookies the site actually uses — because nobody knows what they are.

The third is the sneakiest, because it passes a visual check: the banner appears, it has both buttons, and it still protects nothing. Only the Network tab gives it away.

Checklist to check your site today

In a private window, without clicking anything:

• No analytics or advertising script appears in the Network tab before the choice.
• The banner has "Reject" on the first screen, with the same prominence as "Accept".
• No optional category comes pre-ticked.
• After rejecting and reloading, the trackers stay out.
• There's a permanent link to reopen preferences.
• The cookie policy lists the real cookies, with vendor and duration.
• You can show, for a specific visitor, what they chose and when.

If any item failed, the risk isn't theoretical: the LGPD provides for fines of up to 2% of revenue, capped at R$ 50 million per violation (art. 52), plus warnings and public disclosure of the violation — which for many companies hurts more than the fine.

How to fix it without building everything by hand

You can meet this checklist with your own code, but each item is a project: inventory the cookies, hold the scripts until consent, keep the record, keep the policy up to date when marketing adds a new tag.

That's what a consent management platform (CMP) is for. Ours is Cokei, from M2HP — the same company behind Sentinela. It scans the site's cookies, holds the scripts that depend on consent, records each choice (with the IP stored only as a hash) and generates the cookie policy from what it found. "Reject all" appears on the first layer with the same visual class as "Accept", and there's no way to turn it off in LGPD and GDPR modes.

An honest caveat, which Cokei itself makes: no automatic blocking catches 100% of cases. Inline scripts that set cookies directly and tags fired from inside Google Tag Manager need manual tagging or Google Consent Mode. The platform tells you where the limit is instead of promising automatic compliance.

If you want to know how your banner looks from the outside, the next post in the series shows what the Sentinela audit checks and how to fix each finding. And if you're choosing a tool, we put together a comparison of consent platforms.