Cookie Consent

The Consent Manager

The consent manager decides whether a visitor is asked about cookies, what they are asked, and what loads as a result.

Where to find it

Architect Panel → Security:

• Cookie Consent — categories, services, cookies, scans and records

Three modes

• Opt-in everywhere — every visitor is asked, and nothing non-essential loads until they agree. The strictest and the simplest to defend.
• By region — the treatment depends on where the visitor appears to be.
• Notice only — visitors are informed rather than asked.

How region is worked out

From a country header supplied by your infrastructure — the setting defaults to the one a common content delivery network provides. From that country the platform resolves a jurisdiction and a mode:

• United Kingdom — opt-in.
• European Economic Area — opt-in.
• Brazil — opt-in under its own regime.
• United States — opt-out.
• Elsewhere — notice.

When the region is unknown

There is a separate setting for that case, and it defaults to the strictest treatment. That default is correct and should generally be left alone.

The country header is not always present — a direct request, a different network path, a visitor behind something unusual. Falling back to opt-in means an unknown visitor is treated properly rather than tracked by default.

Opt-in everywhere is often the right choice

Region-based treatment is legitimate and it is more to maintain, more to explain and more to get wrong. If most of your visitors are in an opt-in jurisdiction anyway, treating everybody the same is simpler and defensible.

Consent must come before loading

The rule the whole system exists to implement. A tag that loads and then asks has already set its cookies and sent its request, and the banner is decoration.

Which is why third-party tags belong in the consent manager as services rather than being placed in a page template.

Withdrawal must be as easy as giving

A visible route to change a decision — conventionally a footer link. The platform can also sweep cookies when consent is withdrawn, which is what makes withdrawal mean something rather than being a recorded preference nothing acts on.

Test as a visitor

In a private window, with developer tools open, and look at what is set before you agree. That is the only test that matters and it takes two minutes.

Worked example

An organisation chose opt-in everywhere for simplicity, left the unknown-region fallback at its strictest, and enabled the cookie sweep on withdrawal. A private-window check before launch found an analytics cookie being set before any choice, because the tag was in a template rather than registered as a service.

Recommendations

• Opt-in everywhere unless you have a reason otherwise.
• Leave the unknown-region fallback strict.
• Register tags as services, never in a template.
• Check in a private window what loads before agreement.

Categories and Services

The consent manager works in two layers: categories a visitor chooses between, and services that belong to them.

Where to find it

Architect Panel → Security:

• Cookie Consent — categories, services, cookies, scans and records

Categories

Each has a name, a friendly name, a description, and several flags: whether it is required, whether it defaults to on, whether it emits consent-mode signals, whether the browser’s Global Privacy Control applies to it, and whether it is hidden.

Keep the set small and conventional

Strictly necessary, functional, analytics and marketing covers nearly everything and is what visitors expect. A bespoke set of nine categories is a set nobody reads before clicking accept.

Required means genuinely required

A category marked required cannot be declined, so it must contain only things the site genuinely cannot work without — the session cookie, the consent record itself, security tokens.

Marking analytics as strictly necessary is the single most common bad-faith configuration, and it is exactly what an investigation looks for.

Default-on needs care

In an opt-in jurisdiction, non-essential categories must start off. Default-on belongs to opt-out jurisdictions, where the visitor has the right to refuse rather than the right to be asked.

Global Privacy Control

Some browsers send a signal that the visitor objects to sale or sharing of their data. Categories can be marked as respecting it, which means those visitors are treated as having declined without being asked.

Respecting it is legally required in some places and is good practice everywhere.

Services

Each third party you load is registered as a service in a category, with its provider, purpose, privacy policy address, retention period and where the data goes.

Crucially it also carries how it is loaded — a script address, inline script or attributes — and the patterns used to block it until consent is given.

The blocking patterns are the mechanism

They are what actually stops the third party loading. A service registered with a purpose and no blocking pattern is documented but not controlled, which is the worst of both.

Record the purpose honestly

Purpose, retention and data location are what you publish to visitors and what you rely on if asked. "Analytics" is not a purpose; "counts page views to see which content is used" is.

Review what is registered

Services accumulate. Anything nobody is reading should be removed rather than continuing to collect with a documented purpose.

Worked example

A site uses four categories with only session and security cookies marked required, analytics and marketing both defaulting to off and both respecting the browser privacy signal. Each third party is registered with a real purpose sentence and blocking patterns, verified by checking nothing loads before agreement.

Recommendations

• Four conventional categories, not nine bespoke ones.
• Required means the site breaks without it.
• Always set blocking patterns — the purpose alone controls nothing.
• Respect the browser privacy signal.

Cookie Inventory and Scanning

The consent manager holds an inventory of cookies, and can scan your site to find them.

Where to find it

Architect Panel → Security:

• Cookie Consent — categories, services, cookies, scans and records

The inventory

Each entry records the cookie’s name and how it is matched, its domain, its category and service, its provider, its purpose, its expiry, what kind of storage it is, whether it is first-party, where it came from, and when it was last seen.

That is the cookie table a privacy notice needs, maintained as data rather than written by hand and immediately out of date.

Match modes matter

Many cookies have generated names with a fixed prefix. Matching by pattern rather than exact name is what keeps the inventory accurate as those names change.

The scan finds what you did not know about

A scan requests pages, records what gets set, and reports findings — how many pages were scanned, how many cookies found, and how many are new.

Cookies discovered this way are marked as coming from a scan, so you can see which entries you declared and which the site is actually setting.

The gap between the two is the point

Every organisation believes it knows what its site sets. The first scan reliably finds things nobody declared — an embedded video, a font service, a chat widget, a tag added for a campaign.

Each of those is a third party receiving your visitors’ data, and each needs categorising or removing.

Scan after changes

New pages, new embeds, new integrations and new campaigns all bring cookies. A scan after any significant change, and periodically regardless, keeps the inventory honest.

Last seen tells you what to prune

A cookie in the inventory that scans no longer find is one you can probably remove — the service was retired and nobody updated the notice. Keeping the list current is as important as building it.

Categorise every finding

An uncategorised cookie is one the consent manager cannot govern. Each finding should be assigned to a category and a service, or the thing setting it should be removed.

Publish the inventory

A cookie table in your privacy notice, generated from this rather than written separately, is accurate by construction. Two hand-maintained lists diverge within a month.

Worked example

An organisation’s first scan found eleven cookies it had not declared, five from an embedded map on one page. The map was replaced with a static image, three findings were categorised, and the remainder came from a chat widget that was registered as a service. Scans now run after each release.

Recommendations

• Run a scan before you write anything — assumptions are wrong.
• Match by pattern where names are generated.
• Categorise every finding or remove its source.
• Publish the inventory from this list, not a hand-written one.

Consent Records

Every consent decision is recorded. That ledger is what you produce when somebody asks whether you had permission.

Where to find it

Architect Panel → Security:

• Cookie Consent — categories, services, cookies, scans and records

What a record holds

A consent identifier, the visitor, the signed-in user where there is one, the action taken, which categories were chosen, the policy version in force, the jurisdiction and country, the address and browser, the page and referrer, the language, where the decision came from, when it was made and when it expires.

The sensitive parts are filled in server-side

Time, address, browser and jurisdiction are recorded by the endpoint rather than accepted from the page, and the submitted values are constrained.

That matters: a consent record a visitor’s browser could dictate would be worthless as evidence. Recording it server-side is what makes it a record rather than a claim.

The policy version is the important field

Consent is to a specific version of what you told people. When your privacy notice or cookie usage changes materially, the version changes and previous consent no longer covers the new position.

Without it, you cannot say what somebody actually agreed to — only that they agreed to something, once.

Consent expires

Each record carries an expiry, and re-asking periodically is expected practice. Consent given three years ago and never revisited is weak.

Twelve months is a common period; longer needs a reason.

It is the evidence, so keep it

The whole purpose of the ledger is to answer a question later. Retain records for as long as you might need to demonstrate the consent — which is longer than the consent itself is valid.

It is also personal data

Addresses, browsers and pages visited. Restrict who can read it, do not use it for anything other than demonstrating consent, and include it in your own retention thinking.

Withdrawals are records too

A withdrawal is recorded like any other action, which is what lets you show when somebody changed their mind and that you acted on it.

Check it works before you need it

Give consent as a visitor, withdraw it, and confirm both appear with the right categories and the right policy version. The moment you need this data is not the moment to discover it was not being written.

Worked example

An organisation records consent against a policy version it increments whenever its notice changes materially, with a twelve-month expiry. When a complaint arrived, it produced the specific record, its categories and the version of the notice in force that day.

Recommendations

• Increment the policy version on material changes.
• Expire consent and re-ask, around twelve months.
• Restrict the ledger — it is personal data.
• Test a consent and a withdrawal before launch.

Banner Appearance

How the banner looks is not only presentation. Several of these settings decide whether your consent is validly obtained.

Where to find it

Architect Panel → Security:

• Cookie Consent — categories, services, cookies, scans and records

The settings

• Layout and position — the shape and where it sits.
• Colour scheme and accent colour.
• Dim the page behind.
• Block the page until a choice is made.
• Show "Reject all".
• Show "Preferences".

Show "Reject all"

The single most important one. Refusing must be as easy as accepting, and a banner offering one prominent Accept and a buried Preferences link is the specific pattern regulators have ruled against repeatedly.

Leave it on. A site that makes rejection harder than acceptance has not obtained valid consent, whatever the record says.

Make the two buttons equal

Same size, same prominence, same visual weight. A grey Reject beside a bright Accept is the same dark pattern in a different form, and the accent colour setting is where that goes wrong.

Preferences should be offered

Granular choice between categories is what makes consent specific rather than all-or-nothing. Hiding it pushes people to accept everything, which is the point of hiding it and the reason not to.

Blocking the page is a strong choice

It forces a decision, which improves your consent rate and worsens the experience. It is also close to the line where consent stops being freely given.

Where the content is genuinely public information, blocking it behind a consent wall is hard to justify.

Dimming is the gentler version

It draws attention without preventing use. For most sites this is the right balance.

Position matters on phones

A banner covering the whole screen on a small device, with buttons below the fold, is one people dismiss without reading. Check the banner on a phone specifically.

Write the text for a reader

The banner texts are held separately and per language. Say plainly what you set and why, in a sentence, rather than reproducing a legal paragraph nobody reads.

The colour scheme should be legible, not on-brand

Contrast between the text and the background matters more than matching your palette. A banner people cannot read is one they dismiss.

Worked example

A site shows Accept and Reject as equally weighted buttons with Preferences alongside, dims the page rather than blocking it, and was adjusted after a phone check showed the buttons falling below the fold. The text is one sentence in each supported language.

Recommendations

• Always show "Reject all", weighted equally with Accept.
• Offer preferences rather than all-or-nothing.
• Dim rather than block unless you have a reason.
• Check the banner on a phone.