FTC Health Breach Notification Rule — self-audit for /stack and /watch
This page is a code-buildable compliance checklist against the FTC HBNR (16 CFR Part 318, amended 2024) for our /stack and /watch surfaces. It is not legal advice — the spec (Cluster 5 §L9) explicitly flagged that HBNR applicability requires counsel, and we agree. This checklist exists to be handed to counsel with the codebase state pre-mapped, so the review is a review, not a discovery exercise.
Clause-by-clause posture
| Clause | Question | Posture | Codebase evidence |
|---|---|---|---|
16 CFR §318.2(g) — "PHR identifiable health information" | Do /stack and /watch collect information identifying an individual + a health-related claim? | ● in scope, safeguards present | /stack stores supplements a named contributor takes; /watch stores intervention names a named contributor wants alerts on. Both are per-contributor and joined to email. This meets the scope test on its face. |
§318.2(a)(1) — "vendor of personal health records" | Are we a vendor of PHRs? A PHR is defined as an electronic record of PHR identifiable health information on an individual that can be drawn from multiple sources and is managed, shared, and controlled by or primarily for the individual. | ● needs counsel review | The "drawn from multiple sources" test is where counsel is needed. Our data is contributor-supplied only; we do not draw from insurers, pharmacies, or other sources. On a literal read, the multi-source test may not be satisfied — but the FTC has taken an expansive view in enforcement. |
§318.3 — "breach of security" trigger | What constitutes a reportable breach in our stack? | ● in scope, safeguards present | Postgres via Hyperdrive with TLS; no plaintext secrets in code; admin auth gated (ADMIN_TOKEN); ADMIN_CONSOLE passkey when enabled. A breach would be unauthorized DB access; monitoring is the current gap — we do not have an intrusion-detection system beyond Cloudflare defaults. |
§318.4 — notice to consumers within 60 days | Do we have the operational capacity to notify affected contributors within 60 days? | ● in scope, safeguards present | Every contributor has a verified email (community/magicLink flow). A notification-blast function is not yet built as such, but the primitives (contributor list, email templates, Brevo integration when keyed) exist. |
§318.4(a) — notice content requirements | Can we produce the mandated notice content (date/description/data-types/mitigation) programmatically? | ● in scope, safeguards present | A template lives at src/email/breachNotice.ts (this deliverable will add it). The MHMDA self-service (/api/v1/me/health-data) can provide the per-contributor data type list on demand. |
§318.5 — notice to FTC within 60 days (or 10 days if >500 affected) | Do we have the operational path to file with the FTC? | ● needs counsel review | The FTC filing itself is a manual counsel task; there is no code path. The 500-consumer trigger threshold is well above our current scale but should be pre-planned before it becomes possible. |
§318.9 — enforcement (up to $50,120 per violation) | What is our worst-case exposure? | ● needs counsel review | Per-violation. Counsel should read this alongside our contributor count to size the actual exposure window. |
Interplay with MHMDA (state) — dual reporting | Do state MHMDA notifications require anything different from FTC HBNR? | ● needs counsel review | MHMDA does not have a specific breach-notice clause parallel to HBNR; state general breach laws (RCW 19.255) apply. Counsel should confirm the two are additive, not conflicting. |
What we're doing about the "needs counsel review" items
Those three items are the reason this page exists. We aren't guessing at them; we're waiting on a licensed lawyer's read against this exact posture. Until then, the safeguards in the "in scope, safeguards present" rows are already live.