Regional frameworks and privacy signals

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.

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. The same floor applies when a regional rule matches a visitor in a US state whose law requires honoring GPC — California, Colorado, Connecticut, Delaware, Maryland, Minnesota, Montana, New Hampshire, New Jersey, Oregon and Texas — even if that rule is a custom one without a US opt-out framework and "respect GPC" is off. 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. A visitor who matches no regional rule at all is not subject to the state floor.

While the signal is honored, it holds for every automatic grant: the first-visit defaults, a hidden region's silent grant, and categories the matched rule leaves out of scope are all withheld. Confirming the US opt-out panel does not grant back what the signal withheld either, because confirming the panel is a decision about the opt-out rights, not an opt-in to categories.

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:

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.

Showing visitors that the signal was processed

California's regulations ask a business to show whether it processed a visitor's opt-out preference signal. The banner does this in two places, and both report what the runtime actually applied, not merely that the browser sent the signal:

• A passive confirmation. When the matched rule honors GPC and the signal was applied to the visitor's consent, a small notice ("Opt-Out Request Honored" for California rules) appears in the corner of the page. The visitor does not have to open anything. It does not open the banner, so a returning visitor who already made a choice still sees only the notice. It is announced to screen readers as a status message, uses your banner's theme colours, and steps aside while a consent dialog is open. If the visitor closes it, it stays hidden for the rest of the browser session.
• The US opt-out panel. The panel's status line says the signal is honored only when it was. If the signal was applied to some rights but not others (for example, a per-right policy that does not honor GPC for sale and sharing), it names which rights it was and was not applied to. If the visitor has since opted back in on your site, it says the signal is not fully applied to their current choices.

The confirmation is a per-rule setting, "Confirm honored opt-out signals", under the rule's allow-until-declined display options. It is on by default for rules where honoring GPC is mandatory: the CCPA and US opt-out frameworks, rules with a hard opt-out signal mode, and visitors in the US states listed above. It is off by default everywhere else, and it never shows when the signal was not applied. The wording can be changed per language and per rule through the rule's translation overrides (usPrivacy.gpcStatusHonored, gpcPartiallyHonored, gpcNotHonored and gpcStatusDismiss).

Banners that load the shared latest core show the confirmation without being republished. Banners with purposes enabled pin their core version, so they show it after their next republish.

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.