Starlight's Compliance Plan
How we actually do this — without the consultant theater. This is the opinionated doc. Other compliance pages explain the law and the industry; this one captures what we'll actually do at Starlight.
Erik's stance, May 2026: "There's a market of consultants and auditors selling HIPAA compliance as a checkbox service, which misses the actual point. HIPAA isn't a certification — it's a continuous risk-management posture you maintain. The real work is the risk analysis, the documentation, the incident response plan, the staff training. That's boring and unglamorous. What consultants sell is the comfort of a stamp."
The plan is to do the actual work, prove it ourselves, and get a real auditor in once for SOC 2 when we need it for sales.
Five operating principles
- The work is the work. No "compliance package" purchases. Risk analysis, documentation, training, IR runbooks — we write them, we own them.
- Build it once, audit it twice. Every engineering control satisfies HIPAA and SOC 2 simultaneously. See the overlap matrix.
- Synthetic data first; production access by exception. Engineers never need real PHI to develop, debug, or demo. See Synthetic Data Program.
- Egress as a feature, not a risk. Dr. P's patients can export their full chart in well-structured JSON, anytime. The four egress safeguards are baked into the product, not bolted on. See Egress Architecture.
- Peer review with another real shop, not a consultant. Once we're operational, partner with a similar-sized indie healthtech shop for mutual HIPAA review. Real practitioners with skin in the game.
Inversion: front-load compliance, then CI/CD with confidence
The conventional vendor narrative is "compliance takes 12–18 months." We're inverting it. Compliance work that happens after a product is built is retrofitting; compliance work that happens as the product is built is just engineering hygiene. We get the foundation in fast, then ship the product against it forward.
The plan is sequenced as gating milestones, not calendar months. Each milestone is a clear before/after — when we hit it, we move on; we don't wait for a date.
Gating milestones
| Phase | Milestone | Output / gate |
|---|---|---|
| G0 · Foundation | Security Officer named (Erik). AWS BAA executed via Artifact. Policy library skeleton committed (the 12 policies). Vendor inventory drafted. | Security Officer + BAA on file; policy stubs in repo. |
| G1 · Risk Analysis Done | Initial Risk Analysis complete using NIST 800-66 Rev. 2 as the template. BAA roundup signed with every PHI-touching subprocessor. | Risk register v1; subprocessor BAA folder fully populated. |
| G2 · Engineering Substrate | Synthetic-data generator running in CI. Production-access broker live (no standing prod credentials). Audit-log infrastructure operational. Encryption defaults verified across all stores. | "No prod PHI in dev" is enforced, not aspirational. |
| G3 · Process Substrate | Threat-model template adopted; AI scribe + parent app have completed threat models. IR runbook v1 written. First DR restore drill executed end-to-end. Training program v1 published. | Threat models, runbook, restore evidence, training records all in the evidence directory. |
| G4 · HIPAA Self-Attestation | Internal sign-off that all Required and reasonable Addressable Security Rule specs are implemented. Documented gap analysis on anything still open. | Self-attestation artifact. Gates onboarding the first paying customer. |
| G5 · Operational Evidence | Continuous evidence collection running (access reviews, restore drills, tabletops, vendor reviews) — not as a calendar item, but as a CI-driven and event-driven discipline. | Evidence directory accumulating without manual scrambling. |
| G6 · SOC 2 Type I | Engage SOC 2 auditor. Scope: Security + Availability + Confidentiality. Pre-audit gap assessment. Type I fieldwork. | SOC 2 Type I report. |
| G7 · SOC 2 Type II | Auditor-determined observation period elapses; Type II fieldwork. | SOC 2 Type II report. |
| G8 · Scope Expansion | Add Processing Integrity + Privacy to the SOC 2 scope. Engage peer-review pact partner (sister indie healthtech shop). | Expanded SOC 2 scope; peer-review report and shared action items. |
| Continuous | Risk-analysis refresh on material change (new system, new vendor with PHI, breach, regulatory change). Evidence collection runs forever. | Risk register stays current. |
Hard rule: no synthetic timeline numbers. We move from G(n) to G(n+1) as soon as the gate is met. Erik calls the pace.
Workstream 1 · The 12 policies (the boring foundation)
We need written, dated, owned, version-controlled policies. Every one is a markdown doc in the repo, reviewed on material change and on Security Officer trigger, signed off by the Security Officer.
| # | Policy | Maps to |
|---|---|---|
| 1 | Information Security Policy (umbrella) | 164.316, SOC 2 CC2 |
| 2 | Risk Analysis & Risk Management Policy | 164.308(a)(1) |
| 3 | Workforce Security & Sanction Policy | 164.308(a)(1)(ii)(C), 164.308(a)(3) |
| 4 | Information Access Management & RBAC Policy | 164.308(a)(4), 164.312(a) |
| 5 | Security Awareness & Training Policy | 164.308(a)(5) |
| 6 | Incident Response & Breach Notification Policy | 164.308(a)(6), 164.400–414 |
| 7 | Contingency Plan / DR / Backup Policy | 164.308(a)(7), SOC 2 A1 |
| 8 | Audit Logging & Monitoring Policy | 164.312(b), SOC 2 CC4, CC7 |
| 9 | Encryption Standards Policy | 164.312(a)(2)(iv), 164.312(e) |
| 10 | Vendor Management & BAA Policy | 164.308(b), 164.314 |
| 11 | Data Classification & Handling Policy | (Internal best practice — keystone) |
| 12 | Acceptable Use & Workstation Security Policy | 164.310(b), 164.310(c) |
Each policy is ≤ 2 pages. Long policies don't get read. Each links to the operational runbook that implements it.
Workstream 2 · Risk Analysis (the keystone)
The single most-cited deficiency in OCR enforcement actions is missing or inadequate Risk Analysis. We're going to do it properly, once, then maintain it.
Methodology: Follow NIST SP 800-66 Rev. 2 Section 4.
Output artifacts (all in the repo, in markdown):
- System inventory — every system that creates / receives / transmits / stores ePHI, with owner, classification, and data flow.
- Threat catalog — applicable threats (insider, external, supply-chain, environmental).
- Vulnerability assessment — current control posture per system.
- Risk register — likelihood × impact × residual-risk score per identified risk, mapped to the safeguard standard it implicates.
- Mitigation plan — what we'll do, who owns it, by when.
Trigger: Initial completion at gate G1. Refresh on material change (new system, new vendor with PHI, breach, regulatory change). Treat the risk register as a living artifact — it doesn't get re-opened on a calendar; it gets re-opened when reality moves.
Workstream 3 · Synthetic Data Program
Principle: Engineers should never need real PHI to develop, debug, or demo. Real PHI in dev is a leak waiting to happen.
Approach:
- LLM-generated synthetic patients (children, parents, conditions, visits, vitals, notes, messages, documents).
- High-temperature + explicit edge-case prompts to push past the Gaussian center: rare presentations, comorbidities, atypical demographics.
- Seed prompts with public medical literature (PubMed Central) describing unusual pediatric presentations — never real patient records.
- Generated dataset is large enough to stress-test all flows: 18 patients × 10 families is the prototype demo size; production synthetic dataset will be ~5,000 synthetic patients.
- Validation: synthetic data is checked against a deny-list of real names/DOBs to avoid accidental collision. Salt all synthetic IDs.
- Distribution: synthetic dataset is committed to a separate repo and refreshed when the schema or feature surface changes meaningfully. CI loads it on every test run.
What synthetic data unlocks:
- Local development without prod database access — engineers run a full Starlight environment on their laptop with realistic data.
- UX testing with the actual product manager (Deepak) without IRB or HIPAA implications.
- Full E2E test suites that exercise edge cases (preemie newborns, multi-condition kids, complex family structures, schedule-II Rx).
- Demo / sales / marketing screenshots that aren't blurred PHI — the launch briefing prototype already proves this works.
Workstream 4 · Egress Architecture
The patient data egress feature is a sales advantage, not a liability — but only if the safeguards are airtight.
The four-safeguard wall:
1. Identity verification
- Authenticated request through the parent app or provider portal.
- For parent → child requests: relationship validated against the Family / Guardian model in our DB. Only legal guardians can request a minor's records.
- 2FA required on the requesting account.
- Step-up authentication (re-auth or MFA challenge) on the egress request itself, not just on session login.
- Edge cases (custody disputes, court orders, deceased patients): runbook + manual review.
2. Encrypted transmission
- Egress is delivered as either a download from a TLS-secured endpoint or a time-limited pre-signed S3 URL.
- The exported bundle itself is encrypted at rest in the storage location until downloaded.
- Optional: encrypted ZIP with a passphrase delivered out-of-band (SMS to verified phone).
- No email attachments. No unencrypted physical media.
3. Audit logging — every export, queryable
- Each export logs: requester identity, patient subject, timestamp, scope (full chart vs. specific date range vs. specific encounter), output format, IP, request reason if provided.
- Logs are retained 6+ years (HIPAA documentation retention).
- Log query supports: "list every export for patient X" and "list every export by user Y in date range" — directly serves the Right to Accounting of Disclosures.
4. Documented egress policy
- A written policy, version-controlled, that names: who can request, what we provide, in what format, in what timeframe (we commit to shorter than the 30-day HIPAA requirement as a sales advantage), what fees apply (none for the patient's own records via parent app).
- Linked from the patient-facing privacy notice.
Output format spec (the sales line): "Well-structured JSON, full chart, anytime." Concretely: a JSON bundle conforming to the FHIR R4 patient bundle structure, plus original-format attachments (PDF labs, images), plus a manifest with cryptographic hashes.
Patient liability vs Starlight liability: Once delivered to the verified patient, what the patient does with their data is their concern. Starlight's liability ends when the verified-recipient signed-receipt fires. Document this clearly in the Notice of Privacy Practices.
Workstream 5 · The Peer-Review Pact
The novel idea (Erik, May 2026): two indie shops of similar size doing mutual HIPAA review. Real practitioners give each other real feedback. Skin in the game on both sides. Way more valuable than a consultant's template.
What we exchange:
- Risk analyses (anonymized of any actual PHI).
- Threat models for marquee features.
- Incident-response runbooks.
- Vendor BAA inventories.
- Policy library structure (not the secrets).
- Architecture diagrams.
What we don't exchange: anything containing actual PHI, or production credentials, obviously.
Cadence: Recurring written exchange + a deeper on-site (or video) review session, at a tempo set jointly with the partner shop. Findings tracked as action items in both shops' risk registers.
Target partners: Other small healthtech shops in the indie / DPC-adjacent space. Find one or two through the Direct Primary Care community in Austin / Texas.
This is not a substitute for a SOC 2 audit (we need that for sales). It is a substitute for HIPAA-vendor compliance theater.
Workstream 6 · Workforce Training
Simple, real, recurring. No overproduced theater modules.
Content (60–90 minute video + quiz):
- HIPAA basics: PHI definition, CE vs BA, our role.
- The four rules and what each requires.
- Real-world incident examples — including OCR-published resolution agreements.
- Starlight-specific: how to use synthetic data, how to request break-glass access, what to do if you suspect a leak, who to call.
- Phishing / social engineering refresher with current examples.
Trigger: On hire (before first production access), and on a recurring refresh tempo set by the Security Officer. Tracked by name + completion date. No exceptions.
Sanction policy clear: intentional PHI access for non-work-related reasons = termination + reportable to OCR.
Workstream 7 · Incident Response
Roles:
- Incident Commander — coordinates response, makes external-comms decisions. Default: Security Officer; rotating coverage for off-hours.
- Technical Lead — runs containment, evidence collection, remediation.
- Comms Lead — drafts notifications to customers, OCR, media if 500+ scale.
- Legal Lead — outside counsel on retainer for breach notification.
Phases (per NIST SP 800-61 Rev. 3):
- Preparation — runbooks, contacts, tooling.
- Detection & Analysis — confirm the incident, scope it.
- Containment — stop the bleeding, preserve evidence.
- Eradication & Recovery — remove the cause, restore systems.
- Post-Incident — retro, root-cause analysis, control updates.
Specific runbooks (one per class, ≤ 1 page each):
- ePHI breach (suspected unauthorized access).
- Credential compromise (engineer or service account).
- Ransomware / availability incident.
- Third-party / vendor breach.
- Supply-chain (malicious dependency).
- Insider misconduct.
Tabletops: Recurring, with a different scenario each time. Tempo set by the Security Officer; minimum bar is "frequently enough that the runbook is never first-time-run during a real incident." Findings drive runbook updates.
Notification clock starts at "discovery" — the moment we knew or should have known. The 60-day clock under HIPAA breach notification is real and unforgiving.
Workstream 8 · Continuous Evidence
The single biggest predictor of an audit going smoothly is whether evidence collection is automated and event-driven vs. scrambled-up at audit time. Treat evidence like CI artifacts: produced as a side-effect of doing the work, not as a separate calendar task.
| Evidence | Trigger | Source |
|---|---|---|
| Access reviews (who has prod access) | On every IAM change + on a recurring tempo | Automated IAM report exported to compliance/evidence/access-reviews/ |
| Restore drills | On schema change + recurring | Backup-system logs + drill-runner script output |
| Vulnerability scans | Per CI run | SAST/SCA reports archived per scan |
| Vendor BAA status | On vendor onboarding + on renewal | Vendor inventory snapshot |
| Risk register update | On material change | compliance/risk-register.md commit history |
| Tabletop exercises | Recurring | Runbook + post-exercise notes |
| Training completions | On hire + on training refresh | LMS export |
| IR runbook test (real or tabletop) | Recurring | Runbook + retro |
| Security policy review | On material change + on Security Officer trigger | Policy library commit log |
Cadence-setting principle: the recurring tempos are set by the Security Officer based on risk and audit posture — not preset by this document. Erik calls those tempos when we have the operational signal to set them.
Storage: all evidence in a compliance/evidence/ directory in a private, access-restricted repo. Retention follows HIPAA's documentation-retention requirement of 6 years from creation or last-effective date (45 CFR 164.316(b)(2)).
What we are deliberately not doing (yet)
- Buying a "HIPAA compliance platform" (Drata, Vanta, Secureframe, etc.) as a substitute for doing the work. We may adopt one as evidence-collection automation when we engage the SOC 2 auditor at gate G6 — but it's a tool, not the strategy.
- HITRUST certification. Required by some larger payers / hospital systems but not our customer profile right now. Adopt only if a real customer demands it.
- FDA Software-as-a-Medical-Device path. Our v1 is an EMR + practice-management platform — not a diagnostic device. The post-v1 parent triage tool sits near the SaMD line and would need careful scoping if we ship it.
- HIPAA-compliance consultant on retainer. See "five operating principles."
Where to go next
- HIPAA Overview — the regulatory backbone.
- SOC 2 Overview — the audit framework + overlap matrix.
- Regulated SDLC Guardrails — the engineering practices that make the evidence flow.
- AWS HIPAA Stack — services-to-controls mapping for the AWS substrate.