Free field guide
Cookie and script governance, checked at runtime
A practical guide for privacy leads, engineers, and site owners who need to know what their site actually loads, who owns each item, and what was approved, before a regulator or a visitor asks. It is free and ungated. Every tool and template referenced here runs in the browser.
Why runtime checks matter: a scan of 1,775 sites found that 30% of sites fired a real tracker before consent. That finding comes from the scan itself, cited here as the reason this guide starts with observed behaviour, not declared lists.
Practitioners make the same point from the field. In threads from 2025-2026 on Reddit in r/privacy, r/GoogleTagManager, r/GoogleAnalytics, r/pcicompliance, and r/dataprotection, practitioners report testing banners by hand in DevTools because consent platform scans miss hardcoded tags, cache-reordered consent scripts, and cookieless pings sent after a visitor declines. This guide turns that manual practice into a repeatable protocol.
Method
The three layers
Governance holds when three layers agree: what ran, what is recorded, and what is allowed to run next. Keep them separate, then compare them.
Layer 1: Runtime truth
What the browser actually did. Which scripts loaded, which cookies and storage keys were set, which network calls left the page, and in which consent state each one happened.
Declared lists drift. Runtime evidence is the only version a visitor, a regulator, or a court can test.
Layer 2: Classification and ownership register
Every observed item classified by purpose, technical party, legal party, retention, and control class, with a named business owner for each row.
An item with no owner and no classification is not governed. It is just present.
Layer 3: Gating and drift monitoring
Consent gating enforced in the tag manager and templates, plus a repeat scan on every change and on a fixed cadence, so new or changed items surface fast.
Governance fails between audits. Drift monitoring is what keeps a good audit true next month.
The comparison has a name in this guide: the three-way diff. Declared is what the consent platform and policy say is present. Observed is what the runtime audit found. Approved is what the register has a current approval for. Any row that appears in one list and not the others needs a decision.
The Cookie-Banner Auditor and its audit page are the tool that does the Declared vs Observed part of that diff for a page. Run it first, then bring its output into the protocol below.
Decisions are made as a small committee, by role. The privacy lead chairs. An engineer, a marketing or ad-ops lead, and a security lead sit as standing members. Business owners are called per item, for the items they own. Membership is by role only. The committee approves, gates, or removes. It does not approve by silence.
Protocol
The runtime audit protocol: four passes
Work in a clean browser profile, with cache cleared, on a real page. Record the URL, the date and time, the consent state, and the network evidence for each pass. Do the passes in order.
Pass 1: No interaction
Load the page and touch nothing. Let it settle, then scroll once.
- Filter the network panel for
g/collectand note any hit before any click. A hit here is a pre-consent analytics call. - Record the value of the
_gacookie, if any, before consent. Note when it was set and by which request. - Compare banner load timing with the first tracker. Note the time the banner became usable and the time the first tracker fired. A tracker that fires first is a gating failure, even if the banner later appears.
- List every cookie, storage key, and script that appeared with no interaction.
- Filter the network panel for
Pass 2: Reject All
Reload clean, then choose Reject All where the banner offers it.
- Filter the network panel again for
g/collect. Note any hit after decline, including cookieless pings that send no cookie but still send an event. - Compare the
_gavalue before and after consent. If the value persists or a new identifier appears after decline, record it. - Check whether the banner timing changed, and whether any tracker fired before the Reject All click was processed.
- Confirm that storage set in Pass 1 is cleared, blocked, or explained.
- Filter the network panel again for
Pass 3: Accept All
Reload clean, then choose Accept All.
- Filter for
g/collectand confirm the call now matches the declared purpose and the consent state. - Compare the
_gavalue before and after consent. The value should only be set or linked after consent, not before. - Record the full list of items that consent allowed to run. Anything new here must already be in the register, or it goes to the Owner-Hunt.
- Filter for
Pass 4: Event flows
Stay in the accepted state, then run the key flows: search, form submit, checkout step, video play, chat open, and file download, as they apply to the site.
- Watch for new scripts, new storage, and new
g/collectparameters triggered by an event, not by page load. - Check chat and embed widgets in full. A widget that loads session replay brings replay into scope for the whole widget decision.
- Repeat Pass 2 for one event flow after decline, to confirm events do not restart tracking.
- Watch for new scripts, new storage, and new
Keep the evidence for each pass on the Runtime Audit Evidence Sheet listed in the templates section. An audit with no kept evidence cannot support an approval.
Classification
Classification rules: who, what, and whether it needs consent
Classify on two parties, not one. The technical party is who sets the item or receives the call in technical terms: the domain, the tag, the vendor code. The legal party is the recipient organisation that gets the data and carries accountability for it. When the two differ, the legal party governs disclosure, contract, and approval.
Two rules settle most disputes. First, analytics is never strictly necessary. Second, if an item is unknown, it defaults to gated off until it is classified and approved. Unknown is not a neutral state. It is a closed gate.
| Case | Technical party | Legal party | Decision rule |
|---|---|---|---|
The _ga cookie is set on your own domain | Your domain, set by the analytics tag | Google, as the recipient of the analytics data | Classify and disclose it as Google analytics. Your domain on the cookie does not make it first-party in law. |
| A subdomain that looks like yours points by CNAME to a vendor | Your subdomain, resolved to vendor infrastructure | The vendor behind the CNAME | Treat the CNAME-cloaked subdomain as the vendor for classification, disclosure, and contract checks. |
| A chat widget that also loads session replay | The chat widget vendor | The chat widget vendor, for chat and for replay | Decide on the whole widget. You cannot approve chat and ignore replay when one load brings both. |
Control classes follow from classification. Strictly necessary items may run without consent, with a written justification. Analytics, marketing, and personalisation items stay gated off until consent. Unknown items stay gated off until classified. Write the class into the register, in the Control class column.
Approval
Approval checklist: the 9 checks
Approving a cookie or script in a consent platform does three things at once. It makes a public assertion, because the disclosure and the banner now tell visitors that this item runs for a stated purpose. It gives operational permission, because the gate opens and the tag is allowed to fire in production. And it creates an accountability record, because a named approver and a date now stand behind that assertion and that permission. If any one of the three would be hard to defend, the item is not ready for approval.
So the order matters: gate first, approve second. Keep the item gated off while the checks run. Only open the gate when the record is complete, the disclosure is live, and the expiry date is set. An approval with no expiry is treated as expired in this method.
- Runtime evidence with timestamp and URL. A dated capture from the runtime audit, tied to the exact page or flow where the item fires.
- Legal party named. The recipient organisation is named, not only the domain or tool that set the item.
- Purpose with written strictly-necessary justification. One purpose, written in plain words. If strictly necessary is claimed, the justification says why the service fails without the item.
- Named business owner confirmed. A person, not a team inbox, confirmed they own the item and its outcome.
- DPA located and retention matches actual expiry. The data processing agreement is on file, and the stated retention matches the cookie or storage expiry observed at runtime.
- Consent gate tested in three states. No interaction, Reject All, and Accept All were all tested. The item only fires in the states its purpose allows.
- Disclosure in both languages where required. The cookie or privacy disclosure names the item and its purpose in English and French where that disclosure is required.
- Approver, date, and review date set, max 12 months. The record names who approved it, when, and when the approval expires. No approval runs longer than 12 months.
- CMP, policy, and register updated in the same change. The consent platform, the public policy, and the internal register all change together. No partial updates.
Cadence
Review cadence
| Trigger or interval | Action |
|---|---|
| Tag manager publish, CMP change, template deploy, new vendor, or campaign launch | Same-day scan of the affected pages and flows, then update the diff. |
| Monthly | Full runtime audit across key templates and event flows. Publish the Monthly Diff Report. |
| Quarterly | Register review. Confirm owners, remove dead scripts, and close items with no current purpose. |
| Vendor change notice | Reassess the affected items. A change to purpose, retention, or subprocessors reopens the approval. |
| Annual | Reapproval of every live item. Approvals expire. An expired item is gated off until it is reapproved. |
Templates
Templates: the 9 working documents
Each template is a plain document. Copy the structure into the tools your team already uses. The register and the approval checklist are also offered as CSV downloads below.
| Template | What it is | When to use it |
|---|---|---|
| Mandate 1-pager | One page that sets scope, roles, decision rights, and the expiry rule for approvals. | At the start of the programme, and when scope changes. |
| Runtime Audit Evidence Sheet | A dated record of the four passes, the pages tested, the consent state, and the network evidence kept. | On every runtime audit. |
| Three-Way Diff worksheet | A side by side view of Declared, Observed, and Approved, with a row for every gap. | After each audit, before any approval decision. |
| Owner-Hunt script | A short script for finding an owner. Three questions: what is it, why is it used, who uses it. The clock is 10 business days. | When an observed item has no owner in the register. |
| Approval Checklist form | The 9 checks in this guide as a sign-off form, with evidence fields and an expiry date. | For every new item and every renewal. |
| Removal Proof sheet | Evidence that a removed item no longer loads, sets storage, or sends network calls, checked after removal. | After any removal or vendor exit. |
| Consent Mode Decision Record | A record of how consent signals map to tag behaviour, including what happens on decline and on no interaction. | When consent mode or gating logic is set or changed. |
| Monthly Diff Report | A short report of what appeared, changed, or disappeared since the last audit, with owners and actions. | Every month, after the full audit. |
| Vendor Tier worksheet | A worksheet that sorts vendors by data sensitivity, volume, and contract position, so review depth matches risk. | On vendor onboarding and at the quarterly review. |
Register template: 19-column header
Copy this header row as the first row of the register. One row per cookie, storage key, or script.
ID,Cookie / storage key / script,Type,First seen,Technical party,Legal party / recipient organisation,Purpose category,Strictly-necessary justification,Control class,Initiator / parent tag,Vendor + contract/DPA link,Business owner,Retention / expiry,Consent gate,Decision,Approver + date,Review / expiry date,Disclosure location,Notes / chain childrenThe Owner-Hunt script needs one detail stated plainly. It asks three questions: what is it, why is it used, who uses it. If no owner is confirmed within 10 business days, the item stays gated off and goes to the committee for a removal decision.
Limits
Limits of this method
Client-side scans have clear limits. Name them in every report, so a clean scan is never read as a clean site.
- A browser scan cannot see server-side forwarding. A tag that looks first-party in the browser may forward data on the server, outside the scan.
- A scan in one place cannot see geo or state conditional banners. A banner shown only in Quebec, in California, or in the EU needs a test from that context.
- Bot detection changes behaviour. A site may serve a different banner, or no trackers, to a scanner or a data centre address.
- Classification is a governance judgment, not a measurement. Two reviewers can read the same evidence and differ on purpose or necessity.
- Borderline items go to counsel. This guide organises the evidence for that conversation. It does not settle it.
Next step
Run the auditor, then work the diff
FAQ
Common questions
Why is a CMP scan not enough on its own?
A consent platform scan reads what is declared and configured. It often misses tags hardcoded in templates, consent scripts reordered by caching, and cookieless pings sent after a visitor declines. A runtime audit in the browser shows what actually fired, in which consent state, and in which order.
Is analytics ever strictly necessary?
No. A site can deliver its core service without analytics. Analytics helps the operator learn and improve, and that is a legitimate purpose, but it is not required for the service the visitor asked for. Analytics therefore needs consent and stays gated off until consent is given.
What is the difference between a technical party and a legal party?
The technical party is who sets or receives the item in the browser, such as the domain or vendor behind a script. The legal party is the organisation that receives the data and is accountable for it. A cookie set on your own domain can still send data to a vendor, so the legal party follows the recipient, not the domain on the cookie.
How often should the register be reviewed?
Run a scan the same day a tag manager, consent platform, template, vendor, or campaign changes. Run a full audit monthly. Review the register quarterly and remove dead scripts. Reapprove every item at least once a year. Approvals expire, and an expired approval means the item is gated off until it is renewed.
Is this guide legal advice?
No. This guide is a governance method for organising evidence, owners, and decisions. Classification of a borderline item is a governance judgment, and borderline items should go to counsel. The guide does not replace advice for your facts, sector, or jurisdictions.