Executive Summary
HIPAA governs how startups handle protected health information (PHI) in the United States. If you build software for providers or payers, or handle patient data as a vendor, you are likely a business associate and must sign BAAs, implement the Security Rule safeguards, and be ready to prove it. Unlike SOC 2, HIPAA has no official certificate, so most health-tech startups demonstrate compliance through a risk assessment, documented policies, and a third-party attestation.
Does HIPAA apply to your startup?
HIPAA applies to two kinds of organizations. Covered entities are providers, health plans, and clearinghouses. Business associates are vendors that create, receive, maintain, or transmit PHI on their behalf, which is where most health-tech startups land.
If you store, process, or even just route PHI for a customer, you are almost certainly a business associate and are directly liable under HIPAA, not just through your contract.
The three HIPAA rules
HIPAA compliance comes down to satisfying three rules.
| Rule | What it covers | What it means for you |
|---|---|---|
| Privacy Rule | How PHI may be used and disclosed | Limit access and use of patient data to the minimum necessary |
| Security Rule | Safeguards for electronic PHI | Implement administrative, physical, and technical controls |
| Breach Notification Rule | Reporting after a breach | Notify affected parties and HHS within required timelines |
Business Associate Agreements (BAAs)
A BAA is a contract that makes data-handling responsibilities legally binding. You sign one with every customer whose PHI you touch, and you must sign one with every subcontractor that touches that PHI on your behalf, such as your cloud provider.
No BAA means you cannot lawfully handle PHI for that customer, so confirm your infrastructure vendors will sign one before you build.
The Security Rule safeguards
The Security Rule groups its requirements into three categories.
- Administrative: Risk assessments, workforce training, access management, and an incident response plan.
- Physical: Controls over facilities and devices, including workstation and media security.
- Technical: Access controls, encryption of PHI in transit and at rest, audit logging, and integrity controls.
There is no such thing as HIPAA certification
HHS does not certify or endorse any product as HIPAA compliant. Be cautious of vendors selling a HIPAA certificate. Real assurance comes from a risk assessment, documented controls, and an independent attestation.
The HIPAA risk assessment explained
The Security Rule requires a documented risk assessment, and it is the first thing regulators ask for after an incident. It maps where PHI lives, the threats to it, and how likely and damaging each risk is, then feeds a plan to reduce those risks to an acceptable level.
It is not a one-time document. Repeat it at least annually and whenever you make a major change to your systems, such as adopting a new subprocessor or shipping a new data flow.
HIPAA and your cloud provider
Major cloud providers such as AWS, Google Cloud, and Azure will sign a BAA and offer HIPAA-eligible services. But using them does not make you compliant by itself. Under the shared responsibility model, the provider secures the underlying infrastructure while you remain responsible for configuring services correctly, controlling access, and encrypting PHI.
HIPAA-eligible is not the same as HIPAA compliant
Running on a HIPAA-eligible cloud service does not make your product compliant. You still own configuration, access control, encryption, and the evidence that proves it.
HIPAA penalties and enforcement
The HHS Office for Civil Rights enforces HIPAA, and penalties scale with culpability, from honest mistakes up to willful neglect. Fines can reach into the millions per violation category per year, and settlements are published publicly, which adds reputational damage on top of the financial cost.
For a startup, the reputational hit of a public HIPAA settlement can be more damaging than the fine itself, because it undermines the trust your health-care customers depend on.
HIPAA or SOC 2: do you need both?
Many health-tech startups need both. HIPAA is a legal requirement whenever you handle PHI, while SOC 2 is the independent assurance report enterprise procurement asks for. They serve different masters, but the underlying security controls overlap heavily.
| HIPAA | SOC 2 | |
|---|---|---|
| Type | US law | Independent attestation report |
| Trigger | You handle protected health information | You sell to enterprises that require assurance |
| Proof | Risk assessment, policies, optional attestation | CPA-issued SOC 2 report |
| Overlap | Shares most technical safeguards with SOC 2 | Covers HIPAA-style security controls |
Run them as one program
Because the security controls overlap, a combined program lets the evidence you collect once satisfy both HIPAA safeguards and SOC 2 criteria.
HIPAA readiness checklist
A practical starting point for health-tech founders.
- Complete a documented HIPAA risk assessment.
- Sign BAAs with every customer and every subcontractor that handles PHI.
- Encrypt PHI in transit and at rest, and enforce strong access controls with audit logging.
- Write HIPAA policies and train your workforce annually.
- Prepare an incident response and breach notification plan before you need it.
Frequently asked questions
Ready to stay audit-ready every day?
See how Auditious automates evidence and monitors controls continuously.
