Why a Cookie Banner Isn't HIPAA Compliance
It's the most expensive sentence in healthcare digital compliance: "we have a cookie banner, so we're covered." The federal regulator has said, in plain words, that a banner is not what HIPAA asks for. This guide walks through exactly what HHS said, what the 2024 court ruling did and didn't change, and why the banner myth quietly leaves health systems exposed on the layers where the real money is lost.
The short version
- The claim
- A cookie consent banner makes a healthcare website "HIPAA compliant."
- The reality
- False. HHS Office for Civil Rights states banners "do not constitute a valid HIPAA authorization."
- What HIPAA wants
- A valid patient authorization, or a Business Associate Agreement (BAA) with any vendor receiving PHI — not a banner.
- The 2024 ruling
- A court narrowed one part of the HHS guidance (IP addresses on public pages). It did not bless banners or touch patient portals.
- The bigger point
- Even done perfectly, HIPAA isn't where most settlements happen — state wiretap law (CIPA) is, and a banner's job lives there.
- Honest first step
- Scan your site to see what fires before consent — the pattern behind the demand letters. Free, ~10 seconds.
What this guide covers
Walk into almost any health system's marketing stack and you'll find the same arrangement: Google Analytics, a Meta Pixel, maybe a session-replay tool, installed years ago for sensible reasons, all quietly transmitting visitor data to third parties. And holding the whole thing together, one reassuring belief — we have a cookie banner, so we're covered.
That belief conflates two things that have almost nothing to do with each other: a cookie consent banner, and HIPAA compliance. They come from different bodies of law, they ask for different things, and the tool that does one does not do the other. A health system can run a flawless consent banner and still be squarely offside on HIPAA. It can also be fully HIPAA-diligent and still lose a multi-million-dollar lawsuit that has nothing to do with HIPAA at all.
This piece is about the first half of that: why the "HHS guidance says a banner is HIPAA" idea is simply wrong — not as our opinion, but as the explicit position of the federal regulator — and what it means for reducing risk. This is general information, not legal advice, healthcare privacy law is unsettled, and nothing here makes any website "HIPAA compliant."
Where the banner myth comes from
The myth isn't stupidity — it's a reasonable-sounding wrong turn. Here's the logic that leads teams astray:
Cookie consent banners became familiar through GDPR and, later, US state privacy laws, where their job is to obtain permission before non-essential trackers run. When HHS signalled that tracking on healthcare sites could implicate HIPAA, many organisations reasoned by analogy: "A consent manager asks visitors for permission to be tracked. HIPAA is about permission to use health data. So a consent manager must handle HIPAA too."
It's an intuitive leap, and it's wrong — because HIPAA doesn't ask for "consent" in the banner sense. It asks for something more specific and more demanding. Even the healthcare-specific compliance vendors are blunt about this. Freshpaint, a tool built specifically to make analytics HIPAA-safe, puts it plainly on its own blog: HHS has clarified that consent managers do not work for HIPAA authorization. When the vendors selling into this exact problem tell you a consent manager isn't the answer, that's worth hearing.
What HHS actually said
Let's go to the source. The HHS Office for Civil Rights (OCR) — the agency that enforces HIPAA — issued guidance on online tracking technologies. On the specific question of consent banners, its position is not ambiguous.
Website banners that ask users to accept or reject a website's use of tracking technologies, such as cookies, do not constitute a valid HIPAA authorization.— HHS OCR, "Use of Online Tracking Technologies by HIPAA Covered Entities and Business Associates"
That single sentence dismantles the entire "banner equals HIPAA" story. But OCR goes further, closing the obvious escape hatches:
- Getting a visitor to click "accept" is not authorization. A HIPAA authorization is a specific, defined legal instrument with required elements. A banner click isn't it.
- A vendor's promise to de-identify later isn't enough. OCR has said it is insufficient for a tracking-technology vendor to merely agree to remove or de-identify protected health information (PHI) before saving it. The disclosure of PHI to the vendor has already happened at that point.
- PHI to a vendor requires a BAA and a Privacy Rule permission. If PHI flows to a third party like an analytics or ad platform, HIPAA requires a signed Business Associate Agreement (BAA) with that vendor and an applicable permission under the Privacy Rule.
Read together, the guidance draws a bright line: the cookie banner is expressly not what HIPAA asks for. HIPAA wants a proper authorization, or a BAA-backed data path where PHI never reaches a vendor who hasn't signed one. A banner delivers neither.
Why a banner structurally can't be HIPAA authorization
It helps to understand why, not just that. The gap isn't a technicality — it's structural. Consent and authorization are different legal objects doing different jobs.
A consent banner answers a yes/no question about tracking: may we run these cookies and pixels? It's a permission gate for the general act of tracking, designed to satisfy privacy laws like GDPR and CIPA that turn on whether the visitor agreed before the tracker fired.
A HIPAA authorization is a formal, regulated document. To be valid, it must describe the specific information to be disclosed, name who is disclosing and who is receiving it, state the purpose, include an expiration, explain the right to revoke, and carry the individual's signature — among other required elements. It is a deliberate, informed, specific permission to disclose protected health information to a named recipient for a named purpose.
You can see why one can't stand in for the other. A visitor clicking "Accept all" hasn't been told what health information will be disclosed, to whom, or why, and hasn't signed anything. They've answered a cookie question. Treating that click as a HIPAA authorization is like treating a "we use cookies" notice as a signed medical-records release — not the same instrument.
A banner asks "may we track you?" HIPAA asks "do you specifically authorize disclosing your protected health information to this named party?" Answering the first has never answered the second — which is exactly why HHS says a banner isn't a HIPAA authorization.
The 2024 ruling that "changed everything" — read it carefully
Here's where most coverage goes wrong, in both directions. In 2024 a federal court struck down part of the HHS tracking guidance, and the takes split into two equally inaccurate camps: "tracking is fine now" and "nothing changed." The truth is narrower and more useful than either.
The timeline matters:
- December 2022: OCR issued its original tracking-technologies bulletin, taking a broad position — including that an IP address collected when someone visited an unauthenticated public webpage about a health condition could itself be PHI (the court later called this the "Proscribed Combination").
- March 18, 2024: OCR issued a revised bulletin, softening the tone and noting it wasn't binding law, but maintaining that individually identifiable health information collected on a regulated entity's site is generally PHI.
- June 20, 2024: in American Hospital Association v. Becerra (N.D. Texas), Judge Mark Pittman vacated the "Proscribed Combination" portion — the IP-address-on-unauthenticated-public-pages rule — holding HHS had exceeded its statutory authority.
- August 29, 2024: HHS withdrew its appeal. The vacatur stands; OCR is not challenging it.
The court vacated one narrow slice of the guidance: treating an IP address on an unauthenticated public page as automatically PHI. That's it. The rest of the guidance stands entirely.
Specifically: the ruling did not say a banner is HIPAA authorization (that wasn't even at issue). It did not touch tracking on authenticated patient portals — the logged-in pages where lab results and appointments live, and where the largest settlements originate. And it changed nothing about the BAA requirement, or about the state wiretap laws that drive most of the litigation.
So what did the ruling actually do? It gave hospitals genuine breathing room on public marketing pages — the "find a doctor" and "our services" pages any visitor can load without logging in. On those pages, an IP address alone is no longer automatically treated as PHI. That's a real and useful narrowing.
What it did not do is rehabilitate the banner myth. HHS can still enforce where identifiers combine with health information — an ad-click ID tied to a booked appointment and sent to Meta. Authenticated portals remain fully in scope. And crucially, the wave of tracking lawsuits that has cost health systems over $100 million was argued largely on state law, which the guidance and its partial vacatur don't govern at all. The court narrowed HHS's reach; it didn't narrow the plaintiffs' bar's.
See what a plaintiff firm would see
The 2024 ruling didn't touch what fires before consent on your pages — and that's exactly what drives the demand letters. See which trackers fire before consent on your site, in about 10 seconds. It's the same scan a plaintiff firm would run.
Scan your site free →No account needed · then a 14-day free trial, no credit card, from $8.99/mo
If a banner isn't HIPAA, what is it actually for?
This is the pivot that turns a debunking into something useful. A cookie banner isn't useless — it's just doing a different job than HIPAA, and it's a job that matters enormously. A healthcare website answers to three separate layers at once, and the banner lives squarely in the second one.
A banner is the right tool for Layer 2 — and only Layer 2. Treating it as the answer to Layer 1 (HIPAA) is the myth; leaving Layer 3 (detection) unwatched is how exposure compounds. For the full map, see our healthcare tracking & consent pillar.
The banner's real home is Layer 2 — state privacy and wiretap law, where the money actually moves. California's CIPA — a 1967 wiretapping statute now applied to tracking — treats a pixel transmitting a visitor's activity before consent as an unlawful interception, with statutory damages plaintiffs peg to Penal Code § 637.2. Add CCPA/CPRA (honor opt-outs and the Global Privacy Control), California's CMIA, and a fast-growing set of equivalents elsewhere, and you have the engine behind the marquee settlements — Kaiser's $46M, Sutter's $21.5M, and the rest. Each turned on the same question: did a non-essential tracker fire before the visitor consented?
That question is exactly what a consent banner — a real one that blocks trackers until opt-in — exists to answer. So the banner isn't worthless; it's just been mis-sold. Its job is the state-law layer, not the HIPAA layer. The mistake is claiming it covers a layer it was never built for, while ignoring the layer it was.
The tools, compared honestly
Because this is a buying decision as much as a legal one, it's worth being straight about the categories of tool in this space and what each actually covers. There are three, and they are not interchangeable.
HIPAA-proxy tools (Freshpaint, Feroot, and similar)
These are purpose-built for the HIPAA layer, and they're good at it. Rather than asking for consent, a proxy tool intercepts data server-side and strips or hashes identifiers before anything reaches an ad or analytics vendor, under a BAA. Freshpaint markets making Google Analytics and ad platforms "HIPAA-compliant" by filtering PHI before it's sent; Feroot focuses on client-side scanning that maps script behaviour to the HIPAA Privacy and Security Rules. If PHI genuinely flows to vendors on your site, this is the right category for that problem — and, notably, these vendors agree with HHS that a banner isn't authorization. As Feroot puts it: HIPAA requires authorization, not just consent, and consent alone doesn't eliminate the need for a BAA.
But their coverage has honest edges. A proxy only handles the vendors it's configured to proxy; every other script — session-replay, tag-manager additions, pixels it doesn't proxy — operates without its oversight. It generally doesn't continuously scan for new trackers or GPC compliance. And most importantly: HIPAA compliance does not satisfy CCPA, CPRA, or state wiretap law. You can be perfectly PHI-safe and still fire Google Analytics before consent on a California visitor — and still face a CIPA claim.
Generic cookie banners (the tools being mis-sold)
Standard consent management platforms handle the state-law consent question — if they actually block trackers until opt-in rather than just recording a preference while the tags fire anyway. Many don't block at all, which fails even their own layer. And none of them, ours included, is a HIPAA authorization. A generic banner that also lets trackers fire before the click is the worst of both worlds: it covers neither Layer 1 nor Layer 2.
The honest comparison
| Covers… | HIPAA proxy (Freshpaint/Feroot) | Generic banner | ConsentPixel |
|---|---|---|---|
| HIPAA / PHI-to-vendor (BAA) | Yes (its lane) | No | No — we say so |
| State-law consent (CIPA/CCPA) | No | Only if it truly blocks | Yes |
| Blocks trackers before consent | For proxied vendors | Often not | Yes, by default |
| Honors GPC opt-out | Typically no | Varies | Yes |
| Continuous detection / scan | Typically no | No | Yes |
| Immutable consent log | No | Varies | Yes |
Comparison reflects publicly stated capabilities as of mid-2026, including vendors' own materials and neutral third-party comparisons. Verify current details directly with each vendor. The point isn't that one tool wins — it's that HIPAA proxies and consent layers solve different layers, and neither replaces the other.
Where ConsentPixel fits — honestly
We'll be as straight about our own lane as we've been about everyone else's, because in healthcare, overclaiming is the fastest way to lose a serious buyer's trust. ConsentPixel is not a HIPAA product and does not make your website "HIPAA compliant." We don't proxy PHI, and no consent banner — ours included — is a HIPAA authorization. If PHI is flowing to vendors on your site, you need a BAA or a PHI-safe path, and we'll tell you that plainly rather than pretend we solve it.
What ConsentPixel does is the two layers the HIPAA proxies leave open: the state-law consent layer and the detection layer. We block non-essential third-party trackers until a visitor genuinely consents — the thing CIPA and CCPA actually turn on — fire Google Consent Mode v2 signals correctly, honor GPC opt-out signals, continuously scan for what's firing across your pages, and keep an immutable, timestamped record proving consent came before the tracker did.
For a health system already running a HIPAA proxy, that makes us the complement — the piece that watches what the proxy doesn't and covers the state-law consent it was never built to handle. For a smaller organisation, we're an affordable starting point on the state-law and detection layers, alongside honest guidance about the HIPAA layer you still solve separately. Either way: we cover two of the three layers, we tell you plainly about the third, and we never pretend a banner is compliance.
Managing multiple client sites?
Agencies and multi-brand health systems can scan a whole portfolio for what fires before consent. Start with one site free, in about 10 seconds — no account, no credit card.
Scan a site free →Agency plans available · per-domain pricing from $8.99/mo
What to actually do
The map only matters if it becomes moves. Here's the honest order of operations for a healthcare site, cheapest and most urgent first:
- See what's firing. Scan your site — including patient portals and authenticated pages, where exposure concentrates. You can't govern what you can't see, and this step is free.
- Block non-essential trackers until consent. This is the state-law layer and the highest-frequency source of CIPA/CCPA exposure. The script must not load until the visitor opts in — not load-and-pause.
- Get non-essential trackers off patient portals and sensitive pages entirely. Even with consent, health context plus third-party transmission on authenticated pages is the highest-damage pattern — and the layer the 2024 ruling left fully in scope.
- Solve the HIPAA layer separately. Where PHI genuinely flows to a vendor, you need a BAA or a PHI-safe proxy path — not a banner. Treat it as its own workstream, with counsel.
- Honor GPC and keep consent records. Respect opt-out signals and maintain an immutable, timestamped record showing consent was obtained before each tracker fired. That record is your defense.
- Monitor continuously. Trackers get re-added through tag managers and marketing changes. A one-time cleanup decays; continuous scanning keeps the detection layer closed.
The bottom line
A cookie banner is not HIPAA compliance, and this isn't a matter of interpretation — HHS says a banner "does not constitute a valid HIPAA authorization." HIPAA wants a proper authorization or a BAA-backed data path, not a click on a cookie notice.
The 2024 AHA v. Becerra ruling narrowed one slice of the HHS guidance — IP addresses on public pages — but it didn't bless banners, didn't touch patient portals, and didn't change the state-law wiretap exposure that drives most of the litigation. The banner myth survived the ruling intact, because the ruling was never about banners.
The useful reframe is this: a real consent banner isn't your HIPAA solution — it's your state-law solution, and that's the layer where health systems are actually losing nine figures. Solve HIPAA with a BAA or PHI-safe path. Solve state law with a consent layer that genuinely blocks trackers until opt-in. Close the detection gap by scanning continuously and proving consent came first. Any vendor claiming to make you "HIPAA compliant" with a banner is selling you the exact misunderstanding that has cost the sector over $100 million.
Start with what a plaintiff firm would see
You can't fix the layer a banner actually governs until you can see what fires before consent on your pages. Run the free scan — every tracker loading before opt-in, on the pages that matter most, in about 10 seconds.
We build prevention-first consent tooling that blocks trackers until visitors genuinely consent, and continuously verifies what fires on your pages. We cover the state-law consent and detection layers — honestly — and we'll always tell you plainly what sits outside our lane. This article is information, not legal advice; healthcare privacy law is evolving, so verify current interpretations with qualified counsel before relying on it. ConsentPixel — Privacy · Verified is not a law firm, is not a HIPAA authorization mechanism, and does not make any website "HIPAA compliant."
Frequently asked questions
Does a cookie consent banner make my healthcare website HIPAA compliant?
No. The HHS Office for Civil Rights states explicitly that website banners asking users to accept or reject tracking technologies do not constitute a valid HIPAA authorization. HIPAA requires either a proper patient authorization — a specific, signed legal instrument — or a Business Associate Agreement (BAA) with any vendor that receives protected health information, together with an applicable Privacy Rule permission. A banner is neither. It's part of your state-law consent posture (CIPA, CCPA), not your HIPAA posture. This is general information, not legal advice.
Why isn't clicking "accept" on a banner the same as HIPAA authorization?
Because consent and authorization are different legal objects. A banner click answers a general question about tracking — "may we run cookies and pixels?" A HIPAA authorization is a formal document that must describe the specific information disclosed, name who discloses and receives it, state the purpose, and carry the individual's signature, among other elements. A visitor clicking "accept all" hasn't been told what health information will be disclosed, to whom, or why, and hasn't signed anything. That structural gap is why a banner can't function as a HIPAA authorization.
Didn't a 2024 court ruling say tracking is fine now?
Not exactly. In American Hospital Association v. Becerra (N.D. Texas, June 20, 2024), the court vacated one narrow portion of the guidance — treating an IP address on an unauthenticated public webpage as automatically triggering HIPAA — and HHS withdrew its appeal in August 2024. But the rest stands. It gave hospitals breathing room on public marketing pages, but did not bless banners as HIPAA authorization, did not touch authenticated patient portals (where the biggest settlements originate), and changed nothing about the BAA requirement or state wiretap laws like CIPA. It narrowed one HHS interpretation; it didn't end the litigation risk.
If a banner isn't for HIPAA, what is it actually for?
A consent banner's real job is the state-law layer — chiefly the California Invasion of Privacy Act (CIPA), the CCPA/CPRA, the Confidentiality of Medical Information Act (CMIA), and a growing set of equivalents in other states. These laws turn on a single question: did non-essential trackers fire before the visitor consented? A banner that genuinely blocks trackers until opt-in is what answers that question, and it's the layer where the largest healthcare tracking settlements — Kaiser's $46M, Sutter's $21.5M — were actually decided. So a banner isn't worthless; it's been mis-sold. Its home is state privacy and wiretap law, not HIPAA.
We use a HIPAA-compliant proxy tool like Freshpaint or Feroot. Are we covered?
You've likely addressed the HIPAA layer for the vendors those tools proxy, but not the state-law or detection layers. Proxy tools strip PHI before it reaches ad vendors under a BAA — which does nothing to satisfy CIPA or CCPA, and, per neutral comparisons, they typically cover only the vendors they proxy and don't continuously scan for other scripts or GPC compliance. You can be fully PHI-safe and still fire Google Analytics before consent on a California visitor, and still face a CIPA claim. The state-law and detection layers need their own solution — and these vendors themselves agree a banner is not HIPAA authorization.
What's the cheapest first step to reduce our exposure?
Scan your site to see what's actually firing — it's free and takes about ten seconds. Most exposure begins with trackers the site owner didn't know were running, or didn't know were firing before consent. Seeing the real picture, including on authenticated pages where the highest-damage exposure concentrates, tells you where the risk is before you spend anything fixing it. From there, blocking non-essential trackers until consent addresses the highest-frequency source of state-law claims, and solving the HIPAA layer with a BAA or PHI-safe path is a separate workstream. This is general information, not legal advice.
Sources
- HHS Office for Civil Rights, "Use of Online Tracking Technologies by HIPAA Covered Entities and Business Associates" — banners do not constitute valid HIPAA authorization; BAA and Privacy Rule permission required; vendor de-identification promise insufficient. hhs.gov
- American Hospital Association, "Judge rules in favor of AHA vacating HHS online tracking 'bulletin'" (June 20, 2024) and "HHS will not appeal AHA court victory in online tracking case" (Aug 29, 2024) — AHA v. Becerra, N.D. Tex.; Judge Mark Pittman; scope of vacatur.
- Holland & Knight, "American Hospital Assn. v. Becerra: Are Tracking Tools OK Again? Court Dials Back OCR Bulletin" — Dec 2022 original, March 18 2024 revised bulletin, "Proscribed Combination" vacated, remainder intact, portals still in scope.
- Proskauer / Epstein Becker Green / Morrison & Foerster client alerts (2024) — HHS withdrawal of appeal (Aug 29, 2024); vacatur limited to IP-on-unauthenticated-pages; enforcement where identifiers combine with health information.
- Freshpaint, "HHS Approves Tools Like Freshpaint" and product materials — HIPAA-proxy/BAA server-side filtering; company's own statement that consent managers do not work for HIPAA authorization.
- Feroot Security, "How Third-Party Pixels Jeopardize HIPAA Compliance" and GA4/BAA analyses — client-side scanning; "HIPAA requires authorization, not just consent"; BAA still required.
- Lokker, "Freshpaint" comparison — HIPAA-proxy coverage boundaries: proxies only configured vendors, no continuous scanning of other scripts/GPC, and HIPAA compliance does not satisfy CCPA/CPRA/state privacy law.
- Analysis of healthcare pixel litigation — $100M+ across 19 cases (2023–2025); Kaiser Permanente $46M (CIPA), Sutter Health $21.5M (CIPA/UCL/CMIA); Meta Pixel found on 33+ health systems' portals.