TL;DR: A cookie disclosure is a plain-language explanation of the cookies and trackers your website sets, what they do, and who receives the data — usually published inside your privacy policy or a dedicated cookie page. It is not the same as a consent banner: disclosure informs, consent asks permission before non-essential cookies load. Government sites in the U.S. generally need disclosure under FTC fairness principles and a growing list of state privacy laws; if you serve EU residents, GDPR and the ePrivacy Directive require prior consent for non-essential cookies. A good disclosure names the cookies (or categories), distinguishes first-party from third-party, explains analytics and tracking, and tells visitors how to opt out.
If your county, agency, or university website runs Google Analytics, embeds a YouTube video, or loads a chat widget, it is almost certainly setting cookies — and most government teams have no written record of which ones, set by whom, or why. A cookie disclosure closes that gap. It is the document that tells visitors, in plain language, what cookies your site uses and what happens to the data they collect. As state privacy laws multiply and the FTC sharpens its focus on undisclosed tracking, the absence of a cookie disclosure has shifted from a minor omission to a genuine compliance and trust liability for public-sector sites.
The confusion that trips up most government web teams is the difference between disclosure and consent. They are related, frequently bundled together by the same vendor banner, and governed by different legal regimes. This article explains what a cookie disclosure is, how it differs from a consent banner, when each is actually required, and what a good disclosure for a government site should say.
What a Cookie Disclosure Actually Is
A cookie disclosure is an informational statement. It describes the cookies and similar technologies (local storage, pixels, SDKs, fingerprinting scripts) that your site uses, organized so a non-technical visitor can understand them. It typically lives in one of two places:
- A dedicated cookie policy or “cookie notice” page, or
- A clearly labeled section within your privacy policy.
For a complete picture of where this fits, see our government website privacy policy guide — the cookie disclosure is one component of the broader privacy notice your site should publish.
The disclosure answers four questions for each cookie or category of cookie:
- What is it? A name or category (e.g., “analytics,” “essential,” “social media”).
- Who sets it? Your own domain (first-party) or an outside service (third-party).
- What does it do? Keep you logged in, remember language preference, measure traffic, target ads.
- How long does it last and who gets the data? Session vs. persistent, and which third parties receive it.
Crucially, a disclosure does not ask the visitor for anything. It informs. That is the line that separates it from consent.
Disclosure vs. Consent Banner
This distinction matters because it determines what you legally have to build.
A cookie disclosure tells. It is passive. The cookies may already be set when the visitor reads it.
A consent banner asks. It is active. Under a true consent model, non-essential cookies must not load until the visitor affirmatively agrees — clicking “Accept,” choosing categories, or similar. A blocked-by-default approach is the technical heart of real consent.
| Cookie disclosure | Consent banner | |
|---|---|---|
| Purpose | Inform | Obtain permission |
| Timing | Cookies may already be set | Non-essential cookies blocked until consent |
| Typical legal driver (U.S.) | FTC fairness, state privacy laws | State opt-out laws, some sector rules |
| Typical legal driver (EU) | GDPR transparency | ePrivacy Directive (“cookie law”) + GDPR |
| User action required | None | Click / selection |
The two are not mutually exclusive — a good consent banner includes disclosure (it links to or summarizes the cookie policy). But a disclosure on its own does not satisfy a consent requirement. If you are subject to a true consent regime (most commonly because you serve EU residents), a plain disclosure is not enough. For the deeper treatment of when a banner is required and how to build one that doesn’t itself create accessibility problems, see our guide to government website cookie banner requirements.
First-Party vs. Third-Party Cookies
A disclosure that doesn’t separate these two is missing the point, because the risk profiles are completely different.
First-party cookies are set by your own domain (yourcity.gov). These are usually operational: they keep a user logged into a permit portal, remember a chosen language, hold items in a payment cart, or store a CSRF token for form security. First-party cookies are generally lower-risk and frequently fall into the “essential” or “strictly necessary” category that most laws exempt from consent (though not always from disclosure).
Third-party cookies are set by a domain other than the one in the address bar — Google, Facebook, a CDN, an embedded map provider, a font host. These are the cookies that raise privacy concerns, because the third party can often track the user across many sites. On government sites third-party cookies most commonly arrive through:
- Analytics (Google Analytics, formerly Universal Analytics; Google Tag Manager containers)
- Embedded media (YouTube, Vimeo, social media post embeds)
- Embedded maps (Google Maps, Mapbox)
- Chat and support widgets (Intercom, Zendesk, Drift)
- Web fonts loaded from a third-party host (Google Fonts via fonts.googleapis.com)
- Social sharing buttons that phone home before the user clicks anything
The hard truth is that staff usually have no idea how many third-party cookies their site sets, because each was added by a different person at a different time for a different feature. Building an accurate inventory is a hands-on technical task — we walk through it step by step in how to audit third-party cookies on your government website.
Analytics and Tracking: The Gray Area for Government
Government sites have a legitimate, often mandated, interest in measuring traffic — federal agencies report to OMB, and many state and local sites use analytics to justify budgets and improve services. The complication is that the most popular analytics tools set third-party cookies and may share data with the vendor for that vendor’s own purposes.
Two practical positions have emerged:
- Disclose and configure conservatively. Keep analytics, but turn on IP anonymization, disable data sharing/advertising features, and disclose the use clearly. Many U.S. government teams take this route because measuring traffic is a genuine operational need.
- Move to privacy-respecting analytics. Tools like the federal government’s own Digital Analytics Program (DAP, which powers analytics.usa.gov), Plausible, Matomo (self-hosted), or Fathom can be configured to set no third-party cookies and collect no cross-site identifiers — sometimes eliminating the consent question entirely for analytics.
Either way, analytics must be disclosed. Telling visitors you measure traffic, with what tool, and whether the data leaves your control, is the baseline expectation. If your analytics setup shares data with an advertising network, that is a far more significant disclosure (and likely a consent trigger) than first-party traffic counting.
When Is a Cookie Disclosure Required?
There is no single federal “cookie law” in the United States. Instead, the requirement comes from several overlapping sources.
FTC guidance and fairness principles
The Federal Trade Commission has long held that failing to disclose tracking — or saying one thing in a privacy policy and doing another — is a deceptive or unfair practice under Section 5 of the FTC Act. While the FTC’s direct jurisdiction over government bodies is limited, its guidance sets the de facto national standard for what “fair” data handling looks like, and courts and state regulators lean on it. The practical takeaway: if your site tracks visitors, say so, and make sure your stated practices match reality.
State privacy laws
This is the fastest-moving driver. A growing number of states — California (CCPA/CPRA), Colorado, Connecticut, Virginia, and others — have comprehensive privacy laws with transparency and opt-out requirements that touch cookies, especially cookies used for targeted advertising or that constitute a “sale” or “share” of personal data under those statutes. Many require honoring a Global Privacy Control (GPC) browser signal. Government entities are exempt from some of these laws and not others, and contractors or affiliated nonprofits may be covered even when the agency is not. Because applicability genuinely varies by state and entity type, read our breakdown of state privacy laws for government websites before assuming you’re exempt.
GDPR and the ePrivacy Directive (if you serve EU residents)
If your site is likely to be accessed by residents of the European Union — a public university recruiting international students, a state tourism board, a port authority, a sister-city program — the EU ePrivacy Directive (the so-called “cookie law”) requires prior consent for any cookie that is not strictly necessary, and the GDPR requires transparent disclosure on top of that. This is a consent regime, not just disclosure: non-essential cookies must be blocked until the visitor agrees. Most U.S. local governments won’t trip this wire, but universities and any agency with an international audience should evaluate it seriously.
Section 508 and accessibility overlap
A point teams forget: a cookie banner or disclosure interface is itself part of your website and must meet WCAG 2.2 AA. A consent modal that traps keyboard focus, can’t be dismissed without a mouse, or fails color contrast turns a privacy fix into an accessibility violation. Whatever you publish, it must be operable by everyone.
What a Good Cookie Disclosure Says
A strong government cookie disclosure is specific, plain, and current. At minimum it should include:
- A clear statement that the site uses cookies and what cookies are, in one sentence a constituent can understand.
- Categories of cookies used — essential, preferences, analytics, and (if applicable) advertising — with a short description of each.
- First-party vs. third-party, with the third parties named (Google Analytics, YouTube, Mapbox, etc.).
- Purpose for each category — why the cookie exists and what it enables.
- Duration — session vs. persistent, and roughly how long persistent cookies last.
- Data recipients and transfers — who receives the data, and whether it leaves your jurisdiction or the country.
- How to opt out or control cookies — browser settings, the GPC signal, links to third-party opt-outs (e.g., Google’s), and your consent tool if you have one.
- A “last updated” date and a contact for privacy questions (often your records officer or privacy office).
A useful format is a categorized table:
| Category | Example cookies | First/Third party | Purpose | Duration |
|---|---|---|---|---|
| Essential | session_id, csrf_token | First | Login, form security | Session |
| Preferences | lang, font_size | First | Remember language & display | 1 year |
| Analytics | _ga, _gid | Third (Google) | Measure site traffic | Up to 2 years |
| Media | YouTube cookies | Third (Google) | Play embedded videos | Varies |
If a term in your disclosure needs defining for constituents — “pixel,” “local storage,” “GPC” — link to a plain-language reference like our government web compliance glossary rather than burying jargon in legalese.
Keep it accurate, and keep it current
The most common failure mode is not a missing disclosure — it’s a stale or inaccurate one. A site adds a new chat widget, swaps analytics tools, or embeds a new social feed, and the disclosure never catches up. Now the policy says one thing and the site does another, which is precisely the “deceptive practice” the FTC warns about. A disclosure is only as good as its match to what your site actually loads today.
A cookie disclosure isn’t a legal formality to copy from another agency’s site — it’s a living description of how your government site handles visitor data, and it only protects you if it’s accurate. Because cookies arrive quietly with every new embed, widget, and analytics change, disclosures drift out of date faster than any team can track manually. Govzu continuously monitors what your government website actually loads — including third-party trackers and cookies introduced by new content — so your disclosure stays true to reality and you find new trackers before a constituent, journalist, or regulator does. Pair that with continuous compliance monitoring across accessibility, privacy, and security, and your disclosure becomes a document you can actually stand behind.