GDPR, CCPA, HIPAA or the FTC rule: scope privacy and health-data obligations before choosing controls

Privacy scope begins with processing facts: which data, about whom, collected where, for what purpose, under whose decisions, shared with whom, retained how long and protected by which controls. A table of database columns is useful but incomplete if a support export, analytics stream or backup copy is omitted. Roles can differ by purpose: a service may process customer records on instructions while determining its own purposes for billing or marketing. A vendor label does not settle every relationship.

The fictional Fern service has consumer wellness tracking and a separate clinic integration. Both contain health-related fields, but the relationship with a healthcare entity matters for HIPAA analysis. A random account identifier remains linkable when Fern holds the lookup table; calling the records anonymous does not remove identifiability (/domains/identity-crypto/privacy/tokenization-privacy-engineering/ compares the transformations). Start with the full data-flow map and preserve uncertain facts for the appropriate privacy/legal reviewer. Engineers can demonstrate actual collection, deletion and access behavior without pretending that a technical test alone determines legal scope.

The European Commission explains that GDPR can apply through an EU establishment or through offering goods or services to, or monitoring people in, the EU from outside it. Geography of the server alone does not determine applicability. Encryption or pseudonymization does not make re-identifiable data anonymous. Health data is special category data: Article 9 prohibits processing it unless a condition in Article 9(2), such as explicit consent, applies. Once scope is established, lawful purpose, minimization, rights handling and security require their own analysis; one consent checkbox does not resolve every processing purpose. The engineering side of Articles 25, 32 and 35, from defaults to DPIA screening and erasure, is in /frameworks/gdpr-privacy-by-design-engineering/.

For California, use the current CCPA statute, regulations and threshold notice. CPPA lists regulations effective 1 January 2026 and a gross-revenue threshold of $26,625,000 effective 1 January 2025. That figure is one criterion within the legal definition, not a universal exemption for every smaller entity. Other criteria, relationships and data-specific exclusions require review. The fixture deliberately supplies revenue sufficient for arithmetic but omits some legal facts. A useful engineer reports the threshold comparison and missing facts separately instead of declaring the whole organization covered or exempt.

Regulations in force from 1 January 2026 add three duties that need engineering evidence. Each has its own trigger, so record which ones apply and why.

• Cybersecurity audits: an independent audit of the security program for a business that earns half its revenue from selling or sharing personal information, or that meets the revenue threshold and in the previous year processed the personal information of 250,000 or more consumers or households, or the sensitive personal information of 50,000 or more consumers. The first report is due on 1 April 2028 if 2026 revenue was above $100 million, 1 April 2029 if 2027 revenue was $50–100 million, and 1 April 2030 if 2028 revenue was below $50 million.
• Risk assessments: processing that began before the regulations and continues must be assessed by 31 December 2027, with summary information submitted to the CPPA by 1 April 2028.
• Automated decision-making technology used for significant decisions: notice, opt-out and access duties from 1 January 2027.

HHS describes the HIPAA Security Rule as protecting electronic protected health information handled by covered entities and business associates. A direct-to-consumer wellness application is not automatically a covered entity merely because it stores symptoms. A vendor acting for a clinic may have a business-associate relationship, depending on the actual function and facts. A signed contract can document responsibilities, but lack of a contract does not establish that a legally defined role is absent.

The Security Rule changes HHS proposed on 6 January 2025 were still a proposed rule on 10 October 2026. Keep proposal tracking separate from the current rule and any subsequently adopted requirements; do not present proposed technical details as already binding. For the clinic integration, engineering should identify who can read records, service accounts, logs, backups and third parties, and supply access and recovery evidence. A flow outside HIPAA can still carry the duties described in the next section; the scope record should never substitute “no HIPAA” for “no responsibility”.

A consumer wellness app such as Fern’s flow F1 is usually outside HIPAA, but not outside health-privacy law. Three regimes commonly apply to the same data.

• The FTC Health Breach Notification Rule covers vendors of personal health records and related entities that HIPAA does not, including health apps that draw data from several sources. Since the amendments in force from 29 July 2024, sharing health data without authorization counts as a breach, not only a hack. Notify affected people within 60 calendar days of discovery, the FTC at the same time when 500 or more are affected, and prominent media when 500 or more residents of one state are.
• Washington’s My Health My Data Act, in force for most regulated entities since 31 March 2024 and for small businesses since 30 June 2024, requires consent to collect or share consumer health data, including health inferences drawn from other data, and a signed authorization to sell it.
• For people in the EU, GDPR treats the same data as special category data under Article 9 and requires a breach notice to the supervisory authority within 72 hours under Article 33.

Translate a selected commitment into observable behavior. If a reviewed retention policy says delete active account data after an approved request and expire backups within a stated period, test all linked stores and the restore path, as in /domains/identity-crypto/privacy/data-minimization-retention/. A database row deletion does not prove that search indexes, analytics exports and logs were deleted. A backup exception should name access controls, retention and how restored data is re-deleted; indefinite hidden copies contradict a blanket deletion promise.

The fixture's policy uses a 30-day backup expiry as a fictional company commitment, not a universal GDPR/CCPA/HIPAA deadline. The supplied deletion test removes live rows but leaves a named analytics export and restores deleted data from a backup without a tombstone. That test fails the stated technical promise regardless of the eventual legal classification. Record both findings: behavior failure owned by engineering, and applicability/role questions owned by privacy/legal review. This preserves progress without letting unresolved law become a reason to ignore a demonstrated product defect.

Record scope per flow as data: the purpose, the data, whether it includes health data, each party's role, the regimes considered with their status, and the open questions with an owner and a due date. An undetermined role or a regime under review is an honest state, as long as someone owns the question; what the record must not do is leave a gap that reads as “no obligation”.

{
  "product": "Juniper sleep coaching (fictional)",
  "reviewed_on": "2026-10-10",
  "flows": [
    {
      "id": "S1",
      "purpose": "Sleep diary and coaching for consumers in the EU and US",
      "data": [
        "email",
        "sleep diary",
        "medication notes"
      ],
      "health_data": true,
      "roles": {
        "Juniper": "controller"
      },
      "regimes": {
        "GDPR": "applies: offers the service to people in the EU",
        "HIPAA": "not applicable: no covered entity or business associate relationship",
        "FTC Health Breach Notification Rule": "under review"
      },
      "open_questions": [
        {
          "question": "Which Art. 9(2) condition covers medication notes?",
          "owner": "privacy counsel",
          "due": "2026-10-31"
        }
      ]
    },
    {
      "id": "S2",
      "purpose": "Sleep reports for an employer wellness program",
      "data": [
        "employee ID",
        "weekly sleep score"
      ],
      "health_data": true,
      "roles": {
        "Juniper": "undetermined",
        "Employer": "undetermined"
      },
      "regimes": {
        "GDPR": "under review"
      },
      "open_questions": [
        {
          "question": "Controller or processor for the employer reports?",
          "owner": "privacy counsel",
          "due": "2026-11-15"
        }
      ]
    }
  ]
}

It rejects unknown role names, undecided roles or regimes with no open question, health data with no regime considered, and questions without an owner or past their due date. Run it when the record changes and on a schedule, so stale questions surface before a launch rather than after.

"""Keep privacy scope decisions explicit: every role, regime and open question has an owner.

Usage: python3 check_scope.py processing-scope.json
"""

import json
import sys
from datetime import date

ROLES = {"controller", "joint controller", "processor", "covered entity", "business associate",
         "service provider", "third party", "undetermined"}

with open(sys.argv[1], encoding="utf-8") as f:
    scope = json.load(f)
today = date.fromisoformat(scope["reviewed_on"])

problems = []
for flow in scope["flows"]:
    fid = flow["id"]
    for party, role in flow["roles"].items():
        if role not in ROLES:
            problems.append(f"{fid}: {party} has unknown role {role!r}")
    undecided = [p for p, r in flow["roles"].items() if r == "undetermined"]
    undecided += [r for r, v in flow["regimes"].items() if v == "under review"]
    if undecided and not flow["open_questions"]:
        problems.append(f"{fid}: {', '.join(undecided)} undecided with no open question")
    if flow["health_data"] and not flow["regimes"]:
        problems.append(f"{fid}: health data with no regime considered")
    for q in flow["open_questions"]:
        if not q.get("owner") or date.fromisoformat(q["due"]) < today:
            problems.append(f"{fid}: question without an owner or past due: {q['question']}")

print("\n".join(problems) or f"{len(scope['flows'])} flows: every open point has an owner and date")
sys.exit(1 if problems else 0)

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. European Commission: application of the GDPR
2. Regulation (EU) 2016/679 (GDPR), EUR-Lex. OJ L 119, 4 May 2016.
3. CPPA: CCPA updates, cybersecurity audit, risk assessment, ADMT and insurance regulations. Approved 22 September 2025; effective 1 January 2026.
4. CPPA: updated CCPA monetary thresholds. Effective 1 January 2025.
5. HHS: The HIPAA Security Rule and its rulemaking history
6. 45 CFR Part 164 Subpart D, breach notification (CFR annual edition, via govinfo)
7. 16 CFR Part 318, Health Breach Notification Rule (CFR annual edition, via govinfo)
8. Federal Register: Health Breach Notification Rule amendments (via govinfo). 89 FR 47028, published 30 May 2024; effective 29 July 2024.
9. Washington State Attorney General: My Health My Data Act

Reference information

Tags

Privacy engineeringRegulation

SDLC phase

PlanningDesignSecurity program

Role

Security leaders

Download this guide as Markdown

Continue exploring