HIPAA for Telehealth Startups: The Minimum Viable Compliance Stack

First: are you actually a covered entity?

You become a HIPAA covered entity by conducting one of the standard electronic transactions listed in 45 CFR Part 162, claims, eligibility checks, prior authorization, claim status and so on, not by taking money for care. The definition at 45 CFR 160.103 covers a health care provider who transmits any health information in electronic form in connection with a transaction covered by the rules. A practice that is genuinely cash-only and never runs one of those transactions, itself or through a vendor, may sit outside that definition.

Treat that as a fact to confirm with counsel, not as a compliance strategy, because the position is narrow and fragile in three specific ways. One transaction ever is enough to flip it, and there is no way to flip it back: a single eligibility integration, a superbill you file on a patient's behalf, a billing vendor acting for you. The definition of health care provider also reaches anyone paid for health care in the normal course of business, which a DTC brand collecting payment arguably is. And falling outside HIPAA moves you into the FTC's jurisdiction rather than out of regulation altogether, which is a trade most founders would not make on purpose.

What still applies to a provider genuinely outside HIPAA: state health-privacy law, which in Washington, Nevada and Connecticut now reaches consumer health data directly; the FTC Act's prohibition on deceptive privacy and security claims; the FTC Health Breach Notification Rule; and every obligation you signed up for in your own vendor contracts. The practical answer for almost every telehealth program is to build the HIPAA stack regardless, because your partners will require it contractually even where the statute does not.

Do not write, or believe, that cash-pay telehealth is not covered by HIPAA. The trigger is a Part 162 standard transaction, not the payment model, one transaction ever is enough, and a vendor doing it for you counts.

Who signs what, in an MSO and friendly-PC structure

In the standard structure the professional corporation delivers care and is the covered entity, and the management company that runs the brand, the storefront and the operations is typically a business associate of it. Typically, not automatically: whether the PC is a covered entity at all depends on the transaction question above, and whether your staff are the PC's workforce rather than a business associate depends on whose direct control they work under. Both of those are structural facts about your own company, and both are worth getting a written answer to before you paper the relationship.

One structural trap is worth naming because it catches people who have read just enough. The affiliated covered entity designation, which lets legally separate entities be treated as one for HIPAA purposes, requires common ownership or control. Friendly-PC structures are built specifically to avoid common ownership. So the shortcut that would simplify your paperwork is usually unavailable to you by design, and the BAA chain is the mechanism you actually have.

That chain runs all the way down. A business associate must obtain satisfactory assurances, in a written agreement, from any subcontractor that creates, receives, maintains or transmits protected health information on its behalf. Your email platform's subprocessor is in scope. So is the analytics tool your growth team added last week. The practical version of this rule is a vendor inventory that lists, for every tool touching patient data, who signed a BAA with whom and when.

• Which entity is the covered entity, in writing, with the transaction question answered
• Whether operations staff are the PC's workforce or the management company's business-associate personnel
• A signed BAA between the PC and the management company, dated before any patient data moved
• A BAA with every vendor that touches patient data, and confirmation that they hold BAAs with their own subprocessors
• The breach-notice clock in each BAA, which is usually far shorter than the regulation's and is the clock you will actually live under

The Security Rule has five sections, not three

The familiar summary is administrative, physical and technical safeguards. The regulation says more than that: 45 CFR 164.306(c) requires compliance with sections 164.308, 164.310, 164.312, 164.314 and 164.316. The two usually left out are organizational requirements, which is where business associate contract content lives, and policies, procedures and documentation. That omission has a predictable consequence: startups build the controls and never write the documents, and documentation gaps are among the most-cited findings when a regulator does look.

The second widespread error is reading addressable as optional. 45 CFR 164.306(d) sets out what it actually obliges: assess whether the specification is reasonable and appropriate in your environment, then implement it; or, if it is not, document why not and implement an equivalent alternative measure if an equivalent alternative is itself reasonable and appropriate. Read that last condition carefully, because it is the part usually lost in both directions. It does leave a path where you document the assessment and implement no alternative, so addressable is not a disguised requirement. What it never permits is skipping the assessment, or treating the underlying standard as optional: the standard is always mandatory, and only the named implementation specification is flexible. The obligation addressable creates is therefore a documented decision, and the document is the deliverable.

HHS has said this in its own words, in the Federal Register. Discussing entities that treat addressable specifications as optional, it wrote in the January 2025 proposed Security Rule that this interpretation is incorrect and weakens the cybersecurity posture of regulated entities. Note what that quote is and is not: the proposed rule is not final, but the sentence is the agency describing what the existing regulation already means. In the same preamble it observed that encryption is built into most software today and that regulated entities should already have implemented it in most circumstances, which is worth reading before deciding your program is the exception.

The one implementation specification that is expressly required, not addressable, is the risk analysis at 164.308(a)(1)(ii)(A): an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of electronic protected health information you hold. It is required, it is the foundation every other decision is justified against, and it is the document a startup is least likely to have.

Encryption is the highest-leverage control you own

Encryption sits in an odd place: it is addressable in the Security Rule, and it is also the thing that switches off breach notification entirely. The mechanism runs in three steps. The notification duty attaches only to unsecured protected health information. Unsecured is defined at 45 CFR 164.402 as information not rendered unusable, unreadable or indecipherable through a technology or methodology specified in HHS guidance. And that guidance, published with the breach notification rule in 2009, names encryption meeting the relevant NIST standards, and destruction, as the two qualifying methods.

So an encrypted laptop that walks out of an office is, in the regulation's terms, not a breach of unsecured information at all. That is the highest leverage available in the entire compliance stack, and it is the reason the addressable label misleads people about priority.

Three qualifications decide whether the safe harbor actually holds for you. It fails if the key was compromised too, which is what happens when keys live in the same environment or the same repository as the data. It is about the state of the data at the moment of the incident, not about whether your marketing says the product is encrypted, so data decrypted in application memory, in a debug log, in an analytics export or inside a support tool is unsecured information. And the referenced NIST publications are the 2009 ones, so treat them as a floor and a direction rather than as current cryptographic advice.

The safe harbor is not a claim you make, it is a state your data was in. Keys stored beside the data, or a support tool that renders records in plaintext, quietly removes it.

The breach clock, with the numbers most articles get wrong

Start with the thing that changed in 2013 and is still misreported: there is no harm threshold. Under 45 CFR 164.402(2), an impermissible acquisition, access, use or disclosure is presumed to be a breach unless you demonstrate a low probability that the information was compromised, based on a risk assessment covering at least the nature and extent of the information, who received it, whether it was actually acquired or viewed, and the extent to which the risk was mitigated. The burden runs your way, and the assessment is a document you produce, not a judgment you make in your head.

Individuals must be notified without unreasonable delay and in no case later than 60 calendar days after discovery. Discovery is the first day the breach is known, or would have been known by exercising reasonable diligence, with knowledge imputed from any workforce member or agent other than the person who caused it. So the clock starts on constructive knowledge, not on the day the incident report lands.

The two thresholds above that are not the same number, and this is the detail worth getting right. Media notice is triggered by a breach involving more than 500 residents of a state or jurisdiction. Notice to HHS is triggered at 500 or more individuals. A breach affecting exactly 500 people requires HHS notice and does not require media notice. For those larger breaches the HHS filing is due contemporaneously with the individual notice, not merely within 60 days: sending individual notices on day ten and filing with HHS on day fifty-five is not compliant. Breaches under 500 individuals go into a log filed within 60 days of the end of the calendar year.

Two more that matter for a vendor-heavy stack. A business associate notifies the covered entity, not individuals, and gets the same 60-day outer limit, but BAAs routinely shorten that contractually to 24 or 72 hours, and the contract clock is usually the real one. And 60 days is a ceiling rather than a target: every deadline reads without unreasonable delay and in no case later than, several state breach laws run shorter and in parallel, and sitting on a notice for 59 days with no reason is its own problem.

• Individuals: without unreasonable delay, at most 60 calendar days after discovery
• HHS, 500 or more individuals: contemporaneously with the individual notice
• Media, more than 500 residents of a state or jurisdiction: same 60-day outer limit
• Under 500 individuals: an annual log, filed within 60 days of year end
• Business associate to covered entity: 60 days by regulation, far shorter in most contracts

Your cloud vendor is not a conduit

The conduit exception is the most abused idea in vendor conversations, and the first thing to know about it is that it appears nowhere in the regulations. It is an interpretation from the preamble to the 2013 Omnibus Rule, and it is narrow by construction: it covers entities that transmit information transiently, the postal service or an internet service provider, not entities that maintain it.

The preamble is explicit that an entity maintaining protected health information on behalf of a covered entity is a business associate and not a conduit even if it does not actually view the information. Storage is maintenance, so a cloud host is a business associate. Encryption does not change that, and a vendor holding no decryption key does not change it either. If a vendor tells you it is a mere conduit because it cannot read your data, it is describing a distinction the rule does not draw.

There is no such thing as HIPAA certification

Nothing in 45 CFR Parts 160, 162 or 164 creates, recognizes or accredits a HIPAA compliance certification, and no federal body issues one. When a vendor says HIPAA certified, the accurate translation is that it paid an auditor or a training company. That is not necessarily worthless, but it is not a legal status and it is not a substitute for the one document that actually allocates responsibility.

Three real things exist and get confused with it. An independent audit against a framework, SOC 2, HITRUST or ISO 27001, tells you something genuine about a vendor's controls and is not a HIPAA finding. The ONC health IT certification program certifies software products against criteria in 45 CFR Part 170, and HHS's own framing is that adopting certified health IT could contribute to Security Rule compliance, not constitute it. And recognized security practices under the HITECH amendments are a mitigation factor a regulator must weigh in your favor when setting penalties, which is the closest thing to credit for doing the work.

The corollary points back at your own marketing. Claiming HIPAA certified on your site is not merely inaccurate; it is a representation to consumers, and the FTC enforces deceptive privacy and security claims whether or not you are a covered entity. What you need from a vendor is a signed BAA. Be precise about what that buys, though: since the 2013 Omnibus Rule, business associates are directly liable for their own obligations under the rules, and a covered entity does not shed its obligations by signing one. The BAA defines the relationship and creates the vendor's duties. It is not a transfer of your liability, and it is not a substitute for diligence on the vendor or for negotiating indemnities, which are a separate contractual question. What you should say about yourself is what you actually do.

Ask a vendor for the BAA, not the badge. The badge is a purchase; the BAA is what creates that vendor's own direct obligations under the rules. It does not move your liability off you, and the money question is a separate negotiation about indemnities.

What sits outside HIPAA and still binds you

The FTC Health Breach Notification Rule covers vendors of personal health records not covered by HIPAA, and its exclusion is activity-scoped rather than entity-scoped: an entity is excluded to the extent that it engages in activities as a business associate. So a company can be inside HIPAA for one line of business and inside the FTC rule for another, which is the ordinary shape of a DTC health company running an app alongside a clinical service. The rule was amended in 2024 and the amendments took effect that July.

Advertising trackers are the most common way a telehealth company creates an incident without an intrusion, and they are reachable under both regimes: an unauthorized disclosure under the FTC rule, and an impermissible disclosure under HIPAA where the entity is covered. Our tracking-pixel guide covers the architecture, and the short version is that the problem is not the pixel but the combination of identity with health-condition interest in a transmission to a company that owes your patients nothing.

On penalties, one detail is worth knowing because almost no article carries it: two sets of annual caps are in force at the same time. The four culpability tiers are unchanged, the per-violation figures are adjusted for inflation each year and currently top out around seventy-three thousand dollars, but a 2019 enforcement notice that HHS said applies indefinitely sets much lower annual caps for the first three tiers, including a first-tier cap of twenty-five thousand dollars, while the regulation's own table sets a single higher cap across all four. Both are current. Anyone quoting one number for the annual maximum is quoting half the picture.

What is coming, and what is not

In January 2025 HHS proposed a substantial strengthening of the Security Rule that would, among other things, make most addressable specifications required. As of September 8, 2026 it is not final. It is not at the Office of Management and Budget for review, the Security Rule sections of the CFR have not changed since the 2013 Omnibus Rule, and HHS has moved the rulemaking to long-term actions with projected final action in July 2027. Anything you read describing the new Security Rule as current is describing a proposal.

The rule that is genuinely close is a different one: a HIPAA Privacy Rule final rule touching the individual right of access has been at the Office of Management and Budget since April 2026. Neither of these changes what you should build today, and the January 2025 preamble is useful precisely because it tells you what the existing rule already means. This section is the fastest-rotting content on this page; re-check the docket before relying on it.

The minimum viable stack, in build order

Order it by what unblocks the next thing rather than by what feels urgent. Settle the entity question first, because everything downstream depends on who is the covered entity and who is a business associate. Then the risk analysis, because it is expressly required and every later decision is justified against it. Then encryption at rest and in transit with keys held separately, because it is the one control that turns reportable events into non-events. Then the vendor inventory and the BAA chain, because that is where a startup's actual exposure lives. Then the policies and documentation, because 164.316 is a section of the rule and not paperwork you add later.

Then rehearse the parts that only work if practiced: who declares an incident, who runs the four-factor assessment, which contractual clock is shortest, and who sends what to whom. And keep the marketing site honest, since the claims layer is enforced by an agency that does not care whether you are a covered entity. Our website compliance checklist covers the observable half of that, and the tracking-pixel guide covers the part your growth team is most likely to break.

• Entity map: who is the covered entity, who is a business associate, who is workforce
• The required risk analysis, written down and dated
• Encryption at rest and in transit, with keys stored apart from the data
• A vendor inventory with a signed BAA per vendor and confirmation of their subprocessor BAAs
• Policies, procedures and documentation under 164.316, not just controls
• An incident procedure that names the shortest contractual clock you are actually bound by
• Marketing claims about privacy and security that match what the stack does