Vicedomini Softworks

Digital Regulations

GDPR Cookie Banners in Italy: 7 Checks to Get Right

11 October 2026

GDPR Cookie Banners in Italy: 7 Checks to Get Right

In Italy, a GDPR compliant cookie banner must block non essential cookies until the user gives explicit consent, provide a reject option as visible as accept, let an ‘X’ close count as refusal when defaults keep non essential cookies blocked, link to a detailed privacy or cookie policy, and record consent under GDPR Article 7(1). These five requirements form the baseline against which the Garante per la protezione dei dati personali evaluates every banner on the Italian web.

TL;DR:

  • Strictly technical cookies need no prior consent, while analytics is exempt only when genuinely anonymized and limited to first party statistical purposes.
  • After a refusal, do not prompt again for six months unless the processing changes, such as adding a vendor, pixel, or retention period.
  • Consent logs should capture timestamps, chosen categories, the banner and policy versions, and a session identifier, while collecting no more personal data than needed.
  • Block every nonessential script before it runs, including server side events and scripts added after navigation; visual banner design alone cannot prevent violations.
Vicedomini Softworks
vicedominisoftworks.com
Build Cookie Consent Into Your Software
Vicedomini Softworks engineers custom web applications and integrations, helping businesses address consent requirements as part of their software.
Ask for a consultation

Table of Contents

What Italian law and Garante guidelines require

Cookie consent in Italy sits at the intersection of two legal instruments: the ePrivacy Directive, which governs the storage of and access to information on a user’s device, and the GDPR, which governs the processing of personal data that often follows. The Garante’s 2021 Linee guida translate this interplay into operational rules for Italian website operators, clarifying that the ePrivacy rule on consent for non technical cookies must be read together with the GDPR’s conditions for valid consent.

The guidelines draw a sharp line between two categories of cookies. Technical cookies, used strictly for functions the user has requested such as session management or load balancing, do not require prior consent. Everything else, including profiling cookies, marketing trackers and most third party analytics tools, requires prior, informed and explicit consent before any script executes.

That consent must meet the conditions set out in GDPR Article 7(1): it has to be freely given, specific to each purpose, informed through clear language, and given through an unambiguous affirmative action. A scroll, a continued browsing action or a pre-checked box does not satisfy any of these conditions on its own.

  • Technical cookies: no prior consent needed, but users must still be informed of their use.
  • Profiling and marketing cookies: prior consent required before the script loads.
  • Analytics cookies: consent required unless genuinely anonymised and limited to first party statistical purposes.

Respecting this distinction from the outset avoids the most common enforcement trigger the Garante has flagged: scripts firing before any consent decision has been recorded.

A compliant banner is judged on what happens in the first few seconds a visitor sees it, and on what sits one click away. The Garante’s FAQ on cookies describes a multilayer model: a concise first layer with clear commands, and an extended second layer for granular choices.

  1. Keep the first layer short: a few sentences on cookie use, an explicit “Accept” button and an equally prominent “Reject” button or accessible close control.
  2. Make sure the close (‘X’) preserves the default state, meaning non essential cookies stay blocked if the user dismisses the banner without choosing.
  3. Place a one-click link from the first layer into a preference centre that lists categories, purposes and the vendors behind each script.
  4. Never use pre-ticked boxes for anything beyond strictly technical cookies.
  5. Never treat scrolling, clicking a link or continued navigation as consent to non essential cookies.
  6. Avoid cookie walls that block access to content unless the user accepts tracking, since the EDPB cookie banner taskforce and related EDPB guidance treat forced consent as a threat to its validity.
  7. Do not re-prompt a user who has refused consent within six months of that refusal, unless the processing itself has materially changed, as the Garante’s clarification on re-prompting states.

Pro Tip: Run your banner through a private browsing session with scripts blocked by default, then check your network tab: if any third party request fires before a consent click, the banner fails the audit regardless of how it looks.

GDPR Article 7(1) places the burden of proof on the site owner, not the visitor. Demonstrating valid consent means logging enough detail to reconstruct exactly what the user saw and chose, at what moment, and under which version of the policy.

A defensible consent record typically includes:

  • A timestamp of the consent or refusal action.
  • The specific categories accepted or rejected, not just a single yes or no flag.
  • The version or language of the banner and policy text shown at that moment.
  • A receipt identifier or a hashed user agent string, sufficient to link the record to a session without storing more personal data than necessary.

Withdrawal has to be as easy as giving consent in the first place. A floating icon or a persistent footer link labelled something like “cookie preferences” lets a returning visitor reopen the preference centre and change category choices at any time, with the change taking effect immediately and being logged with its own timestamp.

Consent is not permanent. It expires in practice whenever the underlying processing changes: a new analytics vendor, an added marketing pixel or a revised retention period all justify a fresh consent request. Outside of those triggers, the Garante’s guidance against repeated prompts within six months of a refusal still applies, which means consent state should be treated as durable rather than something to re-ask opportunistically.

Design and UX patterns that satisfy law and user experience

Compliance and usability point in the same direction once the banner treats both choices equally. Symmetry of choice means the “Accept” and “Reject” buttons share the same size, colour weight and position prominence, rather than accept appearing as a bright button and reject as a faint text link buried in a corner.

  • Keep the first layer to a handful of lines, with a clear path labelled “manage preferences” or similar leading to granular, per-category toggles.
  • Size touch targets for mobile so that reject is not harder to tap than accept on a small screen.
  • Write category descriptions in plain Italian, avoiding jargon that would require a user to already understand tracking technology to make an informed choice.
  • Support the languages your actual audience reads in, since an Italian-only banner on a site serving other EU visitors undermines the “informed” requirement for those readers.

Pro Tip: Test your wording by reading only the first layer aloud: if a visitor cannot understand what they are agreeing to without opening the second layer, the first layer is not doing its job.

Accessibility matters as much as legal symmetry. A banner that traps keyboard focus, lacks sufficient colour contrast or cannot be dismissed by screen reader users creates a barrier that undermines the “freely given” standard the GDPR requires, since a user who cannot operate the controls cannot meaningfully choose.

Technical implementation notes for developers

The engineering side of consent compliance is where most banners quietly fail, even when the visible design looks correct. Auto-blocking has to happen before any tag manager or analytics snippet executes, not after a banner merely displays on top of scripts that have already fired.

  • Gate every non essential script behind a consent check at the point of injection, whether that is a tag manager container, an inline script tag or a server-side rendered include.
  • Maintain a script-to-category map that assigns each vendor, pixel or tag to the correct consent category, and keep that map synchronised with the preference centre’s displayed list.
  • Enforce blocking on both client and server where tracking can originate from either layer, since a server-side event sent to an analytics endpoint bypasses a purely client-side consent gate.
  • Store consent logs in a format that can be exported on request, since a regulator or a user exercising their rights may ask for evidence of what was recorded and when.
  • Run automated end-to-end tests that simulate a fresh visitor, a reject action and an accept action, checking that blocked scripts stay blocked and unblocked scripts load only after the matching category is approved.
  • Monitor vendor changes: a third party script that starts loading an additional tracking pixel without a code change on your side can silently break compliance.

Teams building consent-proof audit trails for other channels, such as messaging platforms, face a similar record-keeping problem; the practical guidance in Wattle AI’s piece on WhatsApp opt-in records on what to keep and for how long maps closely onto the same timestamp-and-category logic a cookie consent log needs.

Engineering-first implementation checklist (practitioner notes)

A reliable rollout follows a fixed sequence: audit every script currently firing on the site, implement auto-blocking by category, wire consent events into backend logs so they are queryable alongside other business data, then test accessibility and multilingual behaviour before launch.

Four-stage cookie consent implementation sequence

Once live, production monitoring should alert on script load failures and unexpected vendor changes, and a regression suite should re-run the consent paths after every deployment. Treating consent logging as a first-class backend concern, rather than a frontend afterthought, is what keeps a banner compliant months after launch rather than only on the day it shipped.

The ePrivacy Directive is the instrument that actually requires consent before storing or accessing information on a user’s terminal equipment, cookies included. It does not, however, define what counts as valid consent: for that definition, it borrows the standard set by the GDPR.

This means a cookie banner has to satisfy two overlapping legal tests at once. The ePrivacy rule asks whether consent was obtained before the storage or access happened. The GDPR’s Article 7(1) asks whether that consent, once obtained, can be demonstrated as freely given, specific, informed and unambiguous. A banner that blocks scripts correctly but cannot produce a consent record on request only passes the first test.

Member States implement the ePrivacy Directive through their own national laws, which is why the Garante’s guidelines exist as an Italian-specific interpretation layered on top of the shared EU baseline. Where personal data processing follows from the cookies themselves, such as building an advertising profile, the GDPR’s wider obligations around purpose limitation and data minimisation also apply, not just the consent requirement. Treating the banner purely as an ePrivacy formality and ignoring the GDPR layer underneath is one of the more common gaps in otherwise reasonable-looking implementations.

Outside Italy, the GDPR and ePrivacy Directive apply across the EU and EEA, but implementation of the ePrivacy rules is national, which produces real variation in enforcement style and banner expectations. Germany, France and Spain each have their own data protection authority guidance, and while the underlying principles (prior consent, equal prominence for reject, no cookie walls) are consistent with the EDPB’s positions, specific wording requirements and enforcement priorities differ by market.

The EDPB cookie banner taskforce report was created precisely because of this fragmentation: it compiled complaints across multiple Member States and found the same recurring infringements, absent reject options and pre-ticked boxes, regardless of jurisdiction, which pushed national regulators toward a more harmonised baseline.

For an organisation operating sites across several EMEA markets, the practical implication is to build the banner to the strictest reasonable standard (the Italian Garante’s explicit multilayer and symmetry requirements are a solid floor) and treat national variations as additional labelling or language requirements rather than structural rebuilds. A banner engineered around consent blocking, equal-weight choices and exportable records tends to satisfy the spirit of every national authority’s guidance, even where the exact phrasing expected differs slightly from one country to the next.

Managing third-party cookies and embedded scripts

Third party scripts, embedded video players, social share widgets, advertising pixels and analytics tags are the most common source of consent failures, because they often load additional sub-resources that the site owner did not directly request. A single embedded video widget can silently pull in a tracking pixel from a different vendor entirely.

Every third party script needs an entry in the vendor list shown in the preference centre, including the purpose it serves and the category it belongs to. When a script is loaded through an iframe, such as an embedded map or video, the safest pattern is a consent-gated placeholder: the embed itself does not load until the relevant category is accepted, replaced beforehand by a static preview and a prompt to enable that content category.

Tag managers simplify categorisation but do not remove the responsibility to audit what each tag actually loads, since a tag manager container can be updated by a marketing team without a corresponding code review. Keeping the vendor list and the script-blocking map in sync requires a recurring audit, not a one-time setup, particularly when embedded content comes from platforms that change their own tracking behaviour over time.

Cookie consent in single page applications and modern frameworks

Single page applications built with React, Angular or similar frameworks complicate consent blocking because navigation between views does not trigger a full page reload, which is the moment many traditional consent scripts expect to run. A consent banner that only checks for scripts at initial page load can miss scripts injected later by route changes or lazy-loaded components.

The reliable pattern is to centralise consent state in the application’s own state management layer (a context provider in React, a service in Angular) so that every component requesting a third party script, whether rendered on initial load or after a route change, checks current consent state before injecting anything. Analytics calls tied to route changes, a common SPA pattern for tracking virtual pageviews, need the same gating as the initial page load script.

Server-side rendering and hydration add another wrinkle: a script rendered server-side before the client-side consent check runs can briefly execute before the banner has any chance to block it. Gating script injection in the server-rendered output itself, rather than relying solely on a client-side script that runs after hydration, closes that gap for frameworks that render on the server by default.

A banner that passes an audit on launch day can drift out of compliance within weeks if nobody monitors it. Marketing teams add new pixels through a tag manager, vendors change what their scripts load, and a browser update can alter how a consent management platform’s blocking script behaves.

A recurring audit schedule, checking network requests against the published vendor list and confirming that scripts still respect the consent categories they are mapped to, catches this drift before it becomes a pattern of infringement. Automated regression tests that simulate accept, reject and partial-category consent, run on every deployment, catch code changes that accidentally bypass the consent gate.

Consent logs themselves need periodic review too: spot-checking that timestamps, categories and receipt identifiers are being captured correctly confirms the Article 7(1) record keeping obligation is being met in practice, not just in the original design document. Treating the banner as a feature that ships once, rather than a system that needs the same monitoring discipline as any other production component, is where long-running compliance tends to fail quietly.

Court of Justice of the European Union decisions on consent have consistently reinforced the same principles the Garante and EDPB already apply: consent must be a specific, informed and unambiguous act, and pre-ticked boxes or inactivity cannot stand in for it. Rulings addressing the use of pre-checked checkboxes confirmed that an opt-out model, where the user must actively uncheck a box to refuse, does not meet the active consent standard the GDPR requires.

The practical adaptation for a banner is architectural rather than cosmetic: every category toggle in the preference centre needs to default to off, and the overall design needs to make clear that doing nothing results in no non essential tracking, not partial tracking that the user would need to actively disable. Banners inherited from older implementations, built before these clarifications, often still default marketing or analytics toggles to on, which is the single most common gap a retrofit needs to close.

Ongoing judicial attention to consent also reinforces why exportable, timestamped consent records matter: a banner’s design choices are easiest to defend when there is a verifiable log showing the default state users actually saw, not just a claim about how the code was supposed to behave.

Why the Garante approach benefits Italian websites

Treating consent properly lowers legal exposure, and it sharpens analytics by removing noise from users who never meant to be tracked. Respecting a clear choice is also, simply, part of building a site people trust.

— Pepe F.

Shipping a cookie banner that genuinely blocks scripts, logs consent correctly and survives a vendor change six months later is an engineering problem, not just a design one, and we approach it that way. Our initial assessment maps every script currently running on your site against the categories that actually need prior consent, then we build the auto-blocking, consent logging and preference centre as part of the same architecture, not bolted on afterwards.

Vicedomini Softworks

Because we work directly with the engineers building your systems, consent logic gets integrated into your backend from the start rather than left as a frontend-only patch. Our custom software development and architecture services cover this build end to end, including the ongoing monitoring that catches vendor changes before they become a compliance gap. Get in touch to scope an implementation plan for your site.

FAQ

Any Italian website using non essential cookies, such as profiling or marketing trackers, needs a banner that blocks those cookies until consent is given, per the Garante’s guidelines. Sites using only strictly technical cookies still need to inform users, though prior consent is not required for that category.

Closing the banner with an ‘X’ can count as a valid refusal, but only if the default state keeps non essential cookies blocked and the action is properly recorded, as clarified in the Garante’s FAQ on cookies. It can never count as acceptance of tracking cookies.

How often can we ask a visitor to reconsider cookies after a refusal?

The Garante’s guidance advises against re-prompting a user who has refused consent for at least six months, unless the processing itself changes, such as a new vendor or purpose, as set out in its clarification on re-prompting. Repeated prompts outside that window are treated as invasive rather than as a legitimate compliance measure.

Are cookie walls that force consent to access content allowed?

Cookie walls that condition access to content on accepting tracking are considered risky, since the EDPB cookie banner taskforce treats forced consent as a threat to its validity unless an equivalent, non-tracking alternative genuinely exists. The safer design always gives users a real option to proceed without accepting non essential cookies.

What should we do if our current banner uses pre-ticked boxes?

Pre-ticked boxes for anything beyond strictly technical cookies do not meet the active, unambiguous consent standard under GDPR Article 7(1), so every non essential category toggle should default to off. Updating this typically requires both a design change in the preference centre and a code change to ensure the underlying scripts respect the new default state.

Sources

This article was produced with AI assistance and reviewed for accuracy. It is provided for general information only and is not professional advice.