If you're a digital health company selling into the US market, "HIPAA compliant" is probably sitting in a security questionnaire right now, waiting for an answer. The problem is that HIPAA isn't a certification you can buy off the shelf. There's no HIPAA badge, no accredited auditor stamping a report the way there is with SOC 2. It's a federal law with a set of rules, and "compliance" means you can show, with evidence, that you've met them.
This checklist covers what's actually required under the HIPAA Privacy Rule, Security Rule, and Breach Notification Rule. It's written for founders and engineering leads at digital health startups who need to know what a buyer, partner, or auditor will expect to see, not what a vendor wants to sell you.
1. Determine if you're actually a covered entity or business associate
Before you build a compliance program, confirm HIPAA applies to you. If you create, receive, maintain, or transmit protected health information (PHI) on behalf of a covered entity (a health plan, provider, or clearinghouse), you're almost certainly a business associate. Most digital health SaaS companies fall here. This matters because it determines which contracts you need and which rules apply directly to you versus flow down through agreements.
2. Sign Business Associate Agreements (BAAs) with every relevant party
A BAA is a contract that obligates you to protect PHI the same way the law requires. You need one with:
- Every covered entity customer that shares PHI with you
- Every subcontractor or subprocessor that touches PHI on your behalf (cloud hosting, analytics, backup providers, email services if PHI passes through)
Missing a BAA with a subprocessor is one of the most common gaps we see. If your infrastructure vendor won't sign one, that's a disqualifying finding, not a negotiation point.
3. Conduct and document a Security Risk Assessment
This is the requirement most digital health teams underestimate. The Security Rule requires a documented, periodic risk assessment that identifies where PHI lives, how it flows through your systems, and what could go wrong. It's not a one-time checkbox. It needs to be revisited when your architecture changes and reviewed on a regular cadence. Auditors and enterprise buyers will ask to see the actual document, not just hear that you did one.
4. Implement the required administrative safeguards
- Assign a Security Officer and Privacy Officer (can be the same person at a small company) with clear accountability
- Workforce training on HIPAA obligations, documented and repeated at least annually
- Sanction policy for employees who violate PHI handling rules
- Access management procedures that grant PHI access based on role, not by default
- Incident response plan specific to PHI, tested rather than just written
5. Implement the required technical safeguards
- Access controls: unique user IDs, role-based permissions, automatic logoff
- Audit controls: logging of who accessed or modified PHI and when
- Encryption of PHI at rest and in transit (not strictly mandated as "required" in every case under the letter of the rule, but treated as the practical baseline by every buyer and auditor we've seen)
- Integrity controls to prevent improper alteration or destruction of PHI
- Transmission security for PHI moving across networks, including APIs and third-party integrations
6. Implement physical safeguards
Even for a cloud-native company, this section still applies. Document facility access controls for any offices, workstation security policies, and device and media controls covering laptops, backups, and decommissioned hardware. If you rely entirely on a cloud provider's data centre, your BAA with them covers the physical layer there, but you still need policies for your own offices and employee devices.
7. Build a breach notification process
The Breach Notification Rule sets hard deadlines: affected individuals must be notified without unreasonable delay and no later than 60 days after discovery, and breaches affecting 500 or more individuals must also be reported to Health and Human Services and, in some cases, the media. You need a defined process to determine whether an incident qualifies as a reportable breach, who makes that call, and how notifications go out. Waiting until an incident happens to figure this out is how deadlines get missed.
8. Handle Privacy Rule obligations if you touch patient-facing data directly
If your product interacts with patients directly rather than purely through a covered entity's workflow, review Privacy Rule obligations around minimum necessary use, patient access rights to their own records, and accounting of disclosures. Not every business associate needs a full Privacy Rule program, but it's worth confirming rather than assuming you're exempt.
9. Keep evidence, not just policies
A binder of policies nobody follows is worse than no binder at all, because it creates a paper trail showing you knew the requirement and didn't operate against it. Buyers, and any actual HHS investigation, want to see risk assessments with dates, training records with names, access reviews with logs, and incident response plans that reference real tooling. This is the evidence layer that separates a HIPAA program on paper from one that would survive scrutiny.
Where this fits with SOC 2
Most digital health companies selling to US healthcare organizations end up needing both HIPAA readiness and a SOC 2 report, because enterprise health systems and payers ask for both. The good news is the underlying control work overlaps heavily: access management, encryption, incident response, vendor management, and risk assessment all serve both frameworks. Running them together means you build the evidence once and map it to both sets of requirements, instead of duplicating the work twice on two separate timelines.
We cover how this works in more detail, including where HIPAA and HITRUST diverge and why we scope our engagements to readiness rather than a full HITRUST certification, on our HIPAA compliance for digital health page. If you're also weighing where HIPAA fits against a broader compliance roadmap, our compliance solutions overview lays out how we sequence multiple frameworks for growing health tech companies.
Get a straight answer on where you stand
If you're not sure whether your current controls would hold up against this checklist, or you're trying to figure out how to sequence HIPAA readiness alongside SOC 2 without duplicating the work, talk to us. We'll give you a plain assessment of the gaps and what it actually takes to close them. Contact traztech to get started.