HIPAA Compliance Checklist: 9 Steps for Startups Handling Health Data

A HIPAA compliance checklist is a sequence of steps an organization follows to determine whether HIPAA applies to it, and if so, to build and document the policies, safeguards, and processes the Privacy, Security, and Breach Notification Rules require. This HIPAA checklist for startups focuses on what a SaaS company handling health data actually needs, not a full HIPAA compliance requirements checklist written for hospitals and health plans.

The 3 HIPAA Rules at a Glance

Rule	What It Covers	What It Requires
Privacy Rule	How PHI can be used and disclosed	Limit use to permitted purposes, honor patient access rights, provide notice of privacy practices
Security Rule	Protecting electronic PHI (ePHI) specifically	Administrative, physical, and technical safeguards, including a documented risk analysis
Breach Notification Rule	What happens after a breach	Notify affected individuals, HHS, and in some cases media, within 60 days of discovery

Every one of these HIPAA compliance steps maps back to one or more of these three rules.

The 9-Step HIPAA Compliance Checklist

Step 1: Confirm Your HIPAA Status

Before building anything, confirm whether you're a covered entity, a business associate, or neither. Most startups handling health data are business associates: you're processing PHI on behalf of a covered entity, not delivering care directly. This distinction determines which obligations apply directly to you versus which flow through your contracts.

	Covered Entity	Business Associate
Who it is	Health plans, healthcare clearinghouses, providers who transmit health information electronically	A vendor that creates, receives, stores, or transmits PHI on a covered entity's behalf
Typical examples	Hospitals, clinics, insurers	Cloud hosting, analytics platforms, scheduling tools, customer support software
Direct obligation	Full Privacy, Security, and Breach Notification Rule compliance	Security and Breach Notification Rule compliance, plus whatever the BAA specifies
Most startups fall here	Rarely, unless you're delivering care directly	Almost always, if your product touches PHI

If your product isn't obviously one or the other, HIPAA applies based on what data actually flows through your systems, not how you describe your company. For the full breakdown of what makes an organization a covered entity versus a business associate, see our HIPAA covered entities guide.

Step 2: Designate a Privacy and Security Officer

HIPAA requires a named individual responsible for privacy policy, and a named individual responsible for security policy, these can be the same person at a small company, but the role has to exist and be documented. When OCR investigates an incident, one of the first questions is who owns this and what they've documented.

	Privacy Officer	Security Officer
Owns	Privacy Rule compliance: use and disclosure of PHI, patient rights, notice of privacy practices	Security Rule compliance: administrative, physical, and technical safeguards for ePHI
Typical tasks	Handling access requests, managing disclosure authorizations, staff privacy training	Risk analysis, access control, incident response, technical safeguard implementation
Can be the same person?	Yes, common at companies under ~50 employees	Yes, same condition

At an early-stage startup, this is often a founder or head of engineering wearing the hat alongside other responsibilities. What matters is that the role exists and is documented, not the org chart.

Step 3: Identify PHI and Run a Risk Assessment

You can't protect what you haven't mapped. Start by identifying every system, database, log, and third-party tool that touches PHI, then classify what type of PHI it holds using the 18 HIPAA identifiers (names, medical record numbers, biometric data, and so on).

Once you know where PHI lives, run a risk analysis: for each system, what could go wrong, how likely is it, and what would the impact be. This is the most heavily enforced requirement in HIPAA. Inadequate risk analysis has been the specific, named finding in a string of 2025 OCR settlements, including BST & Co. CPAs, LLP and Deer Oaks Behavioral Health, both of which OCR determined had failed to conduct an accurate and thorough risk analysis before their breaches occurred.

For the exact 18 identifiers that count as PHI, see our HIPAA identifiers guide. For the full risk analysis methodology the Security Rule expects, see our HIPAA Security Rule requirements guide.

Step 4: Implement Required Policies and Procedures

Based on what your risk assessment surfaces, put policies in place covering, at minimum: access control (who can see PHI and how that's granted or revoked), data retention and disposal, incident response, acceptable use, and remote work if your team isn't fully in-office. Each policy needs an owner, a review cadence, and evidence that it's actually been communicated to the people it applies to, not just written down once and forgotten.

A policy that just restates the regulation back at itself doesn't hold up well in an audit. An access control policy that says "access is limited to authorized personnel" tells an auditor nothing. One that says "access to the patient records database is granted only through role-based permissions in [your identity provider], reviewed quarterly by the security officer, and revoked within 24 hours of offboarding" gives them something they can actually verify against your systems.

A specific, frequently asked question worth answering directly here: HIPAA doesn't explicitly mandate multi-factor authentication by name, but the Security Rule's access control and person-or-entity authentication standards are difficult to satisfy without it in practice, and OCR increasingly treats its absence as a red flag during investigations. Most compliance-minded startups implement MFA as a baseline control regardless of whether the word appears in the regulation.

Step 5: Sign BAAs and Manage Vendor Risk

Every vendor that creates, receives, stores, or transmits PHI on your behalf needs a signed Business Associate Agreement before they touch it, no exceptions for "we trust them" or "it's just a small integration." This includes cloud hosting, analytics tools, customer support platforms, and any subprocessor those vendors use themselves.

A BAA isn't a formality. It legally obligates the vendor to protect PHI to HIPAA standards and to notify you if something goes wrong on their end. Track which vendors have signed BAAs, which don't need one, and revisit that list whenever you add a new tool to your stack.

Step 6: Build a Breach Notification Plan Before You Need It

Under the Breach Notification Rule, you have 60 days from discovering a breach to notify affected individuals, and for breaches affecting 500 or more people, HHS and the media as well. Sixty days sounds like a lot of runway until you're actually inside an active incident trying to figure out scope, cause, and who's responsible for what.

Write the plan now: who investigates, who decides if it's reportable, who drafts notifications, and what the internal escalation path looks like. Test it at least once a year, the same way you'd test a disaster recovery plan.

Ransomware is the scenario worth planning for specifically. In one 2025 OCR settlement, Comstar, LLC paid $75,000 after a ransomware incident affected 585,621 individuals. The breach itself is rarely the only thing that gets scrutinized afterward, how quickly and clearly the organization notified people matters just as much to the outcome.

Step 7: Train Your Team Annually

Security awareness training isn't optional, and "we sent a Slack message once" doesn't count as training. Everyone with access to PHI, including contractors and support staff, needs documented, recurring training covering how to recognize phishing, how to handle PHI day-to-day, and what to do if they suspect an incident.

Annual is the practical minimum. Startups growing headcount quickly should train new hires as part of onboarding rather than waiting for the next annual cycle.

Documentation matters here as much as the content of the training itself. A completion record with names, dates, and what was covered is what turns "we train people" into evidence. Without it, an auditor has no way to distinguish a real training program from a policy that exists only on paper.

Step 8: Monitor and Audit Continuously

HIPAA compliance isn't a project with an end date, it's an operating posture. Run internal audits at least annually, review access logs regularly rather than only after something goes wrong, and reassess your risk analysis whenever you ship a feature that changes how PHI moves through your systems. Where it's relevant to a system holding PHI, a periodic penetration test is one of the more concrete pieces of evidence you can show an auditor that your technical safeguards actually hold up, not just that they're documented. This is also where a working HIPAA audit checklist earns its keep, turning a once-a-year fire drill into routine evidence collection.

This is the step where most startups eventually look at HIPAA compliance checklist software rather than tracking everything in spreadsheets, since continuous monitoring is hard to sustain manually once you're past a handful of employees and vendors.

Step 9: Document Everything, and Keep It for Six Years

HIPAA requires retaining documentation, policies, risk assessments, training records, BAAs, audit logs, for six years from the date of creation or the date it was last in effect, whichever is later. In practice, this means your compliance program is only as good as your ability to produce evidence on demand. If an auditor asks for proof of a specific control from eighteen months ago, "we did it, we just don't have a record" is functionally the same as not having done it. Treat this as a living HIPAA audit checklist, not a one-time exercise: revisit it before any customer security review or contract renewal.

What This Looks Like for a Health-Tech Startup

Say your product is a scheduling and messaging tool that a dozen clinics have started using to communicate with patients. Here's how this HIPAA checklist for startups plays out in practice.

You're a business associate the moment the first clinic sends a patient's appointment details through your system, not when you decide to "start taking HIPAA seriously." Your CTO takes on the security officer role alongside their existing job, and your head of ops covers privacy, both documented in a one-page policy, not a formal hire. The risk assessment surfaces that your support team can see full patient messages in your helpdesk tool, which becomes your first real finding: you scope down what support agents can view by default and log every time someone opens a full record.

Every clinic gets a BAA before their first login, no exceptions, including the one that's "just testing it out" for a month. Your cloud host, your error-logging tool, and your customer support platform each need one too, since all three touch PHI indirectly. When a clinic's admin account gets phished six months in, your breach notification plan means you're not improvising: you already know who investigates, what counts as reportable, and how the 60-day clock works before the clock starts.

None of this happens once and stays done. The risk assessment gets revisited when you ship a new feature that changes what data flows where, training happens every year plus at onboarding, and the BAA list gets checked every time procurement adds a new vendor.

Frequently Asked Questions

Turning This Checklist Into an Actual Program

A checklist tells you what to do once. HIPAA expects you to keep doing it. UprootSecurity helps startups turn each of these HIPAA compliance steps into continuous, evidence-backed controls, whether that's with HIPAA compliance checklist software or a shared spreadsheet at first, so the answer to "can you prove it" is always yes, not "let us go check." Explore how the pieces fit together on our HIPAA compliance hub.

→ Book a demo today