HIPAA for Digital Health Startups: What Actually Triggers It

Few regulatory frameworks make digital health founders sweat quite like HIPAA.

Some of that anxiety is entirely justified. HIPAA has real enforcement teeth, and the healthcare sector attracts regulators who are happy to use them.

But much of the panic comes from a simpler place: founders are not always sure whether the law even applies to their product. Legal guidance can be expensive, and sometimes more cautious than necessary.

So let’s cut through the noise. Here is a practical guide to what actually triggers HIPAA compliance for startups, and exactly what you need to do when it does.

The First Question: Covered Entity or Business Associate?

HIPAA applies to exactly two categories of organizations. If you are in neither, the law does not apply to you directly. If you are in one, it does.

Covered entities

• Health plans
• Health care clearinghouses
• Health care providers who transmit health information electronically in connection with covered transactions

If your company directly provides healthcare services or pays for them, you are likely a covered entity.

Business associates

Entities that perform functions or activities on behalf of a covered entity that involve using or disclosing protected health information (PHI).

If your SaaS product is used by hospitals, health plans, physician groups, or other covered entities, and it processes PHI on their behalf, you are a business associate.

The one question that decides it

> Does your product receive, create, maintain, or transmit PHI on behalf of a covered entity?

If yes, you are a business associate, and HIPAA applies.

A note on de-identified data

Using truly de-identified data does not make you a covered entity or a business associate. Properly de-identified data is outside HIPAA’s scope.

HIPAA recognizes two ways to de-identify data. The most commonly cited is the Safe Harbor method: removing 18 specific identifiers. The other is Expert Determination, where a qualified expert confirms the risk of re-identification is very small.

But here is the catch: ”de-identified” does not simply mean “we deleted the name column.” The 18 Safe Harbor identifiers include:

• Geographic data
• Dates (other than year)
• Telephone numbers
• Device identifiers
• Any other unique identifying characteristics

PHI that has been incompletely de-identified is still PHI.

What Counts as Protected Health Information?

PHI is individually identifiable health information. It requires two halves to be whole.

Part 1: Health information

Information about:

• Past, present, or future physical or mental health conditions
• The provision of health care to the individual
• Past, present, or future payment for health care

Part 2: Individually identifiable

This is the half that catches most startups off guard.

Information is individually identifiable if it identifies the individual, or if there is a reasonable basis to believe it could be used to identify them.

Health information linked to a name, email address, IP address, device identifier, or virtually any other common identifier can make it identifiable.

Where startups get surprised

Products that do not look like traditional “healthcare” can still end up handling PHI when they work on behalf of covered entities. For example:

• A wellness app collecting symptom-tracking data linked to user accounts, offered through a health plan or provider
• A telehealth platform delivering care for covered providers
• An employer benefits portal processing health insurance claims for a health plan
• A fitness tracker that uploads health data into a healthcare provider’s records

The deciding factor is always the same question: are you handling this data on behalf of a covered entity?

And if the answer is no, do not celebrate too quickly. Consumer health products outside HIPAA can still face other rules, such as the FTC’s Health Breach Notification Rule and a growing number of state consumer health data laws.

The Business Associate Agreement: No BAA, No PHI

When you are a business associate, HIPAA requires you to sign a Business Associate Agreement (BAA) with each covered entity customer before you receive their PHI.

A BAA is a contract addendum that spells out:

• Your obligations to protect PHI
• Your breach notification obligations
• The conditions under which you may use and disclose PHI

BAAs are not optional

No BAA means no legal authorization to process the PHI.

A covered entity that hands PHI to a vendor without a BAA is in violation. So is the vendor.

Your terms of service won’t cut it

Standard terms of service will not cover your SaaS HIPAA compliance requirements. BAAs have specific required provisions under the HIPAA Privacy and Security Rules.

Your legal team should have a standard BAA template reviewed by a HIPAA-experienced attorney.

Read theirs carefully

Enterprise covered entities will often bring their own BAA template. Review it closely. BAAs can include provisions more onerous than HIPAA actually requires, so know exactly what you are agreeing to before you sign.

The Security Rule: Technical Safeguards

Once you are a business associate, the HIPAA Security Rule applies to your electronic PHI (ePHI). It requires administrative, physical, and technical safeguards.

For modern software companies, the technical layer is where the work happens. Here is the baseline HIPAA technical safeguards checklist:

Access controls

Unique user identification, emergency access procedures, automatic logoff, and encryption and decryption of ePHI. Access to PHI should be limited to those who need it for authorized purposes. MFA for systems containing ePHI is standard practice.

Audit controls

Hardware, software, and procedural mechanisms to record and examine activity in systems containing ePHI.

• Logging is required.
• Log review is required.

Integrity controls

Measures that protect ePHI from improper alteration or destruction: checksums, version control, and audit trails for PHI modifications.

Person or entity authentication

Procedures to verify that anyone seeking access to ePHI is who they claim to be.

Transmission security

Encryption of ePHI in transit. TLS 1.2 or higher is the common standard for data in transit.

“Addressable” does not mean “optional”

The Security Rule labels some safeguards as either required or addressable. Understanding HIPAA addressable vs required controls is critical:

• Required: must be implemented.
• Addressable: must be implemented, or you must document, based on your risk analysis, why it isn’t reasonable and appropriate for your situation, and what alternative you are using instead.

That is not a loophole. It is a documentation obligation.

Changes on the horizon

HHS has proposed a major update to the Security Rule that would, among other things, eliminate the distinction between “required” and “addressable” safeguards. At the time of writing, the proposal is not yet final, and the current Security Rule remains in effect. It is worth tracking, because building toward stronger controls now (like encryption and MFA everywhere) puts you ahead either way.

Breach Notification: The Clock and the Safe Harbor

The timelines

Under the HIPAA Breach Notification Rule, time is the ultimate metric of security. The HIPAA breach notification rule timeline is strict:

• Business associates must notify covered entities without unreasonable delay, and no later than 60 days after discovering a breach of unsecured PHI.
• Covered entities must notify affected individuals within 60 days.
• HHS notification depends on size: breaches affecting 500 or more individuals must be reported to HHS within 60 days, while smaller breaches can be reported in an annual log.
• Media notification is also required for breaches affecting 500 or more residents of a state or jurisdiction.

The encryption safe harbor

“Unsecured PHI” is PHI that has not been rendered unusable, unreadable, or indecipherable using a technology or methodology specified in HIPAA guidance.

This is where the HIPAA encryption safe harbor changes the math. PHI encrypted according to NIST standards is considered secured. If the encryption keys were not compromised, a breach of that data does not trigger the notification requirement.

That is why encryption is not just a security best practice for HIPAA. It is one of the smartest compliance investments you can make.

Ready to Simplify Compliance?

Compliance asks whether you have a policy. Reality tests whether that policy works.

At Regodit, we build HIPAA compliance programs for digital health companies and business associates that bridge the gap between paper promises and operational reality. From BAA management to Security Rule technical safeguards and breach notification infrastructure, we align your controls with actual evidence.

Explore Regodit and schedule a demo with the team.