Most SMBs that have a cookie banner think they are done with cookie compliance. They are not. The banner is one half of the picture — the consent mechanism. The other half — the inventory of what the banner is actually asking consent for — is where supervisory authority audits keep finding gaps. A 2024 sweep by the Dutch Autoriteit Persoonsgegevens, the French CNIL, and the Italian Garante found the same pattern across hundreds of websites: banners present, but no underlying record of which trackers fire, who sets them, what data they read from the device, and whether they are actually classified correctly.

A cookie and tracker inventory is the documentation layer underneath your CMP. It is what an auditor asks for when the banner check passes. This guide explains what an inventory should contain, why it lives separately from your GDPR data map, what ePrivacy Article 5(3) actually requires, and how to keep the inventory current without doing it twice.

ePrivacy Art. 5(3): the rule most SMBs misread

ePrivacy Directive 2002/58/EC Article 5(3) — sometimes called the "cookie law," more accurately the terminal-equipment rule — requires prior consent before any information is stored on, or read from, a user's device. Two things make it harder than it looks:

It applies even when the stored data is not personal data. A counter cookie that records "this is the user's third visit" is governed by Art. 5(3) regardless of whether that count is linkable to an identified person. ePrivacy and GDPR are separate legal frameworks; clearing GDPR does not clear ePrivacy.

It applies to anything stored on the device, not just cookies. localStorage, sessionStorage, IndexedDB entries, pixel tags that read existing identifiers, SDK beacons, fingerprinting that derives a stable signal from the browser, service-worker caches — all of them are "information stored on the terminal equipment of a subscriber or user." If your inventory only tracks cookies by name, it misses most of what supervisory authorities now look for.

The exemption is narrow: a tracker is allowed without consent only if it is "strictly necessary" to deliver the service the user explicitly requested. The CJEU and national DPAs have read this strictly. Session cookies for a logged-in checkout flow qualify. Analytics that "help us improve the service" do not. Marketing pixels never do.

What to inventory

A cookie and tracker inventory is wider than the cookie list your CMP scanner shows. Six categories of storage and signal-collection mechanism count:

  • Cookies — first-party and third-party, session and persistent
  • localStorage and sessionStorage — browser key-value stores that persist longer than cookies for first-party origins
  • Pixel tags — 1×1 image requests that carry identifiers in the URL or read existing cookies on the destination domain
  • SDKs — JavaScript libraries from third parties (analytics, chat widgets, error monitors, ad networks) that often set their own cookies and read or write to localStorage and fire beacons
  • Fingerprinting — derivation of a stable identifier from device characteristics (canvas, WebGL, font list, audio context). Even without storing anything, fingerprinting reads from the device — Article 5(3) applies.
  • Beacons — navigator.sendBeacon() calls that fire on page unload, common in analytics and error-reporting SDKs

For each entry, the auditable record needs at least: name, provider (the company behind it), domain it sets to, type, purpose, duration, the ePrivacy basis (consent or strictly necessary), and the consent mechanism that gates it (your CMP, or "no CMP — strictly necessary"). Anything less and you cannot answer the supervisory-authority question "show me the legal basis for this specific tracker on this specific service."

Inventory ≠ CMP — they do different jobs

A CMP (Consent Management Platform) — Cookiebot, OneTrust, Didomi, Iubenda, Usercentrics, Cookie Information, Axeptio — does three things:

  1. Display the banner with category toggles
  2. Store individual consent records with a timestamp and the version of the policy in force
  3. Block trackers until consent is given (the technical enforcement layer)

A CMP is operational. It runs on every page load. Its job is to manage consent in real time.

An inventory does something different: it is the documentation of what the CMP is asking consent for. It answers questions a CMP cannot:

  • Why is this tracker classified as analytics rather than marketing?
  • Who at the organisation approved adding the LinkedIn Insight Tag, and on which date?
  • What data does this SDK actually read or write — beyond what its vendor documentation claims?
  • If a regulator asks "demonstrate the necessity of this analytics cookie under your legitimate-interests assessment," what is the answer?
  • When the cookie list changes — a new SDK added, a vendor switched — does the change appear in your audit log?

A CMP scan tells you what cookies are firing today. An inventory tells you which ones should be firing, why each one is on the list, and what changed in the last six months. The two are complementary; neither replaces the other.

This is also why supervisory authorities increasingly ask for both. A CMP without an inventory is a banner without justification. An inventory without a CMP is a register without an enforcement mechanism. SMBs that conflate the two — usually by treating the CMP's auto-scan as the inventory — find out during an audit that the CMP scanner missed the SDKs that fire only after a button click, the analytics beacon that fires only on errors, and the localStorage entry the chat widget writes after the user types a message.

The four tracker categories

Every serious CMP and every supervisory authority guidance document classifies trackers into the same four buckets. The classification drives both the consent flow and the inventory's risk posture.

Strictly necessary. Trackers without which the explicitly-requested service cannot work. Session identifiers for an authenticated session, a CSRF token cookie, the cookie that remembers your language preference for the current visit, the load-balancer affinity cookie. These are exempt from the consent requirement. Be conservative — if a regulator could plausibly say "the service would still work without this," it is not strictly necessary.

Functional. Trackers that enhance the user experience but are not essential — remembering UI preferences across sessions, remembering a recently-viewed list, language preference persisted across visits. These require consent. The line between strictly necessary and functional is narrow and often debated; documenting your reasoning per tracker is what survives an audit.

Analytics. Trackers that measure how the service is used — page views, session duration, conversion paths, error rates. The CJEU and most national DPAs have ruled that even first-party analytics need consent unless the data is genuinely aggregated and used only by the controller for measuring its own service. Self-hosted Matomo with IP anonymisation and no cross-site tracking comes closest to a consent-free analytics setup; Google Analytics 4 does not.

Marketing. Retargeting pixels, ad-network identifiers, conversion tags, social media tracking pixels. Always require consent. Almost always third-party. The category that draws the most enforcement attention.

The inventory records the category for each tracker, the ePrivacy basis (consent or necessary), and — critically — the reasoning. The category determines the consent flow; the reasoning determines whether the classification holds up under inspection.

ePrivacy basis vs GDPR Art. 6 legal basis: don't conflate them

This is the single most common error in SMB cookie documentation. ePrivacy Art. 5(3) and GDPR Art. 6 are separate legal frameworks, asking separate questions:

  • ePrivacy Art. 5(3) asks: may this tracker be placed on the device at all? The answer is consent or strictly necessary.
  • GDPR Art. 6 asks: if personal data results from this processing, what is the legal basis for processing it? The answer is one of the six Art. 6(1) bases — consent, contract, legal obligation, vital interests, public task, legitimate interests.

A first-party analytics cookie that requires user consent under ePrivacy may, after consent is given, process the resulting data under GDPR Art. 6(1)(a) (consent) — or under Art. 6(1)(f) (legitimate interests) once consent has been validly obtained for the placement of the cookie. In some interpretations, the placement and the processing both ride on the consent; in others, the placement is consent-gated and the processing is legitimate-interests. National DPA guidance varies. What is universal: the two bases are recorded separately. An inventory that has only one "legal basis" field per tracker conflates the two and produces a register that no DPA will accept.

A serious inventory has a legal_basis_eprivacy field on each tracker (consent / necessary) and a separate legal_basis field on the personal data items the tracker generates (the GDPR Art. 6 basis). They live on different tables in the data model because they answer different questions.

What changes under the Digital Omnibus proposal

In November 2025 the European Commission published the Digital Omnibus proposal COM(2025) 837 final. It is not yet adopted — and it is not certain to pass in its current form — but the direction of travel matters because it would reshape ePrivacy enforcement.

The proposal would move the cookie/terminal-equipment rule from ePrivacy Art. 5(3) into a new GDPR Art. 88a for natural-person subscribers. Six named purposes would be lawful without consent: carrying out an electronic communication, providing an explicitly-requested service, aggregated audience measurement for the controller's own use, maintaining service security, and supporting information-society services the user asked for. Refusal of consent would have to be single-click, and a refused controller would have to wait at least six months before asking again.

A companion Art. 88b would bind controllers to respect machine-readable consent signals — Global Privacy Control, an eventual ESO standard — once technical specifications are published, and would require non-SME browsers to provide them.

For SMBs maintaining a tracker inventory today, nothing changes operationally. The current ePrivacy Art. 5(3) consent/necessary distinction remains correct under the Directive in force. But two pieces of forward-looking guidance follow:

  • The taxonomy that matters going forward is purpose, not cookie type. An inventory that records the purpose of each tracker (the explicit service the user requested, audience measurement for own use, etc.) ports cleanly into the Art. 88a regime if it lands. An inventory that only records "analytics — consent required" needs to be re-classified.
  • Machine-readable consent signal support will be a CMP feature, not an inventory feature — but the inventory needs to record which CMP is in use so the auditor can verify Art. 88b compliance once the standard is published.

The proposal is dated and explicitly previewing future law. Build for current law; design for the proposed direction.

How Readmodel® handles cookie & tracker inventories

Readmodel® keeps the cookie and tracker inventory at the service level — under the same data model that stores your services, data items, and transfers — so a tracker is always tied to the service that sets it, the data it reads or generates, and (where personal data results) the GDPR processing record that uses it.

Each tracker entry captures: name, provider, domain, type (cookie / localStorage / pixel / fingerprint / SDK / beacon / other), category (strictly_necessary / functional / analytics / marketing), the legal_basis_eprivacy (consent / necessary) — deliberately named to avoid conflation with the GDPR Art. 6 legal_basis on data items — purpose, duration, the consent mechanism reference (your CMP), and an optional URL to the vendor's documentation.

A seeded library of 167 common trackers — covering EU CMPs (Cookiebot, Didomi, Iubenda, Usercentrics, Axeptio), analytics (GA4, Matomo, Piwik PRO, Hotjar, Microsoft Clarity), ad networks (Meta, LinkedIn, TikTok, Criteo, RTB House, Google Ads), chat widgets (Intercom, Crisp, LiveChat, Tidio), payment SDKs (Stripe, Adyen, Mollie, Klarna), identity (Auth0, Keycloak, NextAuth.js), commerce (Shopify, WooCommerce, Magento), error/APM (Sentry, Datadog, New Relic), and CMS patterns (WordPress, Drupal, TYPO3) — covers most SMB stacks in a few clicks. Custom entries follow the same schema.

The risk register automatically flags any non-essential tracker (category != 'strictly_necessary' and legal_basis_eprivacy = 'consent') for which no consent mechanism is documented at the row level and no CMP is set project-wide. Either level clears the flag — so SMBs that document one CMP at the project level (Cookiebot for the whole site, say) do not have to repeat it on every tracker row.

A built-in cookie policy generator produces a print-ready and copy-as-Markdown / copy-as-HTML cookie policy document, grouping trackers by category and including descriptions and durations. It is the document you publish on your website to fulfil the transparency requirement that sits alongside the consent requirement.

Crucially, Readmodel® does not replace your CMP. It does not generate consent banners, store individual consent records, parse TCF strings, or scan your site automatically. It is the inventory layer underneath whichever CMP you run. For the broader picture of how Readmodel® fits with the rest of your privacy stack, see the GDPR compliance tools comparison.

Cookie and tracker inventory: frequently asked questions

Is a cookie inventory legally required? The cookie inventory itself is not named in any law, but the obligation it satisfies is. ePrivacy Art. 5(3) requires consent before placing or reading information on a user's device, except for strictly-necessary trackers. Under the GDPR accountability principle (Art. 5(2)), the controller must be able to demonstrate compliance — which in practice means a documented inventory of every tracker, its category, its purpose, and the legal basis. Supervisory authorities increasingly request the inventory during audits.

Doesn't my CMP scanner give me the inventory automatically? A CMP scanner gives you a snapshot of cookies that fired during the scan. It misses trackers that fire conditionally (after a button click, on errors, in authenticated areas the scanner did not log into), it misses non-cookie storage (localStorage, fingerprinting, beacons) on most plans, and it does not record the reasoning behind your category classifications. Use the scanner as input to the inventory; do not treat the scanner output as the inventory.

What is the difference between strictly necessary and functional? Strictly necessary trackers are those without which the service the user explicitly requested cannot work — session identifiers for a checkout flow, CSRF tokens, load-balancer affinity. Functional trackers improve the user experience but are not essential — remembering UI preferences across sessions, recently-viewed lists. Strictly necessary is exempt from consent; functional requires consent. National DPAs read the exemption strictly; if in doubt, classify as functional and require consent.

Do I need to inventory third-party trackers? Yes. Anything that places or reads information on the user's device counts, regardless of who runs it. Embedded YouTube videos that set DoubleClick cookies, Stripe Elements that set fraud-prevention cookies, the Google Maps embed that sets NID — all of these need to be in the inventory, with the third-party provider documented.

Does my fingerprinting library need to be in the inventory? Yes. Fingerprinting reads characteristics from the user's device to derive a stable identifier — the CJEU and EDPB have confirmed this is covered by Art. 5(3) even when nothing is stored. Document the library, its purpose, and the consent mechanism that gates it. Most fingerprinting in production is for fraud prevention (Sift, Forter, DataDome) and may qualify as strictly necessary for the security purpose; document the reasoning.

How does this relate to the EU AI Act? If you use AI on the data your trackers collect — clickstream-fed recommender systems, behavioural ad targeting models, fraud-detection ML — the AI processing layer is governed by the EU AI Act, while the underlying tracker placement is governed by ePrivacy. Both have to be documented separately. See the AI governance guide for the AI layer.

What happens if the Digital Omnibus proposal is adopted? The cookie/terminal-equipment rule moves from ePrivacy Art. 5(3) into a new GDPR Art. 88a for natural-person subscribers, with six named purposes lawful without consent. An inventory built around purpose (rather than around cookie names) ports cleanly. The proposal is not yet adopted; build for current law.

How often should I update the inventory? At least quarterly, plus on any change: a new SDK added to the site, a vendor switched (Cookiebot → OneTrust), a new feature that introduces conditional trackers, a CMP rule update. The inventory is a living document; the audit log on each tracker is what proves you are maintaining it.

Start documenting your trackers

Cookie and tracker inventories are unglamorous. They are also where supervisory-authority audits move next as banner-only enforcement reaches its ceiling. The work is genuinely manageable for an SMB once you have the structure: a tracker per row, a category, a basis, a purpose, a CMP reference, and a duration.

Create a free Readmodel® account, pull in the seeded library, and you have an auditable inventory in under an hour. The trackers page, the cookie policy generator, the risk-register flag for missing consent, and the ROPA inclusion are available on every plan, including the free Explore plan.