What Is HIPAA? A Plain-Language Guide (2026)

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 a SOC 2 report, 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.

Required versus addressable, the mechanic everyone gets wrong

The Security Rule splits its implementation specifications into two kinds, required and addressable, and "addressable" is the most misread word in the whole law. It does not mean optional. It means you must assess whether the specification is reasonable and appropriate for your environment, and if you conclude it is not, you must document that reasoning and implement an equivalent alternative measure where one is reasonable.

Encryption of ePHI at rest is addressable. So is encryption in transit, and automatic logoff, and several others. A team that skips them because the word "addressable" appeared next to them, with nothing written down, has not made a compliance decision. It has made an undocumented gamble that will look terrible in a breach investigation, because the first question after an incident is what you assessed and when.

In practice, for a cloud-native product in 2026, the honest analysis almost always lands on implementing encryption rather than justifying its absence, because managed services make it close to free. The value of understanding the mechanic is elsewhere: it tells you that the risk analysis is the foundational artifact of HIPAA, not the policies. Every addressable decision points back to it. A risk analysis that is a two-page template with no reference to your actual systems, data flows and threats cannot support any of those decisions, and OCR has been explicit for years that an inadequate risk analysis is among the most common findings it makes.

The Breach Notification Rule, and the safe harbor that changes everything

The third rule people forget to read is the one that governs the worst day. If unsecured PHI is acquired, accessed, used or disclosed in a way not permitted by the Privacy Rule, it is presumed to be a breach unless you can demonstrate through a documented risk assessment that there is a low probability the information was compromised. That assessment weighs the nature and extent of the PHI involved, who used or received it, whether it was actually acquired or viewed, and the extent to which the risk has been mitigated.

Timelines run fast. Covered entities notify affected individuals without unreasonable delay and no later than 60 days from discovery. Incidents affecting 500 or more residents of a state or jurisdiction require notice to HHS and to prominent media within that same period, and those appear on a public list that your prospects can and do read. Smaller incidents are logged and reported to HHS annually. As a business associate, your obligation is to notify the covered entity, and your BAA will almost certainly compress the statutory window down to something much shorter, often 5 to 10 days and sometimes 24 hours for confirmed breaches. Read that number before you sign, because it defines how fast your own detection and triage has to be.

The word "unsecured" is where the leverage sits. PHI rendered unusable, unreadable or indecipherable through encryption meeting the specified standards, or through proper destruction, falls outside the notification obligation. A lost laptop with full-disk encryption and verified key management is not a reportable breach. The same laptop unencrypted is a notification event with a public listing attached. That single architectural decision has more effect on your worst-case outcome than most of your policy set.

The BAA is a negotiation, not a form

Founders treat the Business Associate Agreement as paperwork to be signed as fast as possible so the deal can move. The clauses inside it decide what your obligations actually cost.

Watch the breach notification window, as above. Watch the subcontractor flow-down requirement, which obliges you to bind every downstream vendor touching PHI to equivalent terms, and then go and check that you have actually done it rather than assuming your hosting provider covers everyone. Watch the return-or-destroy obligation on termination, and confirm you can technically do what you are promising, including in backups. Watch for provisions that grant the covered entity broad audit rights on short notice, which large health systems ask for and which are survivable but need someone to own. Watch indemnity and any carve-out from the liability cap for data incidents, because that clause is where a mid-size breach becomes an existential one.

On the vendor side, the major cloud providers all offer a BAA, and every one of them covers only a defined list of HIPAA-eligible services. The recurring failure is a team that signs the BAA, assumes the whole account is covered, and then ships a feature using a newer managed service that is not on the list. Check the list against your architecture diagram whenever you adopt a service, and record the check. That is a fifteen-minute task that prevents a genuinely painful conversation.

Where PHI leaks out of the boundary you drew

Almost every gap assessment we run finds PHI somewhere outside the systems the team believed were in scope. The pattern is consistent enough to list.

Application logs and stack traces containing request bodies with patient identifiers. Error monitoring tools capturing the same payloads and shipping them to a vendor with no BAA. Product analytics firing events that include a record identifier plus enough context to re-identify. Support tickets where a customer pasted a patient record into a chat widget. Data warehouse copies made for a reporting project and never governed. Local exports on a developer laptop, made once for debugging, still there eighteen months later. And increasingly, PHI sent into a large language model API by a feature team that never asked about retention, training use or subprocessing.

The remedy is boring and it works: scrub identifiers before logging, put an allow-list on what your analytics can send, disable payload capture in error tracking, and treat every new outbound integration as a data flow change that has to be reviewed. The alternative is discovering the leak during a customer's security review, which is how most teams discover it.

De-identification is worth understanding properly, because it is the only way to get data legitimately out of scope. HIPAA offers two routes: the Safe Harbor method, which requires removing eighteen specified categories of identifier and having no actual knowledge that the remainder could identify someone, and expert determination, where a qualified statistician documents that the re-identification risk is very small. Stripping names and calling the result anonymous is neither of those things. Dates of service, ZIP codes and device identifiers are all on the Safe Harbor list and all commonly left in.

Enforcement, and what actually triggers it

OCR does not audit companies at random in any meaningful volume. Enforcement is driven by two things: individual complaints, and breach reports you filed yourself. That is the practical shape of the risk. Your notification obligation is what puts you in front of the regulator, which is another reason the encryption safe harbor matters so much.

Civil penalties are tiered by culpability, from a genuine lack of knowledge at the low end up to willful neglect left uncorrected at the high end, with annual limits set by statute and adjusted for inflation. The tier is decided largely by what you can show you did before the incident, which is to say the risk analysis, the training records and the remediation history. Many resolutions end in a corrective action plan with monitoring rather than a headline fine, and a corrective action plan is expensive in a different currency: years of reporting obligations while you are trying to run a company. State attorneys general also hold enforcement authority, and some states layer their own health privacy statutes on top with stricter terms.

Being Canadian does not put you outside this

A Toronto or Montreal company selling a platform to a US clinic network is a business associate under a US federal law, and the location of your office does not change that. Nor does hosting in a Canadian region, though your US customers will ask where the data lives and some will have their own constraints about it. You will also be carrying PIPEDA obligations for any Canadian personal information, and Ontario's PHIPA or Quebec's Law 25 if you touch health information on this side of the border, each with its own breach reporting rules that run independently of HIPAA's.

The practical consequence is that you need one control set with a mapping, not three separate compliance efforts. Access control, encryption, logging, incident response and vendor management satisfy requirements in all of them. What differs is notification timing, the regulator you contact, and the documentation each expects. Build the controls once, then maintain a short mapping document that says which obligation each control serves. That document is also the thing that makes your next audit or questionnaire fast rather than painful, and it is exactly what an ongoing continuous compliance retainer is meant to keep current.

When you should not spend money on HIPAA readiness

Some of the best advice we give on a first call costs the caller nothing.

You may not be touching PHI at all. A tool used by a clinic's marketing team, with no patient identifiers flowing through it, is not automatically in scope because the customer is a healthcare provider. Map the data first. Companies talk themselves into a compliance program on the strength of their customer's industry rather than their own data flows.

Architecting PHI out of scope beats complying with it. If a feature can work with a tokenized reference instead of a patient record, or if the identifiable data can stay inside the customer's environment while you process only derived values, you have removed cost permanently. That analysis is engineering work, not compliance work, and it is worth doing before you hire anyone to write policies. The cheapest control is the data you never received.

Your buyer may want less than a full program. Sometimes what unblocks a deal is a signed BAA, a completed security questionnaire, evidence of encryption and access control, and a named security official. Ask the buyer's security contact what they actually require before assuming the answer is a six-figure effort or a HITRUST engagement.

Nobody can sell you a HIPAA certificate, including us. If a vendor offers one, what you are buying is a logo and their own assessment opinion. That has some marketing value and no regulatory standing. We would rather you spent the money on the risk analysis and the technical gaps it finds. If you want to start that yourself, the free traztech Workspace holds the risk register, evidence and BAA tracking without an engagement attached, and plenty of teams get their first honest picture that way before they call anyone.