HIPAA gets a reputation for being a 90-page document that nobody really wants to read. It is technically that, but the way the Office for Civil Rights actually audits against it comes down to five buckets.
If a team can honestly answer “yes, documented, current” to the items in each bucket, they’re compliant. If not, the gaps become a clear roadmap.
Here’s what each bucket actually means in practice.
Bucket 1: Risk Analysis
This is the foundation. It’s the first thing OCR asks for in any audit, every time.
A risk analysis is a written assessment of every place patient data lives in the system, every threat to that data, and what’s been done about each threat.
It’s not a one-time exercise. It needs to be reviewed at least annually and updated whenever something material changes in the architecture.
What a complete bucket looks like:
- A current, written risk analysis covering every system that touches patient data
- A risk management plan addressing the gaps the analysis found
- Evidence of annual review, plus updates after major system changes
- Documentation of decisions not to mitigate certain risks, with reasoning
The most common failure here isn’t failing to do the analysis. It’s doing it in year one and never updating it.
Bucket 2: Administrative Safeguards
This is the people-and-process layer. It covers the policies, training, and accountability that make the rest of the program work.
What a complete bucket looks like:
- A designated Security Officer and Privacy Officer (often the same person at small companies)
- Written policies for access, incident response, disposal, training, and sanctions
- Annual workforce HIPAA training, with documented completion per employee
- A sanction policy that’s been applied in practice when needed
- A documented contingency plan covering backups, disaster recovery, and emergency operations
- Periodic security program evaluation, at least annually
The sanction policy is the one most often skipped. OCR will ask, “What happens to an employee who violates HIPAA?” A vague answer is a finding.
Bucket 3: Technical Safeguards
This is the engineering layer. It’s where most product teams focus, sometimes at the expense of the other four buckets.
What a complete bucket looks like:
- Access controls with unique user IDs, automatic logoff, and role-based permissions
- Audit logs capturing who accessed what data, when, and from where, are retained for six years
- Integrity controls prevent or detect unauthorized changes to patient data
- Authentication, including MFA on every system that touches patient data (mandatory under the 2026 rule)
- Transmission security with TLS 1.2 or higher
- Encryption at rest is also becoming mandatory in 2026
Teams running on AWS HIPAA-eligible services, Google Cloud Healthcare API, or Azure Healthcare APIs get a head start here, but only if the deployment is configured correctly.
HIPAA-eligible infrastructure isn’t the same as a HIPAA-compliant deployment.
Bucket 4: Physical Safeguards
This is the bucket cloud-native teams forget exists.
What a complete bucket looks like:
- Facility access controls for any servers, devices, or workstations
- Workstation security policies (locked screens, no patient data on personal devices without MDM)
- Device and media controls for the full lifecycle (issuance, use, decommissioning, destruction)
- A current inventory of every device or medium that stores patient data
For 100% cloud teams, the hosting provider handles most of this, but policies are still required for laptops, phones, and contractor devices.
Bucket 5: Business Associate Agreements
This is the bucket where most actual violations happen.
A Business Associate is any vendor that touches patient data on behalf of the company; Hosting, analytics, customer support, email, transcription, AI services, and anything.
What a complete bucket looks like:
- A complete inventory of every vendor that touches patient data
- A signed BAA with each one
- Verification that each BAA covers the right scope (some vendors exclude AI features, for example)
- A periodic review process, at a minimum, annual
- A vendor onboarding process that requires a BAA before any patient data touches the system
The trap is signing a BAA at vendor onboarding and never thinking about it again.
The 2026 rule makes ongoing verification a requirement, not a recommendation.
Two cross-cutting items.
Two more items span all five buckets and belong on every program.
Breach notification. When a breach happens, there’s a 60-day window to notify affected individuals, HHS, and in larger cases, the media. Smaller breaches can be reported annually.
A written process is required, and a tabletop exercise is strongly recommended.
Incident response.
Different from breach notification. Incident response covers what happens during the incident itself, before it’s clear whether anything is reportable.
Detection, containment, eradication, recovery, lessons learned. A written plan that’s never been tested almost always fails the first time it’s needed.
How to use this checklist
Three practical applications:
- Self-audit. Score each item green, yellow, or red. The reds become the roadmap.
- Vendor vetting. When evaluating a development partner, ask them to walk through their approach to all five buckets. Vagueness on any bucket is a red flag.
- Investor diligence. Lead investors will ask about HIPAA. A completed checklist makes the conversation move faster.
Where to go from here
The 47-point HIPAA checklist for wellness and health apps covers every item in this post in more depth, with what “compliant” actually looks like for each one.
Free, about an afternoon to run through.
[Download the 47-point HIPAA Checklist →]
English 
German 