How law firms run cookie compliance audits for clients

Start every engagement by pinning down three facts: which domains the client actually operates (marketing site, landing pages, subdomains, regional variants), which jurisdictions those sites face (California traffic means CIPA and CCPA/CPRA; EU traffic adds GDPR and ePrivacy), and what prompted the audit — a demand letter, a deal's diligence checklist, or preventive housekeeping.

The answers set the scope. A firm responding to a CIPA demand letter needs evidence of what the cited page did on specific dates and fast remediation. A preventive audit covers the full domain list and ends in a monitoring schedule. Write the scope into the engagement letter — it also frames the report you'll deliver at the end.

Run each URL through CookieInspector. The scan needs no code access, credentials, or cooperation from the client's web team — it loads the site in a real browser exactly as a first-time visitor would, waits for the consent banner, records everything that fired before consent, then accepts and records what fired after.

Scan the pages that matter, not just the homepage: the contact form (chat widgets), checkout or signup flows (session replay), and any campaign landing pages (ad pixels). Those are the pages plaintiff tooling scans, so they are the pages your audit must cover.

The report separates pre-consent from post-consent activity. Everything in the pre-consent list is your risk surface: session-replay scripts and chat widgets map to CIPA interception theories, advertising pixels to both CIPA and CCPA/CPRA sharing claims, and any EU-facing tracker firing before consent to ePrivacy Article 5(3).

Then check the banner findings: did declining actually stop the trackers, and did Google Consent Mode signals update correctly? A banner that shows but doesn't gate anything is worse than no banner in a complaint — it documents that the operator knew consent was required. For background on the most common failure, see the pre-consent tracking guide.

Translate the findings into a remediation letter the client's web team can execute: which trackers to move behind the consent gate, which vendors to review or drop, what the banner must do on decline, and a deadline. Attach the scan PDF — it names each script and domain, so developers don't have to guess what "the session replay tool" refers to.

Keep the letter factual and scoped. The scan documents what the site did; the legal significance of each finding for this client, in their jurisdiction, is your analysis to add. That division — tool for facts, counsel for judgment — is also what makes the workflow defensible.

When the client's team reports the fixes shipped, re-scan the same URLs. The before-and-after pair of reports is the deliverable: dated evidence that the issues existed, were identified, and were resolved. File both PDFs in the client file.

If a demand letter arrives later, that pair shows the operator acted promptly on discovery — a materially different posture than a site that never looked. It is not a shield against claims, and none of this is legal advice, but it is the factual record you'd want to be holding.

Sites drift. Marketing adds a pixel, a redesign swaps the chat vendor, a plugin update re-enables a tracker. Put every audited domain on a Compliance Monitor schedule — weekly for active sites, monthly for brochure sites — and route the email alerts to your team.

For the firm, this is a recurring service with almost no marginal effort: the scan history accumulates into a dated diligence record, and each alert is a billable touchpoint where the client hears from you before a problem becomes a claim. See the full positioning on the cookie compliance for law firms page.