Change detection
A rescan that finds a cookie the register does not know about raises it rather than silently adding it. Most cookie drift arrives through a marketing tag someone added on a Friday, and the first sign of it should not be a complaint.
Module 02
Cookie Management
Every cookie and tracker on your surfaces, found at source, categorised against a purpose, and blocked until someone says yes, with the record that proves what they were shown. Runs standalone, and shares onboarding data with every other module.
The lifecycle
Six stages, each one evidenced.
- 01
Scan
Scans the website or app for every cookie and tracker actually present, rather than the ones someone remembered to declare. Third-party tags load their own tags, so the list on a spreadsheet and the list in the browser diverge within weeks of going live. Rescans run on a schedule and report what changed since the last one.
- 02
Categorise
Sec 6(1)Essential, performance, analytics and marketing, each mapped to a purpose a Data Principal can accept or reject on its own. Bundling analytics into a single yes/no is not specific consent, so categories stay individually addressable end to end rather than collapsing into one switch at the banner.
- 03
Block
Sec 6(1)Non-essential scripts do not execute until consent is given. Enforcement sits before the tag fires rather than after it. A banner that appears once the tracker has already run is decoration, and the cookie it set is evidence against you rather than for you.
- 04
Ask
Sec 5(3), Sec 6(4)Accept all, reject all and granular control, presented with equal prominence, in English plus Eighth Schedule languages. Nothing is pre-ticked. Refusing takes one action, because the withdrawal path cannot be longer than the path that took the consent.
- 05
Record
Sec 6(10)Each decision writes a versioned record carrying the categories chosen, the banner and policy version shown, the language, and the timestamp. The burden of proof sits on the Data Fiduciary, so the answer to what this visitor consented to on a given date has to survive the visitor clearing their browser.
- 06
Re-ask
Sec 5(2)Consent expires and re-prompts on schedule. A change to the cookie policy (a new vendor, a new category, a new purpose) forces fresh consent for what changed rather than inheriting the old answer, and the prior record is kept rather than overwritten.
The cookie record
A register of what is actually running, checked against what was declared.
The scan produces one of these per cookie and tracker it finds. Where the observed lifetime disagrees with the declared one, the register says so rather than reprinting the declaration.
Each decision, and each block enforced because of one, appends to the same tamper-evident audit log the rest of the platform writes to.
- cookie_name
- the cookie or tracker as it appears in the browser
- provider
- the domain that set it, first or third party
- category
- essential, performance, analytics or marketing
- purpose_id
- the purpose it is mapped to, individually consentable
- duration
- declared lifetime, checked against what was observed
- banner_version
- the banner and cookie policy version displayed
- language
- the language the choice was presented in
- decision
- per category, with the timestamp of the affirmative act
Also inside Module 2Sec 6(10) Sec 6(10)
The banner is the visible part. It is the smallest part.
Blocking that matches the banner
The blocking decision and the consent record come from the same source, so what the banner claims and what the page actually does cannot drift apart. A cookie notice that describes a policy the site does not enforce is a statement you have to defend.
Exportable evidence
Cookie consent records export as a file, per visitor or in bulk, with the notice version and language attached. The question arrives in that form: what did this person see and choose, rather than what does your banner say.