How do I do a HIPAA security risk assessment?

Step by step

1. Inventory your ePHI. List every system, device, service and vendor that creates, receives, maintains or transmits electronic PHI, and where each one stores it. §164.306(c) applies the Security Rule standards to all electronic PHI, so a system left off the list is a gap nobody can see.
2. Identify threats and vulnerabilities. For each system on that list, write down what could go wrong and how: stolen credentials, an unpatched server, a lost laptop, a misconfigured storage bucket, a vendor with broader access than its job needs.
3. Record the security measures already in place. Note what you already do about each threat. The assessment measures residual risk, so the controls you run are part of the input rather than the conclusion.
4. Rate likelihood and impact. Give each threat and vulnerability pair a likelihood and an impact, and derive a risk level from the two. Use whatever scale you can apply consistently; the regulation sets no scale.
5. Write it down. The assessment is documentation, so an undocumented analysis does not satisfy the specification. Record the scope, the method, the findings and the reasoning behind each rating.
6. Reduce the risks you found. Risk management at §164.308(a)(1)(ii)(B) requires security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level, judged against the general requirements in §164.306(a). Track each decision and who owns it.
7. Record every addressable decision. For each addressable implementation specification, record whether you implemented it, implemented an equivalent alternative measure, or concluded that neither was reasonable and appropriate. §164.306(d)(3) sets out that choice, and the third option still has to be documented.
8. Keep it current and keep it for six years. §164.308(a)(8) requires periodic technical and non-technical evaluation, and §164.306(e) requires you to review and modify your security measures as needed. Documentation is retained for six years from creation or last effective date, whichever is later (§164.316(b)(2)(i)).

What the rule actually asks for

The words in §164.308(a)(1)(ii)(A) are "accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate". There is no prescribed template and no approved tool. What is required is coverage of all your ePHI, real analysis rather than a questionnaire score, and a written record. It is a Required implementation specification, so you cannot decide it is not reasonable and appropriate for you.

A risk analysis is not a gap assessment

A gap assessment asks which Security Rule specifications you have met. A risk analysis asks what could happen to your ePHI and how bad it would be. You need both, and they feed each other: the risk analysis tells you how much to invest in a given safeguard, and the gap list tells you which safeguards the rule names. Running only the checklist is the mistake that shows up in enforcement, because a program can tick every box and still have no idea where its data is.

Scope follows the ePHI, not the org chart

Developer laptops, backups, log aggregation, support tooling, analytics, email, a staging database seeded from production: if ePHI reaches it, it is in scope. Subprocessors are in scope too, and they come with the business associate obligations at §164.308(b) and §164.314(a). An asset inventory you maintain anyway is the cheapest way to keep this honest.

How often to redo it

The rule sets no fixed interval. It requires periodic evaluation (§164.308(a)(8)) and maintenance of your measures (§164.306(e)), which in practice means a review at least annually and a fresh look whenever something material changes: a new product surface, a migration, an acquisition, a new subprocessor, or a security incident. An assessment that still describes last year’s architecture is not accurate or thorough.

Where Keel fits

Keel’s HIPAA framework scores the risk analysis and risk management specifications as requirements in their own right, and the addressable ones carry the Addressable label the regulation defines at §164.306(d). Your findings go in the risk register, the measures you took attach as evidence, and the asset register is where the ePHI inventory lives. Keel is not a system of record for PHI, so keep PHI out of what you upload.

FAQ