Why a Breach Does Not Require a Hacker
This chapter examines what counts as a breach under the Federal Trade Commission’s Health Breach Notification Rule once a non-HIPAA product has been identified as a qualifying personal health record. The focus is the step people most often get wrong: a breach is not limited to an intruder breaking into a database. The rule can also reach an unauthorized disclosure or use, so the reader needs to evaluate the condition of the data, the event that exposed it, the company’s representations, and the recipient’s purpose before deciding whether notice may be required.
The trigger is unauthorized acquisition
The FTC rule defines a breach of security as the acquisition of an individual’s unsecured PHR identifiable health information in a personal health record without that individual’s authorization. That sentence contains several gates. The information must be the kind covered by the rule, it must be unsecured, it must be in a qualifying personal health record, and someone must acquire it without the person’s authorization. A company does not reach the breach question merely because it operates a popular health app or stores information that feels sensitive.
The word “acquisition” is broader than the everyday image of data theft. The rule says that unauthorized acquisition is presumed to include unauthorized access unless the vendor, PHR related entity, or third-party service provider that experienced the breach has reliable evidence showing that unauthorized acquisition did not occur or could not reasonably have occurred. Access creates an opportunity to view or obtain the information. The presumption recognizes that the organization controlling the system is usually in the best position to investigate what that opportunity led to.
The presumption is rebuttable, not automatic proof of every possible harm. If an organization can produce reliable evidence that an unauthorized person did not acquire the information, the presumption may be overcome. But the burden is not solved by asserting that no file was downloaded. The relevant question is whether the information was acquired without authorization, and the rule treats unauthorized access as evidence pointing toward that result unless the organization can establish otherwise.
The rule also limits its trigger to unsecured information. “Unsecured” means PHR identifiable information that is not protected through a technology or methodology specified by the Secretary of Health and Human Services under the relevant Recovery Act guidance. This is a defined security boundary, not a general statement that every encrypted dataset is safe from every legal obligation. It tells the reader when the FTC notification rule is activated; it does not turn good security into a complete privacy program.
Most importantly, the final text says that a breach includes an unauthorized acquisition resulting from a data breach or an unauthorized disclosure. The two paths can look very different. In the first, an attacker or unauthorized employee may gain access through a security failure. In the second, the company or someone acting in its data flow may deliberately send information to another company, but that transfer may still be unauthorized because it exceeds what the individual agreed to or reasonably expected.
Consider a medication app that stores prescription names, dosages, pharmacy information, and health conditions. If an attacker obtains that record, the event can fit the ordinary security-incident picture. But if the app voluntarily sends the same information to an advertising platform in a way that conflicts with its privacy representations, the absence of a hacker does not end the analysis. The company has still created a question about whether a third party acquired unsecured PHR identifiable health information without the individual’s authorization.
The Commission describes the definition as consistent with the Recovery Act’s focus on acquisition without the authorization of the individual, rather than merely asking whether the company that possessed the data approved the transfer. That distinction is important. A vendor cannot make every disclosure authorized by simply deciding internally that the disclosure was acceptable. The person whose information is being acquired remains central to the inquiry.
The same logic can reach a later use. The Commission says that, depending on the facts and the scope of the authorizations involved, a breach may occur when an entity exceeds authorized access to use PHR identifiable health information—for example, collecting data for one legitimate purpose and later using it for a secondary purpose that the individual did not authorize. Unauthorized access or use of information derived from PHR identifiable health information may also matter. These are fact-dependent applications, not a declaration that every internal use or every derived data point automatically triggers notice.
The rule’s breadth is deliberate, but it is not unlimited. It does not convert every ordinary business disclosure into a breach. The information must still be unsecured PHR identifiable health information in a qualifying PHR, and acquisition must be unauthorized. Nor did the Commission adopt a catalogue of special safe harbors or exceptions for the FTC rule equivalent to the enumerated exceptions in the HIPAA breach-notification framework. That difference means an organization cannot assume that a familiar HIPAA exception automatically transfers to this non-HIPAA regime.
This is the mechanism in compact form: a qualifying record contains defined health information; an access, disclosure, or use gives another person or entity an opportunity to acquire it; the organization asks whether the person authorized that acquisition; and, if not, the notice duties follow unless reliable evidence rebuts the access presumption or another defined condition is absent. The mechanism focuses on authorization and acquisition, not on whether the event fits a cybersecurity incident report.
The mechanism in compact form can be visualized as a choice between two data paths. The labels are not enough to decide the outcome; the purpose, disclosures, and limits attached to each path matter.
Authorization follows purpose and expectations
The absence of a universal consent formula is not the absence of a standard. The Commission declines to define “authorization” as affirmative express consent in every case. Instead, it says the inquiry depends on the context of the interaction between the consumer and the company, the nature, recipients, and purposes of the disclosure, the company’s representations, and other applicable laws. That approach lets an app share information necessary to provide a requested service while still treating unexpected commercial exploitation as potentially unauthorized.
The Commission’s baseline is that a use is authorized when it is consistent with the company’s disclosures and the consumer’s reasonable expectations, and when the consumer has meaningful choice in consenting to the sharing. A buried statement in a long privacy policy does not satisfy that standard merely because it exists somewhere in the documents. The question is whether the person could reasonably understand the sharing and make a meaningful decision about it, not whether the company can point to a sentence after the fact.
This is why purpose and recipient matter together. Suppose a medication app shares PHR identifiable health information with a cloud provider that hosts the record, a payment processor handling a requested purchase, or a service that sends refill reminders. The Commission says such disclosures can be authorized when they assist with the app’s operation or a service the consumer requested, are limited by contract so the provider does not use the information for unrelated purposes, and are clearly and conspicuously described in the app’s privacy notice. Analytics used to understand crashes or the operation of the app can fit the same logic when the analytics serve the app rather than a separate marketing business.
Now change the recipient’s purpose. If the app sends medication or condition information to a third party so that the recipient can target consumers with advertising, improve its own products, infer attributes, or compile profiles for its own economic benefit, the disclosure is different. The Commission’s example treats it as unauthorized when the sharing is inconsistent with the app’s representations and with what consumers would reasonably expect. It is not essential merely because the company has found a profitable way to use the data.
The distinction is not “service provider good, advertiser bad” as a fixed label. A firm can perform an operational service in one part of a data flow and act for its own purposes in another. The relevant question is what function the disclosure served, what limits were communicated, and whether the recipient was permitted to keep using the information beyond the requested service. A company’s label for a partner—“analytics,” “platform,” or “technology provider”—cannot answer those factual questions by itself.
Meaningful choice also depends on how the choice is presented. The Commission points to dark patterns—interfaces designed to manipulate or deceive consumers, or to impair their autonomy and decision-making—as evidence against the claim that a person meaningfully authorized sharing. A nominal click does not automatically settle authorization if the surrounding design made the decision confusing, coercive, or effectively invisible. This does not create a universal requirement that every operational disclosure use a new opt-in screen. It does require the company’s account of consent to match the actual experience of the person whose information was shared.
The Commission gives a different example for a non-HIPAA COVID-19 contact-tracing app. If the app clearly tells users that it will send a self-reported diagnosis to public-health authorities for reporting, analysis, or tracking the spread of the virus, the disclosure can be authorized and consistent with reasonable expectations. The relationship between the app and the user matters: reporting the diagnosis is connected to the service the app offers, and the purpose is clearly stated. The example shows why a rule aimed at unexpected commercial sharing need not block every socially necessary health-data use.
The enforcement history makes the distinction concrete. In its account of GoodRx, the Commission alleged that the company, a digital health company offering prescription and telehealth products, disclosed more than 500 consumers’ unsecured PHR identifiable health information to advertising platforms such as Facebook and Google without authorization and contrary to privacy promises. The information allegedly included prescriptions, health conditions, contact information, and persistent identifiers. The Commission charged that GoodRx failed to provide the notifications required to affected individuals, the FTC, and media outlets; the settlement included injunctive relief and a $1.5 million civil penalty.
The Commission describes a similar pattern in its account of Easy Healthcare, publisher of the Premom ovulation and period-tracking application. It alleged that the company disclosed PHR identifiable health information to companies including Google and AppsFlyer contrary to its privacy promises and did not comply with the rule’s notification requirements. The settlement included injunctive relief and a $100,000 civil penalty. These were settlements, not trial findings described in the final-rule document, so the amounts should not be read as a universal penalty schedule. Their value as examples is narrower and more useful: they show how privacy representations, recipient purpose, and failure to notify can connect a voluntary disclosure to the FTC rule.
The final rule’s enforcement section adds a separate consequence. A violation of the part is treated as a violation of a rule promulgated under section 18 of the FTC Act concerning unfair or deceptive acts or practices and is subject to civil penalties. That provision gives the notification requirement legal weight. It does not, however, mean that every disputed sharing practice has already been adjudicated, or that the rule replaces other legal tests for privacy, security, or consumer protection.
A careful reading of a new incident therefore asks four related questions. Was the information unsecured and within a qualifying PHR? What person or company acquired it, and did the event involve access, disclosure, or a later use? What did the consumer-facing company actually promise, what choice did it provide, and what purpose did the recipient pursue? Finally, what evidence supports the conclusion—for example, records of the transfer and the interface that disclosed it—rather than merely a general belief that the sharing was reasonable or unreasonable?
The answer can change when the facts change. A clearly disclosed, limited transfer needed to operate the requested service may be authorized. The same health information sent to a recipient for its own advertising or profiling may not be. An access event may be treated as acquisition unless reliable evidence rebuts the presumption. And a voluntary disclosure can be a breach even when the company’s security perimeter was never penetrated. Once those distinctions are visible, the remaining practical question is how responsibility is divided when several companies participate in the same transfer.