HIPAA Compliance Checklist for SaaS Startups in 2026

Quick answer: HIPAA compliance for a healthcare SaaS in 2026 means meeting the Privacy Rule, Security Rule, and Breach Notification Rule, signing Business Associate Agreements with every covered-entity customer, and flowing BAAs down to every subprocessor that touches PHI. The Security Rule splits into administrative, physical, and technical safeguards — risk analysis, workforce training, access controls, audit logs, encryption in transit and at rest, and a documented incident response plan. This checklist is what we wish every healthcare SaaS team had on day one.

HIPAA is the framework every US healthcare SaaS startup eventually has to comply with — and the one that founders most often defer until a customer demands a Business Associate Agreement. By then the cost of retrofitting compliance into a product that wasn’t designed for it can be six figures and several months. The checklist below is the version we wish every healthcare SaaS team had on day one.

In plain language: HIPAA compliance for a SaaS handling Protected Health Information (PHI) means meeting the three rules — Privacy Rule (how PHI may be used and disclosed), Security Rule (administrative, physical, and technical safeguards), and Breach Notification Rule (what to do when something goes wrong) — plus signing a Business Associate Agreement (BAA) with every covered entity customer, and being prepared to flow BAAs downstream to your subprocessors.

Are you actually inside HIPAA?

HIPAA applies if you handle PHI on behalf of a “covered entity” — health plans, healthcare providers conducting standard electronic transactions, or healthcare clearinghouses. As a SaaS, you are typically a Business Associate when your customer is a covered entity and you handle PHI on their behalf.

If your product is consumer-direct (e.g., a wellness app where the user is the customer, not a healthcare provider), you may be outside HIPAA but still inside other regimes — state privacy laws, the FTC Health Breach Notification Rule, and depending on geography, GDPR / India DPDP Act.

The 18 PHI identifiers

HIPAA defines PHI as any individually identifiable health information combined with any of the 18 identifiers: names, all geographic subdivisions smaller than a state, dates (other than year), phone, fax, email, SSN, MRN, health plan beneficiary numbers, account numbers, certificate/license numbers, vehicle identifiers, device identifiers and serial numbers, URLs, IP addresses, biometric identifiers (including fingerprints and voice prints), full-face photographs, and any other unique identifying number, characteristic, or code.

De-identified data — where all 18 are removed or the data is statistically de-identified per HIPAA Safe Harbor or Expert Determination — falls outside the framework.

The checklist — Privacy Rule

• Maintain a written Notice of Privacy Practices describing how PHI is used and disclosed
• Establish the minimum necessary standard — collect, use, and disclose only what is needed for the purpose
• Define permitted uses and disclosures (treatment, payment, healthcare operations, and limited public-interest exceptions); everything else needs authorisation
• Honour patient rights — access to records, amendment, accounting of disclosures, restrictions, confidential communications
• Track and respond to patient requests within the prescribed timelines
• Maintain records of disclosures for the prescribed retention period

The checklist — Security Rule

The Security Rule splits into administrative, physical, and technical safeguards. Required items must be implemented exactly as written; addressable items must be assessed and documented even if not implemented identically.

Administrative safeguards:

• Designate a Security Officer
• Conduct an annual risk analysis (HHS publishes the Security Risk Assessment tool)
• Run a risk management programme that mitigates identified risks
• Implement workforce sanction policies for HIPAA violations
• Provide workforce training at hire and periodically
• Authorise / supervise workforce access to PHI based on role
• Manage information access — grant, modify, revoke
• Conduct periodic security evaluations
• Have contingency plans — backup, disaster recovery, emergency mode operation
• Sign BAAs with every subprocessor that may touch PHI

Physical safeguards:

• Control physical access to facilities housing PHI (data centres, offices)
• Maintain workstation use policies
• Manage device and media controls — including secure disposal

Technical safeguards:

• Implement access controls — unique user IDs, automatic logoff, emergency access
• Implement audit controls — logs of access to PHI, retained per policy
• Implement integrity controls — protect PHI from improper alteration
• Implement authentication — verify the identity of users
• Implement transmission security — encryption of PHI in motion

Encryption itself is technically “addressable” in the Security Rule but in modern practice is treated as effectively required — both because addressable still requires documented alternatives and because OCR enforcement has emphasised encryption.

HHS issued a Notice of Proposed Rulemaking in late 2024 that would tighten several Security Rule requirements (including making encryption explicitly required and adding network segmentation, MFA, and vulnerability management mandates). Confirm the final rule status before publishing.

The checklist — Breach Notification Rule

• Define an incident response plan with documented decision criteria for whether an incident constitutes a breach
• Notify affected individuals without unreasonable delay and not later than 60 days after discovery
• Notify HHS — within 60 days if the breach affects 500+ individuals; annually for smaller breaches
• Notify prominent media if the breach affects 500+ individuals in a state or jurisdiction
• Maintain a breach log with details for the prescribed retention period

Business Associate Agreement essentials

Every BAA must address (per 45 CFR §164.504(e)):

• Permitted and required uses and disclosures of PHI
• Prohibition on further use / disclosure beyond what the BAA permits
• Requirement to use appropriate safeguards
• Requirement to report breaches to the covered entity
• Requirement to ensure subcontractors agree to the same restrictions (flow-down)
• Requirement to make PHI available to the individual and for accounting
• Requirement to make books and records available to HHS for compliance review
• Return or destruction of PHI on termination

Have a template ready. Customers will negotiate, but starting from your reasonable template is faster than reviewing theirs each time.

Common SaaS HIPAA mistakes

1. Logging PHI in application logs — and shipping those logs to a non-BAA logging vendor (Sentry, Datadog) without their HIPAA-tier plan
2. Email-based PHI — sending PHI over standard email channels, including support tickets
3. Subprocessors without BAA — every vendor that may see PHI needs a BAA (cloud, email, analytics, CDN, CRM)
4. Open access controls — engineers with prod database access without break-glass workflows
5. Audit log gaps — patchy access logging that can’t reconstruct an incident
6. No annual risk analysis — required, often skipped, easy enforcement target

What this realistically costs to operate

Initial HIPAA-readiness for a small SaaS is typically a multi-month effort with non-trivial budget — HHS-aligned policies, technical safeguards build, BAA template and process, training, and the initial risk analysis. Annual recurring cost includes the risk analysis refresh, training, security tooling, audit log retention, and (for many SaaS) a SOC 2 Type II audit alongside, since enterprise customers expect both.

CTA: OpenMalo’s HIPAA toolkit module bundles the policy templates, audit log infrastructure, BAA workflow, and risk analysis cadence as a single subscription — designed for SaaS teams getting to HIPAA-ready in weeks, not quarters. See the module →

Closing

HIPAA-ready is a posture, not a milestone. The SaaS teams that operate well treat the checklist as a living programme — refreshed annually, tested through tabletop exercises, audited through SOC 2 — and they sleep better when a customer’s procurement team asks for a BAA.