Cookie and Storage Audit With Vendor Inventory

A cookie table produced by a scanner and one produced by a session are different documents. Scanners crawl anonymously and stop at the login wall, which is exactly where the interesting storage lives: the authenticated session, the cart, account settings, the post-purchase confirmation with an affiliate postback on it. Every audit I have run has surfaced third-party endpoints inside the logged-in journey that the client's own scanner, run the same week, did not report. How the capture is run: Instrumented browser sessions rather than a crawler. Chrome DevTools Protocol capture of every request, response header and storage write, driven through the journeys that matter to your business: anonymous browse, registration, login, checkout or application submission, account settings, unsubscribe, and the pages behind your paid landing URLs with their real query parameters attached. Each journey repeats from an EEA address, a Quebec address, a California address and a market with no rule, because vendor behaviour changes by IP and the difference between those runs is itself a finding. Storage that is not a cookie: The inventory covers localStorage, sessionStorage, IndexedDB, service worker caches, cache-based identifiers carried in ETag and Last-Modified headers, and the fingerprinting surface, meaning canvas reads, font enumeration, WebGL and audio context calls, each recorded as an observed API call attributed to the script that made it. A vendor that moved from a cookie to localStorage did not stop processing personal data, but it did fall off your cookie table, and that is the quietest way an inventory goes stale. CNAME chains: Every first-party-looking subdomain has its DNS chain resolved. A subdomain of yours pointing at a third party is a first-party cookie in name and a third-party data flow in fact. It sidesteps ITP's seven-day cap on script-written cookies, and both the CNIL and the Belgian authority have treated the arrangement as the third-party processing it is. Where I find one, you get the vendor, the contract that ought to cover it, and whether that contract exists. Reconciliation, which is the point: The output is three lists, not one. Declared in your policy and not observed on the site: stale text, cheap to fix, still a misstatement. Observed and not declared: the finding, ranked by what the endpoint receives rather than by cookie count. And observed under a legal entity that is not the one your agreement names, which is the expensive category and the one nobody goes looking for. The vendor inventory: One row per vendor, keyed on legal entity rather than brand name, because the brand you bought from and the entity receiving the data are often in different countries. Each row carries role as controller, processor or joint controller with the reasoning; storage written; the fields received, at field level, read from the observed payload; declared sub-processors; transfer mechanism; retention as stated by the vendor and as observed; and whether a signed agreement exists on your side. Where this stops: This is a measurement engagement. I do not remediate inside it, do not configure your consent platform inside it, and do not write your policy from it. Those are separate pieces of work and you will be told which findings need them. The audit is a photograph of one week; sites change with every release, which is why the monitoring option exists rather than the pretence that a single pass stays true. Not for you if: You need a document for a security questionnaire and would prefer it came back clean. It may not, and I do not soften a finding because it is holding up a deal.