HIPAA Compliance for Health Tech Startups: A Builder's Guide

If you build software that touches health data, HIPAA is less scary than it looks — but only if you understand what it actually asks of you. It is not a certification you pass; it’s a set of administrative, physical, and technical safeguards you can show you follow. Get the fundamentals right early and compliance becomes a byproduct of good engineering, not a project that eats your roadmap.

This is informational, not legal advice — loop in counsel before you sign anything or make a compliance claim.

First: is HIPAA even your problem?

HIPAA regulates two kinds of entities. Covered entities are providers, health plans, and clearinghouses — the doctors and insurers. Business Associates are the vendors who create, receive, maintain, or transmit Protected Health Information (PHI) on behalf of a covered entity. If you’re a health-tech startup selling software to clinics, hospitals, or payers, you are almost always a Business Associate.

That distinction matters because Business Associates are directly liable under HIPAA. Since the Omnibus Rule, the government can come after you, not just your customer. “We’re just the software vendor” is not a defense.

You might not be under HIPAA if you never handle PHI on behalf of a covered entity — for example, a pure direct-to-consumer wellness app where the user volunteers their own data. But that line is thinner than founders assume, and it moves the moment you sign your first clinic or payer. Assume you’re in scope and be pleasantly surprised if you’re not.

What actually counts as PHI

PHI is health information tied to one of 18 identifiers — name, dates, geographic detail smaller than a state, email, phone, MRN, device IDs, IP addresses, and so on. The trap for engineers: it’s not just the diagnosis field. An appointment timestamp joined to a name is PHI. A row in your logs with a patient email and a visit reason is PHI. If it can identify a person and relates to their health, care, or payment, treat it as PHI.

Two practical consequences:

• Minimize what you collect. Data you never store can’t leak and isn’t in scope.
• De-identification is a real escape hatch — but it has to meet HIPAA’s Safe Harbor (strip all 18 identifiers) or Expert Determination standard. Hashing an email is not de-identification.

The two rules you have to know

The Privacy Rule

The Privacy Rule governs use and disclosure — who is allowed to see PHI and for what purpose. For a software company the operating principle is minimum necessary: only access, use, or share the least PHI needed to do the job. Practically, that means role-based access, no “everyone’s an admin,” and not piping PHI into analytics tools, LLM prompts, or Slack because it was convenient.

The Security Rule

The Security Rule is the one engineers live in. It requires safeguards in three buckets:

• Administrative safeguards — the paperwork and process. A named security officer, a written risk analysis, workforce training, access management, and an incident response plan. This is the half founders skip and auditors care about most.
• Physical safeguards — facility and device controls. If you’re all-cloud, most of this is inherited from AWS/GCP under their BAA, but you still own workstation and mobile-device policy.
• Technical safeguards — access control, unique user IDs, audit logging, integrity controls, and encryption in transit and at rest. Note that many controls are labeled “addressable,” which does not mean optional — it means you either implement it or document a defensible reason you didn’t.

The Security Rule is deliberately technology-neutral. There’s no “HIPAA-compliant checkbox” in AWS. You’re responsible for choosing and documenting reasonable controls.

BAAs: the contract that makes it real

A Business Associate Agreement (BAA) is the contract that flows HIPAA obligations down the chain. You sign one with your customer (they require it before sending you PHI), and you sign one with every subcontractor that touches PHI on your behalf — your cloud provider, your email/SMS sender, your error-tracking tool, your analytics vendor.

The rule of thumb: if PHI flows to a vendor, you need a signed BAA with them, or that PHI cannot go there. This single principle kills a lot of casual architecture decisions — you can’t just drop PHI into a tool that won’t sign one. AWS, GCP, and Azure will sign a BAA. Many popular SaaS tools will only on higher tiers, and some won’t at all.

A builder’s checklist — without over-engineering

You do not need a SOC 2 auditor in month one. You need to not build yourself into a corner. In rough priority:

1. Map your PHI. Know exactly what PHI you collect, where it’s stored, and every place it flows. This data-flow map is the foundation of everything else — and your risk analysis.
2. Sign your cloud BAA and stay on HIPAA-eligible services. Cloud providers only cover PHI on specific services; know which ones.
3. Encrypt everywhere. TLS in transit, KMS-backed encryption at rest. This is table stakes and cheap to do from day one.
4. Implement real access control. Unique logins, MFA, least privilege, and role-based access to PHI. No shared accounts.
5. Turn on audit logging for PHI access and admin actions — and make sure logs themselves don’t leak PHI into places you can’t defend.
6. Write the administrative stuff down. Name a security officer, do a written risk analysis, document your policies, train the team, and have an incident-response plan. Auditors ask for documents, not vibes.
7. Vet vendors for BAAs before you integrate them, not after.
8. Manage backups and retention — encrypted, tested restores, and a defined retention policy.

The over-engineering trap is building an enterprise compliance program before you have a product. The under-engineering trap is bolting PHI onto tools that can’t sign a BAA and untangling it later. Aim for the middle: clean data flows, encryption, access control, audit logs, and the paper trail to prove it.

The founder takeaway

HIPAA rewards teams that treat it as an architecture discipline instead of a fire drill. Decide early what PHI you’ll hold, keep it on services and vendors that will sign a BAA, encrypt and log it, and write down what you did. Do that and your first customer’s security review becomes a formality instead of a scramble.

Is my startup a HIPAA business associate?

This is the question that decides whether HIPAA applies to you at all, so answer it deliberately. You are almost certainly a business associate if you create, receive, maintain, or transmit PHI on behalf of a covered entity — a provider, health plan, or clearinghouse. Selling scheduling, billing, analytics, messaging, or clinical software to clinics, hospitals, or payers puts you squarely in that bucket. Business associates are directly liable under HIPAA since the Omnibus Rule — the government can pursue you, not just your customer, and “we’re just the software vendor” is not a defense.

You might not be a business associate if you never touch PHI on behalf of a covered entity — a genuinely direct-to-consumer wellness app where users volunteer their own data can fall outside HIPAA (though other laws like the FTC Health Breach Notification Rule and state privacy laws may still apply). But that line is thinner than founders assume, and it moves the instant you sign your first clinic or payer. If you subcontract PHI to your own vendors, they become your subcontractors and need BAAs too — the obligations flow down the whole chain. When in doubt, assume you’re in scope and be pleasantly surprised if counsel says otherwise.

A HIPAA compliance checklist for startups

Compliance isn’t a single certificate — it’s a set of safeguards you can demonstrate. This is the practical checklist, ordered by what protects you most:

1. Map your PHI. Document exactly what PHI you collect, where it’s stored, and every place it flows. This data-flow map underpins your risk analysis and every decision below.
2. Sign BAAs everywhere PHI goes — with your customers (they’ll require it) and with every subcontractor that touches PHI on your behalf.
3. Stay on HIPAA-eligible services. Cloud providers only cover PHI on specific services; keep an internal list and confirm each is eligible.
4. Encrypt in transit and at rest — TLS everywhere, KMS-backed encryption at rest. Cheap to do from day one.
5. Enforce real access control — unique logins, MFA, least privilege, role-based access to PHI, no shared accounts.
6. Turn on audit logging for PHI access and admin actions — and make sure the logs themselves don’t leak PHI.
7. Conduct a written risk analysis and address the risks it surfaces. This is an explicit Security Rule requirement and the document auditors ask for first.
8. Name a security officer (and privacy officer) responsible for the program.
9. Train your workforce on HIPAA basics and document that they completed it.
10. Write an incident response and breach notification plan — HIPAA has specific breach-notification timelines.
11. Manage backups and retention — encrypted, tested restores and a defined retention and secure-deletion policy.
12. Vet vendors for BAAs before you integrate them, not after.

Notice how much of this is documentation. HIPAA auditors and enterprise security reviewers ask for artifacts — policies, a risk analysis, signed BAAs, access logs — not verbal assurances.

Do startups need a HIPAA certification or audit?

There is no official “HIPAA certification” — HHS does not certify anyone, and any vendor claiming to sell you one is overstating what exists. What you can do is a third-party HIPAA assessment or attestation against the Security Rule, which many startups use to answer enterprise security reviews credibly. In practice, health-tech buyers increasingly ask for SOC 2 plus a HIPAA mapping, because SOC 2’s controls overlap heavily with the Security Rule’s technical and administrative safeguards. You don’t need any of this in month one. You need clean data flows, encryption, access control, audit logs, signed BAAs, and a written risk analysis — the substance that any assessment or customer review will look for anyway.

Frequently asked questions

Is my startup a HIPAA business associate? If you create, receive, maintain, or transmit PHI on behalf of a covered entity — a provider, health plan, or clearinghouse — then yes. Selling software to clinics, hospitals, or payers almost always makes you a business associate, and business associates are directly liable under HIPAA.

Is there an official HIPAA certification? No. HHS does not certify anyone as HIPAA compliant, so no vendor can sell you a legitimate “HIPAA certificate.” You can obtain a third-party assessment against the Security Rule, and many buyers accept SOC 2 with a HIPAA mapping — but compliance is something you demonstrate through safeguards, not a badge you earn.

What is PHI, exactly? Protected Health Information is health information tied to one of 18 identifiers — name, dates, geographic detail smaller than a state, email, phone, medical record number, device IDs, IP address, and more. If data can identify a person and relates to their health, care, or payment, treat it as PHI — including an appointment timestamp joined to a name or a patient email in a log line.

Do I need a BAA with every vendor? You need a signed BAA with any vendor that creates, receives, maintains, or transmits PHI on your behalf — your cloud provider, email/SMS sender, error tracker, analytics tool. The rule of thumb: if PHI flows to a vendor, you need a signed BAA with them, or that PHI cannot go there.

What does the HIPAA Security Rule require? Administrative, physical, and technical safeguards. Administrative: a named security officer, a written risk analysis, workforce training, access management, and an incident response plan. Physical: facility and device controls (largely inherited from your cloud provider if you’re all-cloud, plus your own workstation policy). Technical: access control, unique user IDs, audit logging, integrity controls, and encryption. “Addressable” controls aren’t optional — you implement them or document a defensible reason you didn’t.

If you want a fast, fixed-scope way to get there, I run a HIPAA Readiness Sprint that maps your PHI, closes the gaps that matter, and leaves you with the documentation auditors and enterprise buyers actually ask for.