HIPAA security risk analysis: doing it properly

What does "doing it properly" actually mean?

The Security Rule makes the risk analysis a required specification at 45 CFR 164.308(a)(1)(ii)(A) and HHS calls it the first step in choosing safeguards. What the rule does not do is hand you a method: HHS says plainly that no single approach guarantees compliance. That freedom is where many go wrong: a document can look finished and prove nothing.

From the analyses we review, a sound one shows five qualities at once:

• Specific. It names your applications, vendors, sites and data flows, not a generic list of threats that would fit any company.
• Complete. Its scope reaches every place electronic PHI is created, received, stored or sent, including backups, laptops, e-mail, test copies and hosted services.
• Reasoned. Likelihood and impact are scored on written scales, and each rating carries a sentence explaining why.
• Connected. Every risk that needs treatment appears in the risk management plan, with an owner and a date.
• Current. Each version is dated, approved and revisited when systems, suppliers or threats change.

If you need the method itself, the elements HHS lists and a scored example, our guide to conducting the Security Rule risk analysis walks through it. This article is about judging quality: what counts, what does not, and how to tell the difference.

Four things often mistaken for a risk analysis

OCR thought the confusion common enough to devote its April 2018 cybersecurity newsletter to the difference between a risk analysis and a gap analysis. The distinction is simple once stated. A gap analysis asks whether a required control exists. A risk analysis asks what could happen to your ePHI, how likely it is and how much harm it would do. You need both views, but only the second satisfies this specification.

The common thread is that each item describes controls or compliance status. A risk analysis starts from the data and works outwards to the threats; our comparison of HIPAA, SOC 2, HITRUST and ISO/IEC 27001 explains how those frameworks sit beside the rule.

Tools and frameworks: useful structure, not a substitute

Several free US government resources help organise the work, provided you understand their limits.

The HHS Security Risk Assessment Tool

The SRA Tool, produced by ASTP/ONC together with OCR, is aimed at small and medium healthcare practices. It guides a practice through questions on its safeguards, assets and vendors and produces a report. Its user guide opens with a disclaimer that is worth reading before you rely on the output. It suits a clinic with one practice-management system; a contact centre or billing business with many clients and platforms usually outgrows its fixed questions.

NIST SP 800-66 Revision 2 and the OCR crosswalk

NIST's resource guide for the Security Rule, published in February 2024, maps each standard to the NIST Cybersecurity Framework and SP 800-53 controls. OCR has also released a crosswalk between the Security Rule and the Cybersecurity Framework. Both help when the same evidence must satisfy customers using different frameworks.

Your existing ISMS risk method

If you already run an ISO/IEC 27001 risk assessment, extend it rather than starting a second register. Add the ePHI inventory, confirm that every system holding PHI is in scope and record the addressable-specification decisions against the same risk numbers.

Who should carry out the analysis?

The Security Rule requires you to assign security responsibility to one official, and that person should own the analysis. Ownership is not the same as authorship, though. The people who know where PHI actually moves are the team leads, system administrators and vendor managers, so a good analysis is assembled in short workshops with them, not written alone at a desk.

An external consultant brings method, pace and an outside eye for what staff take for granted, such as a shared inbox full of claim forms. What an outsider cannot do is own the result. The ratings, the risk acceptance decisions and the plan must be approved by your management, because they commit your resources and your organisation answers for them. Keep the analysis separate from the periodic evaluation required at 164.308(a)(8), which HHS allows to be performed internally or by an external organisation; a fresh reviewer for that evaluation strengthens both documents.

A quality test for your existing analysis

Put these questions to your current document. Each weak answer is a finding to fix before anyone else raises it.

OCR's Summer 2020 cybersecurity newsletter on IT asset inventories is a useful companion to the first two questions, since an incomplete inventory undermines every later step.

When the analysis is examined

OCR enforces the rules by investigating complaints, conducting compliance reviews and running education and outreach. Failures of risk analysis recur among the issues in its published resolution agreements, and OCR has announced a series of ransomware settlements, the ninth in January 2025. After an incident, the questions quickly turn to whether an analysis existed and whether it covered the affected systems. A resolution agreement generally carries HHS monitoring for three years.

Three habits make scrutiny easier. Keep every version, not only the latest, since Security Rule documentation must be retained for six years. Date each review, because OCR takes into account whether recognised security practices were in place for the previous twelve months. And keep the evidence behind each control rating where it can be found quickly. Your customers' auditors will ask for the same record, and our HIPAA documentation guide covers the documents around it.

This article explains the Security Rule and good practice. It is not legal advice; for questions about your legal position, speak to counsel familiar with HIPAA.

HIPAA security risk analysis: questions buyers ask