In the first week of September 2025, the French data protection authority CNIL handed down two of the largest cookie-related fines in European history: €325M against Google and €150M against SHEIN. The two decisions are not about exotic edge cases. They are about the cookie banner on the page and the cookies that load behind it. For any SaaS that operates a website (which is to say, every SaaS), the practical lesson is short: the "Reject all" button has to mean what it says, and it has to be as easy to click as "Accept all". This article walks through what each fine actually punished, the two design principles regulators are now enforcing, and a practical pattern for a banner that does not get you a letter from CNIL.

What happened in September 2025

The two fines came out of the same CNIL action plan that has been running since 2019, but they enforce two different problems and it is worth keeping them separate.

Google: €325M for asymmetric design (1 September 2025)

The decision broke down as €200M against Google LLC and €125M against Google Ireland. The CNIL targeted two practices. The first was displaying advertisements between Gmail users' emails without their consent. The second was the cookie banner shown during Google account creation. Until October 2023, the "express personalization" path required users to click six times to refuse personalized advertising cookies, against two clicks to accept them. The CNIL ruled that consent collected this way was "neither free nor informed" and ordered Google to fix the flow within six months, with a daily penalty of €100,000 for each day of delay after that.

SHEIN: €150M for placing cookies before consent (3 September 2025)

Two days later, the same CNIL fined SHEIN €150M. The violation was different and arguably worse: cookies were placed on visitors' devices without any consent at all. There was no "Accept all" or "Reject all" choice that mattered, because the cookies dropped before the user had a chance to decline. The CNIL framed this as one of the non-compliant practices it remains vigilant about: placing cookies without the user's consent.

Both decisions used the same underlying rule (Article 82 of the French Data Protection Act, transposing the ePrivacy Directive). The difference is what they enforce: Google was punished for how the choice was offered; SHEIN was punished for not offering a real choice at all.

Design principle one: parity between Accept and Reject

The Google fine codifies a principle that CNIL and several other DPAs have been telegraphing for years: the choices presented to a user must be substantively equivalent. Concretely, that translates into a short checklist for the buttons on your banner.

  • Same number of clicks. If "Accept all" is one click, "Reject all" is one click. No menu drill-down to find the refuse option.
  • Same visual weight. Same font size, same button style, same prominence. A grey "Reject" against a blue "Accept" is asymmetric, even if both buttons are technically visible.
  • Same position in the flow. Both buttons in the first layer of the banner. Not "Accept" up top and "Manage preferences → ... → Reject" three taps deep.
  • Equal language. "Accept all" and "Reject all" is the symmetric pattern. "Accept all" and "Customize" is not — it conceals the refusal option behind a different verb.

This is the standard that France's CNIL, Germany's BfDI, Spain's AEPD, and the European Data Protection Board have all aligned on. Banner vendors who still ship asymmetric designs are now openly aware they are selling regulatory risk.

Design principle two: nothing loads before consent

The SHEIN fine codifies the other half of the rule. A correctly designed banner is useless if the cookies it claims to gate fire anyway. The principle is mechanical:

  1. On first visit, the banner appears.
  2. Until the user clicks "Accept all" or makes a granular choice, only strictly necessary cookies may be set. Strictly necessary means cookies required to deliver the service the user explicitly asked for: a session cookie, a CSRF token, a load-balancer affinity cookie.
  3. Analytics, advertising, personalization, A/B testing, retargeting, fingerprinting — none of these load on the first request.
  4. If the user clicks "Reject all", those non-essential cookies stay un-fired for the rest of the session.

In practice, this means your scripts have to be loaded conditionally. A common pattern is to gate every non-essential <script> tag behind a consent state held in a JavaScript variable, with the analytics or ad SDK loading only after the variable flips to granted. If you load Google Analytics from a static HTML tag without that gate, you are SHEIN's pattern.

A compliant cookie banner in practice

What does a banner that satisfies both principles actually look like? The mechanical recipe:

  1. First layer: a short message explaining that cookies are used, with two clearly equivalent buttons: Accept all and Reject all. Optionally a third "Manage" link for granular control.
  2. Visual treatment: both buttons share the same color family, same size, same border radius. Either both filled or both outlined. The reject is not greyed out.
  3. No pre-checked boxes in the granular preferences. Each category starts off. The user opts in, not out.
  4. Easy revocation: a persistent "Cookie preferences" link in the footer so the user can change their mind. Hidden revocation flows are themselves a separate violation.
  5. Consent record: store proof of consent that includes the exact text the user saw and the version of the policy they accepted. CNIL routinely asks for this in investigations.
  6. Strictly-necessary-only on load. No conditional firing tricks. Until consent is granted, nothing fires beyond what the service strictly needs.

Common mistakes that still get flagged in 2026

  • "Accept all" highlighted in color, "Reject all" rendered as plain text or a small grey link. Pure asymmetry. The CNIL ruled this is non-consent in the Google decision.
  • Cookie banner with no "Reject all" at the top level, only a "Manage" or "Customize" option. The European Data Protection Board has said the refusal must be available in the same layer as the acceptance.
  • "You can change your preferences later" buried in a privacy policy. Revocation has to be accessible without hunting.
  • Analytics tag that fires on every page load regardless of consent state. This is the SHEIN pattern. Audit your <head> manually before you assume your consent platform is doing its job.
  • Granular preferences with everything pre-ticked. Consent has to be a positive action. Pre-ticked is no consent.

Where Termerly fits in the picture

Termerly has a free consent banner that you embed with a single async script. It is designed for the SaaS case where you do not run programmatic advertising and you do not need IAB TCF compliance. If you are an ad tech platform or you sell display inventory, you need a TCF 2.3 compliant CMP and Termerly is not it.

For the rest, where the banner exists to satisfy ePrivacy and GDPR for analytics and product cookies, what Termerly provides is concrete:

  • The banner renders with your branding (color, position, light or dark). The "Reject all" and "Accept all" buttons share the same visual weight by default, so the asymmetric-design trap is closed.
  • Every "Accept" registers which exact version of the policy the user saw. That is the consent record CNIL asks for in investigations.
  • The policy text the banner links to is the same one you publish in your Termerly legal center. Updating the policy does not require you to redeploy your site.
  • If you run multiple SaaS products from one account, each project gets its own banner and its own consent log, so a customer audit is scoped to the right product.

Conclusion

The €475M of fines from CNIL's first week of September 2025 are not aimed at edge cases. They land on patterns that are still everywhere on the modern web: a louder Accept button, a quieter Reject, and an analytics tag that fires anyway. The fix is mechanical and cheap if you do it before you become the test case. Audit your banner for parity, audit your <head> for unconditional script tags, and log every consent against a versioned policy you can produce on demand.

If you do not have a banner yet, or yours is the asymmetric kind that came bundled with a tracker, open a free Termerly project and ship a parity-by-default banner today. It is the kind of work that costs an afternoon now and saves a much longer conversation later.