HIPAA Security Risk Assessment (SRA): A Step-by-Step Guide

A HIPAA security risk assessment (SRA) is a documented process for finding, evaluating, and reducing the risks to the electronic protected health information (ePHI) your organization creates, receives, maintains, or transmits. It is required by the HIPAA Security Rule for every covered entity and business associate, regardless of size. In practice, an SRA means listing where ePHI lives, identifying the threats and vulnerabilities that could expose it, rating how likely and how damaging each one is, and writing down what you’ll do about it.

That last part matters. The risk assessment is not a one-time form you file away. It is the foundation of your entire security program: the safeguards you choose, the policies you write, and the money you spend should all trace back to risks you identified here. If you ever face an audit or a breach investigation, this is one of the first documents regulators ask for, and a missing or stale risk analysis is among the most common findings in HIPAA enforcement actions.

This guide walks through a practical, seven-step approach that a small team can actually complete without an enterprise GRC budget.

What the HIPAA Security Rule actually requires

The HIPAA Security Rule applies to ePHI specifically: electronic health data, not paper records or spoken conversations (those fall under the Privacy Rule). It organizes safeguards into three categories: administrative, physical, and technical. The first administrative safeguard it lists is the requirement to conduct an “accurate and thorough” assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI.

Two points trip people up. First, the rule does not prescribe a specific methodology or tool. You have flexibility to scale the assessment to your size, complexity, and capabilities, which is why a 5-person clinic and a 5,000-person hospital can both be compliant with very different efforts. Second, the SRA is distinct from a “compliance checklist.” A checklist tells you whether you have a control; a risk assessment tells you whether the controls you have are sufficient for the actual threats you face. You need both, but the SRA is the one the law specifically mandates.

It’s also worth watching where the rule is heading. In early 2025, HHS published a proposed update to the Security Rule aimed at strengthening cybersecurity requirements, with an emphasis on more rigorous and regularly updated risk analysis, written asset inventories and network maps, mandatory encryption, and multi-factor authentication. As of mid-2026 that proposal is still pending and has drawn significant industry pushback, so the specifics could change, be delayed, or be withdrawn. You don’t need to comply with a proposal, but building your SRA on those stronger habits now is a low-regret move.

The 7 steps of a HIPAA security risk assessment

Step 1: Define scope and inventory where ePHI lives

You cannot protect data you haven’t located. Start by mapping every place ePHI is created, received, stored, or transmitted: your EHR, billing system, email, cloud storage, laptops, phones, backup systems, and any third-party platforms. For each, note the system, who has access, and how data flows in and out.

This data-flow inventory is the single most valuable artifact of the whole exercise. Many breaches at small organizations start in the places teams forgot were in scope: an old laptop, a personal Gmail account, a vendor portal nobody documented.

Step 2: Identify threats and vulnerabilities

For each asset, ask two questions. What could go wrong (the threat)? And where are we weak (the vulnerability)? Threats include ransomware, phishing, lost or stolen devices, insider misuse, and natural events like fire or flood. Vulnerabilities are the gaps that let a threat succeed: unencrypted laptops, shared passwords, no multi-factor authentication, unpatched software, or excessive access permissions.

Be honest and specific. “Email is a risk” is not useful. “Staff send patient summaries to referring doctors through unencrypted Gmail, and three accounts lack MFA” is something you can act on.

Step 3: Assess current controls

Document what you already have in place to address each threat: encryption, access controls, audit logging, backups, staff training, and your existing policies. The goal is an honest gap analysis, not credit for controls that exist on paper but aren’t actually enforced. If your policy requires encryption but two laptops aren’t encrypted, that gap belongs in the assessment.

Step 4: Determine likelihood and impact

For each risk, estimate two things: how likely it is to occur, and how serious the impact would be if it did. Most teams use a simple low/medium/high scale for each and combine them into an overall risk rating. A high-likelihood, high-impact risk (say, unencrypted laptops carrying ePHI in a field-based team) rises to the top. A low-likelihood, low-impact risk can wait.

You don’t need a fancy formula. The point is to rank risks so you spend limited time and money on the ones that matter most, and to show your reasoning if anyone asks later.

Step 5: Assign a risk level and prioritize

Combine likelihood and impact into a prioritized list. This becomes your remediation backlog. Resist the urge to mark everything “high” — a risk register where everything is urgent is a register where nothing gets done. Force yourself to rank.

Step 6: Document a risk management plan

The Security Rule pairs risk analysis with risk management: you must not only find risks but reduce them to a reasonable and appropriate level. For each prioritized risk, decide on a response — mitigate it (add a control), accept it (with documented justification), or transfer it (for example, through cyber insurance or a vendor contract). Assign an owner and a target date.

This document, your risk management plan, is what turns an assessment into action. It’s also the evidence that you took the findings seriously, which is exactly what investigators look for after an incident.

Step 7: Review, update, and repeat

An SRA is a living process. Regulators expect it to be reviewed and updated periodically, and whenever something material changes: a new EHR, a new office, a merger, a significant new vendor, or a security incident. A common, defensible cadence is at least annually, plus an update after any major change. Treat the prior year’s plan as your starting point and show progress.

Common mistakes that turn up in audits

A few patterns show up again and again at smaller organizations:

• Confusing a checklist for a risk analysis. Running an EHR vendor’s “security checklist” is helpful but does not satisfy the requirement to analyze risks across your whole environment.
• Scoping too narrowly. Forgetting email, mobile devices, backups, or a SaaS vendor leaves the most likely breach paths unexamined.
• No follow-through. An assessment with findings but no dated remediation plan is arguably worse than none, because it documents that you knew and didn’t act.
• Ignoring business associates. If vendors touch your ePHI, their risk is partly your risk — you need a signed Business Associate Agreement plus some assurance they’re actually securing the data.
• Doing it once. A three-year-old SRA describing systems you no longer use is not “accurate and thorough.”

How small teams can do this affordably

You do not need a six-figure consulting engagement. A capable small team can complete a credible SRA with a structured template, a spreadsheet risk register, and a few focused days of work. HHS, through ONC and OCR, publishes a free Security Risk Assessment (SRA) Tool aimed specifically at small and medium providers — available as a Windows application and an Excel workbook — and it’s a reasonable starting point.

The harder part is maintenance: keeping the asset inventory current, tracking remediation to completion, re-running the analysis when things change, and tying it to the rest of your HIPAA program (policies, training, vendor agreements, and your overall HIPAA compliance checklist). That’s where lightweight automation earns its keep, especially if you’re balancing HIPAA at a small practice or stacking other frameworks like SOC 2 on top.

Forteri is a multi-framework compliance platform built for SMBs and startups that need real HIPAA, SOC 2, or ISO 27001 coverage without enterprise pricing. It can help you maintain your risk register, manage policies, monitor controls, track vendor risk and BAAs, and keep your SRA evidence current between reviews — so the assessment stays a living process instead of a once-a-year scramble. If you’d rather spend your time fixing risks than chasing screenshots, that’s the problem it’s built to solve.