If you sell software or services that touch US patient data, someone on your team has probably asked "do we need to be HIPAA compliant?" The honest answer is usually yes, but the term gets thrown around so loosely that most founders and engineering leads do not actually know what it requires. This guide breaks it down in plain language: what HIPAA is, who it applies to, what the work looks like, how long it takes, and where most teams get confused.
What HIPAA actually is
HIPAA stands for the Health Insurance Portability and Accountability Act, a US federal law passed in 1996. Most of what people mean today when they say "HIPAA compliance" refers to two later additions to that law: the Privacy Rule, which governs how protected health information (PHI) can be used and disclosed, and the Security Rule, which sets requirements for protecting electronic PHI (ePHI) with administrative, physical, and technical safeguards.
Unlike SOC 2 or ISO 27001, HIPAA is not a certification you earn from an accredited body. There is no HIPAA certificate, no official seal, and no government agency that hands out a pass or fail grade. HIPAA is a set of legal obligations enforced by the US Department of Health and Human Services (HHS) through its Office for Civil Rights (OCR). What vendors, partners, and enterprise health systems actually want to see is evidence that you have implemented the required safeguards and can demonstrate it on demand, usually through a security assessment, a signed Business Associate Agreement (BAA), and documented policies.
Who actually needs HIPAA compliance
HIPAA applies to two categories of organization. Covered entities are health plans, healthcare providers, and healthcare clearinghouses that handle PHI directly. Business associates are any vendor or contractor that creates, receives, maintains, or transmits PHI on behalf of a covered entity. This second category is where most digital health startups land.
If your product is a SaaS platform that stores patient records, a telehealth app, a billing tool for clinics, an analytics platform processing clinical data, or infrastructure that a healthcare provider relies on, you are almost certainly a business associate under HIPAA, whether or not you ever interact with a patient directly. The trigger is not "are you a hospital," it is "does PHI pass through your systems."
What the work actually involves
HIPAA readiness generally breaks down into three buckets:
- Administrative safeguards, including a documented risk analysis, workforce training, access management policies, incident response procedures, and a designated security official.
- Technical safeguards, including encryption of ePHI at rest and in transit, access controls and audit logging, automatic session timeouts, and integrity controls to detect unauthorized changes to data.
- Physical safeguards, which matter less for cloud-native teams but still cover things like workstation security and facility access controls if you run any on-premises infrastructure.
On top of the technical work, every business associate relationship requires a signed BAA with each covered entity (and with your own subprocessors who touch PHI, like your cloud hosting provider). Enterprise health systems will also increasingly ask for a third-party risk assessment or a completed security questionnaire before they will sign that BAA at all.
A common misconception: HITRUST is not HIPAA
This is where a lot of confusion happens. HITRUST is a private certification framework that maps to HIPAA requirements (among other frameworks) and produces a formal, auditable certificate. It is rigorous, expensive, and typically takes many months, and larger health systems sometimes require it specifically. But HITRUST certification and HIPAA compliance are not the same thing. You can be genuinely HIPAA compliant, with real safeguards, documented policies, and signed BAAs, without ever pursuing HITRUST.
For most digital health startups selling into mid-market and enterprise healthcare buyers, what actually unblocks a deal is a defensible readiness posture: a completed risk assessment, the right technical controls in place, documented policies, and a BAA your legal team is comfortable signing. HITRUST becomes relevant later, usually once a specific large customer contractually requires it. Our HIPAA compliance guidance for digital health companies is built around that readiness-first reality rather than assuming every company needs the heaviest possible framework on day one.
Realistic timelines
For a digital health company with a reasonably modern cloud stack (think AWS, GCP, or Azure with standard managed services), HIPAA readiness typically takes six to twelve weeks when the work is scoped properly. That includes the risk analysis, gap remediation, policy documentation, and getting BAAs in place with your key subprocessors. Companies with legacy infrastructure, unmanaged servers, or a sprawling list of subprocessors should expect the longer end of that range, or beyond it.
The biggest timeline killer is not the technical controls, most cloud providers make those straightforward. It is the documentation and the subprocessor BAA chase, which involves getting every vendor touching PHI (hosting, email, analytics, support tooling) to sign off, and that can drag if you have not inventoried your data flows ahead of time.
Where HIPAA and SOC 2 overlap
If you are a B2B SaaS company selling into US healthcare, you are very likely being asked for both HIPAA compliance and SOC 2 certification, often by the same buyer at different points in the sales cycle. The good news is that the two frameworks share a large amount of underlying evidence: access controls, encryption, incident response, vendor management, and audit logging all satisfy requirements in both. Running HIPAA readiness and SOC 2 preparation together, rather than as two separate projects months apart, means you build the evidence once and reuse it, instead of duplicating the same policy work twice for two different auditors. This is generally the more efficient path for a lean engineering team that does not have a dedicated compliance hire yet, and it fits well within a broader compliance program rather than a one-off exercise.
Getting started
The right first step is not writing policies, it is a gap assessment: what PHI you actually touch, where it flows, which safeguards you already have, and which are missing. That assessment tells you the real scope and the real timeline, instead of guessing based on a generic checklist. From there, the work is sequenced: fix the technical gaps that block a BAA, document the policies auditors and enterprise buyers expect to see, and get subprocessor agreements signed in parallel.
If you are trying to figure out where your team stands on HIPAA, or you are running into it because an enterprise health system is asking for proof before they will sign, get in touch and we will walk through what your specific stack and customer requirements actually call for.