HIPAA risk analysis: how to conduct the Security Rule risk analysis

What does the Security Rule require of a risk analysis?

The Security Rule places the risk analysis inside the security management process standard of the administrative safeguards. Four implementation specifications sit there, and all four are required: risk analysis, risk management, a sanction policy and information system activity review. HHS guidance calls it the first step in identifying and implementing safeguards: every later choice should follow from its findings.

The rule is deliberately flexible, scalable and technology neutral. When you decide which measures are reasonable and appropriate, you may weigh your size, complexity and capabilities, your technical infrastructure, the cost of the measures and the likelihood and impact of the risks. The written analysis must show that reasoning.

Two boundaries matter from the start. The Security Rule applies to electronic PHI only; paper and spoken PHI are protected through the Privacy Rule's safeguard requirement, not through this analysis. And the obligation reaches business associates as well: the 2013 Omnibus Rule made them directly liable for compliance with certain requirements of the HIPAA Rules, and every business associate agreement requires Security Rule compliance for the ePHI involved. Our HIPAA requirements guide covers the other safeguards.

The elements HHS expects, and the record each one leaves

Whatever method you choose, HHS guidance lists the elements an analysis should contain. Use them as the contents page of your document.

How to conduct a HIPAA risk analysis, step by step

1. Find every place ePHI lives and moves

Begin with the contracts and services that bring PHI into the organisation, then follow the data: which application receives it, where it is stored, who can view it, which reports or exports carry it out, which vendors host or support the systems, and how it is destroyed. The map usually exposes a shared mailbox, a reporting spreadsheet or a test environment holding real records.

2. Agree the scales before anyone scores

Define three to five levels for likelihood and impact, each described plainly enough that IT, operations and compliance read it the same way. Decide in advance which levels need treatment and who may accept the rest.

3. Pair threats with weaknesses and record what is in place

For each asset or group of assets, list the reasonably expected threats, from phishing to power loss, and the weaknesses that would let them succeed. Record the measures actually operating, checked against configurations and logs, not policy.

4. Rate, rank and approve

Score likelihood and impact, derive the level, rank the results and have the security official and a senior manager approve the document. NIST SP 800-66 Revision 2, published in February 2024, is a useful resource here, mapping the Security Rule to the NIST Cybersecurity Framework and SP 800-53 controls; it is guidance, not a HIPAA requirement.

A worked example: a contact centre serving a US health plan

Take a hypothetical business associate: an offshore contact centre handling member enquiries and claims follow-up for a US health plan. Agents use the plan's claims system remotely, calls are recorded and weekly reports go out as spreadsheets. Three register rows:

The centre does not score the plan's claims system as if it controlled it; it rates the remote-access path it does control, within the terms of its business associate agreement. The spreadsheet row exists only because someone traced the data rather than listing servers.

From analysis to the risk management plan

The companion required specification, risk management, turns the findings into security measures that bring the ranked risks down. In practice that is a plan listing each risk needing action, the measure chosen, the owner, the target date and the evidence of completion. Cross-reference plan and analysis by risk number so every change traces back to a risk.

The plan is also where addressable specifications are settled. For each one you either implement it, or record why it is not reasonable and appropriate in your environment and what equivalent measure you use instead. Encryption of stored and transmitted ePHI is addressable under the current rule, so the reasoning for any decision not to encrypt belongs here in writing. The January 2025 proposal would make encryption and most other specifications required and ask for a more detailed written analysis; our guide to the proposed Security Rule update explains where that proposal stands.

Keep the analysis distinct from the evaluation standard at 164.308(a)(8). The analysis asks what could go wrong with your ePHI; the evaluation asks whether your safeguards and policies still meet the rule. Both are required. OCR also considers whether recognised security practices were in place over the previous twelve months, one more reason to date every review.

Where HIPAA risk analyses fall short

• A template with your name on it. Generic threat lists describe nobody's systems.
• Scope stops at the main application. Backups, mobile devices, test data, e-mail, collaboration tools and vendor-hosted services are left out.
• A scan mistaken for an analysis. A vulnerability scan is useful input, but it rates no likelihood or impact and says nothing about people or processes.
• No link to action. Risks are rated high and nothing follows: no plan, no owner, no date.
• Written once, never updated. New platforms, sites and clients arrive; the analysis stays as it was.

For the documents around the analysis, see our HIPAA documentation guide.

HIPAA risk analysis: questions buyers ask