How to Perform a Cookie Audit Before Implementing OneTrust

This is article 6 of the Cookie Compliance series. You already have the legal map (article 1), GDPR and DPDP checklists (article 3, article 4), and banner design notes (article 5). Here the job is the pre-install audit so OneTrust categorisation is not guesswork.

What a cookie audit is (and is not)

An audit is a structured inventory of storage and access on the user’s device plus the scripts that cause it: HTTP cookies, local storage, pixels, SDKs, beacons, and form trackers. Regulators care about device storage/access and about personal data that results. Your audit does not need a courtroom format. It does need enough detail to write an honest notice and to block the right tags.

OneTrust’s Getting Started flow starts with scanning the website for that reason. Implementation Best Practices stress regular scans so the inventory stays current enough to support informed consent. OneTrust also warns that a scan is not a permanent source of truth: cookies that appear only after login or after specific actions can be missed, and crawl behaviour can differ between runs. Official inventory lives in Categorizations, refined by your team.

Prep before you click Scan

1. Name an owner (marketing ops or eng) and a counsel contact for edge cases.
2. List environments: production hostname, staging, app subdomain, checkout path, blog.
3. Export containers: Google Tag Manager workspaces, Segment/Tealium maps, hard-coded theme scripts, Shopify/app injectors.
4. List journeys to test by hand: anonymous home page, product or article page, add to cart or lead form, logged-in account area, thank-you page after conversion.
5. Note regions you care about (EEA, UK, India, California) so later geo rules match the inventory, not marketing wishful thinking.

Manual discovery (do this even if OneTrust will scan)

1. Tag manager export

From GTM (or your tag tool), export every tag, trigger, and variable. Mark which tags set cookies or load third-party pixels. Note consent requirements already configured, if any. Orphan tags with no triggers still matter if someone re-enables them later; delete or document them.

2. Browser pass on key URLs

Use a clean profile (or a dedicated container) with DevTools open:

• Application / Storage: cookies, local storage, session storage per origin.
• Network: filter for known ad and analytics hosts; note Set-Cookie headers and pixel query strings.
• Elements: search for gtag, fbq, chat widgets, A/B tools.

Repeat after Accept and after Reject once a temporary banner exists, and again while logged in. Login-only cookies are a classic scan miss that OneTrust troubleshooting docs call out explicitly.

3. Server and CMS injectors

Check theme headers, Cloudflare/GTM server-side containers, CMS plugins that inject analytics, and marketing “pixel helper” plugins. Audits that only look at GTM miss half the stack on WordPress and ecommerce themes.

4. Build the sheet

Columns that pay for themselves:

• Name / key
• Domain and first- vs third-party
• Source script or tag ID
• Vendor
• Purpose category (Strictly Necessary, Performance/Analytics, Functional, Targeting/Ads, Social)
• Essential vs optional for your counsel model
• Data shared (identifiers, events, approximate location)
• Retention if known
• Found how (GTM, DevTools, OneTrust scan)
• Action (keep, delete, recategorise, block until consent)

Run the OneTrust website scan

In Cookie Consent, open Websites, add the domain, and start a scan. OneTrust describes the aim as finding first- and third-party cookies, tags, trackers, pixels, beacons, forms, and storage. You can target include/exclude/prioritise for pages, paths, or subdomains when a huge site wastes crawl budget or when ads only fire on a microsite.

Practical tips from OneTrust guidance and field practice:

• Scan early; large domains can take hours or days before categorisation finishes.
• Prefer the production hostname you will protect, plus any subdomain that drops separate tags.
• After the scan, open the Scan Results dashboard (pages scanned, cookies found, category breakdown).
• Expect Cookiepedia-based auto-categorisation into Strictly Necessary, Performance, Functionality/Functional, Targeting, and sometimes Social Media, with leftovers as Unknown.

When categorisation fails or stalls, OneTrust surfaces a Recategorization control on the results view. Use it rather than guessing from a half-finished map.

Reconcile scan results with your manual sheet

Unknown is not a shipping category

OneTrust Implementation Best Practices state that Unknown is not valid for the Cookie List users see. Assign every Unknown cookie with help from developers who know what the script does. Fill missing descriptions so Preference Center and cookie list text are readable.

New vs still-required

Compare exports across scans. Scans do not automatically purge older cookies from Categorizations. Keep or remove manually when a vendor is gone or still required offline from the crawl.

Add what the crawler cannot see

Manually add cookies that only appear after login, after payment, or after a specific user action. Document the trigger so the next auditor does not “clean” them by mistake.

Delete dead weight before banner copy

Every optional vendor you remove is one less purpose to explain and one less tag to gate. Audits that skip deletion force darker banners and worse consent rates later (see banner best practices).

Classify for consent and blocking

Map each row to how geolocation rules will treat it:

• Strictly Necessary: security, session, load balancing, consent storage itself. Usually allowed without marketing-style opt-in when strictly needed for the service the user requested (EU ePrivacy practice; confirm with counsel).
• Performance / Analytics: measurement. Treat as optional for EEA/UK and for DPDP-style optional tracking.
• Functional: remembered UI that is not strictly required.
• Targeting / Advertising / Social: ads, retargeting, social pixels. Optional; block until grant where consent is required.

Wrong classification is how illegal tags get a free pass. If a cookie supports ads measurement, do not park it under Strictly Necessary to inflate Accept convenience.

Audit deliverables before OneTrust configuration

1. Signed-off inventory sheet (or Categorizations export plus manual addenda).
2. List of tags to delete this sprint.
3. Draft purpose language for the banner and Rule 3 / GDPR-style notice (itemised where DPDP Rule 3 will apply; see article 4).
4. Region matrix: which categories need prior consent vs disclosure/opt-out.
5. Owner for quarterly rescans.

Only then move to templates, geolocation rules, script publish, and Consent Mode wiring in article 2.

Rescan cadence

OneTrust maintenance guidance expects rescans at a frequency that matches how often marketing adds tags, with export comparisons so new cookies get categories and blocking methods. Many teams pick quarterly plus an event-driven rescan after major campaigns or theme changes. Treat marketing launches that add pixels as a change-control item, not a surprise for the next annual review.

Common audit failures

• Scanning only the marketing site while checkout lives on another subdomain.
• Trusting Cookiepedia labels without a human pass.
• Ignoring local storage and pixels because “we only care about cookies.”
• Writing the privacy notice before the inventory exists.
• Skipping logged-in journeys.
• Leaving Unknown cookies in production Preference Centers.

FAQ

Can I skip the manual pass if OneTrust scans?

You can start with the scan, but you should not skip reconciliation. OneTrust itself says scans are snapshots and that Categorizations plus manual updates are the official list.

How deep does the first audit need to be?

Deep enough that every live optional tag has a purpose and an owner. Perfect historical archaeology of deleted pixels is optional; deleting them is not.

Does an audit replace legal review?

No. It feeds legal review. Counsel still decides edge cases (children’s products, health data, sale/share under CCPA/CPRA).

Sources and further reading

• OneTrust: Getting Started with Cookie Consent; Scanning a Website; Viewing Scan Results; Implementation Best Practices: Cookie Consent; Troubleshooting: Interpreting Scan Results (MyOneTrust Knowledge Base).
• EDPB Cookie Banner Taskforce report (17 January 2023) on prior consent and informed choice (inventory supports those duties).
• Google Tag Platform: Set up consent mode on websites (wire after inventory and banner exist).
• Series: article 1, OneTrust setup, GDPR, DPDP checklist, banner practices.

Next in this series

Up next: OneTrust vs Manual Cookie Compliance: Which Is Right for Your Business? That comparison uses the audit outputs above to decide when a full CMP is worth the cost versus a careful custom banner.

Disclaimer

This article was prepared by Imran using publicly available information. It is for general education only and is not legal advice. Do not rely on it alone when implementing cookie compliance, DSAR handling, consent flows, privacy policies, or other privacy and data-protection controls. Consult your own legal counsel for advice that fits your business, jurisdictions, and systems.

Last updated on 5 September 2026