SOC 2 — and How It Overlaps with HIPAA
Why we care about SOC 2 too: HIPAA is the regulatory floor for ePHI. SOC 2 is the procurement floor for selling B2B software — every practice's accountant, every employer-sponsored DPC plan, every payer integration, every billing/financing partner is going to ask for our SOC 2 report before they share data with us. We're going to need it for the invoicing and financing side of Starlight regardless of HIPAA. Good news: a solid HIPAA Security Rule build does ~70–80% of the SOC 2 work for free.
What SOC 2 actually is
SOC 2 (Service Organization Control 2) is not a regulation. It's an independent audit report issued by a CPA firm against the AICPA Trust Services Criteria. Its full name is "SOC 2 — Report on Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy."
There is no government enforcement — but in practice, no enterprise B2B SaaS sells without one.
The five Trust Services Criteria (TSC)
You pick which apply to your service. Security is mandatory — the others are scoped in based on what you do.
| Criterion | Question it answers | Mandatory? |
|---|---|---|
| Security (Common Criteria) | Are systems protected against unauthorized access, disclosure, and damage? | Yes — always |
| Availability | Is the system available for operation as committed? | If we promise SLAs |
| Processing Integrity | Is processing complete, accurate, timely, and authorized? | If we transform/process customer data (we do — billing, eRx, AI scribe) |
| Confidentiality | Is information designated as confidential protected? | If we hold confidential customer info beyond the privacy of individuals (we do) |
| Privacy | Is personal information collected, used, retained, disclosed, and disposed of according to commitments? | If we handle personal info under our own privacy notice (we do) |
For Starlight, all five will likely be in scope by the time we're operating at scale. To start (Type I) we'll typically scope Security + Availability + Confidentiality and add Processing Integrity and Privacy when the audit cadence catches up.
Type I vs Type II reports
| Type I | Type II | |
|---|---|---|
| What it tests | Are the controls designed appropriately as of a single point in time? | Did the controls operate effectively over a period of time? |
| Period covered | A single date | An auditor-determined observation period |
| Effort | Lower — one snapshot | Higher — sustained evidence collection across the observation period |
| Customer trust value | Low–medium ("they have policies") | High ("they actually followed them") |
| When to do it | First — to establish design | Second — to prove operation |
Sequencing principle (not a calendar): Type I once controls are designed and our internal evidence shows them in operation. Type II once the auditor's observation period has accrued enough evidence. The pace is set by gating milestones (see Starlight's Compliance Plan — gating milestones), not by a vendor-template schedule. Most enterprise customers will eventually want Type II — Type I gets us in the door for the first wave.
Reference architecture in the AICPA framework
| AICPA Document | Year | What it specifies |
|---|---|---|
| Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (TSP Section 100) | 2017, revised 2022 | The criteria your auditor evaluates against. |
| Description Criteria for a Description of a Service Organization's System in a SOC 2 Report (DC Section 200) | 2018, revised 2022 | What management's "System Description" must include. |
| AICPA SOC 2 Implementation Guide | 2022 | Practical guidance for building toward an audit. |
All available at aicpa-cima.com — SOC 2.
SOC 2 ↔ HIPAA Overlap Matrix
The crux for Starlight: most controls double-count. Build once, audit twice.
| HIPAA Security Rule Standard | Cite | SOC 2 TSC Coverage | Notes |
|---|---|---|---|
| Risk Analysis | 164.308(a)(1)(ii)(A) | CC3.1 (Risk Identification), CC3.2 (Risk Assessment), CC3.4 (Mitigation) | Same risk-management process satisfies both. |
| Risk Management / Sanction Policy | 164.308(a)(1)(ii)(B–C) | CC1.1 (Integrity & Ethics), CC1.5 (Accountability) | Sanction policy = SOC 2's "ethics + accountability." |
| Information System Activity Review | 164.308(a)(1)(ii)(D) | CC4.1 (Monitoring of Controls), CC7.2 (Anomaly Detection) | Audit log review programs cover both. |
| Security Officer Designation | 164.308(a)(2) | CC1.3 (Reporting Lines & Responsibility) | Same designated officer. |
| Workforce Security / Authorization | 164.308(a)(3) | CC6.2 (User Provisioning & Deprovisioning) | Joiner-Mover-Leaver process. |
| Information Access Management | 164.308(a)(4) | CC6.1 (Logical Access Controls) | RBAC, principle of least privilege. |
| Security Awareness Training | 164.308(a)(5) | CC2.2 (Internal Communication), CC1.4 (Workforce Competence) | One training program covers both. |
| Security Incident Procedures | 164.308(a)(6) | CC7.3 (Incident Response), CC7.4 (Incident Recovery) | Same runbook satisfies both. |
| Contingency Plan | 164.308(a)(7) | A1.2 (Availability), A1.3 (Recovery), CC9.1 (Business Continuity) | DR / BCP plan. |
| Evaluation (periodic security review) | 164.308(a)(8) | CC4.1 (Monitoring), CC4.2 (Evaluation) | Recurring security review at a tempo set by the Security Officer. |
| Business Associate Contracts | 164.308(b) / 164.314(a) | CC9.2 (Vendor Management) | Vendor due-diligence + contracts. |
| Facility Access Controls | 164.310(a) | CC6.4 (Physical Access) | If we use AWS, this is largely inherited via AWS SOC reports. |
| Workstation Use & Security | 164.310(b–c) | CC6.7 (Endpoint Security) | MDM + workstation policy. |
| Device & Media Controls | 164.310(d) | CC6.5 (Asset Disposal) | Crypto-shredding + asset inventory. |
| Access Control (Unique IDs, Auto-Logoff, Encryption) | 164.312(a) | CC6.1, CC6.6 (Logical Access), CC6.7 | SSO + 2FA + idle timeouts. |
| Audit Controls | 164.312(b) | CC4.1 (Monitoring), CC7.2 (Anomaly Detection) | CloudTrail + application audit logs. |
| Integrity Controls | 164.312(c) | PI1.1–PI1.5 (Processing Integrity) | Cryptographic hashes, signed records. |
| Person/Entity Authentication | 164.312(d) | CC6.1 | Strong auth, MFA. |
| Transmission Security (Encryption + Integrity) | 164.312(e) | CC6.7, CC6.8 | TLS 1.2+ everywhere. |
| Documentation & Retention (6 yr) | 164.316 | CC2.3 (External Communication) | Policy library with retention. |
| Breach Notification | 164.400–414 | CC7.5 (Recovery & Communication) | Same incident-response playbook with HIPAA-specific notification timelines layered in. |
What's HIPAA-only (SOC 2 won't catch it):
- The Privacy Rule's consent / authorization / minimum-necessary / right-of-access workflows.
- Business Associate Agreements as a legal instrument (vs. SOC 2's vendor-management process language).
- HIPAA-specific Breach Notification timelines to OCR / individuals / media.
- HIPAA workforce training content (PHI-specific, not generic security awareness).
What's SOC 2-only (HIPAA won't push you to it):
- Availability commitments at SLA granularity (HIPAA cares about contingency planning, not 99.95% uptime).
- Change management as a separately auditable control (HIPAA expects it but doesn't break it out).
- Vendor management as a programmatic discipline beyond just "have BAAs."
- Customer-facing system descriptions and SLA documentation.
Combined audit sequence
The HIPAA + SOC 2 work is sequenced as gating milestones rather than a calendar — see the full breakdown in Starlight's Compliance Plan.
| Gate | What it produces |
|---|---|
| G0–G3 · Foundation + substrate | Security Officer, BAA, policy library, risk analysis, vendor BAAs, synthetic-data substrate, audit logs, IR runbook, restore drill, training. |
| G4 · HIPAA Security Rule self-attestation | Internal documented self-attestation. Gates onboarding the first paying customer. |
| G5 · Operational evidence accruing | Continuous, event-driven evidence collection in compliance/evidence/. |
| G6 · SOC 2 Type I | Auditor's Type I report. Scope: Security + Availability + Confidentiality. Sales-enabling. |
| G7 · SOC 2 Type II | Auditor's Type II report covering an auditor-determined observation period. |
| G8 · Scope expansion | Add Processing Integrity + Privacy to SOC 2 scope. Engage peer-review pact partner. |
| Continuous | HIPAA Risk Analysis refresh on material change. SOC 2 Type II re-issued on the audit cycle the auditor sets. |
Reference URLs
| Source | URL |
|---|---|
| AICPA SOC 2 landing page | aicpa-cima.com — SOC 2 |
| AICPA Trust Services Criteria (PDF) | [Available via the AICPA SOC 2 page above] |
| AWS SOC reports (for inherited controls) | aws.amazon.com/compliance/soc-faqs |
| HHS · How HIPAA aligns with NIST 800-53 / FedRAMP | hhs.gov · Security guidance |
Where to go next
- HIPAA — The Whole Picture — the regulatory backbone we're double-counting against.
- Regulated SDLC Guardrails — the engineering practices that produce the evidence both audits need.
- Starlight's Compliance Plan — our actual roadmap, including peer-review pact and synthetic-data testing.