A banner with no reject option: what the LGPD audit flags and how to fix it
The LGPD layer of the Sentinela audit looks at your site as an anonymous visitor and points out what's wrong with consent. The six possible findings, what each one means and how to fix each one.
Short answer
The Sentinela LGPD audit visits your site without accepting anything and checks for a banner, a reject option and any tracker loading before the choice. The most serious findings are trackers with no banner and a banner with no reject option; both are fixed by blocking scripts until consent and putting "Reject" on the first layer.
When the Sentinela audit reaches the LGPD layer — the checks for Brazil's data protection law, the local counterpart of the European GDPR — it does what a regulator would do: it enters your site as a visitor who just arrived, without accepting anything, and writes down what happened. Which third-party scripts loaded? Which cookies were set? Is there a banner? Does it let you reject?
The result comes out as findings in the report, each with a severity. This post explains the six that deal with consent, what each one means and how to fix it.
If you don't yet know what a banner needs to have, start with the previous post in the series.
How the check works
The LGPD probe requests the site's home page as a new visitor: no cookies, no clicks. In the response, it looks for:
- known trackers — Google Analytics, Google Ads, Meta Pixel, TikTok, LinkedIn, Hotjar and the like — by the script loaded and the cookies set;
- a consent banner, by the signature of known platforms and by common markup of home-grown banners;
- the reject option inside the banner.
All of this is external observation: the audit doesn't log into your server or into your consent tool's dashboard. That's exactly why it's useful — it sees what the visitor sees.
The findings, one by one
Tracking cookies or scripts with no banner
What it says: the site set tracking cookies, or loaded analytics and advertising scripts, on the first request, and no consent banner was found.
Why it's serious: it's processing of personal data for analytics or advertising with no consent at all. There's nothing to discuss about the quality of the banner, because it doesn't exist.
How to fix: install a banner that blocks the scripts until consent. Installing just the notice doesn't solve it: the finding comes back as the next one on this list.
Tracking scripts detected (with a banner)
What it says: there's a banner, and there are trackers on the page. From the outside, we can't say whether they wait for consent.
How to check: in a private window, open DevTools on the Network tab before any click. If the trackers' domains show up there, they don't wait. Reject, reload and check again — they need to stay out.
Consent banner not detected
What it says: we didn't find any known banner. It may be a real absence or a home-grown banner we didn't recognize.
How to fix: if the banner exists and is built in-house, a recognizable class on the container (for example cookie-consent) already helps. If it doesn't exist, this is the first step.
Banner with no visible reject option
What it says: we found the banner, but no "Reject", "Decline" or equivalent button or link. It's the "accept or nothing" banner.
Why it's serious: consent with no alternative isn't free (LGPD, art. 8, §4), and the cookie guide from the ANPD (Brazil's data protection authority) asks for rejection on the first layer. It's a high finding, and it weighs on LGPD and GDPR compliance in the report.
How to fix: put "Reject" (or "Necessary only") on the banner's first screen, with the same visual prominence as "Accept" — same fill, size and contrast. A grey link at the bottom of the banner isn't enough.
Reject option not verifiable from the outside
What it says: the banner exists, but it's built in shadow DOM — an area of the page isolated from the main HTML, which some platforms use so the site's styles don't break the banner. The buttons don't appear in the served HTML, so we can neither confirm nor deny that rejection exists.
Why it's informational only: saying "your banner doesn't let visitors reject" without seeing the buttons would be making it up. The finding says what we couldn't see and asks you to check in your tool's dashboard. It doesn't lower your score.
How to solve it for good: it depends on the platform. If it exposes the banner configuration publicly, the audit can read it instead of guessing — and that's what we do with Cokei, as explained below.
The Cokei case: rejection verified through the configuration
Cokei, M2HP's consent platform, draws its banner in shadow DOM. Because of that, until October 2026, every site with Cokei got the "not verifiable" finding.
Today the audit recognizes the Cokei script on the page, reads that banner's public configuration and checks whether rejection is enabled. There are three possible outcomes:
- rejection enabled: no rejection finding;
- rejection disabled: the high "banner with no reject option" finding, with the configuration cited as evidence;
- we couldn't read the configuration: the informational finding comes back, with no guess in either direction.
In practice, the first is the only one that happens today: in LGPD and GDPR modes, Cokei forces "Reject all" on the first layer, with the same visual class as "Accept", and offers no switch to turn it off. When that rule went in, the banners that had rejection disabled got their version bumped — and visitors were asked again, because consent collected with no reject option isn't valid.
One thing the configuration does not tell us is whether the reject button looks as important as the accept button on your site's screen. With Cokei that's guaranteed by the banner's own design; with another platform, it's worth checking with your own eyes.
Fix in the right order
If your report brought several of these findings, the order that reduces the most risk per hour of work is:
- Block trackers until consent. That's what turns the banner from a notice into a control.
- Put rejection on the first layer, with the same weight.
- Provide a way back — a permanent link or button to reopen preferences.
- Record the choices with date and banner version.
Cokei covers all four: it scans the cookies, holds the scripts that depend on consent, records each decision and keeps the "Manage cookies" button in the corner of the page. If you run Google Ads or GA4, also set up Consent Mode v2 — it's what keeps Google from losing the conversions of people who rejected.
After fixing, run the audit again. The finding only leaves the report when the fix is observed in the next run; until then it stays there, because the absence of a finding only counts when it was measured.
A cookie banner that holds up to LGPD and GDPR, with nothing built by hand.
Cokei is the consent platform from M2HP, the company behind Sentinela: it finds the cookies on your site, holds back the ones that need consent and records each visitor’s choice. Reject weighs the same as accept. Free plan with no end date.