Privacy, security & data responsibilitiesModule 05 · Founders, governance & business assets
IGNITE EXTENDED / LESSON 28
Privacy, security & data responsibilities
How can a company understand what it collects and what responsibility follows?
A data-life-cycle map and a privacy/security review brief.
1
28 / OpeningPrivacy, security & data responsibilities
The decision and the learning goals
Trace a data flow through a product and its vendors
Identify unnecessary collection or unclear control
Prepare questions about rights, security and incident responsibilities
90-minute workshopOpening 5 minConcepts and original examples 35 minPractice 25 minDebrief 15 minReview 10 min
2
28 / TheoryPrivacy, security & data responsibilities
A data map connects purpose, information and responsibility
A useful data map records what information the product collects, whose information it concerns, why it is needed and where it goes. Include vendors, copies, access and retention. This reveals obligations that an architecture diagram focused only on servers can miss.
Begin with the purpose rather than a list of everything technically collectable. Each data element should have an explainable connection to a product or operational need. New uses and new recipients require a fresh review of that connection and the applicable responsibilities.
3
28 / TheoryPrivacy, security & data responsibilities
Privacy and security solve related but different problems
Security concerns protection against events such as unauthorized access, loss or misuse. Privacy concerns appropriate collection and use in relation to people and applicable obligations. A technically secure database can still contain information collected without a justified purpose.
Consider both in product design. Restrict access, protect copies and prepare incident processes, while also examining minimization, transparency and retention. The historical privacy slides are a starting point for questions. Current requirements depend on jurisdiction, context and the people whose data is involved.
4
28 / TheoryPrivacy, security & data responsibilities
A data responsibility begins with a purpose
State why the information is needed.
Identify which people the information concerns.
Trace collection, use, storage, sharing and deletion.
Separate a useful feature from an unlimited reason to collect data.
5
28 / TheoryPrivacy, security & data responsibilities
The data life cycle
Map purposes, access and responsibilities at each stage, including vendors and copies.
6
28 / TheoryPrivacy, security & data responsibilities
Privacy and security
Privacy examines purposes, expectations and permitted handling of personal data. Security examines protection against unauthorized access, loss or alteration. A system needs both.
Privacy questions
Which personal information should be processed, for what purpose, under what conditions and with what control?
Security questions
How is information protected against inappropriate access, alteration, loss or other threats?
Worked application
Illustrative application: encrypting a customer database protects it in some respects but does not explain why an unnecessary field is collected or shared. Conversely, a carefully limited collection purpose does not prevent a poorly controlled administrator account from exposing the records.
Map the purpose and data flow, then examine access, retention, vendors and operational responsibilities throughout that flow.
7
28 / TheoryPrivacy, security & data responsibilities
Data minimization is a design decision
Identify the information necessary for the specified purpose.
Consider less precise data, shorter retention or a local calculation.
Remove collection that has no clear justified use.
Revisit the decision when a purpose or product changes.
8
28 / Source insightPrivacy, security & data responsibilities
Data protection and privacy: personal data, security, and clarity and control
Defines personal data as any data that can identify or distinguish a person, varying by country; describes security as appropriate technical and organizational measures that vary by data type; and lists what people expect clarity and control over: what you collect, how you use it, where you store it and who you share it with. The EU, UK, Brazil and California flags signal that more regimes are coming.
The four questions in the bottom box are the columns of a data map. For Relay, a phone number plus 'your clinic has an opening' is health information about an identifiable patient, so the definition is met before any diagnosis appears.
9
28 / Source insightPrivacy, security & data responsibilities
Why privacy matters: regulators, customers and trust
Regulators care (GDPR with fines of up to 4% of global turnover, HIPAA for health data, FERPA for student data, the FTC and state attorneys general, California law); customers care because when you process data they control, they will diligence your practices and require contract terms; and trust in the brand depends on privacy and security.
The middle box describes Relay exactly: clinics are the HIPAA covered entities and Relay processes their patients' data, so every clinic will send a security questionnaire and require a Business Associate Agreement before go-live. Hospital outpatient departments add longer security reviews.
10
28 / TheoryPrivacy, security & data responsibilities
Minimization changes the product design
Minimization can concern the amount, precision, duration and location of the data. A feature may work with a broad age range instead of a birth date, a local calculation instead of central storage or short-lived data instead of indefinite retention.
Evaluate the effect on usefulness alongside the reduction in exposure. The goal is a specific design decision supported by the purpose. Document why the retained information remains necessary and how deletion works across logs, backups and vendors.
11
28 / TheoryPrivacy, security & data responsibilities
A vendor relationship extends the operating system
Sending data to a vendor creates dependencies on that vendor’s practices and on the agreement governing the service. The team needs to understand access, onward use, location, deletion and incident handling.
Assign responsibility for actions the product promises to people. A notice is ineffective if no process can locate or delete relevant records. Test the workflow across systems and make sure product changes trigger a review. The source’s “privacy by design” discussion places these questions during development rather than after launch.
12
28 / TheoryPrivacy, security & data responsibilities
A practical data map
Item
Record
Information
What is collected or derived?
Purpose
Why is it used?
Location and recipients
Where does it go, including vendors?
Access and retention
Who can use it, and for how long?
User and incident processes
How are requests and problems handled?
13
28 / TheoryPrivacy, security & data responsibilities
A vendor is part of the system
What will the vendor do with the information?
Where are data and copies kept?
How do access, deletion and export work?
Who is responsible for handling an incident or a request?
14
28 / TheoryPrivacy, security & data responsibilities
A notice and a working process
A public statement describes how the organization says it handles data. A working process determines whether the organization can consistently deliver that behavior.
Notice
Explains relevant information to people.
Working process
Implements the promised collection, controls, security, retention and response. A notice does not perform those actions by itself.
Worked application
Illustrative application: a notice promises removal after an account closes, but exports remain on shared drives and the vendor retains a copy. The design task is to identify those copies, responsibilities, rules and exceptions and verify the process across them.
Check the implementation behind the promise. Wording alone does not make a deletion, access or incident workflow function.
15
28 / TheoryPrivacy, security & data responsibilities
Design for the whole life cycle
A data promise must hold throughout the system, including vendors and copies. Follow an illustrative customer-support record from collection to deletion.
01
Collect
Identify the purpose and the minimum fields required. If a support issue can be resolved with an order reference, explain why a full identity document would be needed before collecting one.
02
Use & access
Map which people and systems need which data for that purpose. Restrict access accordingly and record what happens when a person changes roles or leaves.
03
Share & retain
Trace vendor transfers, exports, logs and backups. Define responsibilities and the period for which each copy is needed. A record deleted in one screen can remain elsewhere.
04
Correct & remove
Design the operational process for relevant requests and deletion rules. Check how exceptions and recovery copies are handled, and verify that actual system behavior matches the promise.
Privacy concerns purpose and permitted handling; security concerns protection. Both require a working process across this life cycle.
16
28 / Deep divePrivacy, security & data responsibilities
Relay's PHI data map
Each element earns its place by purpose, or it is cut.
The map follows the data life cycle for Relay Scheduler. The right-hand column is where most findings sit: retention and vendor coverage, not the main database.
Retention periods are an illustrative policy. HIPAA status, BAA scope and retention rules depend on current law, the clinics' agreements and review by qualified counsel.
Data element
Purpose
Minimum needed
Recipients and vendors
Retention and BAA status
Patient name
Match the waitlist entry to the clinic record
Stored; never placed in SMS or LLM prompts
Relay app, cloud host
Life of the clinic contract; cloud host BAA
Mobile number
Send slot offers; receive replies
Required
SMS provider, cloud host
Delete 30 days after the patient leaves the waitlist (illustrative); SMS provider BAA
Open slot time and clinic
Content of the offer
Time and 'your clinic' only; no therapist or visit reason
SMS provider, patient's phone
Message logs 12 months (illustrative)
Patient reply text
Interpret acceptance or reschedule
Reply text only, stripped of identifiers
LLM API
Vendor retention at the minimum available; LLM BAA for this configuration; no training
Acceptance history
Prediction model features
Aggregated features, not raw messages
Relay data store
24 months, then de-identified (illustrative); use limited by clinic BAAs
EHR appointment data
Detect cancellations; book confirmed slots
Appointment slots and waitlist flags; no clinical notes
ClinicOS API, cloud host
Sync only what booking requires; ClinicOS terms plus clinic BAA
17
28 / Source insightPrivacy, security & data responsibilities
Watch out for it: security incidents and cloud vendors
Incident readiness means knowing an incident happened (monitoring), knowing what to do (a runbook) and knowing who to tell within a short window (24 to 72 hours). For cloud services it asks about the vendor's security, whether it uses your data for its own purposes, how you get data back, where it is kept and what happens if governments request it.
The 24-to-72-hour window reflects GDPR's 72-hour regulator notice and contract terms. Under HIPAA, a business associate must notify the clinic without unreasonable delay and no later than 60 days after discovery, and BAAs often set shorter periods. The vendor questions apply directly to Relay's SMS gateway, cloud host and LLM provider.
18
28 / Source insightPrivacy, security & data responsibilities
Privacy please: legal bases, data-subject rights and design for deletion
Personal data is held about both employees and customers. The page lists GDPR-style legal bases (consent, contractual necessity, legitimate interest with notice and opt-out), key data-subject rights (access, objection and restriction, correction and erasure, portability, limits on automated decisions) and privacy by design, by default and by documentation.
These are EU-style concepts. For PHI that Relay handles as a business associate, HIPAA's rules on permitted uses and the BAA govern instead, and patients exercise access and amendment rights through the clinic. The design principle still applies: build deletion and minimal use from the start.
19
28 / Source insightPrivacy, security & data responsibilities
Privacy by design: minimization, access control and documentation
A checklist: data minimization (do you need all of it?), access control (only those who need it, with security and training), privacy by default, clear explanation of collection and use with ways to exercise rights, user controls such as opting out and restricting processing, and documentation in a GDPR Article 30 record of processing activities.
Map each item to a Relay control: minimum-necessary SMS content, role-based access to the patient list, opt-out handling that honors a STOP reply, and a written inventory of where PHI flows. The documentation habit is what lets Relay answer a clinic's security questionnaire in days rather than weeks.
20
28 / ApplicationPrivacy, security & data responsibilities
A useful feature with unnecessary data
A fictional appointment service needs a contact channel and an available time. Its first design also collects exact location continuously and retains detailed usage logs forever, without a stated need. A vendor can reuse the logs under unclear terms.
What should change before the service relies on this design?
21
28 / Current practicePrivacy, security & data responsibilities
Current practice: health data, AI vendors and new state rules
HIPAA Security Rule overhaul pending
HHS proposed major Security Rule changes on January 6, 2025: mandatory encryption and MFA, asset inventories and network maps, regular penetration tests and vulnerability scans, and written verification of business associates' safeguards at least every 12 months. Final action is now projected for July 2027, but clinics and investors already ask for these controls.
Risk analysis drives enforcement
With risk analysis at the center of its 2025 enforcement, including its Risk Analysis Initiative, OCR announced ten resolution agreements in the first five months of 2025, each citing failure to conduct an enterprise-wide risk analysis, with penalties from $25,000 to $3 million and corrective action plans often lasting several years. A documented, enterprise-wide risk analysis that includes AI vendors is the first artifact to produce.
AI vendors sign BAAs for specific configurations
OpenAI states API data is not used for training by default and that it can sign a BAA; Anthropic offers a BAA for the Claude API with a HIPAA configuration enabled. Coverage is feature-specific, so the BAA must match what Relay actually calls.
Texas adds AI and EHR rules
Texas SB 1188 (effective September 1, 2025) requires practitioners who use AI for diagnosis or treatment based on medical records to disclose it, and requires covered entities to keep electronic health records physically in the United States from January 1, 2026. TRAIGA (HB 149), effective January 1, 2026, requires health care providers to disclose AI use in a patient's care. Relay Scheduler handles scheduling rather than diagnosis, but clinics will ask where data is stored and whether patients must be told they are texting an AI.
Texting consent and the EU AI Act
Since April 11, 2025, FCC rules let consumers revoke text consent by any reasonable means, including replying STOP, honored within 10 business days; the broader 'revoke all' provision is waived until January 31, 2027. If Relay ever serves EU patients, the AI Act's duty to tell people they are interacting with an AI applies from August 2, 2026. Texas's general privacy law exempts HIPAA business associates and PHI. Application to Relay depends on current law and the facts and needs legal review.
28 / PracticePrivacy, security & data responsibilities
Redesign a small data flow
Use the appointment-service packet. The stated purpose is to offer available appointments and send reminders; no routing feature exists.
Your task
Map the minimum data for the purpose, identify the vendor question and define retention, access and deletion questions for review.
23
28 / DebriefPrivacy, security & data responsibilities
Worked answer and reasoning
Separate appointment contact and timing information from unexplained continuous location collection.
Ask whether the vendor can reuse data and how access, export, deletion and incidents are handled.
Define a practical retention and control process instead of relying on a generic privacy notice.
24
28 / Venture stepPrivacy, security & data responsibilities
Venture step: Relay's PHI data map and HIPAA review brief
Relay · venture step 28
Month 20, after the pivot. Relay Scheduler sends patient replies to a third-party LLM API to interpret 'can't do 3, anything after 5?' and propose slots. Relay stores names, mobile numbers, appointment times, therapist names and acceptance history for about 120 clinic locations (illustrative). Clinic owners want texts to say the therapist and the reason for the visit to raise acceptance. An earlier near-miss (month 11, Lesson 35): a test message containing a patient's full name went to the wrong number. Northpoint PT's security team has sent a 200-question review (illustrative).
Your task
Produce a data map covering collect, use, store, share and retain/delete for each PHI element, with the minimum needed, recipients and vendors, retention period and BAA status. Add a one-page brief: Relay's HIPAA role, three design changes, vendor requirements and the incident plan.
25
28 / Venture stepPrivacy, security & data responsibilities
Venture step: worked reasoning
Role: Relay creates, receives, maintains and transmits PHI on behalf of clinics, so it is a business associate. It needs a BAA with each clinic and must have BAAs with its own subcontractors that handle PHI (cloud host, SMS provider, LLM API), and it may use PHI only as its BAAs permit.
Minimize the SMS: send 'A 3:30pm slot opened at your clinic tomorrow. Reply YES to book,' with no full name, therapist, diagnosis or visit reason. Decline the clinic's request to add the visit reason: it raises the harm of every misdirected text, and texts sit on lock screens.
LLM path: send only the reply text and candidate slots, with no name, phone number or chart data, under a vendor BAA covering the exact API configuration, with no training on Relay's data and the shortest available retention. Log prompts in Relay's own HIPAA environment with the same retention rules as the rest of PHI.
Security program: a documented risk analysis (the most-cited failure in OCR enforcement), role-based access, MFA, encryption, test environments seeded with synthetic data (the fix for the near-miss), and reply-STOP handling within the required time. Retention: acceptance history kept 24 months, then de-identified (illustrative policy).
Incident plan: detect, contain, assess whether a breach of unsecured PHI occurred, and notify the clinic without unreasonable delay and within the BAA's deadline (no later than 60 days under HIPAA). The clinic notifies patients. A recorded post-incident review feeds the culture work in L35.
26
28 / DebriefPrivacy, security & data responsibilities
Reasoning traps
Assuming 'no medical records' means no PHI
A name, phone number and a slot at a named PT clinic are individually identifiable health information when Relay handles them for that clinic. Relay is in HIPAA from the first pilot text, including the Wizard-of-Oz phase.
The BAA that covers a different product
LLM and cloud vendors sign BAAs for specific services and configurations. Turning on an uncovered feature, a new model endpoint or a debug log can move PHI outside the agreement without anyone noticing.
Test data made of real patients
Relay's near-miss came from a test message built on a real record. Synthetic data in non-production environments and a fixed allowlist of test numbers remove a whole class of incidents.
27
28 / ReviewPrivacy, security & data responsibilities
What you can now explain
Relay's PHI data map and a one-page HIPAA review brief covering its role, design changes, vendor terms and incident plan.
A data map starts from purpose and traces each element through collect, use, store, share and delete, including vendors, logs and backups.
Privacy and security are different tests: a well-encrypted dataset can still hold data the purpose does not justify.
For Relay, HIPAA status, BAAs down the vendor chain and PHI-minimal messages are prerequisites for selling to clinics, not later compliance tasks.
Next lesson: Venture capital, angels & investor economics
28
Current rules: IRS: business structures · USPTO: IP tools. Legal, tax and privacy examples teach concepts; application depends on current law and the actual facts.
Check your understanding
How can a company understand what it collects and what responsibility follows?
Score
Question 1
Relay stores waitlist patients' names, mobile numbers and appointment slots on behalf of PT clinics. What is Relay's status under HIPAA?
Clinics are covered entities; a vendor that creates, receives, maintains or transmits PHI on their behalf is a business associate. Names and phone numbers tied to a clinic appointment are PHI without any diagnosis. Encryption reduces risk but does not change status.
Question 2
Relay's cloud host stores only encrypted PHI and never holds the decryption keys. According to HHS guidance, does Relay need a BAA with that host?
HHS's cloud computing guidance states that lacking an encryption key does not exempt a provider that maintains ePHI, and that the conduit exception is limited to transient, transmission-only services. Storage is persistent access.
Question 3
A clinic owner wants Relay's texts to read: 'Hi Maria Lopez, Dr. Shah has a 3:30pm opening for your knee rehab tomorrow.' Which response best applies minimization?
SMS content is visible on lock screens and to anyone who holds the phone, and numbers change hands. The purpose, filling a slot, is met without the name or condition. Encryption in transit does nothing once the text is displayed.
Question 4
Relay Scheduler passes patient replies to an LLM API. Which configuration is necessary before any production PHI flows to the vendor?
A vendor processing PHI for Relay is a subcontractor business associate and needs a BAA. Vendors limit BAA coverage to particular products and settings, so the configuration matters. Patient consent does not replace the BAA requirement.
Question 5
An engineer argues: 'Our database is encrypted with strict access controls, so storing every patient's full message history forever is fine.' What is the flaw?
This is the lesson's central distinction. Privacy asks whether data should be collected and kept for the purpose; security asks how it is protected. HIPAA's minimum-necessary standard and Relay's BAAs push toward defined retention, not indefinite storage.
Question 6
A Relay engineer discovers on Monday that a misconfigured export exposed 300 patients' names and appointment times to another clinic. Under HIPAA's Breach Notification Rule, what must Relay do as a business associate?
Business associates notify the covered entity, which then notifies individuals. The 500-person threshold changes how and when HHS and the media are told, not whether a breach is reported. The 72-hour figure is GDPR's regulator deadline, not HIPAA's.
Workbook
How can a company understand what it collects and what responsibility follows?
Module output: A founder discussion brief, governance questions, IP map and privacy data map.
Sources
Materials this lesson draws on
Original pages and full documents are in the Library edition.