Drupal cookie consent with Klaro

How Drupal cookie consent with Klaro works and when you need it

Klaro is a consent layer for websites. On a Drupal site, it presents a consent notice to the visitor and keeps blocked services from loading until the visitor allows the category they belong to. A Drupal site that loads analytics, video players, maps or chat widgets from third parties on the first page view is sending data to those services before anyone has chosen anything. That is the situation this work addresses, and it is why a team should treat consent as a separate piece of work rather than a line item in the theme build.

You should plan it as its own workstream when the site embeds any service that sets cookies, loads scripts from another domain or writes visitor data to a third party. The decisions are split across roles. Legal or privacy staff decide which categories exist, what each service is described as, and what the notice must say for your jurisdictions. Marketing owns the analytics and campaign tags that need to be in each category. Engineering decides how Klaro is installed, how scripts and iframes are marked so they wait for consent, and how the consent state is stored and tested. Confirm early which of these decisions are yours and which need sign-off from outside counsel, because the configuration only reflects what those owners decide.

The work lives in your own Drupal codebase and your own hosting. Klaro configuration, the markup changes in templates and any custom module that renders third-party embeds are committed to your repository and deployed through your normal release process. Nothing in this implementation certifies that the resulting site meets any legal requirement; that judgment belongs to your privacy function and, where needed, an independent assessor. What this work gives you is a site whose behavior matches the choices your owners made, with evidence you can show them.

Klaro configuration options and when each one fits

This table compares the main Klaro configuration decisions for a Drupal consent setup, from service categories to how each third-party service is declared. Read each row as a choice to settle before build, with the cost of reversing it later. Confirm exact option names and default behavior against the Klaro documentation and the Drupal integration module you choose, because this page does not rely on release-specific details.

Decision	When the option fits	What it costs to change later
Service categories and default state	Choose categories such as necessary, analytics, marketing and embeds when your legal team wants per-purpose consent. Default-off suits most regulated sites.	Low to moderate. Renaming categories means updating every service declaration and any stored consent records that reference them.
Banner or modal layout	A banner with a short summary fits sites with few services. A modal with a per-category list fits sites that must show every purpose before consent.	Low. Layout is mostly theme and template work, but accessibility testing must be repeated after any change.
Consent required before first interaction	Required consent fits sites that load analytics or embeds in EU or UK audiences. Notice-only designs fit only where your counsel has confirmed that model is acceptable.	High. Switching from notice-only to blocking means reworking script loading and retesting every tag and embed.
Where the visitor's choice is stored	A browser cookie fits anonymous sites with a simple policy. Storing decisions server-side with a user record fits authenticated sites that need an auditable history.	Moderate to high. Moving storage later requires a migration of existing choices and a change to how the site reads them.
How each third-party service is declared	Declaring services in configuration fits teams that want version-controlled consent settings. Declaring them through a content or admin interface fits teams where marketing edits services often.	Moderate. Changing the declaration method means re-entering every service and checking that blocking still applies to each one.
Script and iframe blocking method	Blocking by type or attribute fits sites with many embeds from different sources. Explicit wrapping in templates fits small sites with a few known embeds.	Moderate. Templates and contributed modules that render embeds must be rechecked after each change to the blocking rule.
Consent record retention	Keep a log of choice, timestamp and policy version when you must show what a visitor agreed to. Keep only the current choice when your policy does not require history.	Moderate. Adding a record later covers only new visitors, so earlier consent cannot be reconstructed.

Setting up Klaro on a Drupal site, step by step

This sequence takes a Drupal team from version checks and a script inventory to a tested consent layer that blocks third-party services until a visitor agrees. Each step ends with a check that shows whether the consent behavior holds before launch.

Confirm version and module compatibility
The site lead and a developer confirm the Drupal core version in use, the Klaro release, and the Drupal module that connects Klaro to Drupal. Drupal 11 requires PHP 8.3 or later, so check the server PHP version first, then read the module's project page on Drupal.org for its supported core versions and open issues. Ask the integration partner or your developer to confirm in writing which Klaro version the module bundles or loads. The step is done when a written compatibility note names the core version, PHP version, Klaro release and module release, and a test site on those exact versions loads without errors in the browser console.
Inventory every third-party script and embed
The marketing lead and a developer list every script, iframe, pixel and tag the site loads, including those added through tag managers, theme templates, custom blocks and embedded widgets such as video players, maps and chat. Record where each one is added (theme file, block, text format, tag manager container), what data it sends, and which page types load it. Crawl the staging site with browser developer tools and note any request to a third-party domain. The step is done when the inventory lists every third-party origin observed on a full page crawl, with an owner and an insertion point for each item, and nothing loads from a domain that is not on the list.
Define service categories with legal and marketing owners
The privacy or legal owner and the marketing owner agree on the consent categories, usually strictly necessary, analytics, marketing and embedded content, and assign each service from the inventory to one category. Legal decides which categories need opt-in and what the wording must say about each purpose. Marketing confirms which tools depend on consent for their reporting. Document the decisions in a short register that names the service, category, purpose, data sent, and the person who approved it. Ask your legal team to confirm the requirements that apply in each jurisdiction you serve, since this page does not set them. The step is done when every inventoried service maps to exactly one category and the register is signed off.
Declare services and configure blocking
A developer writes one Klaro service declaration per item in the register, with a unique name, its category, a purpose description, and the script or iframe selectors Klaro must intercept. Scripts are changed so that their type or source is held until the matching service is accepted, and iframes are given a placeholder that appears until consent is granted. Store declarations in version-controlled configuration so changes go through review. The step is done when a page with no stored consent loads none of the blocked third-party requests in the network panel, and accepting one service releases only its own scripts.
Rebuild the banner and preference text in the theme
A front-end developer and a content editor rebuild the consent banner, preference center and placeholder messages in the Drupal theme, so they match the design system and the language approved in the register. Keep the strings translatable if the site is multilingual, and confirm that the banner, buttons and preference controls work with the keyboard and screen readers. Link to the privacy notice from the banner. The step is done when the banner renders on every template type, every control is reachable by keyboard, and the text in each language matches the approved wording.
Test blocked and unblocked states on staging
A tester opens staging in a fresh browser profile or a private window that has never stored consent, then runs through each page type. Before any choice, confirm that no blocked service requests data, no placeholder is replaced by an embed, and no analytics hit reaches its collector. Accept one category at a time, reload, and check that only that category loads. Withdraw consent and confirm the scripts stop on the next page view. Save screenshots and network logs as test evidence. The step is done when the test script covers every category and every page type, and the results are recorded for each pass.
Verify cache behavior and analytics after consent
A developer checks that the page cache, reverse proxy or CDN does not serve a page with consent-dependent markup to a visitor who has a different choice. Confirm that the consent state is varied by a cookie the cache honors, and that Drupal's cache tags purge correctly when declarations change. Then check analytics end to end: a visitor who accepts analytics should produce a hit in the analytics tool, and a visitor who declines should produce none. Ask your hosting or CDN provider to confirm how their cache treats cookies on your plan. The step is done when cache headers and a cached page test show correct behavior for both states, and the analytics real-time view records hits only after acceptance.

Which services to categorize and how each one behaves

A Drupal site rarely embeds one third-party script. Analytics, advertising, video, chat, social embeds and tag managers each load differently, so each group needs its own category, blocking rule and test plan. The groups below are the ones most projects inventory first.

Web analytics

Analytics tags set cookies and send page views to an external collector, so they usually belong in a statistics or analytics category. Blocking them until consent is given means pages visited before consent produce no page view, and sessions can look shorter or start later than they really did. Check that the tag fires only after the matching category is accepted, that the initial page view is not lost on consent, and that any server-side or first-party collection setup follows the same rule. Confirm each analytics vendor's own consent and data-retention requirements.

Advertising and pixels

Advertising tags, retargeting pixels and conversion trackers usually fall in a marketing category and are the most likely to need strict blocking. When they are blocked, conversion events from a session that consented late may never reach the ad platform, and audience lists shrink. Test a full path from landing page to form submission in a private window, once with consent accepted and once with it refused, and confirm that refused visitors trigger no outbound requests to the ad domain. Confirm each platform's consent mode requirements before choosing a configuration.

Embedded video and maps

Video players and map widgets set cookies and load content from their provider's servers when the page renders. Klaro can replace an iframe with a placeholder until the visitor accepts the matching service, which keeps the page layout intact. The common failure is an empty block with no way to accept, or a placeholder that never reloads the embed after consent. Test each embed template in the theme, including lazy-loaded blocks, Views and any content inserted through the editor, and confirm the placeholder text meets your accessibility standard.

Chat and support widgets

Live chat and help widgets often load a large script, store an identifier in local storage and open a persistent connection, so they need a functional or support category decision. Blocking the script hides the chat launcher entirely, which can remove a support path that visitors expect. Decide whether the widget is essential, and if so, whether it needs consent at all under your own legal review. If it is consent-gated, test that the launcher appears after acceptance without a page reload, and that the widget does not start before the visitor opens it.

Social embeds and sharing

Social post embeds and share buttons load scripts from social networks and can read the visitor's browser state. Embedded posts commonly appear as blank boxes when blocked, and share buttons may stop working if their script is gated but their markup is not. Map each embed type to its own service entry, check that the placeholder explains which provider is blocked, and test both the embed and its share action after acceptance. Confirm the provider's own consent requirements, since these change over time.

Tag managers and container scripts

A tag manager loads other tags, so it must be classified before anything it contains can run. If the container script is allowed by default, tags inside it can fire before the visitor has chosen, and if it is blocked, every tag inside it stops, including ones that were meant to be essential. Decide which tags the container may load in each category, confirm that tags are gated inside the container and not only by Klaro, and test a fresh browser session with consent refused to confirm that no outbound tag request appears.

What Drupal cookie consent records should hold and who keeps them

A consent record is the evidence that a visitor made a choice, so it should capture enough to show what was decided and when. In a Klaro setup on Drupal, plan for a timestamp, the service categories the visitor accepted or declined, the version of the cookie policy and consent notice shown at the time, and a decision about how the visitor is identified. That last item matters most. A random consent identifier stored in the browser is different from an IP address or a logged-in account ID, and each carries different personal data obligations. Before you design any log table or export, confirm with the Klaro module documentation and your own testing exactly what the browser stores, under which key, for how long, and whether any server-side hook or logging is provided by the module or your integration code. Do not assume the module records anything you have not seen in the browser's storage inspector.

Consent records can live in browser storage, in a first-party cookie, or in server-side logs maintained by your Drupal site. Browser storage and cookies are simple but leave no central evidence if a visitor clears their data or a dispute arises months later. Server-side records give you an audit trail but turn consent choices into personal data held in your database, your backups and your logging pipeline, all of which need retention rules. Decide the storage location, retention period and lawful basis with your legal and privacy owners before the build starts. DeployOpen does not make those decisions. What DeployOpen can do is configure the controls, document the data flows and collect the technical evidence that an independent auditor or certification body may ask for. DeployOpen does not issue audit reports, attestations or certifications.

Once the storage design is agreed, write it down as a short data inventory: each consent field, where it lives, who can read it, how it is exported for a data subject request and when it is deleted. Include backups, since a deleted record may persist in restored snapshots unless your retention policy covers them. Ask whoever operates the hosting environment to confirm log rotation and access roles for any server-side store. Then test the design against real flows: accept, decline, change choice, revisit after the policy version changes, and clear browser data. Each test result becomes evidence for your compliance file and tells you whether the record actually reflects the visitor's choice.

Consent setup for single sites, multisite estates and decoupled front ends

On a single site with a traditional Drupal theme, consent is mostly a configuration and theme task. Klaro runs in the browser, so the service list, categories and banner text live in one configuration that loads on every page. Drupal renders the scripts and iframes, and the consent manager decides when they may run. The visitor's choice is held in a browser cookie, so the decision stays on the visitor's device.

Service configuration: Register each analytics tool, embed and marketing tag as a service with its category and the purpose text shown to visitors.
Script markup: Change the scripts and iframes that the theme or a text filter outputs so they carry the service identifier instead of loading directly.
Page cache: Drupal's page cache serves identical HTML to anonymous visitors, so consent-dependent markup must not be baked into cached pages. Read the cookie in JavaScript after the page loads.
Consent records: A browser cookie alone does not give you an audit trail of who agreed to what and when. Decide early whether you need server-side records.

Confirm which templates and contributed modules output third-party code today, because each one needs a consent path.

Security and operational risks in consent configuration

A consent banner only protects visitors if the configuration holds after launch. The risks below come from the page itself, from people who edit it, from the caching layer, from updates and from the records that prove consent was asked for and respected.

Scripts that bypass consent

Inline scripts, hard-coded tags in templates and iframes added directly to content can load before Klaro has a visitor's choice. Crawl the rendered pages of each template with consent declined and list every outbound request to a third-party host. For each one, confirm it is either blocked until consent or is a strictly necessary request you have documented. Treat any missed iframe as a configuration defect, not a cosmetic issue.

Undeclared third-party additions

A content editor or a tag manager container can add a new analytics or embed script without anyone updating the Klaro service list. Require a review gate for every tag manager change and every new embed type in content, with the vendor, purpose, category and cookie names recorded before publication. Ask who in your team can publish tag manager containers and whether that change path is logged.

Consent state shared between visitors

If a reverse proxy, CDN or page cache stores a response that was rendered for one visitor's consent state, the next visitor may receive the wrong banner state or scripts that should be blocked. Exclude pages and requests that set or read the consent cookie from shared caching, and confirm that cache tags and vary rules are tested with two separate browser sessions. Ask your hosting team how cache keys are built.

Banner markup changes after updates

A Drupal core or contributed module update can change the markup, class names or load order that Klaro depends on, and the banner may stop appearing or stop blocking. Add regression tests that check the banner renders, scripts stay blocked before consent and the preference link works, and run them after each update. Track advisories and release notes through the Drupal Security Team process so security fixes are scheduled, not delayed.

Lost evidence of consent

When a regulator, auditor or data subject asks what was agreed to, you need records showing the banner version, categories accepted, time and a way to match them to a session. Logs that rotate on a short schedule can remove this evidence before the question arrives. Set a written retention rule for consent records, decide who can read them, and confirm with your legal and privacy team how long they must be kept.

Questions teams ask before outsourcing Klaro consent work

How much effort does Klaro consent work take, and what makes it bigger?

The effort depends mostly on the number of third-party services that load on your pages, the number of sites or domains that share a consent setup, whether scripts are custom or come from vendor tags, and how many review rounds your legal and privacy teams need. A site with a short list of standard analytics and video embeds is a smaller job than a multisite estate with tag-manager containers and bespoke scripts. Ask for the effort broken down by these drivers in a written scope, not as a single figure. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the quote follows from the inventory you provide.

Can an internal Drupal developer set up Klaro alone?

A capable Drupal developer can install and configure Klaro, but the technical wiring is only part of the job. Someone must map every script, iframe and pixel to a service category, decide which categories need prior consent, and test that nothing loads before a visitor agrees. Those decisions need input from privacy, legal and marketing owners who are not usually on the development team. Teams with one developer, no staging environment and no named owners for each category often find the non-technical work takes longer than the code. An outside partner can take on the build and testing while your owners make the policy decisions.

What does the work need from our team before it starts?

Plan to provide four things. First, a complete inventory of third-party services, including tag manager containers, embedded players, maps, chat widgets and analytics tags, with the page or template where each one appears. Second, a named owner for each service category who can approve how that service is classified. Third, staging access that mirrors production closely enough to test blocked and allowed states. Fourth, a sign-off step for consent wording and for the final test results. Missing inventory items are the most common cause of late changes, so ask the partner to state how the inventory will be verified before build begins.

What sets the duration of a Klaro consent project?

Duration is set by how quickly the inventory can be completed, how many services need individual decisions, how many sites share one configuration, and how long each approval cycle takes on your side. Build and testing time is usually the smaller part when the inventory is clear. Legal review, consent text changes and waiting for vendor documentation on how a script behaves can each add a cycle. Request a timeline in the written scope that lists the client-side dependencies separately, so you can see which delays belong to your organization and which belong to the build.

What recurs after launch, and who maintains it?

Consent work does not end at launch. New marketing tags, changed vendors, updated embeds and new pages can all introduce scripts that load before consent. Drupal core and Klaro module updates need regression testing of blocked and allowed states. Consent text and category descriptions also need periodic review when your policies change. Decide before launch who owns the service inventory, who approves new services, and whether testing runs after each release. These recurring tasks can be kept in-house or covered by an ongoing support arrangement, and the choice should be written into the scope.

How is consent work quoted, and what should the quote include?

DeployOpen does not publish a price list. A quote follows from a written scope that lists the sites, services, categories, integrations, testing approach, deliverables, client responsibilities and timeline. Ask that the quote separate one-time build work from any recurring support or testing, and that it state what happens if the inventory grows during the project. Compare proposals on the same inventory and the same definition of done, not on headline totals. Ask each bidder to confirm what they will not check, such as the legal adequacy of your consent wording, which remains with your counsel and any independent assessor you use.

Limits to confirm in your environment before you start

Klaro consent work depends on facts about your Drupal version, your caching and CDN layer, your third-party vendors, your legal wording and your hosting. Each card below names one limit to verify and the person who can answer it.

Klaro and module compatibility

Confirm which Klaro release and which Drupal integration module version work with your Drupal core and PHP version. Drupal 10 requires PHP 8.1 or later and Drupal 11 requires PHP 8.3 or later, so an older PHP runtime can block the upgrade path before the consent work starts. Ask your Drupal lead to check the module's supported core range on its project page, and ask your platform team which PHP version the production hosts run. Record the pair you approve so later updates can be tested against it.

Caching and CDN behavior

Consent logic runs in the browser, but a page cache, reverse proxy or CDN can serve a copy of a page that was rendered for a different visitor state. Ask your platform team whether the cache layer varies by cookie, and whether the Klaro integration's configuration and consent cookie are excluded from cached responses. Confirm that script blocking still works after a cache purge, and that the CDN does not rewrite or strip the attributes used to defer scripts.

Vendor support for deferred loading

Each analytics tool or embed must load only after the visitor consents, and that requires the vendor's snippet to be movable into a blocked state. Ask each vendor whether its tag can be deferred, whether it supports consent mode or a callback, and whether its embeds such as video players and maps can be swapped for a placeholder until consent. Vendors that inject tags through their own tag manager may need a separate configuration, so confirm that path too.

Consent text and categories

Your legal or privacy team owns the wording of each consent notice, the category names and what each service is described as doing. Agree that wording in writing before developers configure the service inventory, because changes after launch require a new release and a review of the stored records. Ask legal whether essential cookies need a separate category and whether the notice must be available in each language your site serves.

Storage for consent records

Consent records need a store that holds the visitor's choices, a timestamp and the version of the notice shown. Ask your hosting team whether the database or log platform can keep these records for the period your policy sets, whether it lets you export them, and whether it sits within the data location your organization requires. If the site is cached aggressively, confirm that records are written by the server and not inferred from the cache.

Ownership of the service inventory

The service list is the record of every script, iframe and pixel the site loads, and it goes stale whenever marketing adds a tag. Name an owner in marketing or product who must request a review before any new third-party embed is published. Ask your Drupal team whether they can maintain the category assignments, and whether the editorial team can add embeds without a developer. Without this owner, the consent setup will drift from what the site really loads.

How DeployOpen scopes and delivers Klaro consent on Drupal

DeployOpen plans and builds Drupal cookie consent with Klaro inside your own infrastructure, starting from a written scope that names every service, category and script. Work is fixed-scope where possible, with agreed deliverables, and the finished configuration is documented so your own team can run it.

How we scope

Inventory every cookie, tag, pixel and embedded third-party service that loads on each site and template.
Agree the service categories, the default state for each, and which pages or regions the banner applies to.
Define the written scope, deliverables and acceptance tests before build starts, with ongoing support available as a retainer.

How we build

Configure Klaro services and purposes, then wire blocking so scripts and iframes stay inert until consent is recorded.
Set up consent records and the Drupal side of the banner, including translations and the settings page for editors.
Test analytics events, embeds and fallback content in a staging environment that mirrors your production hosting.

How we hand over

Document the service register, category mapping and the steps to add a new third-party service.
Hand over configuration as code in your repository so changes move through your normal review and release process.
Walk your privacy, marketing and engineering owners through the consent flow and the evidence it produces.

How we support

Review the service register when marketing or engineering adds a tag, embed or tracking script.
Keep Klaro and Drupal updates tested against the consent configuration as part of routine maintenance.
Provide support arrangements as a retainer, with scope agreed in writing and confirmed with your own counsel.