How do organisations get started with a cookie audit?

Why a cookie audit starts with inventory, not cleanup

The first practical step is a complete inventory, because you cannot govern cookies you have not identified. Treat the exercise as a site-wide discovery task, not a one-page review, and include any script, pixel, tag, embedded widget, or SDK that sets or reads identifiers. A good audit records purpose, owner, lifetime, domain, and whether the item is first or third party, then groups them by business function so you can separate essential behaviour from optional tracking.

That inventory should be compared against the real visitor experience, not just the published privacy notice. A tracker may look acceptable on paper but still fire before consent, continue after opt-out, or survive through tag manager changes. The most useful outcome is a clear map of what is actually running, where it runs, and which business or legal justification exists for each item.

For the consent side of that review, NHIMG’s Consent Management Guide: Cookies, CMPs and GPC is a useful companion because it focuses on banners, consent logging, and preference signals that often determine whether a cookie audit passes or fails in practice.

How to compare cookie behaviour with policy and consent settings

Once you have the list, the key question is whether each cookie behaves the way the organisation says it should. That means checking timing, scope, persistence, and trigger conditions against policy, consent rules, and the declared purposes in the cookie notice. If a tracker is claimed to be strictly necessary, verify that it really is needed for the stated service and does not carry hidden analytics or marketing functionality.

This comparison also needs to look at implementation detail. Consent decisions can be lost across domains, tag manager containers can reintroduce removed scripts, and third-party libraries can set additional cookies outside the original design. A credible audit therefore tests actual network behaviour in a browser, reviews tag configurations, and checks whether the consent state is respected after refresh, navigation, and returning visits.

When the review touches broader compliance or assurance expectations, SOC 2 Trust Services Criteria (AICPA) is relevant because it frames the kind of control evidence many organisations need when proving that tracking, disclosure, and access to personal data are being managed consistently.

What to do after you remove unnecessary trackers

Removal should be followed by retesting, because cookie cleanup often breaks quietly. After any change, confirm that the unwanted item no longer appears in page loads, that consent states still work, and that new deployments have not reintroduced the same tracker through a different tag or template. The audit is not complete until the site is checked again after release, in staging and in production, because cookie drift often returns through normal web maintenance.

It is also worth keeping a change record for each removal, including why the tracker was deleted, what pages were tested, and what evidence shows the browser state now matches policy. That record matters when marketing, product, privacy, and engineering later disagree about why something disappeared or whether a replacement tool is equivalent. A strong audit leaves behind a repeatable review method, not just a one-time cleanup.

Risk and Threat Considerations

Cookie inventories often expose more than privacy gaps. If tracking code fires before consent, persists longer than intended, or is loaded from third parties with weak oversight, the organisation can create unnecessary data exposure, misrepresentation of user choice, and avoidable dependency on external scripts.

Failure mechanism: The browser state drifts away from the documented policy because tags are added, removed, or reordered without a matching review of consent logic, resulting in trackers that continue to execute after an opt-out or before consent is recorded.

Impact: That drift can undermine compliance, weaken user trust, and create a larger attack and supply-chain surface if third-party scripts or shared tag managers are allowed to inject more behaviour than the audit originally approved.

Practitioner Guidance

What to verify: Confirm that your crawl or manual review covers every template, region, and logged-in state that can set cookies, not just the homepage. Hidden trackers often appear only after a banner interaction, a language change, or a feature flag is enabled.

Decision rule: If a cookie is not clearly necessary for the requested service, treat it as removable until the business owner can justify both its purpose and its timing. If the owner cannot explain why it must run before consent, it does not belong in the default build.

Common mistake: Teams often audit the banner copy and assume the implementation is aligned. The better test is whether a clean browser session, with no prior consent state, behaves exactly as policy says it should.

Practitioner takeaway: A useful cookie audit is less about finding every tracker once and more about proving that discovery, consent, and release management stay aligned after the next site change.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?