Skip to documentation content

Regional frameworks and privacy signals

The per-region banner defaults CookieBeam ships as starting points, and how Global Privacy Control interacts with an explicit choice.

CookieBeam ships a set of named regional frameworks. Each one seeds a regional rule with a banner mode, consent defaults, and presentation overrides for the visitors it matches.

These are configurable defaults, not legal advice. They are starting points chosen to be reasonable for a common case. They are not a determination that a given model is correct for your site, your sector, or your processing, and applying one does not transfer any obligation to CookieBeam. Have your counsel review the framework you apply and the values it seeds.

Shipped frameworks

Each framework matches on country, and on state or province where noted. optIn means nothing non-essential is granted until the visitor agrees; optOut grants at load and lets the visitor withdraw; notice informs without seeding a consent state.

FrameworkMatchesBanner mode
GDPR (EU/EEA)30 EU/EEA and associated countriesoptIn
UK GDPRUnited KingdomoptIn
CCPA/CPRAUnited States — CaliforniaoptOut
US Opt-Out StatesUnited States — 18 states with opt-out lawsoptOut
LGPDBraziloptIn
Quebec Law 25Canada — QuebecoptIn
PIPEDACanadanotice
PIPLChinaoptIn
APPIJapanoptIn
PIPA KoreaSouth KoreaoptIn
PDPA ThailandThailandoptIn
PDPA SingaporeSingaporeoptIn
Vietnam PDPDVietnamoptIn
Australia Privacy ActAustralianotice
NZ Privacy ActNew Zealandnotice
POPIASouth AfricaoptIn
NDPRNigeriaoptIn
Kenya DPAKenyaoptIn
FADPSwitzerlandoptIn
KVKKTurkeyoptIn
Argentina PDPAArgentinaoptIn
Colombia Law 1581ColombiaoptIn

The three notice frameworks — PIPEDA, Australia and New Zealand — deliberately seed no consent defaults. The product's own description of the Canadian default says to configure consent defaults manually. If you apply a notice framework and change nothing else, you have configured a banner that informs and records, not one that gates.

Frameworks are grouped into three regimes internally — a GDPR family, a US opt-out group, and notice — and it is the regime, not the individual framework, that determines how privacy signals behave.

Applying a framework does not narrow request types in the privacy request portal. That portal uses its own, shorter region mapping, documented in Data subject requests. A visitor in a country that has a banner framework here may still see only the fallback request types.

Global Privacy Control

Global Privacy Control is implemented, but honoring it is not on by default. Whether the runtime acts on the signal is resolved in this order:

  1. A self-hosted gpc configuration key, when present, decides it.
  2. Otherwise a privacy-signals integration decides it, through its "respect GPC" setting.
  3. Otherwise honoring is off.

One case overrides all three: when the matched regional rule is a US opt-out regime, honoring is switched on and cannot be switched off, because the opt-out is legally mandated there. That floor only ever raises honoring — nothing can disable GPC inside a mandated region — but outside it, a banner with no signal configuration ignores GPC.

Do Not Track is off unless a privacy-signals integration enables it explicitly; it is treated as a deprecated signal.

Where the signal is honored, the runtime records on the consent row both which signal was present and whether it shaped the recorded state. That flag is written at the time of the event, so a record remains auditable later without consulting your current settings — changing your configuration tomorrow does not rewrite what yesterday's record says.

Detection requires an actually readable, actually set signal. If the runtime cannot read the browser environment, it records no signal rather than assuming one: a missing environment must not opt every visitor out of everything. (A separate, deliberately fail-safe check does treat an unreadable environment as "signal present", but it governs only whether an A/B experiment override may be applied — it never shapes a consent record.)

Once a signal is being honored, how it interacts with a visitor's choice depends on the regime:

RegimeBehaviourWhy
GDPR familyAlways pre-selects deny; an explicit opt-in still overrides the signalAn automated signal may not suppress a freely given, explicit opt-in
US opt-outThe signal is a binding opt-outGPC is a recognized opt-out mechanism under California rules
Notice and othersAdvisory by default; can be configured to pre-select denyNo statutory binding effect to implement

Two details are worth calling out because they are easy to get wrong:

  • The GDPR-family behaviour is fixed. It cannot be configured into a hard opt-out, even by the per-banner consent-precedence setting, because suppressing an explicitly granted category would contradict the opt-in model.
  • Under US opt-out, a visitor can still opt back in for a specific right through the opt-out panel, and that deliberate, right-specific choice overrides the signal. That is a narrow exception carried in the runtime's per-right logic, not a general override of the signal.

For regimes with no statutory binding signal, the per-banner setting decides: left at its default the signal is advisory, and switched over it becomes a default-deny that an explicit choice can still override. It never becomes a hard opt-out, because there is no legal basis to lock the visitor out of a choice they are entitled to make.

Choosing and reviewing

Applying a framework writes a regional rule you can then edit — the seeded values are a starting point, not a locked policy. Two questions are worth taking to your counsel before you rely on a framework:

  1. Is the mode right for your processing? A notice or opt-out default is seeded because it is common in that region, not because it is correct for every site operating there.
  2. Does the country match reflect where your visitors actually are? Matching is by detected location. Visitors using a VPN, or travelling, are matched by where they appear to be.