Skip to main content
The state of ai impact assessment
Category: Auditing and Scanning

Cookie Inventory

Simply put

In the context of cookie consent and privacy compliance, a cookie inventory is a catalogue of the cookies and similar tracking technologies present on a website or app, describing what each one does and why it is used. However, the evidence provided for this entry does not support a definition in that privacy-law sense, so the description here cannot be verified against the supplied sources.

Formal definition

A cookie inventory would typically refer to a documented register of cookies, pixels, local storage entries, SDKs, and comparable technologies deployed across an organization's digital properties, capturing attributes such as name, provider, purpose, category (for example strictly necessary, functional, analytics, or advertising), duration, and whether prior consent is required. Such an inventory generally underpins consent management and record-keeping practices under EU and UK frameworks. This definition cannot be substantiated from the evidence packet supplied: all provided sources concern Girl Scout cookie sales and inventory tracking, not web-tracking cookies or data protection law, and therefore no verified privacy-law definition can be sourced here.

Why it matters

The evidence digest supplied for this entry does not support any claims about cookie inventories in the privacy-law or cookie-consent sense. Every source provided concerns Girl Scout cookie sales, delivery tracking, and booth inventory management applications, not web-tracking technologies, consent management, or data protection law. As a result, we cannot substantiate a discussion of why a cookie inventory matters for compliance using these materials, and we decline to construct one from unsupported assertions.

In general terms, and independent of the supplied evidence, the concept of a cookie inventory in privacy practice refers to a catalogue of tracking technologies on a website or app. Any explanation of its regulatory significance would need to be grounded in verified sources addressing the ePrivacy Directive, the GDPR, UK rules, or US state privacy laws. Because no such sources are present in this evidence packet, this section cannot responsibly present that significance as verified.

Readers seeking authoritative guidance on cookie inventories for compliance purposes should not rely on this entry as currently sourced. We recommend that the entry be regenerated once evidence relating to web-tracking cookies and applicable data protection frameworks is provided.

Who it's relevant to

Evidence limitation
The relevance of a privacy cookie inventory would ordinarily extend to privacy officers, data protection professionals, legal counsel, web developers, and marketing compliance teams. However, the evidence digest provided for this entry relates entirely to Girl Scout cookie sales rather than web-tracking cookies or data protection law, so we cannot verify audience relevance in the privacy context from these sources.
Recommended next step
This entry should be regenerated using evidence that addresses web-tracking cookies and similar technologies, applicable frameworks (such as the ePrivacy Directive, the GDPR, UK rules, and US state privacy laws), and consent record-keeping practices. Until then, the audience-relevance guidance cannot be stated reliably.

Inside Cookie Inventory

Cookie and Similar Technology Register
A catalogue listing each cookie and comparable client-side technology (such as pixels, local storage entries, SDKs, and fingerprinting mechanisms) set through the website or app. Similar technologies are typically listed alongside cookies because, in most EU jurisdictions, the placing of or access to information on a user's device is governed by the ePrivacy rules regardless of whether a literal cookie is used.
Purpose and Category Classification
For each entry, a stated purpose and a category, commonly strictly necessary/essential, functional, analytics, or advertising. This classification matters because, under EU law, strictly necessary cookies are generally exempt from consent while analytics and advertising cookies typically require prior consent. The classification is a compliance judgment, not a purely technical fact.
Provenance (First-Party vs Third-Party)
An indication of whether each cookie is set by the site operator (first-party) or by an external provider (third-party), and identification of that provider where applicable. This supports transparency obligations and helps determine which parties are involved in any subsequent processing of personal data.
Duration and Storage Details
The retention period or expiry of each cookie (for example session versus persistent) and, where relevant, the type of storage used. This information typically feeds the disclosures presented to users and supports data minimisation considerations.
Data and Recipient Mapping
A record of what data each technology may access or transmit and to which recipients, including whether that data may constitute personal data. Where personal data is processed, the GDPR applies in addition to the ePrivacy rules governing the device access itself; the two regimes are distinct and consent under one does not automatically satisfy the other.
Consent Linkage
A reference connecting each entry to whether and how consent is obtained, and how it maps to the categories or purposes surfaced through a consent management platform (CMP). The inventory documents the linkage but does not itself establish that valid consent has been collected.

Common questions

Answers to the questions practitioners most commonly ask about Cookie Inventory.

Is a cookie inventory just a list of the cookies my website sets directly?
No. A cookie inventory typically extends beyond first-party cookies set by your own domain to include third-party cookies dropped by embedded services, as well as similar technologies that are not literally cookies, such as pixels, tracking beacons, local storage, session storage, software development kits (SDKs) in mobile contexts, and fingerprinting techniques. In most EU jurisdictions these adjacent technologies fall within the same ePrivacy rules on storing or accessing information on a user's device, so limiting the inventory to your own cookies would generally leave material gaps. The exact boundaries of what should be catalogued depend on your specific site architecture and integrations, which this definition cannot enumerate for you.
Does having a complete cookie inventory mean my site is compliant?
Not on its own. An inventory is a factual mapping exercise; it documents what is present but does not by itself establish a lawful basis, obtain valid consent, or satisfy transparency obligations. Compliance generally also requires correct categorisation, appropriate consent handling for non-exempt cookies under EU law, accurate disclosures, and record-keeping, alongside legal judgment about your specific circumstances. An inventory supports these activities but does not replace them, and no single document or tool should be treated as a guarantee of compliance across the EU, UK, US state regimes, or other jurisdictions.
How do I actually build a cookie inventory from scratch?
A common approach is to combine automated scanning of your site with manual review. Scanners can crawl pages and detect cookies and some similar technologies, but they may miss items triggered only after consent, behind logins, or by conditional scripts, so manual verification is generally advisable. Practical steps often include cataloguing each item's name, the domain setting it, its apparent purpose, whether it is first- or third-party, its duration, and the vendor involved. The completeness of any given method depends on your site's behaviour and cannot be assumed; treat the output as a starting point for review rather than a definitive list.
How should I categorise the cookies I find?
Cookies are commonly grouped by purpose, for example strictly necessary or essential, functional or preference, analytics or performance, and advertising or targeting. This categorisation matters because, under EU law, strictly necessary cookies are generally exempt from consent while analytics, advertising, and functional cookies typically require prior consent. Categorisation should reflect the actual function of each cookie rather than a vendor's label, and borderline cases may require legal input. Note that treatment can differ under US state privacy laws, which often rely on opt-out mechanisms rather than opt-in, so the same cookie may be handled differently depending on the applicable regime.
How often should a cookie inventory be updated?
Because sites change frequently through new integrations, marketing tags, and third-party updates, a cookie inventory is generally treated as a living document rather than a one-time task. Many teams schedule periodic re-scans and reviews and also re-check after significant site changes or new vendor deployments. There is no single mandated frequency stated here, and the appropriate cadence depends on how often your site and its third-party components change. Maintaining an update trail can also support consent record-keeping and demonstrate ongoing diligence.
How does a cookie inventory relate to a consent management platform (CMP)?
A cookie inventory typically feeds the configuration of a CMP: the categorised list informs which cookies the CMP blocks before consent, how they are grouped in the consent banner, and what disclosures are shown to users. Some CMPs offer scanning features that help build or maintain the inventory. However, the CMP's effectiveness depends on the inventory being accurate and on scripts being correctly tagged so they only fire after appropriate consent. A CMP supports compliance but does not replace the underlying accuracy of the inventory or the legal judgment about how each cookie should be treated in a given jurisdiction.

Common misconceptions

A cookie inventory only needs to list actual HTTP cookies.
In most EU jurisdictions the relevant rules cover the placing of or access to information on a user's device generally, so pixels, local storage, SDKs, and fingerprinting techniques fall within the same scope even though they are not literally cookies. An inventory limited to HTTP cookies is typically incomplete for compliance purposes.
Maintaining a cookie inventory makes an organisation compliant.
An inventory supports compliance by providing an accurate basis for classification, disclosures, and consent design, but it does not by itself satisfy legal obligations. Whether consent is valid, whether a cookie is genuinely exempt as strictly necessary, and how personal data is processed all require separate legal judgment, and requirements differ across the EU, the UK, and individual US states.
Once compiled, a cookie inventory is a one-time exercise.
The technologies loaded by a site or app change as tags, vendors, and features are added or removed. An inventory that is not reviewed and updated periodically may misrepresent what is actually running, which can undermine the disclosures and consent choices presented to users.

Best practices

Include similar technologies (pixels, local storage, SDKs, fingerprinting) alongside HTTP cookies, since in most EU jurisdictions these fall within the same rules governing access to a user's device.
Classify each entry by purpose and category, treating the exemption for strictly necessary cookies as a documented judgment rather than a default, because analytics and advertising cookies typically require prior consent under EU law.
Record provenance (first-party versus third-party) and the recipients of any data, so that both the ePrivacy device-access rules and any GDPR obligations over resulting personal data can be assessed separately.
Re-scan and update the inventory on a defined schedule and after site or tag changes, since the set of technologies actually loaded can drift over time.
Map each inventory entry to how consent is presented and collected through your CMP, while recognising that the tool supports but does not replace the legal judgment needed to establish valid consent.
Document the geographic and legal scope for each classification, because consent obligations differ between the EU, the UK, and individual US states such as California under the CCPA and CPRA, and flag entries whose treatment depends on facts or unresolved regulatory questions.
Application Security Isn’t Optional Anymore.