Consumer Health Data Toolkit: Consent Forms, Data Maps, and Breach Notification Decisions

How to use this toolkit

Take these papers in the order of the table below if you're starting from nothing. Tools 1 to 4 tell you what you have. Tools 5 to 8 are what the public and your vendors see. Tools 9 to 12 are for the day something happens. Reasoning sits in the companion documents: the article on consumer health data outside HIPAA for the law, the practical guide on bringing a health app into compliance for the sequence, and the compliance checklist for review.

Three warnings apply to everything here. These templates are built to Washington's My Health My Data Act because it is the strictest, so adapt them for other states and strike what doesn't apply. A template that describes a practice you don't follow creates the deception claim it was meant to prevent. And state section numbers should be checked against the current code before you cite them to anyone.

Tool 1: Applicability matrix

Purpose: Record which law applies to which product, and why, in a form you can defend later. Owner: counsel. Timing: first week, repeated annually and before each new integration.

Drafting notes.

• The HIPAA definitions are in 45 C.F.R. § 160.103. The FTC rule's definitions, including "health care services or supplies," are in 16 C.F.R. § 318.2. The statutory basis is 42 U.S.C. § 17937.
• Write down the facts, not just the answer. "No, because the product takes only user-typed entries and has no import, API, or sync capability" is a position. "N/A" is not. If product adds a HealthKit import next year, this row flips.
• For Washington, record your position on the attorney general's FAQ (an entity that only stores data in Washington isn't regulated; non-prescription purchases are covered only if the entity draws an inference). Note in the "facts" column that it's guidance.
• For the omnibus statutes, see State Consumer Privacy Laws: The CCPA, the CPRA, and the Multi-State Patchwork.
• California's test comes from Cal. Civ. Code § 56.06, read with J.M. v. Illuminate Education, Inc., No. S286699 (Cal. May 14, 2026). Compare Frasco v. Flo Health, Inc., No. 21-cv-00757 (N.D. Cal. May 22, 2025), and Kady v. Opencare, Inc., No. 4:25-cv-05037 (N.D. Cal. Aug. 31, 2026).

Tool 2: HIPAA status worksheet

Purpose: Separate the HIPAA hat from the consumer hat for each product. Owner: counsel, with sales. Timing: first week, and at each new customer type.

Fill in one per product.

Product: [name]                         Reviewed by: [name]    Date: [date]

A. Who pays or directs us?
   [ ] Consumer directly       [ ] Employer       [ ] Health plan
   [ ] Provider or hospital    [ ] Other: [describe]

B. Does a covered entity direct patients to this product for care,
   records, or billing, under a contract with us?        Y / N
   If Y, list contracts and whether a BAA exists: [list]

C. Do we bill insurers or send claims, eligibility, or remittance
   transactions electronically, ourselves or through a billing vendor? Y / N

D. Does data from this product flow into a covered entity's record,
   or does theirs flow into ours?                         Y / N

E. Result:
   [ ] Inside HIPAA for all data
   [ ] Outside HIPAA for all data
   [ ] Split. HIPAA stream: [describe]. Consumer stream: [describe].
       Technical separation: [how]. Contract separation: [how].

F. Public statements about HIPAA that we make: [quote each one]
   Each one is accurate because: [reason] / Removed on: [date]

Drafting notes.

• Business associates include subcontractors, per 45 C.F.R. § 160.103, and they are directly liable, per 42 U.S.C. §§ 17931 and 17934.
• Line F exists because the FTC pleaded a false HIPAA seal against GoodRx and a HIPAA compliance claim against Monument. In Kady, a privacy policy's own business associate statement helped carry the plaintiffs past the pleadings.
• An authenticated patient portal should have no third-party ad trackers. OCR's bulletin survives for that context, because American Hospital Ass'n v. Becerra, 738 F. Supp. 3d 780 (N.D. Tex. 2024), vacated only the portion about IP addresses and unauthenticated public pages.
• For cloud vendors, use HIPAA Business Associates and Cloud Computing.

Tool 3: Traffic capture script and SDK log

Purpose: Find out what leaves the app, browser, and server. Owner: an engineer, with a marketer available. Timing: weeks 1 to 3, then quarterly and after any tag or dependency change. Have counsel request it in writing if a dispute is possible, and preserve configurations first.

Test personas. Create test accounts with invented, distinctive data so payloads are easy to search, such as a test user named "Zebra Testuser" with condition "testcondition-migraine."

Script.

1. Install the build on a test device with an intercepting proxy trusted. Note the app version and OS.
2. Launch the app for the first time. Save all traffic before you tap anything. This captures initialization.
3. Refuse every permission and consent. Walk the main flow. Save it.
4. Reset. Grant every permission and consent. Walk the main flow. Save it.
5. Enter each health data type, one by one: symptom, medication, cycle log, mood, test result, photo.
6. Use import flows: HealthKit, Health Connect, wearable, lab.
7. Buy something. Book something. Cancel something.
8. Request deletion. Confirm what happens on the wire, and later in vendor dashboards.
9. Repeat on the other mobile OS.
10. On web, repeat with developer tools and a clean browser, logged out and logged in. Search the capture for your test strings, the email address, and its common hashes.
11. Log in to each ad platform and record event names received, audiences, and match rates.
12. Ask engineering in writing: "List any server-to-server transmission to a third party." Ask marketing in writing: "List every list you've uploaded in three years."

SDK and tag disposition log.

Drafting notes.

• Save payloads, because the event names matter as much as the destination. The FTC alleged Monument named events "Paid: Weekly Therapy" and "Paid: Med Management."
• Test step 2 carefully. Prior consent is a statutory element under RCW 19.373.030(1)(c). In Kady, the alleged sequence of quiz first and policy notice later defeated a consent defense at the pleading stage.
• Step 3 tests whether an opt-out is honored, the core of the allegations in Shah v. MyFitnessPal, Inc., No. 25-cv-04430 (N.D. Cal. Sept. 28, 2026).
• For web-specific technique, see Auditing Your Website Tracking Stack: A Practical Guide and the Adtech Privacy Toolkit: Tag Inventories, Consent Records, and Litigation Defense.

Tool 4: Data map template

Purpose: The single source for your policy, consent screens, rights responses, and breach analysis. Owner: engineering and marketing jointly, with counsel completing the legal columns. Timing: build in weeks 1 to 3; update at every release.

Drafting notes.

• Keep removed flows on the map with dates. You'll need them for access requests about past sharing, and for Tool 9.
• The recipient list has to be concrete. RCW 19.373.040(1)(a) entitles consumers to a list of "all third parties and affiliates" with a contact.
• "Consumer health data" under RCW 19.373.010(8) includes data derived or extrapolated from non-health information. Add a row for each model or segment that scores a condition.
• Retention is part of security. See Data Minimization and Avoiding the Over-Retention of Personal Information.

Tool 5: Consumer health data privacy policy clauses

Purpose: The separate policy required by RCW 19.373.020 and Nevada's parallel provision. Owner: counsel, reviewed line by line by an engineer. Timing: weeks 3 to 6, and before any new category or purpose.

Placement. Separate page. A link labeled "Consumer Health Data Privacy Policy" in the site footer of every page where you collect personal information, on the app store listing, and in the app's settings or about screen.

Clause 5.1: Scope.

This policy applies to consumer health data that [Company] collects through [products]. It covers Washington and Nevada consumers and any other person to whom these laws apply. It does not cover information that is protected health information under HIPAA, such as information we handle on behalf of a hospital or clinic. That information is governed by that organization's notice.

Clause 5.2: What we collect and why.

We collect these categories of consumer health data, for these purposes:

Category	Examples	Why we collect it and how we use it
Sleep and mood information	Sleep times, mood check-ins	To show your trends and suggest routines
Symptoms you enter	[examples]	[specific use]
Information we infer	[e.g., a sleep pattern score]	[specific use]
Precise location	[only if collected]	[specific use]

Clause 5.3: Sources.

We get this information from you, from your device, and from services you connect, such as [Apple Health, a wearable]. [We also get it from: list.]

Clause 5.4: What we share, and with whom.

We share these categories of consumer health data: [list]. We share them with these categories of third parties: [e.g., research organizations you choose to share with]. We share with these affiliates: [list by name, or "We do not share with affiliates"]. We share only with your separate consent, or where sharing is necessary to provide something you asked for.

We also use service providers ("processors") who process this information only for us, under contract, and who can't use it for their own purposes.

Clause 5.5: Sale. Use one, and be sure it's accurate.

Option A: We do not sell consumer health data. That means we do not exchange it for money or other valuable consideration. [Confirm against Tool 7 notes.]

Option B: We sell consumer health data only with your signed authorization, which names the buyer and the specific data, and expires in one year.

Clause 5.6: Your rights.

You can:

• Find out whether we collect, share, or sell your consumer health data, and get a copy.
• Get a list of all third parties and affiliates who received it, with a way to contact each one.
• Withdraw your consent.
• Have it deleted. We'll delete it from our systems and tell everyone we shared it with to do the same. Copies in backups are deleted within six months.

To make a request, [go to Settings > Privacy, or use this form: link, or email address]. You don't need to create an account. We'll respond within 45 days. If we need more time, we'll tell you why, and we'll take no more than 45 additional days. It's free up to twice a year.

If we deny your request, you can appeal by [method]. We'll answer within 45 days. If we deny your appeal, you can complain to the Washington Attorney General at [current link] or the Nevada Attorney General at [current link].

Clause 5.7: Changes.

We won't collect, use, or share new categories of consumer health data, or use it for new purposes, without first telling you and getting your consent.

Words to avoid unless you've proved them: "never," "anonymous," "de-identified," "HIPAA compliant," "private," "secure," "discreet," "only accessed by your provider," "we don't sell your data."

Drafting notes.

• Required contents are in RCW 19.373.020(1)(a). The link requirement is in (1)(b), and "homepage" is defined in RCW 19.373.010(16) to include an app's platform or download page and an in-app link.
• The Washington attorney general's FAQ says the policy must be "a separate and distinct link" and "may not contain additional information not required under the My Health My Data Act." Don't paste this into a general privacy policy, and keep marketing language out of it.
• Clause 5.1's HIPAA carve-out reflects RCW 19.373.100(1)(a), which works at the level of data, not the company. Nevada's exemption is at the entity level, so a HIPAA-regulated company may be fully outside Nevada's law.
• Clause 5.4's processor sentence must be true. RCW 19.373.020(1)(e) makes it a violation to contract with a processor inconsistently with your policy.
• The word list comes from pleaded claims. See Count I of the FTC's complaint in FTC v. Hims & Hers, No. 3:26-cv-7871 (N.D. Cal.), still pending. Deception is 15 U.S.C. § 45(a).
• For general policy drafting, see Drafting and Maintaining a Privacy Policy: A Practical Guide and the Privacy Notice Toolkit: Policy Templates, Consent Flows, and Change Management Records.

Tool 6: Consent language

Purpose: Valid, separate consent to collect and to share. Owner: product and counsel. Timing: weeks 3 to 8. Test: every screen must actually control data flow, verified by Tool 3.

Form 6.1: Consent to collect (only where collection isn't necessary for the requested service).

Use your [category] for [purpose]?

[Company] would like to collect [specific categories, e.g., your symptom entries and medication list] so that we can [specific use, e.g., show you how your symptoms change when your medication changes]. This data stays with [Company] and our service providers. [If shared, say so with categories of recipients.]

You can withdraw at any time in [location]. If you do, we will stop collecting this data and delete what we have.

[Yes, collect this] [No, thanks]

Form 6.2: Consent to share (always its own screen).

Share your [category] with [category of recipient]?

With your permission, we'd share [specific categories] with [categories of recipients, e.g., university sleep researchers] so that they can [purpose]. They will [how it will be used]. You don't have to agree. [Product] works the same either way.

You can withdraw any time in [location]. We'll stop sharing and tell them about your withdrawal.

[Share] [Don't share]

Form 6.3: Precise location.

Use your exact location for [feature]?

We use your exact location only to [e.g., show pharmacies near you when you open this screen]. We don't keep it after [time]. We don't share it with advertisers.

[Allow] [Don't allow]

Form 6.4: New purpose.

We'd like to use your data in a new way.

We'd like to use [category] to [new purpose]. We haven't done this before and won't unless you agree. Your current use of [Product] doesn't change if you say no.

[Agree] [Don't agree]

Form 6.5: Withdrawal confirmation.

You've withdrawn consent for [activity]. We've stopped, and we've told [recipient categories]. You can [delete your data] or [change this] at any time.

Form 6.6: Consent ledger record.

user_or_device_id | consent_type (collect|share|location|new_purpose)
text_version_id   | screen_id | app_version
choice            | timestamp_utc | source_ip_retained? (Y/N)
withdrawn_at      | downstream_notified_at

Do not do this.

Drafting notes.

• Read the elements together: prior, clear affirmative act, specific purpose, categories, recipients, withdrawal. The definition is at RCW 19.373.010(6), and the content requirement at RCW 19.373.030(1)(c).
• Don't use consent to authorize ad-tech health data without counsel. The "sale" definition may independently require Tool 7, and FTC orders ban the practice for those who settled. See In re BetterHelp, Inc. Data Disclosure Cases, No. 23-cv-01033 (N.D. Cal. July 15, 2024), for class claims following such conduct.
• For wiretap exposure, consent must cover what is actually intercepted. In In re Meta Pixel Healthcare Litigation, No. 22-cv-03580 (N.D. Cal. Sept. 7, 2023), the court put the burden of showing consent on the party asserting it, so keep the ledger. California's CIPA needs all parties' consent. See 18 U.S.C. § 2511(2)(d) and Cal. Penal Code § 631.
• Location Form 6.3 assumes you've done Tool 11. No consent can authorize a Washington geofence in the listed uses, because the section has no consent exception.
• Design guidance is in Dark Patterns, Auto-Renewal, and the FTC Click-to-Cancel Rule.

Tool 7: Valid authorization to sell consumer health data

Purpose: The signed document RCW 19.373.070 requires before any sale. Owner: counsel. Timing: only if a sale has been approved at the executive level. Most companies should restructure instead.

First, screen. Is any of these true? If so, assume a possible "sale" and get advice: someone pays us for data; a vendor gets rights to use data for itself in exchange for a free or cheaper service; we receive data or audience access in return; we get a fee tied to users' health status or a referral.

Form.

AUTHORIZATION TO SELL YOUR CONSUMER HEALTH DATA

What we want to sell: [specific data, e.g., "your weekly average sleep duration and your insomnia severity score for the past 12 months"]

Who is selling it: [Company legal name, address, email, phone]

Who is buying it: [Purchaser legal name, address, email, phone]

Why: [Company] would sell this data to [Purchaser] for [purpose]. We'd gather it by [how]. [Purchaser] would use it to [how].

You don't have to sign. We won't refuse you goods or services or change them if you don't.

You can change your mind. You can revoke this at any time by [method]. Revoking won't undo a sale we've already made.

The buyer may share it again. Data sold under this authorization may be redisclosed by the buyer and may no longer be protected by Washington's My Health My Data Act.

This authorization expires on: [date one year from signing].

Signature: ______________________ Date: ____________

You'll receive a copy of this after you sign.

Administrative steps.

• Standalone document; not combined with terms, consent, or any other form.
• Provide a copy to the consumer.
• Seller and purchaser each retain for six years from signature or last effective date, whichever is later.
• Expiration calendar; no sale after expiry or revocation.
• Sale limited to what the document says.

Drafting notes.

• Elements are in RCW 19.373.070(2), defects in (3), copy in (4), retention in (5). A compound or conditioned authorization is invalid.
• "Revoking won't undo a sale we've already made" is our suggested clarity, and it should be checked against your program. The statute says the consumer may revoke at any time. Stop further sales the day you receive one.
• Nevada requires written authorization. Connecticut's § 42-526 requires consent to sell consumer health data. Maryland bars sale of sensitive data, so Maryland consumers should be excluded altogether. Check the current state of other states' bans, as several changed in 2026.
• In M&A, the sale exclusion in RCW 19.373.010(26)(b)(i) depends on the acquirer complying with the chapter. In bankruptcy, see 11 U.S.C. § 363(b). In Illinois, see Bridges v. Blackstone, Inc., 66 F.4th 687 (7th Cir. 2023).

Tool 8: Vendor clause bank and notice letter

Purpose: Make the processor label true, and satisfy the FTC rule's service provider notice. Owner: counsel and procurement. Timing: weeks 3 to 10, and every renewal.

Clause 8.1: Role and instructions.

Vendor processes Consumer Health Data only on Customer's behalf and only as described in Schedule A. Vendor shall not sell, share, or use Consumer Health Data for its own purposes, including advertising, cross-customer analytics, audience building, or training models for use outside Customer's account. If Vendor believes an instruction violates law, it will promptly tell Customer.

Clause 8.2: Assistance.

Vendor shall give Customer the technical and organizational assistance reasonably needed to meet its obligations under Consumer Health Data Laws, including responding to consumer requests within [10] days of notice.

Clause 8.3: Deletion on notice.

On notice of a consumer's deletion request, Vendor shall delete the relevant data from its systems within [30] days, including from backups within six months, and shall pass the request to its subprocessors. Vendor shall confirm completion in writing on request.

Clause 8.4: Subprocessors.

Vendor shall disclose subprocessors in advance, bind them to terms at least as protective, and remain liable for their acts. Customer may object within [30] days.

Clause 8.5: Security.

Vendor shall maintain administrative, technical, and physical safeguards appropriate to the sensitivity of Consumer Health Data, including access limited to those who need it, multifactor authentication, encryption in transit and at rest, and logging. [Attach schedule.]

Clause 8.6: Incident notice.

Vendor shall notify Customer's Designated Official at [name, title, email, phone] without unreasonable delay, and in any case within [72] hours after discovering any actual or reasonably suspected unauthorized acquisition, access, or disclosure of Consumer Health Data. Notice shall identify each affected individual, to the extent known, and shall be supplemented as more is learned. Vendor shall obtain acknowledgment of the notice from the Designated Official.

Clause 8.7: Evidence.

Vendor shall give Customer, on request, its current SOC 2 report or equivalent, and written confirmation of configuration settings that limit its use of data under Clause 8.1. Vendor shall not change defaults affecting data use without [30] days' notice.

Clause 8.8: Status.

Customer hereby notifies Vendor that Customer is a vendor of personal health records or PHR related entity subject to the Health Breach Notification Rule, 16 C.F.R. Part 318. Vendor acknowledges it may be a third party service provider under that rule.

Clause 8.9: Consequence of going outside instructions.

Vendor acknowledges that processing outside Customer's instructions may make Vendor a regulated entity for that data under applicable law. Vendor shall indemnify Customer for claims arising from such processing.

Clause 8.10: End of contract.

On termination, Vendor shall return or delete all Consumer Health Data within [30] days and certify completion.

Letter 8.11: Notice to existing service providers.

[Date]
To: [Vendor legal contact]
Re: Health Breach Notification Rule status and designated official

[Company] offers [product]. We are a [vendor of personal health records]
subject to the FTC's Health Breach Notification Rule, 16 C.F.R. Part 318.
If you access, maintain, retain, modify, record, store, destroy, or otherwise
hold, use, or disclose unsecured PHR identifiable health information as a
result of services for us, you may be a third party service provider under
that rule.

Please direct any breach notice to our designated official:
[name, title, email, phone]. Notice must be given without unreasonable delay
and no later than 60 calendar days after discovery, must identify each
affected customer of ours, and you must obtain acknowledgment that the notice
was received.

Please confirm receipt by replying to this letter.

SDK and platform questionnaire (send before adding any vendor):

1. What data does the default configuration collect? Attach a payload sample.
2. Can you use this data for your own purposes? Under which setting and clause?
3. Is event forwarding on by default?
4. Where is data stored, and how long is it retained?
5. Do you have a deletion API? What does it delete?
6. Will you sign terms limiting use to our instructions? If not, stop here.

Drafting notes.

• Processor contract requirements: RCW 19.373.060(1)(a). A processor going outside the contract becomes a regulated entity: (1)(c). Recipient deletion: RCW 19.373.040(1)(c)(ii).
• Clauses 8.6 and 8.8 and Letter 8.11 track 16 C.F.R. § 318.3(b) and § 318.4(a). Many companies have never sent this notice. Connecticut also requires a compliant processor contract: Conn. Gen. Stat. §§ 42-521, 42-526.
• For HIPAA streams, use a BAA meeting 45 C.F.R. § 164.504(e). A processor addendum is not a BAA.
• Vendors should know the exposure is real. See Frasco v. Flo Health, Inc., No. 21-cv-00757 (N.D. Cal. Sept. 23, 2024), on SDK providers and standing, and the jury's August 2025 verdict against Meta. Contrast the earlier dismissal of AppsFlyer in Frasco, June 6, 2022.
• Broader process is in Building a Vendor and Third-Party Risk Management Program.

Tool 9: Breach notification decision tree, memo, and letter

Purpose: Decide quickly and defensibly whether an event, including a voluntary disclosure, is reportable. Owner: counsel, with the executive sponsor deciding. Timing: prepare now; run within days of any finding.

Decision tree.

START: We learned that health-related data reached someone it should not have,
       or may have. Log date and time learned, and by whom. PRESERVE.
  |
  1. Is this data PHI held for a covered entity (business associate hat)?
     YES -> HIPAA path. Notify the covered entity under the BAA
            (45 C.F.R. 164.410; no later than 60 days, often sooner by contract).
            Continue at step 7 for any consumer-hat data.
     NO  -> go to 2.
  |
  2. Are we a vendor of personal health records or PHR related entity?
     (health service online + technical capacity for multiple sources)
     NO  -> Record why. Go to 7.
     YES -> go to 3.
  |
  3. Is the data PHR identifiable health information?
     (relates to health + identifies, or reasonably could identify)
     Device IDs, hashed emails, and app identity can count.
     NO  -> Record why. Go to 7.
     YES -> go to 4.
  |
  4. Is it unsecured? (not protected per HHS guidance as to this recipient)
     SECURED -> Record why. Go to 7.
     UNSECURED -> go to 5.
  |
  5. Was it acquired without the individual's authorization?
     Hacker, stolen laptop, or employee snooping: presumed, absent reliable
     evidence otherwise.
     Disclosure to vendor or ad platform: Check the consent ledger.
     Did this user specifically authorize this disclosure?
     YES for all -> Record why. Go to 7.
     NO or unclear -> go to 6.
  |
  6. BREACH under 16 C.F.R. Part 318 unless counsel documents otherwise.
     Discovery date = first day known or reasonably should have been known
     to any employee, officer, or agent (other than the wrongdoer).
     - Individuals: without unreasonable delay, max 60 calendar days.
     - 500+ people: FTC at the same time as individuals.
     - <500: annual log to FTC within 60 days after year end.
     - 500+ residents of a state: prominent media too.
     Keep proof. The burden is on us.
  |
  7. State law check, for each state with affected residents.
     Does the state's breach statute cover this data and this kind of event?
     Shorter clocks? AG notice? Washington: 30 days; AG if over 500.
  |
  8. Other tracks: contract notices, insurers, investors, app stores,
     payment partners. Tell recipients to delete. Fix the root cause.

Decision memo. Keep it privileged and short.

PRIVILEGED AND CONFIDENTIAL | ATTORNEY WORK PRODUCT
Event: [one sentence]
Date first known to anyone in the company: [date, person, role]
Date reasonably should have been known: [analysis]
60-day outer date: [date]

Facts: data elements; identifiers; recipient(s); dates; number of people;
states; how it stopped.
What the recipient could do with it, and what its contract says.
Consent facts: what users saw; what the ledger shows.

Analysis by regime:
  HBNR: PHR? identifiable? unsecured? unauthorized? Conclusion.
  HIPAA: any stream? Conclusion.
  State breach laws: list. Conclusion.
  MHMDA/other: rights and consent implications.

Decision: [notify / not notify], by [name], on [date]. Reasons.
Risks accepted. Follow-up items and owners.

Letter 9.1: Individual notice for an unauthorized disclosure.

Notice of a disclosure of your health information

What happened. Between [date] and [date], [Company] sent information about your use of [app] to [names of companies]. You did not authorize this. We discovered it on [date]. We stopped it on [date].

What information was involved. [The fact that you use [app]; your email address in hashed form; device identifier; specific events such as "[plain description]".]

What you can do. You can [adjust ad settings at those companies: links]; [request deletion here]; [review your account]. Watch out for messages that mention [app] and that you did not expect.

What we're doing. We removed the tools that sent the information. We asked those companies to delete it. [We reviewed other tools and changed our process for adding them.]

How to reach us. Toll-free [number]; email [address]; or in the app at [location].

Delivery rules. First-class mail, or email if the person has specified email as the primary method of contact (under the rule, "electronic mail" means email combined with a text, in-app message, or banner, and must be clear and conspicuous). Substitute notice if contact details are insufficient for ten or more people: conspicuous home page posting for 90 days, or major media, with a toll-free number active for at least 90 days.

Drafting notes.

• The "unauthorized disclosure" clause is in the definition of "breach of security" at 16 C.F.R. § 318.2. The FTC's compliance guide says a breach isn't limited to cybersecurity intrusions.
• Letter content tracks § 318.6, including "the full name or identity" of third parties that acquired the data if known, and a description that may include "the individual's use of a health-related mobile application" or a device identifier. Plain-language form and two contact methods are required.
• Timing is at § 318.4, discovery at § 318.3(c), and burden of proof at § 318.4(c). Delivery and substitute notice are at § 318.5. Submit to the FTC under the instructions on its website. There is a law enforcement delay at § 318.4(d).
• The September 2026 rescission withdrew the FTC's 2021 policy statement and left the amended rule in place. Don't cite the old statement.
• Penalties are civil penalties for a rule violation, 15 U.S.C. § 57a, with amounts adjusted annually. See 16 C.F.R. § 318.7. Check the current figure at 16 C.F.R. § 1.98. Preemption is in 42 U.S.C. § 17951.
• For HIPAA, the notification provision is 42 U.S.C. § 17932 and 45 C.F.R. §§ 164.400 to 164.414.
• An FTC or plaintiff's reader will compare this letter to your policy. Say what happened, plainly. For California consumers, a stolen database event now has a lower bar under J.M..
• General incident workflows are in the Data Breach and Incident Response Toolkit: From Detection to Notification.

Tool 10: Consumer rights procedures and scripts

Purpose: Answer access, withdrawal, deletion, and appeal requests on time. Owner: support lead, with an engineering contact. Timing: weeks 6 to 16.

Workflow and deadlines.

Script 10.1: Intake (phone or chat).

"Thanks for reaching out. You don't have to use any special words or create an account. I'll log this now. Could I confirm [the email on your account / the device ID in Settings] so we can make sure it's you? You'll hear from us within 45 days, and usually sooner."

Letter 10.2: Access response.

We confirm that we [collect / share / do not sell] consumer health data about you. Attached is a copy. Here are the third parties and affiliates who received it, with a contact for each:

| Name | What they received | When | Contact |

You can ask us to delete this data or withdraw your consent at [location].

Letter 10.3: Deletion confirmation.

We deleted your consumer health data from our active systems on [date]. Copies in backups will be gone by [date, no later than six months after we authenticated your request]. We told these recipients to delete it too: [list]. We kept [only what's excepted, and why].

Letter 10.4: Authentication problem.

We couldn't confirm that this request came from you, using [what we tried]. Please [send what's needed]. We need this only to protect your information, and we'll use it only for that purpose.

Letter 10.5: Denial.

We didn't act on your request because [specific reason]. You can appeal by [method, similar to how you made this request]. We'll give you a written answer within 45 days.

Letter 10.6: Appeal denial.

We reviewed your appeal and [explanation of reasons]. If you disagree, you can file a complaint with the Washington Attorney General at [current link].

Letter 10.7: Deletion request to a recipient.

We shared consumer health data about [identifier] with you on or about [dates]. The consumer has asked for deletion. Under RCW 19.373.040, you must delete this from your records, including from your network and backup systems, subject to the same requirements. Please confirm by [date].

Drafting notes.

• Don't charge unless you've met the burden of showing that a request is "manifestly unfounded, excessive, or repetitive." Up to two free responses a year. RCW 19.373.040(1)(f).
• Exemptions are narrow. RCW 19.373.100(3)-(4) allow processing for security and fraud purposes and put the burden on you. There is no general "we need it" exception to deletion in the text. Think about what you truly must keep under other laws, and say so in Letter 10.3.
• For non-account visitors, authenticate against what you have, such as a cookie ID. Log what you did.
• If you are a HIPAA business associate for some data, route those requests to the covered entity, and say so.
• See also the Data Subject Rights Request Handling Checklist: A Practical Checklist.

Tool 11: Geofence decision matrix and agency instruction

Purpose: Stop prohibited location uses before a campaign runs. Owner: growth lead. Timing: now, then at each campaign and vendor change.

Scenarios.

Instruction 11.1: To agencies and media buyers.

You may not, on our behalf, use any geofence, radius targeting, location-based audience, or proximity trigger within 2,000 feet of any hospital, clinic, doctor's or dentist's office, pharmacy, mental health facility, reproductive or sexual health facility, addiction treatment facility, or similar place, or use any audience built from visits to such places. You may not buy or use a health-related location or inferred-health audience for us. Tell us at once if you learn of any such use. This applies to all campaigns and states unless we approve an exception in writing.

Drafting notes.

• Text: RCW 19.373.080, RCW 19.373.010(14), (15). The section reaches "any person," so an agency's act doesn't insulate you, and it has no consent exception. Connecticut: Conn. Gen. Stat. § 42-526(a)(1)(C). Nevada: S.B. 370 (commonly read to apply even with consent). Maryland's act has a similar provision.
• We set 2,000 feet for all states because it is simpler.
• For brokers, see the FTC's May 2026 stipulated order in the Kochava case, which requires a sensitive location program and supplier assessment, and the decision in FTC v. Kochava, Inc., No. 2:22-cv-00377 (D. Idaho Feb. 3, 2024). Also see In re Amazon Ads SDK Litigation, No. 2:25-cv-00252 (W.D. Wash.), for background location collection through SDKs, and People-Search Toolkit: Opt-Out Letters, Claim Evaluation Worksheets, and Defense Frameworks for broker-side issues.

Tool 12: Legal process intake sheet

Purpose: Prevent an unreviewed production, especially for reproductive and gender-affirming data. Owner: counsel. Timing: adopt by week 6; use for each demand. Support staff should know to send anything that looks like a legal demand directly to counsel, without replying.

Received: [date, channel, by whom]      Deadline stated: [date]
Issuer: [court / agency / private party; state]
Type: [subpoena / warrant / court order / civil discovery / informal request]
User(s): [identifier]; state of residence: [state]
Data requested: [list]    Do we hold it?  [Y/N, per data map]

Checks:
[ ] Is the issuer's authority valid over us? Where are we served?
[ ] Does it involve reproductive, gender-affirming, mental health, SUD,
    or genetic data?
[ ] Does our state's shield law, or the user's, apply?
[ ] Is this PHI? (HIPAA 45 C.F.R. 164.512 path; covered entity's role)
[ ] Part 2 record? (42 C.F.R. Part 2 court order requirements)
[ ] Does MHMDA permit disclosure? (RCW 19.373.100 has no general process
    exception; analyze specifically)
[ ] Is a gag order in place? If not, notify the user per policy.
[ ] What did our public statements promise?

Response: [produce / narrow / object / move to quash]
Decided by: [counsel], [date]. Produced: [what, when]. Log retained.

Drafting notes.

• Reasoning: RCW 19.373.100(3) preserves processing related to activity illegal under Washington or federal law. It doesn't name subpoenas or activity illegal only elsewhere. Have counsel analyze each one.
• Purl v. U.S. Department of Health & Human Services, No. 2:24-cv-228 (N.D. Tex. June 18, 2025), vacated most of the 2024 HIPAA reproductive rule, including attestations. The context is Dobbs v. Jackson Women's Health Organization, 597 U.S. 215 (2022). For government access to location records, see Carpenter v. United States, 585 U.S. 296 (2018).
• Federal confidentiality for substance use disorder records is at 42 U.S.C. § 290dd-2 and 42 C.F.R. Part 2.
• For objection forms and notification letters, use the Government Data Demand Toolkit: Legal Process Review, Objections, and Notification.

Quick reference: clocks and numbers

Litigation file starter

If a claim comes in, put these into one privileged folder at once: Tools 1 to 4 as they stood on the day, consent ledger samples and the versions of each consent screen, the historical tag manager versions, ad platform exports, the policy's version history, marketing copy with dates, and a chronology of who chose each tool and what they understood. Courts are looking at those facts: Sweat v. Houston Methodist Hospital, No. 4:24-cv-00775 (S.D. Tex. Sept. 22, 2025), turned on testimony about what marketers understood. Class and standing arguments turn on technical uniformity and what specifically was sent, per Doe v. Adventist Health System/West, No. B344951 (Cal. Ct. App. July 24, 2026), Santoro v. Tower Health, No. 24-3173 (3d Cir. Aug. 28, 2026), and Rand v. Eyemart Express, L.L.C., No. 25-10784 (5th Cir. Oct. 23, 2026). Defenses on the arbitration side depend on how users accepted terms, as in Neblock v. Gene by Gene, Ltd., No. 24 CV 12118 (N.D. Ill. May 19, 2026). For standing allegations and motions, see the Justiciability Toolkit: Standing Allegations, Rule 12(b)(1) Motions, and Mootness Briefing.

This toolkit is general information and is not legal advice for a specific situation.

Related Documents

Related Articles

• Consumer Health Data Outside HIPAA: My Health My Data, the FTC, and the Apps That Know Too Much: the law behind these forms.
• Data Breach Response and Notification: The Fifty-State Patchwork, Regulators, and Litigation: the state law steps in Tool 9.

Related Guides

• Bringing a Health App Into Compliance With Consumer Health Data Laws: A Practical Guide: how and when to use each tool.
• Auditing Your Website Tracking Stack: A Practical Guide: the web side of Tool 3.

Related Checklists

• Consumer Health Data Compliance Checklist: A Practical Checklist: review and sign-off.
• Privacy Policy Drafting and Review Checklist: A Practical Checklist: for the general policy that sits alongside Tool 5.

Related Toolkits

• Adtech Privacy Toolkit: Tag Inventories, Consent Records, and Litigation Defense: more on tags and consent records.
• Biometric Privacy Toolkit: Retention Policies, Consent Forms, and Vendor Terms: related forms for biometric data, which Washington treats as consumer health data.
• People-Search Toolkit: Opt-Out Letters, Claim Evaluation Worksheets, and Defense Frameworks: when your data supply chain reaches brokers.
• Computer Access Dispute Toolkit: Access Revocation Letters, Loss Worksheets, and Pleading Outlines: revocation letters when a former vendor or employee still holds access to health data.