The HIPAA risk analysis, done so it holds up.

The Security Rule's security management process standard, at 45 CFR 164.308(a)(1), lists the risk analysis as a required implementation specification. It asks for an accurate and thorough look at the risks and vulnerabilities facing the confidentiality, integrity and availability of electronic protected health information (ePHI) that you hold.

Its partner is risk management: putting in place measures that bring those risks down to a reasonable and appropriate level. The analysis finds the risks. Risk management acts on them. One without the other fails an investigation.

The rule names no method or tool. HHS guidance describes the elements a sound analysis contains, and the National Institute of Standards and Technology (NIST) publications on risk assessment and on implementing the Security Rule are commonly used to structure the work.

The analysis covers all ePHI you create, receive, maintain or transmit, on every medium and in every location. That includes the obvious clinical or billing platform and the many places copies drift to without anyone deciding they should.

• Production databases
• Backups and snapshots
• Email and attachments
• Laptops and phones
• Shared drives
• Support and ticketing tools
• Application logs
• Analytics exports
• Test environments with real data
• Scanned paper
• Vendor-hosted systems
• Removable media

Follow the data rather than the org chart. Trace each data flow from where ePHI enters, through every system and person that touches it, to where it is archived or destroyed. Each hop is an asset in your analysis.

1. Inventory. List every system, device, vendor and data flow that holds or moves ePHI, with an owner for each.
2. Threats. For each asset, name what could realistically go wrong: ransomware, a lost device, an insider browsing records, a misconfigured storage bucket, a power failure.
3. Vulnerabilities. Record the weakness each threat would exploit, such as no multi-factor sign-in, unpatched software or shared accounts.
4. Current controls. Note what is already in place and whether it actually works, not what the policy says should happen.
5. Likelihood. Rate how probable each threat-and-weakness pair is, on a scale you define and apply the same way every time.
6. Impact. Rate the harm if it happened: to patients, to operations, to the data's integrity and availability.
7. Risk level. Combine likelihood and impact into a level, and rank the results.
8. Documentation. Write up the method, the findings, the ratings and the date. A finished analysis is a dated document, not a conversation.
9. Review. Revisit it on a set schedule and whenever the environment changes: a new system, a new vendor, a migration, an incident.

Rows are illustrative. Use your own scales, but define them in writing so a reviewer can see why a risk was rated medium and not high.

The Security Rule asks you to keep this documentation for six years from the date it was created or last in effect, whichever is later. Keep superseded versions. An investigator often asks what the analysis said before an incident, not after it.

• Enterprise-wide coverage. Every system and location with ePHI, not one application.
• A current date. Updated after the changes that matter, not a document from years ago.
• A visible method. How threats were found and how scores were set.
• Risks rated. Likelihood and impact for each, with a resulting level.
• Treatment that happened. A risk management plan, and evidence that its actions were done.
• Retained versions. Earlier analyses kept, so the history can be followed.

• Scoping one product. The core platform is analysed; email, laptops and backups are not.
• A checklist in disguise. Yes and no answers against the rule's headings, with no threats or ratings.
• A one-off. Done for a client questionnaire, then never opened again.
• No link to action. High risks listed, with no owner, plan or date beside them.
• Vendors left out. Business associates handling ePHI do not appear at all.

HHS has proposed changes to the Security Rule that would spell out more of what a risk analysis must contain. Check whether a final rule has been published before relying on the current text alone.

Sources: 45 CFR 164.308(a)(1) and 164.316 (HIPAA Security Rule); HHS Guidance on Risk Analysis Requirements under the HIPAA Security Rule; NIST SP 800-30 Rev. 1 and NIST SP 800-66 Rev. 2.