A team I talked to recently had everything that usually signals "we're on top of compliance." BAAs signed with every vendor. Data encrypted at rest and in transit. SSO on. A SOC 2 report from each SaaS tool in the stack. They asked, reasonably, whether that made them HIPAA compliant.
It didn't, and the missing piece wasn't a feature they could buy or a contract they could countersign. It was a document they had to write themselves.
That document is the risk analysis, and it fails more healthcare software teams than any other single requirement.
It's required, and no one else can do it for you
The HIPAA Security Rule states it at 45 CFR §164.308(a)(1)(ii)(A): you must "conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information" your organization holds.
Read it closely. It's about your systems and your ePHI. A vendor's BAA covers how that vendor handles data you send it. A vendor's SOC 2 describes that vendor's internal controls. Neither one looks at how ePHI moves through the code you wrote, the database you run, the laptop a contractor uses, or the logging tool quietly capturing request bodies. That map is yours to draw.
It's also one of the most common findings in OCR enforcement. When a breach gets investigated, "failure to conduct an accurate and thorough risk analysis" turns up in resolution agreement after resolution agreement, usually next to a fine that dwarfs what the analysis would have cost.
Why teams that aren't careless still skip it
Two reasons, mostly.
It sounds like paperwork, so it slips behind shipping. And — the subtler one — teams believe they've already done it because they did something next to it. They quietly swap:
- a vendor risk review ("did our SaaS tools sign BAAs?") for a risk analysis ("where does ePHI actually live in our system, and what could go wrong with it?")
- a penetration test ("can someone break in?") for a risk analysis ("how likely is that, and how bad across every place data sits?")
- encryption, which is a safeguard, for the assessment that's supposed to tell you which safeguards you even need
Each of those is worth doing. None of them is the thing §164.308 asks for.
What it actually has to contain
You don't need a consultant or a 40-page template to start. A defensible risk analysis answers, in writing:
- Where does ePHI live and move? Every store, queue, log, backup, analytics pipe, and third party. Most teams hit a surprise here — the error tracker, the support inbox, a CSV someone exports once a month.
- What are the threats and vulnerabilities to each location? Per place data sits, not in the abstract.
- How likely is each, and how bad if it happens? A plain likelihood × impact rating is enough to begin.
- Which safeguards address the high ones, and what's the plan for the rest?
- When do you redo it? It tracks changes to your systems; it isn't a one-time artifact.
The first pass is the work. After that it's mostly diffs.
A free way to see where you stand
I maintain BAA Atlas, a directory that tracks BAA and PHI eligibility for the AI and SaaS tools developers actually wire in. (Affiliation up front: it's my project.) Enough people kept asking "fine, but am I doing the risk-analysis part right?" that I built a free self-check for exactly that.
It walks the §164.308 questions above, takes no signup, and hands back a gap report you can give to whoever owns compliance: https://baa-atlas.foundagent.net/sra
If your gaps turn out to be vendor-shaped — a tool that won't sign a BAA, or only signs on the enterprise tier — the directory is here: https://baa-atlas.foundagent.net
If you do one compliance thing this quarter, make it the risk analysis. It's the requirement with no vendor to outsource it to, and it's the one the auditors tend to open with.
Top comments (0)