A breach with no attacker: the FTC’s warning to health apps

The week

On September 15, 2021, the Federal Trade Commission voted 3-2 to issue a policy statement on its Health Breach Notification Rule. It was a short document with a long reach, and it changed how anyone running a health app should think about the word “breach.”

Most people know HIPAA, the federal law that protects medical records held by doctors, hospitals and health insurers. Far fewer know that a large share of health information now lives outside HIPAA altogether: in period trackers, fitness apps, symptom checkers, meditation apps and connected devices such as smart scales. HIPAA generally does not cover those companies, because they are not health care providers or insurers.

The FTC, which polices unfair and deceptive business practices, had a rule aimed at part of that gap. The 2009 rule requires personal health record vendors and related entities outside HIPAA to notify consumers, the FTC and sometimes the media after a breach of security of unsecured identifiable health information. A personal health record in this sense is an electronic record of a person’s health information that the person can manage, drawn from more than one place.

The rule’s origins explain why it had been so little used. Congress directed the FTC to write it in the American Recovery and Reinvestment Act of 2009, the same stimulus law that funded the push to electronic health records. At the time, lawmakers expected a market of web-based personal health record services that people would use to gather their records from doctors and hospitals. Several of those services closed within a few years. The rule stayed on the books, aimed at a market that had largely not arrived in the form expected.

Meanwhile the market it might cover grew in a different shape. Smartphone apps for fitness, fertility, sleep, mental health and chronic conditions multiplied through the 2010s. Many collected detailed health information directly from users, and most were built on the same advertising and analytics tools as any other consumer app. In 2016 the FTC, working with other federal health agencies, published an interactive tool to help mobile health app developers work out which federal laws applied to them. Guidance existed. Enforcement of this rule did not.

The September statement made two important points. First, it said that health apps and connected devices that draw health information from more than one source can be personal health record vendors under the rule. Its example was a user’s own entries combined with data pulled through an application programming interface from a fitness tracker. An application programming interface, or API, is a standard doorway through which one piece of software requests data from another. So an app that combines what you type in with step counts from your watch could be covered.

The statement went further than many readers first noticed. An app was covered if it had the technical capacity to draw information through such an interface, whether or not a particular user had connected a device. And an app could be covered even if the health information came from only one source. The statement’s example was a blood sugar app that took readings typed in by the user and dates from the phone’s calendar. The calendar dates were not health information, but drawing on them made the app a multi-source record.

The legal route to that reading ran through a definition. The rule covers records containing health information created or received by a health care provider. The statement said the developer of a health app or connected device is itself a health care provider under the cross-referenced definitions, because it furnishes health care services or supplies. That single step brought a large part of the consumer health app market within reach.

Second, and more striking, it said a breach is not limited to cybersecurity intrusions and includes unauthorized disclosures, such as a company sharing health information without the user’s authorization. A company could “breach” its own users’ data simply by sending it somewhere they had not agreed to.

The rule had been on the books for years without being used. The statement said so plainly: the FTC had never enforced it. Earlier in 2021 the agency had settled with the fertility app Flo Health over data sharing without invoking it. When that settlement was announced, two commissioners wrote separately that the agency should have charged a violation of the breach rule as well. The September statement adopted their view as the Commission’s position.

The statement was approved at an open Commission meeting, part of a practice of holding votes in public that the agency’s new chair had introduced that year. The two commissioners who voted against it each issued a dissent. They objected to the reading of the rule and to making so significant a change through a policy statement rather than through formal rulemaking. The FTC had in fact already asked for public comment on the rule in 2020 as part of a periodic review.

The statement closed with a reminder of the stakes. The Commission said it intended to bring enforcement actions consistent with the statement, and that violations faced civil penalties of $43,792 per violation per day. For a consumer app with a large user base, a per-violation penalty is a very different exposure from a reputational one. The September statement told the industry, in effect, that the FTC now read its own rule broadly and expected companies to do the same.

Take the general counsel of a fast-growing wellness app on a Monday morning. Over the weekend, a privacy researcher has published a report showing that every time a user logs a symptom, the app sends a note of it to an advertising platform. Nobody hacked anything. No firewall failed. The data left through code the company’s own marketing team installed to measure its ad campaigns. Her first question is whether this is an embarrassment or a legal event. After September 2021, the answer could be both.

Most organizations think of a breach as something done to them. An attacker gets in, takes data, and the organization responds. The FTC’s statement described a different kind: a company that sends users’ health information to an advertising or analytics partner without the users’ authorization has, under the rule, experienced a breach of security, with the same notification duties as if it had been hacked. No intruder is needed; the organization itself is the cause.

That has an uncomfortable implication for how breach prevention is organized. Security teams own firewalls, endpoint tools and incident response. They usually do not decide which software development kits ship in the mobile app, which data a marketing partner receives, or what the consent screen says. Those decisions sit with product managers, marketing teams, web agencies and business development. Under the FTC’s reading, each of them can create a reportable breach without touching a security control. The statement therefore moved breach prevention into three business decisions: what code ships, what partners receive, and what users agreed to.

The rule reaches entities outside HIPAA, which in 2021 meant most consumer health, fitness and wellness apps. Health systems and payers are mostly governed by HIPAA instead. But they sit close to the issue: they partner with digital health companies, they send records to apps at patients’ direction, and their own websites use the same tracking tools. The three decisions apply to them as well, under different rules.

Who sits on which side of that line matters, and it is often misunderstood. A consumer fertility or sleep app that people download on their own is the rule’s core target. A hospital’s patient portal is covered by HIPAA. Between them is a wide middle. A life sciences company that runs a patient support app for people taking its medicine is usually not a HIPAA covered entity, so its app may fall under the FTC’s rule. An employer wellness program offered through a group health plan generally falls under HIPAA, while one the employer runs directly may not. A digital health company that contracts with a health system to deliver care is often a business associate for that work. The same company may run a separate consumer product under the FTC rule at the same time. Organizations should check with counsel which regime applies to each product, because the answer can differ within a single company.

How health data leaks without a hacker

The mechanism surprises many executives, and it starts with how modern apps and websites are built.

Very few companies write every line of their app themselves. Instead, they assemble it from parts supplied by others. A software development kit, or SDK, is one of those parts: a ready-made bundle of code from another company that adds a feature, such as crash reporting, analytics or the ability to log in with a social media account. A pixel is a tiny piece of code on a web page that reports back to an advertising or analytics company when someone visits or takes an action.

These tools are useful. They tell a company which features people use, where the app crashes and which ads bring in new customers. But they work by sending information to the company that supplied them. That is their job.

On a shopping site, an event such as “added running shoes to cart” is commercially sensitive but not very personal. On a health app, the equivalent event might be “logged a missed period,” “searched for depression support” or “booked an appointment with an oncologist.” Attached to a device identifier, which advertising systems can often link to a real person, that event reveals something deeply private. The tool is doing exactly what it was built to do. The problem is what it is carrying.

Why identifiers make the data personal

Companies sometimes assume that data sent to an analytics or advertising partner is anonymous because no name is attached. That assumption rarely survives a close look at how the tools work. Mobile apps can expose an advertising identifier tied to the device. Web pixels can carry cookies, IP addresses and, in some configurations, hashed email addresses or phone numbers. Hashing turns an email address into a scrambled string, but advertising platforms use exactly that string to match visitors with their own account holders. A hashed email is designed to be matched, which makes it a weak basis for any claim that the data cannot be linked to a person.

Event names add the health content. A developer who names an event after the screen it fires on can end up sending “insulin_dose_logged” or “anxiety_assessment_complete” to a partner. Web pixels often send the page address and title automatically, so a visit to a page about a particular cancer can reveal the condition without any custom setup. The combination of a linkable identifier and a revealing event is what turns routine measurement into a disclosure of health information.

A doctor’s office would be in the same position if it let a marketing firm put a counter on the waiting-room door to measure foot traffic, and the counter also recorded which specialist each patient came to see and sent that list to the firm. Nobody broke in; the office installed the device itself. Under the FTC’s reading, that could be a breach.

The leaks do not require bad intent. In most organizations, tracking tools are added for sensible reasons by people trying to do their jobs well: a marketer who wants to know which ads work, a designer who wants to see where users get stuck, a developer who wants crash reports. The risk comes from the gap between those everyday decisions and an understanding of what data the tools carry. Closing that gap is the purpose of the three controls described next, and none of them depends on a firewall.

Tools that capture what users type

Some tools carry more than events. Session replay scripts and some chat and form widgets can record what a user types into a page, including into free-text fields. On a health site, that can include a symptom description, a medication name or the reason for an appointment. Many such tools offer settings to mask input fields, but the masking has to be switched on and tested. Academic researchers showed years before 2021 that session replay scripts on popular websites could capture form contents, so the risk was known well before the FTC’s statement.

Free text is the hardest data to control, because nobody can predict what a user will type. The safest assumption is that any field where a user can describe their health will at some point contain sensitive information, and that no third-party script should be able to read it.

What code ships: tracking as a disclosure channel

Modern apps and websites are assembled from third-party components. Analytics libraries, advertising pixels, crash reporters, chat widgets and session replay tools (which record what a user clicks and types so designers can watch it back) each send data to their providers, often including device identifiers, page names, search terms and events such as “appointment booked” or “cycle logged.” On a health app, those events can reveal a condition.

Many organizations could not list every third-party component in their products, because marketing teams, agencies and developers added them over years, and some loaded further components of their own. That last point is easy to miss. One advertising tool may pull in two or three others, so the company that thinks it has installed one partner’s code may in fact be sending data to several.

The control is a release gate. No third-party code ships without a named owner, a record of what data it collects and where it sends it, and a check against the privacy policy and user permissions. That review needs to see actual network traffic, because configuration screens often understate what a library transmits. In practice that means a technician runs the app, uses it as a customer would, and watches what actually leaves the device and where it goes, rather than relying on the vendor’s description.

Building the inventory

An inventory of third-party code is built from three angles, because none of them is complete alone. The first is the build: the list of libraries declared in the app’s source and dependency files, which shows what was deliberately included. The second is the running product: traffic captured while a tester walks through key journeys on real devices, which shows what actually leaves. The third is the tag management system, the console marketing teams use to add web tags without a code release, which shows what can be switched on outside engineering’s view.

Each item in the inventory needs a few fields. They are its owner, its business purpose, the data elements it sends and its destination. They also include the screens or pages where it fires and the user permission it relies on. An item without an owner should be treated as unapproved until someone claims it.

Designing events so they carry less

The cheapest control is often in the event design itself. Analytics events can use neutral codes rather than condition names. Page addresses and titles can be stripped or generalized before they leave. Tracking can be switched off entirely on screens where users enter health information, such as symptom logs, medication lists and appointment booking. These changes cost little and reduce the damage if a tool is later found to send more than expected.

Some organizations moved tracking from the user’s device to their own servers, a pattern often called server-side tagging. That gives the company more control over what is forwarded to partners. It does not change the legal question. Data the company forwards from its own server is still a disclosure, and it is less visible to outside researchers, which can make internal review more important rather than less.

What the gate costs

A release gate has real costs. Marketing loses some measurement precision when health screens carry no tracking. Releases slow slightly while new components are reviewed. Someone has to staff the traffic testing. Organizations that accepted those costs usually replaced the lost signal in other ways. Common choices were aggregate reporting, first-party analytics hosted under their own control, and campaign measurement that does not depend on what a user did inside a health feature.

Periodic scans of production apps and pages catch components added outside the release process, which is how many of them arrive. A marketing agency adding a new pixel to a landing page for a campaign, for example, may never pass through the engineering team’s review at all.

A scan that finds an unapproved pixel sending health events to an advertiser is no longer only a cleanup task. Under the FTC’s reading it may be a breach. The rule set deadlines: notice to affected individuals without unreasonable delay and within 60 days of discovery, and, where 500 or more people were affected, notice to the FTC within ten business days. The finding needs to go to whoever owns the breach decision the day it is made, because the clock may already be running.

A second point about scans is easy to miss. The rule also covers service providers to personal health record vendors, and requires them to notify the vendor of a breach. A company that builds or hosts a health app for someone else therefore has its own duty to report what it finds to its client, and its contract should say how quickly.

What partners receive: contracts and data maps

The second decision is deliberate sharing. Health apps commonly send data to advertising platforms to measure campaigns or build audiences, to analytics vendors, to research partners, and to employers or insurers in wellness programs. Each flow needs a basis: a user authorization that covers it, a contract that limits what the recipient may do, and a record that the two match.

The practical gap in 2021 was that data sharing agreements were signed by business teams without a data map, and data maps were drawn by engineers without reading the agreements. A data map is simply a diagram or inventory of where information goes: which systems collect it, which store it and which send it outside the company. The business team knows what was promised in the contract; the engineers know what actually flows. Neither, alone, knows whether the two agree.

Bringing them together means an inventory of every outbound health data flow, with its recipient, purpose, legal basis and contract reference, reviewed whenever a new partner is added. For health systems, the same inventory belongs in vendor due diligence for digital health partners, including the question of whether the partner is a business associate under HIPAA or a consumer company under the FTC’s rule. A business associate is a company that handles patient information on a HIPAA-covered organization’s behalf and is bound by HIPAA through a contract. A consumer app that a patient chooses to use is usually not one, and the rules that protect the data change when it leaves the hospital’s hands.

What the contract needs to say

For partners that will negotiate, a health data sharing agreement should cover at least the following:

• Purpose limitation. The recipient may use the data only for the stated purpose, such as measuring a specific campaign.
• No onward use. No use for the recipient’s own advertising, profiling or product development, and no onward sharing without written approval.
• Deletion. Deletion on request and at the end of the contract, with written confirmation.
• Incident notice. Prompt notice of any unauthorized access or use, so the sender can meet its own deadlines.
• Audit. A right to verify compliance, or at least to receive independent assurance reports.

The largest advertising and analytics platforms, however, offer standard terms that most companies cannot change. For those partners, the contract question collapses into a simpler one: whether to send health-related data to them at all. Many organizations concluded, after reading those standard terms closely, that the answer for health screens was no.

How the partner question differs by organization

For a HIPAA covered entity, the threshold question is whether the vendor will sign a business associate agreement. Several widely used analytics and advertising services said they would not, which meant a hospital could not lawfully send them patient information in most cases. For a consumer app, the question is whether the user authorized the flow. For a life sciences company, it is often both: the patient support program may involve a pharmacy or a provider under HIPAA, while the app itself falls under the FTC rule. Each needs the flow inventory to answer the question it faces.

What users agreed to: authorization that holds up

The third decision is the consent itself. The FTC’s statement turned on authorization: sharing a user had authorized was not a breach, and sharing they had not authorized could be. Authorization buried in a long privacy policy, or implied by continued use of an app, is weak ground for a company that sends health information to advertisers.

Clear authorization is a design task. It means plain statements at the point of collection, separate choices for separate uses, a record of what each user agreed to and when, and systems that honor a withdrawal across every downstream flow. “Downstream” here means every place the data travels after it is collected: if a user withdraws permission for advertising use, every advertising flow has to stop, including any the engineering team has forgotten.

The test is whether a company can show, for any given user and data flow, what the user saw and chose. If it cannot, the safer reading is that the flow was not authorized.

Consent as a record, not a screen

Consent is often designed as a screen and stored nowhere. A defensible approach treats it as data. Each version of the notice text is kept with its dates. Each user’s choice is recorded with the version they saw, the time, and the channel. And each downstream tool checks that record before it fires. Consent management platforms can do much of this for websites, and similar logic can be built into apps, but only if every tracking tool is wired to respect the stored choice.

Withdrawal is the hardest part to get right. A user who switches off advertising use in the app’s settings expects that choice to reach every partner that receives data about them. That requires the company to stop sending new data, to tell partners that already received data where the contract allows, and to keep a record that both happened.

Health systems face a parallel test under HIPAA. Using patient information for most marketing purposes requires a written authorization with specific required elements, and a website cookie banner does not meet that standard. A hospital therefore cannot rely on a banner to justify sending patient information to an advertising platform, even where a consumer app might argue that a clear in-app choice was enough.

Design choices that undermine authorization

Some consent designs make authorization hard to defend. Pre-ticked boxes, a single button that bundles analytics, advertising and research, and a prominent “accept” beside a hidden “decline” all invite the argument that the user never really chose. The FTC published a staff report on manipulative design practices in 2022, and regulators have treated such patterns with suspicion. For health data, a separate, specific choice for each use is the stronger position.

When a finding lands: who decides, and how fast

The rule’s deadlines change what an organization needs to have ready before anything goes wrong. A company that discovers an unauthorized flow of health data has to decide quickly whether it is a reportable breach, how many people are affected, and what to tell them. Those are hard questions to answer from a standing start.

Take a sleep-tracking app whose quarterly scan, run by an outside firm, shows that a newly added marketing SDK has been sending users’ sleep and medication entries to an advertising network for about four months. The engineer who reads the report opens a ticket to remove the SDK. If that is where it stops, the company may already be eating into its notification window without knowing it.

In a better-prepared company, the scan report goes on the same day to a named breach decision owner, typically the privacy officer working with counsel. Within days, the team establishes the facts: which data was sent, from which versions of the app, to whom, for how long, and whether any user authorization covered it. Engineering confirms the flow has stopped. The partner is asked, under the contract, to delete what it received. Counsel judges whether the rule applies and, if so, who must be notified and by when. The communications team drafts a plain notice for users. All of this is far easier if the inventory, the consent records and the release gate already exist, because the answers are on file rather than reconstructed from memory.

Counting and describing what happened

Two facts drive the notice decision: how many people were affected and what was sent. Both depend on logs. Teams need to know which app versions carried the component, when each version was in use, which events fired and which data elements each event contained. If the app does not keep that history, the company may have to assume the widest plausible scope, which means notifying more people than were actually affected.

The rule set out what a notice to individuals must contain. It includes a description of what happened, the dates of the breach and of its discovery, and the types of information involved. It also covers the steps people should take to protect themselves and how the company is responding. Writing that notice well depends on the same facts. A vague notice prompts more questions and more distrust than a specific one.

The board’s role is simple but important: make sure such a decision owner exists, that scans actually reach them, and that a rehearsal has been run at least once. A tabletop exercise, in which leaders talk through a realistic scenario around a table, often reveals in an hour that nobody knew who was supposed to make the call.

What a rehearsal should test

A useful tabletop for this kind of breach does not start with an attacker. It starts with a scan report, a researcher’s blog post or a journalist’s email describing an outbound data flow. The exercise then walks through the response in order, and each step has a test.

• Routing. The report reaches the named decision owner the same day, and the exercise records how long that took.
• Scope. Engineering can say within a day which app versions and pages carried the component, and for how long.
• Basis. The privacy team can find the contract and the consent text that applied at the time of the flow.
• Containment. Someone with authority contacts the partner to request deletion, citing a specific contract clause.
• Record. Each decision, and the reason for it, is written down as it is made, so the company can later show how it reached its conclusion.

The exercise should also test the uncomfortable branch, in which the company concludes that the flow was a breach. That means a draft notice, a list of who must receive it, a plan for user questions, and a decision on whether the media must be told. Organizations that ran this exercise often found that the slowest step was simply locating the right people and documents.

Money, trust and who owns the risk

The business stakes are straightforward. A breach notice is expensive and public. It requires contacting every affected user, and possibly the media, at the moment of greatest embarrassment. Regulators may follow with penalties and long-running orders that restrict how the company can use data. And in health, trust is the product. People who learn that their fertility, mental health or medication data went to advertisers are unlikely to keep logging it.

There is also a governance point. If the controls that prevent this kind of breach sit with product and marketing, then those leaders need to understand that their choices carry breach risk. A marketing team rewarded only for customer acquisition, with no visibility of privacy risk, will keep adding tracking tools, because they genuinely help measure campaigns.

The strongest case against this view

The two dissenting commissioners made a serious argument in 2021. They said the statement stretched a narrow rule well beyond its text and the agency’s earlier guidance. A change of this size, they argued, belonged in formal rulemaking with public comment, not in a short policy statement. Industry groups added practical objections. Advertising measurement is a normal part of running a consumer business. Much of the data sent is pseudonymous. And a strict reading risked burying users in consent prompts they would click through without reading.

Those objections have merit as points about process, and the FTC did later write the statement’s reading into the rule through notice and comment. On substance they are weaker. Pseudonymous identifiers in advertising systems are built to be linked to people, as described above. A consent prompt that users ignore is an argument for better design, not for sending health data without authorization. And the business decisions at issue, which code ships and which partners receive data, are ones companies control entirely.

Say a regional health system launches a symptom-checker on its website, built by an outside agency. The agency adds the usual analytics and advertising pixels. Months later, a routine scan shows that the symptoms people enter are being passed to an advertising platform along with their browser identifiers. The health system is mostly governed by HIPAA rather than the FTC rule, but the questions are the same ones: who approved the code, what does the contract with the agency say, and what did visitors agree to? If nobody can answer, the health system has a problem, whichever regulator ends up asking.

Where the costs land

The costs of an unauthorized flow fall in several places at once. There is the direct work of investigation, notification and response. There are regulatory orders that can restrict data use for years, which may close off a marketing channel the business relied on. There is litigation, since consumer class actions tend to follow public disclosures of health data sharing. And there are partner costs, because a company that must ask an advertising platform to delete data may find that the platform’s terms give it little bargaining power.

Those costs fall unevenly across organization types. A venture-funded consumer app may face an existential question of trust with its user base. A life sciences company may find that a patient support app becomes a regulatory issue for the brand it supports. A health system, already used to breach reporting under HIPAA, may face the same class action exposure with a reputational cost in its local community. The control set is similar for all three, but the case for funding it is made in different terms.

A program product and marketing can run

Together the three decisions define a program that a privacy office can run with product and marketing leaders: a release gate for code, an inventory for partners, and an auditable record of consent. The security team remains essential for intrusions. For the breaches the FTC described, the controls belong to the people who build and market the product.

Who does what

A workable allocation of roles might look like this. Product owns the release gate and the event design. Marketing owns the list of partners it relies on and keeps agencies inside the gate. Engineering owns the traffic testing and the technical inventory. The privacy office owns the flow inventory, the consent design and the breach decision, with counsel. Security supports the scans and the incident process. The board or a committee of it receives a short report on all of this at least once a year.

Measures worth tracking

A small set of measures shows whether the program is working.

• The share of third-party components with a named owner and a completed review.
• The number of unapproved components each scan finds, and whether that number is falling.
• The time from a scan finding to a breach decision.
• The share of outbound health data flows with a matching contract and authorization record.

A program that cannot produce these numbers is unlikely to be able to answer a regulator either.

Programs tend to fail in familiar ways:

• Treating privacy as a policy document. The privacy policy says one thing; the code may do another. Only traffic testing shows which.
• Trusting vendor descriptions. Configuration screens often understate what a tool sends.
• Letting agencies add code freely. Campaign pages are a common route for unreviewed pixels.
• Signing data deals without engineers. Contracts and data flows drift apart.
• Relying on “by continuing, you agree.” That is weak ground for health data.
• Routing findings to the cleanup queue. An unapproved flow of health data may be a reportable event with a deadline.

Five checks on tracking code and consent

1. Can we list every third-party SDK, pixel and tracking tool in our apps and websites today? Who owns each one?
2. Who is allowed to add tracking code to our sites, including agencies, and does it pass through a review first?
3. Do we have an inventory of every outbound flow of health data, with its recipient, purpose, authorization and contract?
4. For each flow, can we show what the user saw and chose? What happens when someone withdraws permission?
5. If a scan found health data going to an advertiser tomorrow, who would decide whether it is a breach, and how quickly?

With hindsight

The statement marked the start of active enforcement. A rule that had sat unused for more than a decade became a working enforcement tool.

In 2023 the FTC brought its first cases under the rule. In February it announced an action against GoodRx, a prescription discount company, which agreed to a $1.5 million civil penalty over sharing health information with advertising platforms. The order also barred GoodRx from sharing health information for advertising. In May the agency brought a second case, against Easy Healthcare, the maker of the Premom fertility app, which agreed to a $100,000 civil penalty. It also used its general authority against BetterHelp, an online counseling service, which agreed to pay $7.8 million for consumer refunds over sharing for advertising. Each case turned on the kind of disclosure the statement described: data sent to advertising and analytics partners through ordinary business decisions, not stolen by attackers.

In July 2023 the FTC and the HHS Office for Civil Rights jointly wrote to a large group of hospital systems and telehealth providers. The letters warned them about the privacy risks of online tracking technologies on their websites and apps. Two regulators with different jurisdictions were sending the same message to the same audience.

In April 2024 the FTC finalized amendments that wrote the statement’s main points into the rule, clarifying that it covers health apps and that unauthorized disclosures are breaches. The vote was again 3-2. The amended rule also changed the mechanics. It allowed notice by email and other electronic means. It required notices to name the third parties that acquired the data. And for breaches affecting 500 or more people, it required notice to the FTC at the same time as notice to individuals. What had been a policy statement, which a company might have hoped to argue against, became the text of the rule itself.

For companies watching these cases, the orders mattered as much as the penalties, because they restricted how the businesses could use data for years.

Organizations under HIPAA faced a parallel debate. For HIPAA entities, HHS issued guidance on online tracking technologies in December 2022 and revised it in March 2024. In June 2024 a federal court in Texas ruled in a case brought by the American Hospital Association. It vacated the part of the guidance that treated tracking on public, unauthenticated web pages as a potential disclosure of protected health information. The legal details shifted, but the practical question for hospitals and insurers using tracking tools on their websites stayed much the same: what data is leaving, to whom, and on what basis.

Several large health systems had by then reported tracking-related incidents to HHS. Advocate Aurora Health disclosed in 2022 that pixels on its websites and patient portal may have sent information about up to three million patients to outside parties. In 2024 Kaiser Permanente reported that tracking tools on its websites and apps may have exposed information about some 13.4 million people. Class actions followed many such disclosures.

States moved too. Washington’s My Health My Data Act, whose main provisions took effect in March 2024, added consent rules for consumer health data and gave consumers a private right to sue. Nevada passed a similar law the same year Washington did. That added another layer for companies that had hoped consumer health data sat in a lightly regulated space.

Across these, the controls that mattered were the three business decisions above, not perimeter security. The practical course is to treat tracking code, partner data flows and consent records as matters of governance, owned by the people who make product and marketing decisions, reviewed before launch and checked regularly afterward.