Wearable Data Privacy: Key Regulations

Most wearable data in the U.S. is not protected by HIPAA. What applies instead depends on who collects the data, what they do with it, and where the user lives.

If I had to boil the whole article down, I’d put it this way:

• HIPAA usually applies only when wearable data flows into a hospital, health plan, or another covered healthcare setup.
• GDPR can apply if an app or device handles data from people in the EU, especially health, location, or biometric data.
• CCPA/CPRA can apply to consumer wearable companies that do business in California and meet size or data thresholds.
• BIPA is the Illinois biometric rule, and it focuses on fingerprint, face, voice, and similar data used to identify someone.
• The FTC can act when a company shares health data in ways users were not told about, or when breach notice rules are missed.
• State breach and IoT laws add more rules for connected devices, breach notices, and device security.

A few numbers stand out fast:

• 60 days: the FTC Health Breach Notification Rule deadline after discovery
• 500+ people: the point where FTC media notice may also apply
• $43,792 per violation per day: possible FTC HBNR penalty
• $25 million in annual revenue: one California coverage threshold
• 100,000 consumers or households: another California threshold

Ethics of Wearable Technology: Privacy, PHI and IP Considerations

sbb-itb-f5765c6

Quick comparison

Rule	Main trigger	What it tends to cover
HIPAA	Wearable data enters a covered healthcare setting	PHI handled by covered entities or business associates
GDPR	EU user data is processed	Personal data, health data, biometric data
CCPA/CPRA	California business meets thresholds	Personal and sensitive personal information
BIPA	Illinois biometric collection for identity use	Biometric identifiers and related data
FTC HBNR / Section 5	Consumer health data breach or misleading sharing	Health app and wearable data outside HIPAA
State breach / IoT laws	Breach event or connected device sale	Personal data, device security duties

The main takeaway is simple: wearable privacy is a multi-law issue, not a one-law issue. If I’m reviewing a wearable health app, I’d start with the data flow, perhaps by centralizing it in real-time health dashboards, then check consent, sharing, storage, vendor access, and breach response.

Quick Comparison of Wearable Privacy Rules

Use this table to line up each rule with the moment it tends to kick in.

Regulation	Who It Covers	Data Protected	Key User Rights	Key Company Obligations	Typical Wearable Trigger
HIPAA	Covered entities (providers, health plans, clearinghouses) and business associates	Protected Health Information (PHI) - individually identifiable health data	Access, amendment, accounting of disclosures, notice of privacy practices	Safeguards, BAAs, breach notice	Syncing wearable data to an EHR or remote patient monitoring platform
GDPR	Any controller or processor handling EU users' personal data	Health and biometric data, plus related location and behavior data	Access, erasure, portability, rectification, objection, restriction	Lawful basis, DPIAs, breach notice	Any wearable or health app processing data of users located in the EU
CCPA/CPRA	For-profit businesses doing business in California that meet the revenue or data-volume thresholds	Personal information and sensitive personal information, including health data and biometric identifiers	Know, delete, correct, opt out of sale/sharing, limit use of sensitive data	Privacy notices, rights workflows, vendor contracts	A consumer wearable company meeting California's thresholds
BIPA	Private entities collecting biometric data from Illinois residents	Biometric identifiers and biometric information derived from them	Written informed consent before collection	Written consent, retention/destruction policy, security	Wearables using fingerprint login, facial recognition, or unique physiological signals for Illinois users
FTC Health Breach Notification Rule (HBNR)	Vendors of personal health records (PHRs) and consumer health record vendors not covered by HIPAA	PHR-identifiable health information	Notice after a breach	Breach notice to users, FTC, and sometimes media	Any consumer health app or wearable that draws data from multiple sources and is not covered by HIPAA
State Breach-Notification and IoT Laws	Device manufacturers and data holders doing business in covered states	Personal information including health and medical data; IoT laws focus on connected device security	Timely breach notification	Security features, breach notice	Any internet-connected wearable sold in California, or any breach involving personal or health data

There’s a simple way to think about this: HIPAA is narrow, while the consumer-facing rules cast a much larger net.

HIPAA applies only when wearable data reaches a covered entity or business associate. So if a fitness tracker sends data into an EHR or a remote patient monitoring platform, HIPAA may step in. If that same data stays in a consumer app, other rules may matter more.

GDPR and BIPA set the toughest consent standards in this group. And the FTC Health Breach Notification Rule carries real teeth: the FTC can fine HBNR violations up to $43,792 per violation per day.^[3]

A good way to read the chart is to start with HIPAA, since it’s the narrowest rule here, and then move outward to the broader consumer privacy laws.

1. HIPAA

Who It Applies To

HIPAA applies to covered entities - health plans, providers involved in HIPAA-covered electronic transactions, and clearinghouses - as well as business associates that handle PHI on their behalf.^{[19][20][22][23]}

A consumer fitness tracker usually sits outside HIPAA. But that can change fast. If the tracker sends patient data to a hospital or an EHR, the company behind it may become a business associate.

That line matters. The same wearable data can be outside HIPAA in one setting and inside HIPAA in another, based on who receives it and why.

What Wearable Data It Covers

HIPAA protects PHI, which means identifiable health information tied to a person's health, care, or payment for care.^[21][23]

For wearables, that can include data like:

• Heart rate
• Sleep data
• Glucose readings
• Activity data

But here's the key point: this data becomes PHI only when a covered entity or business associate handles it.

When It Applies to Wearables

HIPAA often comes into play when wearables are used in health care settings, such as:

• Hospital-issued post-op monitoring
• Insurer wellness programs
• Provider apps that send wearable data into clinical systems for chronic care management

Main Compliance Duties

When wearable data counts as PHI, covered entities and business associates take on three main duties.

Privacy Rule: PHI can be used or shared only for treatment, payment, or health care operations, unless the patient gives authorization. The minimum necessary rule also applies. In plain English, that means access or sharing should be limited to what the task actually needs.

Security Rule: Organizations must use administrative, physical, and technical safeguards. That includes encryption in transit and at rest, access controls, audit logs, and risk analysis for APIs and cloud systems.

Breach Notification Rule: If PHI from a wearable is compromised, the organization may need to notify affected individuals, HHS, and sometimes the media, based on the size of the breach and timing rules.

A BAA sets the ground rules when a vendor handles PHI for a covered entity. It spells out permitted uses, safeguards, and breach duties.^{[20][21][22][23]} And business associates aren't just on the hook by contract - they also face direct liability under HIPAA.^[24]

When wearable data stays outside HIPAA, consumer privacy laws step in.

2. GDPR

Who It Applies To

When wearable data falls outside HIPAA, GDPR is often the next big rule to check for people in the EU. A U.S.-based app or device company can still fall under GDPR if it targets EU users, such as by offering EU languages, showing prices in euros, or otherwise aiming its product at that market. Wearables often trigger GDPR because they involve ongoing monitoring and profiling. ^[29][30][28]

In plain terms, features like continuous activity tracking, location tracking, and AI health profiling can bring a wearable app within GDPR’s reach. ^{[25][26][27][35]}

What Wearable Data It Covers

Under GDPR, account emails, device IDs, and usage logs count as personal data. But the rules get much stricter when the data shows something about a person’s physical or mental health. At that point, it can become special-category health data under Article 9. ^{[29][7][6][31]}

For wearables, that can include:

• Heart rate
• Sleep stages
• Blood oxygen
• Body temperature
• Menstrual cycle data
• Stress signals

^[32][33][34]

Main Compliance Duties

Special-category health data is banned by default unless a specific Article 9 exception applies. For consumer wearables, explicit consent is often the main route. But that’s not enough on its own. A company also needs a separate lawful basis under Article 6. Consent must be separate, specific, and easy to withdraw. ^[36][42][6]

Beyond consent, wearable companies still have to do the nuts-and-bolts privacy work. That means collecting less data than they may want, handling user rights requests, using strong security controls, running a DPIA for high-risk wearable processing, and setting up a valid transfer mechanism for cross-border data flows. ^{[39][40][41][38][37]}

3. CCPA/CPRA

Who It Applies To

For consumer wearables, CPRA is usually the main California privacy law once HIPAA no longer applies.

The California Consumer Privacy Act (CCPA) and the California Privacy Rights Act (CPRA) apply to for-profit businesses that do business in California, collect personal information from California residents, and meet at least one of these thresholds: annual gross revenue over $25 million, collecting, selling, or sharing data from 100,000 or more Californians or households, or getting 50% or more of annual revenue from selling or sharing Californians' personal information. ^[44][48]

A company doesn't need a California office to fall under the law. If it does business with Californians and meets one of those thresholds, it can still be covered.

What Wearable Data It Covers

CCPA/CPRA covers data that identifies a consumer or household, relates to them, or can be linked back to them. That includes device IDs, location data, profiles, and sensor-based behavior patterns. ^[48][49]

CPRA also treats wearable health data, biometric data, and precise location data as sensitive personal information. ^[50][52][53] HIPAA-covered health data is exempt, but most consumer wearable data is not. So if a smartwatch app tracks heart rate or sleep, that data will often fall under CPRA. ^[51]

In plain English: for many wearable apps in California, CPRA is the rulebook that matters most.

Main Compliance Duties

For wearable companies, CPRA calls for:

• clear notices at collection
• rights workflows for access, deletion, correction, portability, and opt-out of sale or sharing
• a way for users to limit the use of sensitive personal information ^[48][51][53]

It also requires data minimization, purpose limits, and retention limits tied to the purpose disclosed to the user. On top of that, the law bans dark patterns that push people away from making privacy choices they want to make. ^{[43][45][46][47]}

For Illinois users, biometric data can trigger even tighter rules under BIPA.

4. BIPA

For Illinois users, the bar is higher when a wearable uses biometric data for identity or access control.

Who It Applies To

In Illinois, the main issue isn't general health tracking. It's the collection of biometric data from residents. BIPA applies to private entities that collect biometric identifiers or biometric information from Illinois residents.

What Wearable Data It Covers

BIPA covers biometric identifiers and biometric information used to identify a person. It does not cover ordinary health metrics by default.

When It Applies to Wearables

For wearables, BIPA comes into play when biometric data is collected for identification or authentication. That includes fingerprint, face, voice, or similar biometric matching.

When BIPA applies, it also requires:

• Written informed consent
• A retention schedule
• A destruction policy
• Reasonable security controls as part of a broader wearable health data security strategy

BIPA is narrower than GDPR and CPRA in terms of geography, but it's stricter on consent for biometric collection.

5. FTC Health Privacy and Consumer Protection Enforcement

When biometric laws and state privacy laws don’t cover a consumer wearable, the FTC often steps in. For wearables that sit outside HIPAA, the FTC is usually the main federal fallback. It uses Section 5 to go after unfair or deceptive data practices, including false statements about data collection, sharing, and security.^{[60][61][2][66]}

Who It Applies To

The FTC’s Health Breach Notification Rule (HBNR) applies to companies that are not covered by HIPAA but still collect or process individually identifiable health information. That can include wearable trackers, health apps, and connected devices that pull together sensor data, user input, or API syncs. In 2024, the FTC made clear that the rule extends to health apps and connected devices.^[5][11][65]

What Wearable Data It Covers

The FTC’s reach here is broad. Data like heart rate, sleep, step count, weight, calories, and other wellness metrics can fall under HBNR when linked to a personal health profile. Data combined from sensors, apps, or APIs may also be covered.^[3][54][9]

When It Applies to Wearables

FTC enforcement comes into play when a non-HIPAA company has a breach involving unsecured health information or shares covered health data without the consumer’s specific authorization. The FTC also treats unauthorized sharing as a breach. That includes disclosures to ad-tech partners without consent.^[62][55][54]

GoodRx and BetterHelp make the point pretty clear: the FTC will penalize companies that share sensitive health data with advertisers after telling users something else.^{[1][57][58][59][60][61]}

Main Compliance Duties

If a breach happens, covered companies must notify affected individuals and the FTC within 60 calendar days after discovery. If the breach affects 500 or more people, the company must also notify local media. Civil penalties can reach up to $43,792 per violation per day, which means a slow or half-done response can get expensive fast.^{[5][10][56][3][63][64]}

In practice, this puts vendor review and ad-tech scrutiny on the same level as breach response. Companies should:

• map the health data they collect
• review each API and ad-tech integration
• get specific authorization before sharing covered data
• keep an incident-response process that can meet the 60-day deadline

For consumer wearables, FTC risk often comes down to sharing, disclosures, and breach response.

6. State Breach-Notification and IoT Security Laws

When federal rules don’t fully cover wearable data, state law often steps in. Every U.S. state, plus D.C., Guam, Puerto Rico, and the U.S. Virgin Islands, has its own data breach-notification law.^[8] California’s SB 327 is often pointed to as the first U.S. IoT security law. It sets a baseline for device security that other states and federal regulators have been watching closely.^[13][73]

There’s a simple way to think about the split here: breach-notification laws deal with what happens after an incident, while IoT laws like SB 327 focus on building security into the device from the start.

Who It Applies To

State breach-notification laws usually apply to any entity that owns, licenses, or maintains personal information about state residents, no matter where the company is based.^[8] In the wearable space, that can reach a lot of players, including manufacturers, apps, employers, and providers that store data generated by wearables.^[68][70][15]

California’s SB 327 is more narrow. It applies to manufacturers of connected devices sold or offered for sale in California. That includes companies that make, or hire others to make, internet-connected wristbands, rings, patches, or smart clothing.^{[12][67][13][14]}

What Data It Covers

For breach-notification laws, raw metrics usually trigger notice duties only when they’re linked to an identified person.^[68][15] Many states also treat biometric data, along with some health-related or inferred data, as sensitive information. That matters because modern wearables often produce exactly that kind of data.^[4][8]

SB 327 looks at things from the device side. It covers any information the device may collect, contain, or transmit. That can include device identifiers, user credentials, and telemetry streams like heart rate variability or sleep stages.^{[12][67][13][69]}

When It Applies to Wearables

Breach-notification duties kick in when personal information is acquired, or is reasonably believed to have been acquired, by an unauthorized person.^[68][15][71] For wearable companies, that often shows up in pretty familiar ways: a hacked cloud database, a misconfigured API that exposes user records, or ransomware hitting backend systems tied to wearable devices.

SB 327 works in a different lane. Its duties begin when a connected device is manufactured and offered for sale in California, not after a breach happens.^{[12][67][13][14]} So even selling wearables online to California residents can pull a product into scope.

Main Compliance Duties

Under SB 327, manufacturers must build in reasonable security for both the device and the data it handles. In practice, that means each device needs either a unique password or a requirement that the user set a new password the first time the device is used.^{[12][67][13][14][69]}

For breach-notification laws, the main duty is prompt notice. Most states require notice to affected residents within 30 to 60 days after discovering a breach, along with details about what happened, what data was involved, and what steps users should take.^[8][15][72] Many states also require notice to the state attorney general or another regulator when the breach passes a set threshold, often 500 to 1,000 affected people.^[15][71][72]

Here’s the split in plain English:

	State Breach-Notification Laws	IoT Security Law (CA SB 327)
Primary focus	Post-incident duties: who to notify, what to include, how fast	Pre-incident security-by-design: what security features devices must have
Who is covered	Any entity owning or maintaining personal information of state residents	Manufacturers of connected devices
When it applies	After unauthorized access or acquisition of personal information	Before sale, during design and manufacturing
Key requirement	Notify affected individuals and regulators within 30–60 days	Unique passwords per device or forced credential setup on first use

That distinction matters for wearable companies. One security failure can set off state notice duties, while weak device design can create separate exposure under SB 327.

Common Wearable Privacy Mistakes Companies Make

Most wearable privacy failures come down to day-to-day decisions. Companies collect too much, ask for consent in overly broad ways, share data with too many parties, and keep it far longer than they should.

One of the biggest mistakes is thinking HIPAA covers all wearable health data. It doesn’t. HIPAA applies only to covered entities and business associates, not most direct-to-consumer wearables. So if a company tells users their data is HIPAA-protected when it isn’t, that can trigger FTC action for deceptive practices ^{[16][75][76][18]}.

Over-collection is another common problem. A lot of wearable apps default to pulling in nonstop streams of detailed data - 24/7 heart rate, GPS location, sleep stages, menstrual cycle data - even when the product needs only a small slice of that to enhance wearables with context-aware AI. That creates more exposure under CCPA/CPRA, increases breach risk, and makes vendor oversight harder. It also complicates the process of extracting personalized health insights from wearable anomaly data without compromising user privacy.

Vague consent often sits right next to that problem. Many companies roll monitoring, marketing, and third-party sharing into a single checkbox. That’s a common compliance miss. Users expect sensitive health data to be limited and kept apart from marketing. The safer move is simple: use separate, plain-language consent for sensitive data and for sharing ^[17].

The riskiest mistake, though, is making privacy promises the product doesn’t actually keep. A company may say it does not share health data, while its SDKs, ad tools, or vendor contracts allow that sharing anyway. If your marketing says you never share health data, your technical setup and vendor agreements need to match that claim all the way through.

The same gap shows up after a breach. Breach response is not just a HIPAA matter; FTC and state laws can also set notice deadlines, and keeping data forever only adds to the risk ^[3][74][56]. Clear retention periods by data type, plus automated deletion built into the system, are not nice-to-haves. They are basic risk controls.

Conclusion

HIPAA is only one piece of the privacy puzzle. Whether it applies depends on the kind of data involved, where the user is located, and the role the company plays. And for consumer wearables, the rulebook usually doesn't stop at HIPAA. More than one set of privacy rules can apply at the same time.

The fastest way to sort this out is to map the data before launch. Build a data-flow map that shows the full path of the data: what gets collected, where it goes, who can access it, and how long it stays in the system. That single view makes it much easier to see which rules apply, in which places, and to which data.

Once the map is in place, the next move is simple control design. In practice, that means three things: tighten notices and consent flows, match security controls to data sensitivity, and set clear retention limits. Notices should say what the product actually does. Consent for sensitive health data should be separate, written in plain language, and tied to a specific use, not buried in one bundled checkbox. Security controls and retention schedules should fit the risk level of the data being stored.

These basics matter even more for AI health tools that tailor guidance from wearable data. For AI-powered health tools like Healify, these controls support both compliance and user trust.

Strong privacy practices are the base everything else rests on.

FAQs

How do I know which privacy law applies to my wearable data?

It mostly comes down to who handles your data and what they do with it.

In the U.S., HIPAA usually does not cover data from consumer wearables unless that data is tied to a service from a healthcare provider, hospital, or insurance plan.

If your wearable data is collected only for personal use, it’s often covered instead by state privacy laws, such as California’s CCPA, along with FTC oversight.

That’s why it’s smart to check your device’s privacy policy. It should spell out how your data is used, stored, and shared.

Is my smartwatch data protected if it never goes to a doctor?

Usually not under HIPAA. If your smartwatch data isn’t handled by a healthcare provider, hospital, or insurance company, it usually sits outside HIPAA. That’s because most consumer wearables aren’t covered entities.

Instead, this data is usually governed by the Federal Trade Commission and state privacy laws, which may offer weaker protections. Review your device’s privacy policy, turn on encryption, and limit data sharing in the app settings.

Can multiple privacy laws apply to the same wearable app?

Yes. The same wearable app may fall under more than one privacy law. It depends on where the user is located, what data the app collects, and how the app operates.

In the U.S., that may mean HIPAA in some cases, state laws such as California’s CCPA/CPRA, FTC oversight, and the FTC’s Health Breach Notification Rule. If the app has users outside the U.S., it may also need to comply with the GDPR.