Client cookie compliance means every tracker your agency installs captures visitor consent before it fires, on every client domain, with proof on demand. The method is simple: standardize the setup once, deploy it per client, monitor it all from one place.
This guide covers who is actually liable when something goes wrong. It covers the nine-step workflow for compliance across a client portfolio. It also covers turning compliance into recurring revenue, and the mistakes that expose agencies to liability.
What "client cookie compliance" actually means for an agency
Client cookie compliance means every non-essential cookie, tracking pixel, and analytics script your agency installs captures documented visitor consent before it loads. You can prove that on any site, at any time. If you put something on a visitor's device that lets you track them across page views, the banner is required, period. That single test decides whether a site needs a banner at all.
A compliant client site has four things in place:
- A consent banner with equally prominent accept and reject actions
- Non-essential cookies and scripts blocked until the visitor consents
- A published cookie policy that matches what the site actually does
- A consent log that timestamps every visitor's choice
Skipping any one of the four leaves the agency exposed. A banner that shows up but doesn't actually block tracking is not compliance. It is a decoration that makes the violation easier to prove.
Who is liable: are you the controller or the processor?
Under GDPR, the client is usually the data controller and your agency is a data processor. Your agency still carries its own legal duties independent of the client. "The client is responsible" is only half the sentence. A processor that mishandles data, skips a breach notification, or processes outside the client's instructions faces its own liability.
The distinction matters because controllers decide why and how data gets processed, while processors carry out that processing on the controller's instructions. Your agency can hold both roles at once: processor for a client's site, controller for your own contact form and analytics. For the full breakdown of each role, see data controller vs data processor.
Article 28 of the GDPR makes the split concrete. It requires a binding written contract, the data processing agreement, before any processor touches a controller's data. That contract is not optional paperwork. It is the legal boundary that decides which failures land on you.
When your agency is a processor (most client work)
As a processor, your agency has to:
- Process personal data only on the client's documented instructions
- Maintain technical and organizational measures (TOMs) that protect the data
- Assist the client with data subject access requests (DSARs)
- Notify the client of a data breach within 72 hours of discovery
- Keep processing records: data categories, purposes, retention periods, security measures
None of these duties disappear because the client signed off on the banner. A processor that skips breach notification or processes data outside scope is liable for that failure on its own.
When your agency is a controller (your own site and data)
Your agency is the controller for anything you collect for your own purposes: your own contact form, your own site analytics, your own marketing list. Those live under your own privacy policy and your own consent setup, separate from any client work.
What you need before you start
The one thing most agencies skip is a written contract clause naming who owns cookie compliance, backed by a signed data processing agreement (DPA). Without that document, "the client is responsible" is an assumption, not a fact.
Before you start, line up:
- Roles: one person who owns the compliance config per client and one who signs off before launch
- Time: a first standardized setup runs a session per site once your framework exists. Real tracker blocking across a large site can take much longer; one agency owner bills hourly for that heavier work
- Inputs: a list of every client domain and the regions its visitors come from
- Tools: a multi-site consent platform, a DPA template, and a tag manager account for clients running Google tags
How to manage cookie compliance across every client site
Nine steps turn cookie compliance from a one-off favor into a repeatable operation you run across every client domain.
Step 1: Map each client's jurisdiction and consent model
Every client site needs its consent model matched to where its visitors actually are, before you touch a banner setting. Requirements vary by location. EU and UK visitors need opt-in consent, so review what a GDPR banner must do before you configure one. US states need an opt-out model plus a way to honor Global Privacy Control (GPC) signals.
| Region | Consent model | Notes |
|---|---|---|
| EU / UK | Opt-in | GDPR / UK GDPR; consent required before non-essential cookies fire |
| California and other US states | Opt-out | CCPA/CPRA-style; disclosure plus a way to opt out of sale/sharing; honor GPC |
| Brazil | Opt-in | LGPD |
| Canada | Meaningful consent | PIPEDA |
Do this for every client: list their target regions, then assign the matching consent model per site. A client selling only to US visitors needs a different banner behavior than one running ads into the EU.
💡 Using Consently? Automatic geotargeting applies the GDPR opt-in template to EU/UK visitors and the CCPA opt-out template to US visitors. Configure the region rules once, then apply them across every client site on the account.
Cookie risk is not uniform across regulated industries. See how cookie rules change by industry before you finalize banner behavior for a new sector. A healthcare client needs stricter tracker handling; see the guide for healthcare client sites.
Done: you have a one-row-per-client table mapping each domain to its regions and consent model.
Step 2: Standardize one cookie-category framework across the portfolio
Every client site should sort cookies into the same four categories, so your team stops re-deciding the same judgment calls per client. The standard model has four categories:
- Strictly necessary
- Functional
- Analytics
- Marketing
Document how you classify the ambiguous cases once (a chat widget, a CDN, a session-replay tool). Every team member then follows that same call on every new site.
💡 Using Consently? The cookie category set, plus custom categories for anything the default four don't cover, ships on a base site. Clone it into every new client configuration.
Done: a shared categorization document every team member follows, with no re-litigating category calls per client.
Step 3: Put every client site under one dashboard
Managing consent from a separate login per client does not scale past a handful of sites. The fix is one dashboard that shows every client domain, so you stop juggling logins and start managing the whole portfolio from a single screen.
This is the core operational shift for an agency: one account, every client domain visible from one login, instead of a separate account per site.
Consently's multi-site dashboard and site selector do exactly this from one account (5 domains on Premium, 10 on Enterprise). See how Consently handles managing consent across every client site from one account.
Done: every client domain is visible and manageable from one login, with no separate per-client accounts left running.
Step 4: Scan each site and block trackers before consent
Every client site needs an initial scan, then a recurring one, because a banner that displays without actually blocking trackers is not compliant. It is decoration. The scan finds every cookie, script, and iframe; blocking stops the non-essential ones from firing until the visitor consents. The first pass on a new client is a full cookie audit, so run it before you set any blocking rules.
To do this for each site:
- Run an initial full-site scan and review the findings
- Categorize every cookie, script, and iframe the scan surfaces
- Block non-essential items until consent is captured
- For clients using Google Tag Manager, set a consent-initialization trigger so the consent script fires before any tracking tag
Google's Consent Mode v2 has required EEA consent signals since March 2024. A site serving ads or measuring EEA visitor behavior has to pass consent choices to Google tags. Without that signal, Google can't verify consent and measurement degrades.
💡 Using Consently? Full-site scans, weekly scheduled re-scans, and on-demand scans run per site. Automatic blocking covers cookies, scripts, and iframes, with Consent Mode v2 enabled by default and install available through GTM's Custom HTML tag.
For SaaS clients running product analytics, see the SaaS consent guide. For ad-supported content sites, see the blog and content-site consent guide.
Done: the scan report shows no non-essential tag firing before consent, verified in the browser's dev tools network tab.
Step 5: Deploy a branded banner from a compliant base template
Build the compliance rules into one base banner first, then restyle it per client brand. The base template needs equally prominent accept and reject actions (a CNIL enforcement focus since 2021). It also needs granular category toggles one click away, and a link to the site's cookie policy.
Once that base template passes every compliance check, cloning it into a client's colors, fonts, and logo is a styling exercise, not a compliance one.
💡 Using Consently? Deep banner customization (colors, fonts, custom CSS, font inheritance, live preview) applies on top of a cloned base configuration. The compliance logic never has to be rebuilt per client.
Done: every client banner passes the same compliance checklist and matches that client's brand.
Step 6: Sign a DPA and set the client contract straight
Every client relationship needs a signed data processing agreement and a contract clause that puts compliance responsibility in writing. GDPR Article 28 requires that DPA whenever you process a client's data. A verbal understanding is not evidence if a regulator or a client later asks who was responsible. If you are new to the document, start with what a data processing agreement is. Every client contract needs two things:
- A DPA that covers processing instructions, security measures, sub-processor terms, and breach notification.
- A clause that carries legal advice outside your scope of work, with a written waiver on file if a client declines the consent setup entirely.
Here is one agency owner's practice for a client who declines the service.
"If they refuse the service even after being informed, make sure to obtain written notification from them to protect yourself from any liability."
That waiver turns a client's bad decision into their liability, not yours.
💡 Using Consently? A customer-facing DPA with subprocessor list and SCCs is available on request. It feeds directly into your own processor paperwork with clients.
Done: a signed DPA and a contract clause on file for every client, plus a written waiver for anyone who declines.
Step 7: Keep per-client consent logs as audit proof
Every client site needs a timestamped consent record you can hand over the moment a client or a regulator asks for it. The record should show status (accepted, rejected, or partial), country, and date for every visitor decision.
💡 Using Consently? Consent logs with export and analytics run per site. A client-specific audit trail is a few clicks away instead of a data-recovery project.
Done: an exportable consent log exists for every client site, ready to hand over on request.
Step 8: Onboard new sites with a repeatable checklist
Every new client site should follow the identical sequence, so onboarding stops depending on who on your team happens to be free that week. Use this checklist:
- Scan the new site for cookies, trackers, scripts, and iframes
- Map the client's jurisdiction and consent model (Step 1)
- Apply the standardized category framework (Step 2)
- Configure geo-rules for the client's visitor regions
- Categorize every detected item
- Deploy the branded banner from the base template (Step 5)
- Set blocking rules and, if relevant, the GTM consent trigger
- Verify in the browser's dev tools that nothing non-essential fires pre-consent
- Schedule recurring scans
- Document the final configuration for the client file
💡 Using Consently? Add a website, customize from a cloned base configuration, embed the one-line script or GTM tag, scan, and publish. That sequence fits inside an hour once your base template exists.
Done: a new client site is live and compliant in under an hour, following the same checklist every time.
Step 9: Monitor consent rates and re-scan on a schedule
Every client site's consent rate needs a monthly check. A rate that suddenly drops usually means a broken or hidden banner; a rate near 100 percent usually means a dark pattern is forcing consent. Investigate a rate below roughly 30 percent, since the banner is likely broken or invisible. Investigate a rate above roughly 95 percent too, since the accept path may be easier to find than the reject path, exactly what regulators flag.
Re-scan monthly as a baseline. Move to weekly for client sites that change frequently, since a new plugin or ad pixel can introduce an unblocked tracker between scans.
💡 Using Consently? Weekly scheduled scans, consent analytics per site, and email alerts before a client hits its pageview limit do the watching. Review becomes exception-based, not a manual per-site check.
Done: a monthly review catches new trackers and banner problems across the whole portfolio, without opening every site by hand.
How to turn client compliance into recurring agency revenue
Cookie compliance is not a one-time setup fee. It is an ongoing service. Charge a flat setup fee scaled to site complexity, then a recurring care plan on top. The prevailing agency rate cards for the setup work break down by site type, from a simple brochure site to complex multisite work.
| Site type | Typical setup fee | What the fee covers |
|---|---|---|
| Basic brochure site | $150 to $300 | Install and style a standard consent banner on a simple site |
| E-commerce or lead-gen site | $300 to $750 | Map Consent Mode v2, automate script blocking, cover GDPR and CCPA |
| Enterprise or complex multisite | $1,000+ | Custom tag-manager integration, data mapping, and custom banner UX |
On top of the setup fee, a monthly care plan typically runs $50 to $150 per client. That plan covers re-scans, re-categorization, banner and Consent Mode upkeep, and a quarterly legal review. Package it instead of billing a one-off job.
A compliance care plan should include:
- Monthly or weekly re-scans depending on how often the client's site changes
- Re-categorization when a scan surfaces a new cookie or tracker
- Banner and Consent Mode maintenance as Google or the platform changes requirements
- A quarterly review of legal changes relevant to the client's regions
- Consent log export on request
There is a real, honest split on who should own the license. One practice: every client purchases and owns their own license. If the retainer ends, the client stays covered rather than the agency holding something the client is legally on the hook for. The opposite practice: bundle a multi-domain plan into your own account and price compliance into the retainer. That only works if the per-domain cost stays flat as you add clients.
Consently's Premium plan covers 5 domains for $199 per year, with the pageview quota shared across the account. That flat capacity pricing is what makes the "one plan, priced into the retainer" model work. Cost per client stays predictable as the portfolio grows. Be direct with clients about the tradeoff: Consently runs on a single agency account, with no formal reseller or partner-discount program yet. This is the flat-plan-into-retainer model, not a resale-markup model.
One agency owner's frustration with the category:
"I hate compliance. I hate lawyers. They add a tax on everything I do."
That resentment is exactly what a packaged care plan flips into margin instead of overhead.
Common agency cookie-compliance mistakes to avoid
The single most damaging mistake is assuming the client's controller status covers everything. It does not. Your agency carries its own processor duties no matter what the client's contract says. Five mistakes recur across agencies running client compliance.
- Assuming client responsibility covers everything. Consequence: processor liability exposure the agency didn't know it had. Remedy: sign a DPA and know exactly which duties are yours.
- Copying one client's banner configuration onto another. Consequence: the wrong consent model for that client's jurisdiction (an opt-in banner on a US-only site, or an opt-out banner on an EU-facing one). Remedy: map jurisdiction per client (Step 1) before cloning any configuration.
- A banner that shows but tags fire anyway. Consequence: a decorative banner and a real compliance violation, because nothing was actually blocked. Remedy: block before consent and verify in the browser's dev tools, every time.
- No re-scan after launch. Consequence: a new plugin or ad pixel adds an unblocked tracker that nobody catches. Remedy: schedule recurring scans (Step 9), monthly at minimum.
- Doing it for free with no written scope. Consequence: unpaid liability exposure and scope creep, with no contract to point to if something goes wrong. Remedy: a care plan, a scope-of-work clause that carries legal advice outside your scope, and clarity on who owns the license.
FAQs
Who is responsible for GDPR compliance, the agency or the client?
The client is usually the data controller and carries primary responsibility, but the agency is a data processor with its own separate duties. The agency is not absolved just because the client is the controller.
Can one cookie consent tool manage all my client sites?
Yes. A multi-site consent management platform with a shared dashboard lets one account manage every client domain. Consently supports 5 domains on its Premium plan and 10 on Enterprise, from a single login.
Should the agency or the client pay for the consent platform?
Both models work. Having the client purchase and own the license means they stay covered if the agency relationship ends. Bundling a multi-domain plan into the agency's account works when the per-domain cost stays flat as the portfolio grows.
Do US client sites need a cookie banner?
No US state strictly mandates a banner the way GDPR does. US privacy laws generally run an opt-out model instead. Sites must disclose data collection, let visitors opt out of data sale or sharing, and honor Global Privacy Control signals where applicable.
How often should I re-scan client sites for new cookies?
Monthly is the baseline for most client sites. Move to weekly for sites that change frequently, since a new plugin, pixel, or embed can introduce an unblocked tracker between scans.
Can I share consent across client domains?
Generally no. Each client is typically a separate data controller with its own visitors and cookie inventory, so consent does not carry across different clients' domains. Sharing consent across subdomains within one controller's own domain is a separate, narrower case.
How much should an agency charge for cookie compliance?
Charge a setup fee scaled to complexity, then a recurring care plan. Setup runs $150 to $300 for a basic site and $300 to $750 for e-commerce or lead-gen. Enterprise multisite work starts at $1,000. A monthly care plan usually adds $50 to $150 per client. Treating it as a free add-on is the mistake that creates unpaid liability.
Running consent across a client portfolio gets simpler once every site sits under one account instead of a separate login per client. Consently's multi-site dashboard, one-line install, per-client consent logs, and flat multi-domain pricing are built for exactly this. Start a free Consently trial and set up your first client site today.
