MOFU Compliance Checklist · 2026

HIPAA Compliance Checklist for Startups

A practical readiness checklist for health-tech startups: the administrative, physical, and technical safeguards, the BAAs, and the program work that turns a well-built system into a posture you can actually defend in an audit.

By Bill Beltz, founder of QUANT LAB USA INC · Published June 3, 2026

Quick answer: what does HIPAA readiness require?

Five things, all documented: signed Business Associate Agreements with every vendor that touches PHI; the three categories of Security Rule safeguards (administrative, physical, technical); a completed Security Risk Analysis with a remediation plan; workforce training and written policies; and an incident response plan that meets the 60-day breach-notification window. Architecture gets you encryption and access control — this checklist is the program wrapped around it. Plan three to six months from a clean start, and treat it as an ongoing operating rhythm, not a one-time project.

Not legal advice. QUANT LAB USA is a software engineering and cybersecurity firm, not a law firm. HIPAA applicability and your specific obligations are determinations for qualified counsel and your compliance advisors. This checklist is operational and engineering guidance to get a startup audit-ready, not a substitute for legal review of your program.

We build health-tech startups to HIPAA readiness as part of every engagement at QUANT LAB USA, and the pattern is consistent: the engineering is usually further along than the program. Founders encrypt PHI and lock down access, then stall on the risk analysis, the BAAs, and the policies an auditor actually asks to see first.

This post is the checklist. For the build itself, read its companion: HIPAA-Compliant SaaS Architecture, and the primer What is HIPAA compliance?

Step 0: confirm scope and roles

Determine whether you are a Covered Entity or a Business Associate. Most startups are Business Associates serving healthcare customers.
Define what counts as PHI in your product and exactly where it enters, lives, and leaves.
Name a security official and a privacy point of contact, even if it is the same founder wearing both hats for now.
Decide the boundary of your in-scope systems so the rest of the checklist has a clear target.

Administrative safeguards checklist

The program and people controls — the category auditors open with.

Security Risk Analysis (SRA). Documented, methodical (NIST 800-30 works well), with risks scored and a remediation plan. This is the single most-skipped requirement.
Risk management plan. Owners, timelines, and residual-risk decisions recorded.
Written policies and procedures. Acceptable use, access management, incident response, sanction policy, contingency plan.
Workforce training. Security awareness at onboarding and at least annually, with completion records.
Access authorization and termination. A defined process to grant, review, and revoke access; offboarding revokes access promptly.
Designated security official. A named person responsible for the program.
Business Associate management. An inventory of vendors and the BAAs covering them (see below).
Contingency plan. Backups, disaster recovery, and a tested restore procedure.

Physical safeguards checklist

Even a fully cloud-hosted, remote-first startup owns part of this category.

Facility access. For your cloud, this is largely inherited from the provider's SOC reports — keep those on file as evidence.
Workstation security. Full-disk encryption, automatic screen lock, and a clear policy for devices that can access PHI.
Device and media controls. Mobile device management, a process for decommissioning hardware, and rules against PHI on personal/unmanaged devices.
Remote-work policy. Locked screens, no PHI on local downloads, secured home networks where feasible.

Technical safeguards checklist

The software controls. This is where the checklist meets the architecture.

Access control. Unique user IDs, no shared accounts, RBAC enforced at the data layer — not just hidden in the UI.
Authentication. MFA on all workforce access to PHI systems; SSO for admin.
Encryption. AES-256 at rest, TLS 1.2+ in transit, managed keys.
Audit controls. Immutable logs of PHI access (read/create/update/delete) with six-year retention and anomaly alerting.
Integrity protection. Controls to detect improper alteration or destruction of PHI.
Automatic logoff. Idle sessions time out.
Minimum-necessary access. Just-in-time elevation for support, with reason capture.
PHI redaction in logs. Scrub PHI at the application boundary so it never reaches a tool without a BAA.

The implementation details for each of these live in the HIPAA architecture guide; access control specifically benefits from Postgres row-level security.

Business Associate Agreements checklist

A BAA is required with every vendor that touches PHI on your behalf. Verify the specific service is BAA-eligible, not just the brand.

Vendor category	BAA needed?	Note
Cloud hosting	Yes	Confirm the specific services are HIPAA-eligible
Database	Yes	Verify the managed tier qualifies
Email / SMS	Yes if PHI flows through	Standard tiers are often NOT covered
Error tracking / logging	Yes	Or redact PHI before it leaves your app
Analytics	Yes if it sees PHI	Field-level scrubbing required otherwise
AI / LLM APIs	Yes	Use BAA-covered tiers or self-host
Marketing site analytics	Usually no	Only if no PHI is ever present

Incident response and breach notification checklist

Written incident response plan with severity levels and a named incident commander.
Breach assessment protocol — what starts the 60-day notification clock for breaches affecting 500 or more individuals.
Notification templates prepared for regulators and affected individuals.
Forensic readiness — log retention and an evidence-collection procedure.
An annual tabletop exercise, documented.

Ongoing operating rhythm

HIPAA is maintained, not achieved once. A workable cadence:

Quarterly: access reviews, audit-log review, vendor/BAA check, backup-restore test.
Annually: full Security Risk Analysis refresh, workforce training, incident response tabletop, and an independent penetration test on PHI-handling systems.
Continuously: dependency scanning and patching, monitoring and alerting, prompt deprovisioning on offboarding.

On testing, see pen test vs vulnerability scan and our web app pentest service.

FAQ

Does my startup actually fall under HIPAA?

You fall under HIPAA if you are a Covered Entity (a health plan, healthcare clearinghouse, or provider that transmits health information electronically) or a Business Associate (you create, receive, maintain, or transmit Protected Health Information on behalf of a Covered Entity). Most health-tech startups are Business Associates. If you touch PHI for a healthcare customer, you are in scope and need a signed Business Associate Agreement.

What are the three categories of HIPAA Security Rule safeguards?

Administrative, physical, and technical. Administrative safeguards are the program and people controls — risk analysis, workforce training, policies, a designated security official. Physical safeguards cover facility and device access. Technical safeguards are the software controls — access control, audit logs, integrity protection, and transmission security. A defensible posture needs all three plus the documentation to prove them.

What is the difference between this checklist and HIPAA architecture?

Architecture is how you build the system — encryption, BAA-eligible infrastructure, audit logging, access controls. This checklist is the broader readiness program that surrounds the build: the risk analysis, the policies, the training, the BAAs, the physical safeguards, and the incident response plan. You need both. Strong architecture with no documented program still fails an audit, and great policies on top of a leaky system fail just as hard.

What goes wrong most often for startups on HIPAA?

Four recurring gaps: skipping the formal Security Risk Analysis, missing Business Associate Agreements with vendors that touch PHI, PHI leaking into logs and error trackers that have no BAA, and treating UI-level hiding as access control instead of enforcing it at the data layer. None of these require a big budget to fix — they require doing the unglamorous program work before an auditor or a breach forces it.

Do I need a signed BAA with every vendor?

You need a BAA with every vendor that creates, receives, maintains, or transmits PHI on your behalf — cloud host, database, email, SMS, error tracking, analytics, AI APIs, support tooling. Vendors that never touch PHI do not need one. The trap is that not every service inside a provider is BAA-eligible, so verify the specific services you use are covered, not just the vendor name.

How long does it take a startup to get HIPAA-ready?

For a focused product with a clean stack, three to six months to a defensible posture. The work splits across engineering (encryption, access control, audit logs, BAA-eligible infrastructure), program (risk analysis, policies, training, incident response), and contracts (BAAs upstream and downstream). Starting before you have PHI in production is far cheaper than retrofitting after.

Is HIPAA a one-time project or ongoing?

Ongoing. HIPAA expects an annual risk analysis, recurring workforce training, periodic access reviews, audit-log monitoring, and breach-notification readiness. Compliance is a posture you maintain and document continuously, not a certificate you earn once. Most teams run it as a quarterly operating rhythm with an annual deep review.

Get HIPAA-ready without the guesswork.

Free 30-minute readiness review. We will walk the checklist against your actual stack and program, flag the missing BAAs and the skipped risk analysis, and give you a prioritized punch list.

Or call Bill at (770) 652-1282

More compliance + architecture reading

All posts

All blog postsUpdated June 3, 2026