I review a lot of security questionnaires from early-stage healthtech companies, and the same gap shows up constantly: the team believes they are HIPAA compliant because they encrypted the database and wrote a privacy policy. HIPAA is not a feature you ship. It is an operating discipline across three rules, and hospitals will test all three before they sign anything.

Are you actually inside HIPAA?

The first question is not "are we compliant," it is "does HIPAA even apply to us." You are a covered entity or a business associate if you create, receive, maintain, or transmit protected health information (PHI) on behalf of a covered entity. A huge number of consumer wellness apps genuinely sit outside HIPAA because they never touch a covered entity's data. The moment you sign your first contract with a hospital, health plan, or clinician group, that changes, and it changes retroactively for every system touching that data path. Know your status before your first enterprise conversation, because the compliance obligations differ meaningfully by entity type.

The 18 PHI identifiers you need to actually track

HIPAA defines PHI by 18 identifier categories, not just obviously medical fields. Name, dates tied to an individual, geographic subdivisions smaller than a state, phone and fax numbers, email, Social Security numbers, medical record numbers, device identifiers, IP addresses, and biometric identifiers all count. Most engineering teams under-scope what counts as PHI in their own logs and analytics pipelines, which is the most common source of an accidental HIPAA violation: a debug log or an analytics event stream that captures an identifier nobody flagged as sensitive.

Privacy Rule checklist

  • Notice of Privacy Practices drafted and posted, if you are a covered entity.
  • Minimum necessary standard applied: every internal role only sees the PHI fields it needs, not the full record by default.
  • Patient rights process defined: access requests, amendment requests, and accounting of disclosures have an actual workflow, not just a policy sentence.
  • Data use agreements in place for any de-identified or limited data set sharing.

Security Rule checklist

  • Access controls: role-based access, unique user IDs, automatic session timeout.
  • Audit controls: logging of who accessed what PHI and when, retained and reviewable.
  • Encryption: at rest and in transit, using current standards, not a legacy cipher suite nobody has reviewed in three years.
  • Risk analysis: a documented, periodically updated security risk assessment. Auditors ask for this document by name.
  • Workforce training: documented, annual, role-specific, not a one-time onboarding slide deck.
  • Incident response plan: written, tested, with a named owner and a communication tree.

Breach Notification Rule checklist

  • A defined process to determine if an incident meets the breach threshold, using the four-factor risk assessment.
  • Notification timelines mapped: affected individuals within 60 days, HHS notified on the appropriate schedule based on the size of the breach, media notification if the breach affects 500 or more residents of a state.
  • A pre-drafted notification letter template, so you are not writing one under legal review pressure during an actual incident.

Business Associate Agreements: the one document every deal needs

If you are a vendor touching PHI on behalf of a covered entity, you need a signed BAA with them, and you need a signed BAA with every subprocessor of yours that touches that data too, including your cloud host, your analytics vendor, and any AI model provider you call. A BAA for every vendor is one of the two documents virtually every entity needs, and missing a subprocessor BAA is one of the most common findings in a hospital's vendor risk review.

Common mistakes that stall enterprise deals

  1. Treating HIPAA as a legal document instead of an engineering control. A privacy policy without access logging and encryption in the actual codebase does not survive a technical review.
  2. No signed BAA with a third-party AI API. If your product calls a large language model API and PHI passes through that call, you need a BAA with that provider, and not every API provider offers one by default.
  3. Logging PHI into general-purpose observability tools. Error tracking and analytics platforms are a frequent, unintentional PHI leak point.
  4. No documented risk assessment. This is the single most requested artifact in enterprise security reviews and the one founders most often do not have.
  5. Confusing HIPAA compliance with SOC 2. They overlap but are not the same. A SOC 2 report accelerates a hospital's trust, it does not replace a HIPAA risk assessment.

The takeaway

HIPAA compliance is not a certificate you earn once. It is an operating posture that a hospital's security and compliance teams will probe from multiple angles: your access logs, your subprocessor BAAs, your incident response plan, and your risk assessment document. Build these five artifacts before your first enterprise conversation and you remove the most common reason healthtech deals stall for months in security review.