HIPAA compliance for health-tech startups
Built HIPAA infrastructure at Color & Redesign Health
HIPAA compliance means protecting patient health data to the standard US law requires, and it's a legal obligation, not a certificate you earn.
For a health-tech startup it comes down to three things: implement the safeguards in the HIPAA Security Rule, follow the Privacy Rule for how you use patient data, and sign Business Associate Agreements with every vendor that touches it. SOC 2 or ISO 27001 build most of the foundation, but neither makes you HIPAA compliant on its own.
If you're about to run a pilot with a health system or payer, they'll ask for a signed Business Associate Agreement and evidence of safeguards before sharing a single patient record. Here's what that actually requires.
What HIPAA is (and what it isn't)
HIPAA, the Health Insurance Portability and Accountability Act, is US federal law governing how protected health information (PHI) is handled. It's enforced by the Department of Health and Human Services (HHS). The critical thing to understand up front: there is no official HIPAA certification. No government body issues a HIPAA certificate. Compliance is demonstrated through implemented safeguards, documentation, risk assessments, and contracts, and a vendor claiming to be "HIPAA certified" is describing a third-party attestation, not an official credential.
For a startup, HIPAA breaks into three rules that matter most:
- The Security Rule, administrative, physical, and technical safeguards for electronic PHI. This is where most of the IT and security work lives.
- The Privacy Rule, the standards for how PHI may be used and disclosed.
- The Breach Notification Rule, what you must do if PHI is exposed.
- HIPAA is a legal obligation, not a certificate. Nobody issues an official HIPAA certification.
- The Security Rule is the IT work. Administrative, physical, and technical safeguards for electronic PHI.
- BAAs are mandatory. Every vendor touching PHI needs a signed Business Associate Agreement.
- SOC 2 / ISO 27001 build most of it. Shared controls cover much of HIPAA, but add BAAs and PHI-specific policies.
Are you a covered entity or a business associate?
HIPAA applies to two categories, and most health-tech startups are the second:
- Covered entities, health plans, healthcare clearinghouses, and healthcare providers who transmit health information electronically.
- Business associates, companies that create, receive, store, or transmit PHI on behalf of a covered entity. A SaaS platform used by a hospital, a health-data analytics tool, a care-coordination app: these are almost always business associates.
If you're a business associate, HIPAA obligations flow to you contractually through a Business Associate Agreement, and you must comply with the Security Rule directly.
What the Security Rule requires, in practice
Translated out of legalese, the technical safeguards a health-tech startup needs look a lot like good modern security engineering:
- Access controls, unique user identity, single sign-on, MFA, and role-based access so only the right people reach PHI.
- Encryption, PHI encrypted in transit and at rest.
- Audit controls, logging and monitoring of who accessed what.
- Device and endpoint security, managed, encrypted devices with enforced posture.
- Incident response and breach procedures, a documented, tested plan for when something goes wrong.
- Administrative safeguards, risk assessments, workforce training, and assigned security responsibility.
Health system pilot asking for a BAA and safeguards?
I've built HIPAA-compliant infrastructure at Color and across 40+ companies at Redesign Health. Let's map your path.
Business Associate Agreements (BAAs)
A Business Associate Agreement is a HIPAA-required contract between you and any vendor that handles PHI on your behalf. If PHI flows through it, you need a BAA for it. The good news: the major infrastructure providers, AWS, Google Cloud, and Microsoft, all offer BAAs for their covered services, as do many health-focused SaaS tools. The work is inventorying every place PHI touches, confirming each of those vendors will sign a BAA (and that you're using them in a HIPAA-eligible configuration), and getting the agreements executed. Missing a BAA for a tool quietly handling PHI is one of the most common compliance gaps.
How HIPAA relates to SOC 2 and ISO 27001
This is where startups save real time and money. HIPAA's Security Rule shares most of its DNA with SOC 2 and ISO 27001, access control, encryption, monitoring, incident response, risk assessment. If you build those controls for one framework, you've covered the bulk of the others. The efficient approach for health-tech is to design the security foundation once and map it to all three, then layer on the HIPAA-specific pieces (BAAs, PHI handling policies, breach procedures).
| HIPAA | SOC 2 | ISO 27001 | |
|---|---|---|---|
| Nature | US law (obligation) | Audit report | Certification |
| Artifact | No official certificate | Attestation report | Certificate |
| Scope | Protected health information | Customer data broadly | Information security broadly |
| Who requires it | Health systems, payers, the law | US enterprises | International / regulated buyers |
| Control overlap | High, the same security foundation supports all three | ||
For a fuller breakdown of the two certifications, see SOC 2 vs ISO 27001 for health-tech.
Where I've done this
I built and scaled HIPAA-compliant infrastructure at Color (genomics, through 300% growth) and standardized HIPAA-aligned security across 40+ portfolio companies at Redesign Health. The consistent lesson: HIPAA is far less daunting when you treat it as security engineering plus contracts, rather than a mysterious legal hurdle, which is exactly how a fractional CIO approaches it.