HIPAA Risk Assessment Checklist: A Step-by-Step Guide

HIPAA Risk Assessment Checklist: A Step-by-Step Guide Photo: Unsplash

The HIPAA Security Rule requires every covered entity and business associate to conduct "an accurate and thorough assessment of the potential risks and vulnerabilities" to electronic protected health information (ePHI). It is the first requirement in the rule, the document auditors and buyers ask for first, and one of the most common failures in HHS enforcement actions. This checklist walks through a HIPAA risk assessment step by step, based on HHS guidance and NIST methodology, so you end up with a document that holds up.

Key takeaways

The risk analysis is required, not addressable. It sits at 45 CFR 164.308(a)(1)(ii)(A), alongside the requirement to manage the risks you find.
Scope is all ePHI, everywhere. Databases, backups, logs, laptops, email, vendors, and anything else that creates, receives, maintains, or transmits ePHI.
HHS does not mandate a method, but its guidance lists the elements a compliant analysis needs, and NIST SP 800-30 and SP 800-66 are the reference methods.
Document everything. An undocumented analysis counts as no analysis, and records must be kept for six years.
It is never finished. Review it at least annually and whenever your systems, vendors, or threats change.

Risk analysis vs risk management

HIPAA separates two linked requirements:

Risk analysis identifies where ePHI lives, what could threaten it, how likely that is, and how bad it would be.
Risk management means implementing security measures that reduce those risks to a reasonable and appropriate level, and recording what you decided.

Many organizations produce an analysis and stop. Regulators look for both: the risks you found and what you did about them.

HIPAA risk assessment checklist

1. Define the scope

List every system, application, and service that creates, receives, maintains, or transmits ePHI
Include cloud accounts, databases, file storage, backups, and disaster recovery copies
Include logs, monitoring, analytics, and data warehouses that may capture ePHI
Include endpoints: laptops, phones, and removable media used by the workforce
Include vendors and subcontractors that handle ePHI, and confirm each has a signed BAA
Record what is out of scope and why

2. Map where ePHI flows

Document how ePHI enters your environment (APIs, integrations, uploads, user input)
Document where it is stored and processed, including regions and replicas
Document where it leaves (exports, customer integrations, vendors, support tools)
Identify who and what can access it: workforce roles, service accounts, vendors
Keep a data flow diagram with the date it was last reviewed

3. Identify threats

Human threats, deliberate: external attackers, ransomware, credential theft, malicious insiders
Human threats, accidental: misconfiguration, misdirected email, lost devices, excessive access
Technical threats: software vulnerabilities, vulnerable dependencies, leaked secrets, outages
Environmental threats: cloud region failure, power, natural disasters affecting facilities
Third-party threats: a vendor breach, a vendor outage, a subcontractor without a BAA

4. Identify vulnerabilities

Review access control: MFA coverage, shared accounts, stale accounts, least privilege
Review encryption at rest and in transit for every ePHI store and connection
Review audit logging: what is logged, where, for how long, and who reviews it
Review patching and vulnerability management for systems and code
Review backup and restore capability, including when a restore was last tested
Review device security: disk encryption, screen lock, endpoint protection
Review workforce training completion and policy acknowledgement
Use technical input such as vulnerability scans, cloud configuration checks, and penetration test results, not only interviews

5. Assess current security measures

For each threat and vulnerability pair, record the controls already in place
Note whether each control is technical, administrative, or physical
Note whether each control is actually configured and operating, with evidence

6. Determine likelihood

Rate the likelihood that each threat exploits each vulnerability (for example low, medium, high)
Base ratings on your environment, existing controls, and real incidents, not generic lists
Record the reasoning behind each rating

7. Determine impact

Rate the impact on confidentiality, integrity, and availability of ePHI
Consider harm to patients, the number of records affected, and operational disruption
Consider regulatory, contractual, and reputational consequences

8. Determine the level of risk

Combine likelihood and impact into a risk level using a defined scale or matrix
Rank risks so the highest are addressed first
Record the risk level for every item in a risk register

9. Decide and document risk treatment

For each risk, choose to mitigate, transfer, accept, or avoid it
Assign an owner and a target date for each mitigation
Document the justification for any accepted risk, approved by management
For each addressable implementation specification you do not implement as written, document why and what you do instead

10. Finalize, retain, and review

Compile the analysis, risk register, and management plan into one dated document
Have it approved by your security official and leadership
Retain it for at least six years from creation or last effective date
Schedule a review at least annually
Re-run the analysis after significant changes: new products, new vendors, infrastructure migrations, acquisitions, or security incidents

Common mistakes that fail an audit

Treating a questionnaire as the analysis. A checklist of yes/no answers about policies does not identify threats, likelihood, or impact.
Leaving systems out of scope by accident. Logs, backups, and support tools are the usual gaps.
No risk management plan. Listing risks without owners, dates, and decisions only does half the job.
Stale analyses. An analysis from three years and two architectures ago does not reflect current risk.
Relying on interviews only. Technical scanning results show what actually runs, which is often different from what people describe.
Confusing a vendor's compliance with your own. Your cloud provider's controls cover their part. Your configuration of their services is still your risk.

Tools and references

HHS guidance on risk analysis explains the elements OCR expects.
NIST SP 800-30 describes a general risk assessment process.
NIST SP 800-66 Revision 2 maps the Security Rule to NIST guidance and is written for HIPAA-regulated entities.
The HHS Security Risk Assessment (SRA) Tool is a free tool aimed at small and medium healthcare providers. It works as a starting structure for SaaS vendors, though it is oriented toward provider practices.

If you are working out what the whole program costs, see HIPAA compliance costs. If buyers will also want a SOC 2 report, your risk analysis doubles as the SOC 2 risk assessment. See HIPAA vs SOC 2.

How SecureSlate helps

In SecureSlate's HIPAA program, a dedicated compliance lead runs your risk analysis for you, as part of one fixed price:

They trace how PHI enters, moves through, and leaves your product to set the scope.
They identify threats and vulnerabilities to ePHI, rate likelihood and impact, and record a risk management plan with owners and review dates.
Security scanning of your code, cloud configuration, domains, and dependencies feeds the technical side, so the analysis reflects what actually runs.
The analysis is revisited when your systems change and on a regular schedule, and evidence collects continuously in between.

See SecureSlate for healthcare for the full program.

FAQ

Is a HIPAA risk assessment required?

Yes. The Security Rule requires covered entities and business associates to conduct an accurate and thorough risk analysis of ePHI and to implement measures that reduce the risks found. It is a required implementation specification, not an addressable one.

How often should a HIPAA risk assessment be done?

HIPAA does not set a fixed interval, but it expects the analysis to stay current. Most organizations review it at least annually and re-run it after significant changes such as new systems, new vendors, migrations, or security incidents.

Who should perform a HIPAA risk assessment?

Anyone with enough knowledge of your systems and of the Security Rule can perform it, including internal staff. Many small companies bring in an outside expert for the first one so the method and documentation hold up to scrutiny.

Is there a HIPAA risk assessment template?

HHS does not publish a mandatory template, but the free HHS Security Risk Assessment Tool and NIST SP 800-66 provide a structure. The checklist above follows the elements HHS guidance expects in a compliant analysis.

What is the difference between a HIPAA risk assessment and a gap analysis?

A gap analysis compares your controls against the rule's requirements. A risk analysis identifies threats and vulnerabilities to ePHI and rates their likelihood and impact. HIPAA requires the risk analysis. A gap analysis is useful but does not replace it.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory, or professional advice. Requirements vary by organization and change over time. Consult qualified advisors for your specific obligations.