# Managing cookie consent across many client sites

> An agency playbook for managing cookie consent across many client sites: roles and contracts, shared baselines, onboarding, monitoring and consent records.

Source: https://www.cookiesh.eu/blog/cookie-consent-for-agencies  
Published: 2026-10-20

## Key takeaways

- The client is usually the controller for its website's cookies, so the client must approve banner wording, categories and policy text.
- Agencies scale consent work by standardizing categories, script blocking and Consent Mode logic, then configuring legal content per client.
- A fixed onboarding sequence of audit, classify, configure, test and sign-off keeps every client launch consistent.
- Scheduled cookie scans catch trackers that client teams add through tag managers after launch.
- Keep each client's consent records separate and exportable, with access limited to the people who work on that client.

To manage cookie consent across many client sites, standardize everything technical and keep everything legal client-specific. Use one setup pattern, one category model and one script-blocking approach for every site. Give each client its own configuration, policy text, regional rules and consent records. Then re-scan regularly, because client sites keep changing after launch.

## Who is responsible for consent on a client's site?

The client usually is. As the business that decides why and how visitors' data is processed, the client is normally the controller under the GDPR, and it is the party a regulator will contact.

Agencies typically act as processors when they manage tags, analytics or consent logs on a client's behalf. Article 28 of the GDPR requires a contract that sets out what a processor may do with that data. In practice, that means:

- A data processing agreement with each client where you handle personal data for them.
- Written client sign-off on banner wording, categories, regions and the cookie policy.
- A clear line between implementation and legal advice. Recommend that the client's counsel decides contested questions, such as whether to use [advanced consent mode](/blog/basic-vs-advanced-consent-mode).

Clear roles protect the agency as much as the client. When a complaint arrives, everyone should already know who approved what.

## What should you standardize across clients?

Standardize the engineering and the process, not the legal content. A shared baseline cuts setup time, and every site benefits when you fix or improve something once.

| Standardize across all clients | Configure per client |
|---|---|
| Banner component, accessibility and performance budget | Company name, branding and languages |
| Category model: necessary, preferences, analytics, marketing | Which vendors and cookies sit in each category |
| Script-blocking pattern | Regions served and the banner each region sees |
| Google Consent Mode default and update logic | Basic or advanced mode, per the client's legal decision |
| Consent log format and retention mechanics | Retention period and data processing terms |
| Scanning schedule and alert routing | Client owners who receive alerts |

Use the same approach to [blocking scripts until consent](/blog/block-scripts-until-consent) everywhere. When every site follows one pattern, any developer on your team can debug any client site in minutes instead of relearning a custom setup.

Keep your baseline in version control with a changelog. When you change it, roll the update out deliberately, client by client, and record which sites run which version.

## How do you onboard a new client site?

Treat onboarding as a fixed sequence so nothing gets skipped under deadline pressure.

1. **Audit:** run a [cookie audit](/blog/how-to-run-a-cookie-audit) of the live site to inventory cookies, scripts and vendors.
2. **Classify:** map each vendor to a category and flag anything you can't identify for the client to explain.
3. **Decide regions:** confirm where visitors come from and which rules apply, such as GDPR opt-in consent in the EU, UK GDPR and PECR in the UK, or CCPA opt-out rights in California.
4. **Configure:** create the client's banner, policy link and language versions from your baseline.
5. **Gate tags:** block non-essential scripts until consent and set Consent Mode defaults in Google Tag Manager (GTM).
6. **Test:** confirm that nothing non-essential runs before consent, and that rejecting and withdrawing both work.
7. **Sign off:** get written approval from the client before go-live.
8. **Hand over:** document what you configured, who can change it and how the client can request consent records.

Step 2 is where most surprises appear. Older sites often carry scripts nobody on the client side remembers adding, and each one needs an owner and a purpose before it can be categorized.

## How do you keep client sites compliant after launch?

Schedule recurring scans and alert on changes. Client sites drift: a marketing team adds a pixel in GTM, a plugin update brings a new cookie, or a landing page tool ships its own trackers.

Controls that keep drift in check:

- Restrict who can publish in client GTM containers, and require consent settings on every new tag.
- Re-scan after each release and on a fixed schedule, and route new, unclassified cookies to a named client owner.
- Bump the banner version and ask for consent again when purposes or vendors change materially.
- Review banner design against current regulator guidance on manipulative patterns at least once a year.

Report these findings to clients in a short, regular summary: new vendors detected, banner versions changed and open issues. It shows the value of the work and keeps decisions documented.

## How do you manage consent records for many clients?

Keep each client's records logically separated, with access limited to the people who work on that client. Mixing data across clients in one shared log creates confidentiality problems and makes exports harder.

Each client should be able to get an export of its own [consent records](/blog/proof-of-consent-records) on request, for example to answer a regulator or a data subject access request. Agree in the contract what happens to records when the engagement ends: return them, delete them, or both, and on what timeline.

Apply the same discipline to people. Use role-based access and multi-factor authentication, and remove access promptly when staff leave or a client relationship ends.

## Bottom line

Agencies that handle consent well treat it as a repeatable product, not a per-site project. Standardize the technical baseline, keep legal decisions with the client, monitor sites continuously and keep each client's records separate and exportable. Tools like Cookiesh offer white-labeling and multi-tenancy for agencies, which helps run this playbook from one place.

*This article is general information, not legal advice. For decisions about your specific situation, consult a qualified privacy professional.*

## FAQ

### Is an agency a data processor for its clients' cookie consent?

Often, when it handles personal data such as consent logs or analytics on the client's behalf. In that case GDPR Article 28 requires a written contract covering that processing. The exact role depends on the arrangement, so confirm it with counsel.

### Should every client use the same cookie banner?

They can share the same component and behavior, but not the same content. Each client needs its own company details, cookie list, policy link, languages and branding, because each site uses different vendors for different purposes.

### Who should write the cookie policy for a client site?

The client owns it, because it describes the client's processing. An agency can supply a template and the technical inventory from cookie scans, but the client or its legal advisor should review and approve the final text.

### How often should agencies re-scan client sites?

After every release and on a fixed schedule, such as monthly. Tag managers let marketing teams add tags without a code deploy, so scheduled scans catch changes that release-based checks miss.

## Sources

- [Regulation (EU) 2016/679 (GDPR), EUR-Lex](https://eur-lex.europa.eu/eli/reg/2016/679/oj)
- [Directive 2002/58/EC (ePrivacy Directive), EUR-Lex](https://eur-lex.europa.eu/eli/dir/2002/58/oj)
- [EDPB Guidelines 05/2020 on consent](https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-052020-consent-under-regulation-2016679_en)