Appearance
Privacy Impact Assessment
Status: First version. Effective 2026-05-11. Owner: Asad Khalid (org / privacy regulatory) + Taha Abbasi (technical implementation). Reviewed: Annually + whenever a new data flow that touches PII / PHI / FTI is introduced or materially changed.
Purpose
A Privacy Impact Assessment (PIA) is the documented walkthrough of every personal-data flow in the system: what is collected, why, how it is protected, how long it is retained, who has access, and how data subjects can exercise their rights. Required artifact for:
- CMS EDE Phase 3 (Privacy Notice + PIA are explicit submission artifacts)
- HIPAA Privacy Rule §164.520 (Notice of Privacy Practices) once PHI flows begin
- State-level privacy laws (California CCPA, New York SHIELD Act, etc.) covering the consumer states we serve
This PIA covers the current data flows as of 2026-05-11. New flows (Phase 5+ member enrollment, agent platform Phase 2 discovery survey expansion) get their own PIA addendum before launch.
Scope of personal data today
| Flow | Personal data fields | Class | Volume estimate |
|---|---|---|---|
| Anonymous quote (ZIP + age + income) | none — stateless | n/a | Highest-volume flow; not stored |
| Consumer waitlist signup | PII | Low (< 1000) | |
| Agent waitlist signup | email, full name, phone, company name, NPN, role | PII | Low |
| Agent discovery survey | email, NPN, agent profile fields, free-text response | PII | Low |
| Founder + ops email (Google Workspace) | employee email, calendar, drive content | PII | Internal |
Not yet in scope (Phase 5+, target after 2026-06-15 platform v1): consumer SSN, DOB, plan-enrollment records, income-verification documents, agent-of-record assignments. Each of these warrants a PIA addendum at the time of collection.
Flow-by-flow analysis
Flow 1 — Anonymous quote (ZIP + age + income)
| Question | Answer |
|---|---|
| What data is collected? | ZIP code (5 digits), ages (one or more integers), annual household income (integer) |
| Why? | To calculate eligibility for ACA marketplace subsidies and return a price + plan list |
| Is it stored? | No. The fields are passed to the calculation pipeline and the response is returned to the user. No Mongo write, no audit-log row, no PostHog event capturing the inputs. |
| Who has access? | The Next.js API route handler (/api/eligibility, /api/plans) — in-memory only |
| How long retained? | Not retained |
| Is it shared with third parties? | No. The CMS Marketplace API is queried for eligibility (federal states) but the request is anonymized (no identifying info beyond ZIP + ages + income, which by themselves are not PII per HIPAA Safe Harbor when not bound to a specific individual) |
| Data subject rights | n/a — no record exists to access, amend, or erase |
Flow 2 — Consumer waitlist signup
| Question | Answer |
|---|---|
| What data is collected? | Email address only |
| Why? | To notify the prospective consumer when AskFlorence opens to consumers (post Phase 5) |
| Is it stored? | Yes. agent_waitlist_submissions collection on prod Atlas (consumer-side rows are tagged interest: "consumer") |
| Who has access? | App writer Mongo user (app_writer_survey); admin Mongo user; AskFlorence ops via Atlas Admin (Taha today; access reviewed quarterly) |
| How long retained? | 6 years from last activity, per data retention policy |
| Consent capture? | Visible privacy notice on signup form (pending publish per #55) explains the use; submission is consent. Per-record consent stamp (privacy-policy version + timestamp) planned per #58. |
| Is it shared with third parties? | AWS SES (transactional email — AWS BAA covers). HubSpot CRM is NOT used for consumer waitlist (consumer data does not flow to HubSpot by design). |
| Data subject rights | Access: email Asad. Amend: email Asad. Erase: email Asad → 30-day GDPR-style erasure (process in data retention policy). |
| Marketing consent | Single-purpose: launch notification. Generic marketing emails are NOT sent. CAN-SPAM + GDPR-style unsubscribe flow pending per #59. |
Flow 3 — Agent waitlist signup
| Question | Answer |
|---|---|
| What data is collected? | Email, full name, phone, company name (optional), NPN (6-10 digits), role (individual / agency), team size (if agency) |
| Why? | To populate the Phase 5 agent portal launch list + perform NPN validation pre-launch |
| Is it stored? | Yes. agent_waitlist_submissions (interest: "agent") on prod Atlas. Also mirrored to HubSpot CRM for agent-relations workflow (Ian + Asad). |
| Who has access? | App writer Mongo user (narrow-scoped app_writer_survey); admin Mongo user; AskFlorence ops via Atlas Admin; HubSpot users (Ian + Asad have full HubSpot access today, reviewed quarterly) |
| How long retained? | 6 years from last activity (Atlas); HubSpot 7 years from last contact |
| Consent capture? | Privacy notice on signup form + submission = consent. Per-record version stamp planned per #58. HubSpot mirror is described in the privacy notice + ToS. |
| Is it shared with third parties? | HubSpot CRM (vendor register — agent waitlist mirror only, no PHI); AWS SES (transactional email); NIPR (NPN validation Phase 5) |
| Data subject rights | Same as consumer waitlist + HubSpot soft-delete path (not gdpr-delete — see data retention policy for the procedure that avoids the irreversible-blocklist failure mode) |
Flow 4 — Agent discovery survey
| Question | Answer |
|---|---|
| What data is collected? | Email, NPN, agent-business profile fields (years in business, primary specialty, etc.), open-ended responses |
| Why? | Research to inform Phase 5 agent platform design |
| Is it stored? | Yes. agent_survey_responses on prod Atlas. NOT mirrored to HubSpot. |
| Who has access? | App writer Mongo user (app_writer_survey, append-only — no UPDATE/REMOVE); Asad + Ian for analysis (via export); Atlas Admin (Taha) |
| How long retained? | 6 years from collection |
| Consent capture? | Per-record consent sub-document (privacy-policy version + timestamp + IP + userAgent + checkbox confirmation) ships with the survey route. See agent platform compliance. |
| Is it shared with third parties? | No third-party sharing (research-internal only) |
| Data subject rights | Standard access + amend + erase via email |
Flow 5 — Founder + ops email (Google Workspace)
| Question | Answer |
|---|---|
| What data is collected? | Employee email, calendar, drive content |
| Why? | Operate the business |
| Is it stored? | Yes (Google Workspace), under the Google HIPAA BAA |
| Who has access? | Account owner + Google Workspace admin (Taha) |
| How long retained? | Per Google Vault retention rules (to be set: mail 7y, chat 1y, drive until role change) |
| Consent capture? | Employment relationship implies consent for business-internal communication |
| Is it shared with third parties? | Google Workspace subprocessors per Google's BAA / DPA |
| Data subject rights | Employee data is handled per employment law + offboarding runbook |
Privacy controls (cross-cutting)
| Control | Mechanism | Evidence |
|---|---|---|
| Notice — privacy policy and ToS | Publish on consumer site before any PII collection ramps | #55 (in flight) |
| Notice — versioning | Each user submission stamps the privacy-policy version they consented to | #58 (planned) |
| Minimization — only collect what's needed | Per-flow review at design time; each new flow files a PIA addendum | this PIA |
| Purpose limitation — data only used for stated purpose | Audited via data retention policy erasure procedure; no re-purposing without re-consent | this PIA |
| Access control | Narrow-scoped Mongo users (ADR 0003); SSO + MFA for admin access (access-control policy) | live |
| Encryption | All flows encrypted at rest + in transit per encryption policy | live |
| Audit trail | DB-layer append-only audit log (ADR 0002) — every access by an admin / future per-agent / per-consumer logged | live |
| Right-to-erase | Procedure documented in data retention policy | live procedure; first exercise pending |
| Right-to-access / amend | Email request → manual fulfillment within 30 days | live procedure |
| Breach notification | Per HIPAA Breach Notification Rule (60-day window) + state-AG notifications; procedure in incident response plan | live procedure |
| Sub-processor disclosure | Maintained in vendor / subprocessor register; included in privacy policy by reference | live |
Risks identified during PIA
| # | Risk | Mitigation |
|---|---|---|
| PIA-001 | Privacy policy + ToS not yet published; consumer waitlist + agent surveys are collecting PII against an unpublished notice | #55 — publish before any marketing ramp |
| PIA-002 | Consent versioning not yet shipped; old waitlist rows lack version-stamped consent | #58 — backfill is acceptable on re-engagement; new rows ship with version stamp |
| PIA-003 | Unsubscribe flow not yet shipped; CAN-SPAM exposure on first marketing send | #59 — ship before first marketing email |
| PIA-004 | HubSpot mirrors agent waitlist + survey — second copy of PII outside the primary Atlas store | HubSpot is enterprise-tier BAA-covered (when signed); soft-archive (not gdpr-delete) on erasure; per-record consent applies |
| PIA-005 | Future PHI flows (Phase 5) require CSFLE + per-CMK-per-field encryption | Pre-launch checklist in encryption policy |
PIA review + amendment trigger
This PIA is amended:
- Annually as part of compliance review (next: 2027-05-11)
- Before any new data flow that touches PII / PHI / FTI launches
- After any incident that involves personal data
- When the privacy policy or ToS materially changes
- When a new subprocessor is added or removed (sync with vendor register)
Reference
- Data Classification Policy
- Data Retention Policy
- Encryption Policy
- Access Control Policy
- Incident Response Plan
- Vendor / Subprocessor Register
- Agent platform compliance design
- HIPAA Control Mapping — Privacy Rule rows (added at PHI launch)
- CMS EDE Appendix A Mapping — Privacy Notice requirement
