HIPAA Risk Assessment Requirements
Reviewed by Marcus Williams, CISSP, HCISPP
A HIPAA risk assessment is a mandatory, documented process that identifies all systems handling PHI, evaluates threats and vulnerabilities specific to your environment, rates likelihood and impact of each threat, assesses current controls against residual risk, and documents treatment decisions with business justification. HHS requires annual updates. The risk assessment is the single most cited deficiency in HHS enforcement actions — the majority of resolution agreements and civil monetary penalties reference inadequate or absent risk analysis. Without this foundation, every control decision is indefensible guesswork.
Your compliance team tells you that you need to conduct a risk assessment. You've heard that everyone should do one, you know most organizations skip it or half-do it, and you're worried that whatever you produce will come back to haunt you during an audit. Here's what makes it worse: the regulation is vague about exactly what the assessment should look like, so you're not sure whether a spreadsheet counts, whether hiring a consultant is required, or whether you can do it in-house. The truth is simpler than you think. A risk assessment is the documented process where you identify the systems handling patient data in your environment, identify the threats to those systems, evaluate what could realistically go wrong and how bad it would be, assess what controls you have in place right now, and determine whether the remaining risk is acceptable to your organization. Without this foundation, you're selecting compliance controls based on guesswork. With it, you can justify every control decision to an auditor and allocate your compliance budget rationally. The risk assessment isn't bureaucratic overhead. It's the essential bedrock that makes every other compliance decision defensible.
What a HIPAA Risk Assessment Actually Is
The regulation requires a documented risk assessment — meaning it can't be a spreadsheet that exists only in someone's head. It can't be a consultant's report that sits on a shelf gathering dust after they leave. It must be an organizational artifact — dated, signed by appropriate leadership, and referenced when you're making compliance decisions going forward.
The assessment must identify all systems, applications, and processes that handle, process, store, or transmit protected health information. Most organizations think this means the electronic health record system and maybe the backup systems. In reality, you need to cast a much wider net. If patient data flows through email, email is in scope. If clinicians access records on laptops from home, laptops are in scope. If patient lists exist in cloud storage, cloud storage is in scope. If a legacy system stores archived patient encounters that nobody uses anymore, it's still in scope because it contains PHI. Many organizations discover during the assessment that they're handling patient data in systems they didn't formally account for — a practice management system that was deployed years ago, a reporting database that gets a nightly sync of clinical data, a shared drive where office staff stores patient contact information. The assessment forces you to map the actual flow of data through your environment, which often reveals surprises.
For each system you identify, the assessment must document what data it handles. Is it identified patient information with names, medical record numbers, and diagnoses? Is it de-identified data where patient identifiers have been removed? Is it aggregated summary data showing trends but not individual records? The type and sensitivity of data matters because threats have much higher impact against systems handling identified sensitive information than against systems handling aggregate statistical data.
The assessment must also identify where each system lives physically and what the access points are. Is the system on-premises in a locked data center? Running in cloud infrastructure? Accessible from employee laptops? Accessed remotely from clinicians' homes through a VPN? Each access point creates a potential threat vector, and different locations have fundamentally different threat profiles. Understanding location and access tells you what categories of threats you need to address, which is where scope definition becomes critical.
Defining Your Scope
Scope is where many risk assessments fail because organizations either make it so broad it becomes unwieldy or so narrow it misses critical systems. You could theoretically conduct a risk assessment of your entire healthcare organization, but that's impractical and overwhelming. Instead, scope is typically defined by department, system, or business function. A hospital might conduct one risk assessment scoped to the EHR system, another to the billing system, another to the laboratory information system. Each assessment is bounded and specific.
Your scope definition must be reasonable and must be documented. If you're assessing EHR risk, specify exactly which EHR system, which departments or clinics use it, what patient populations are affected, and what data types flow through it. Don't assume an auditor understands your environment. Document the boundaries in detail so someone reviewing the assessment can understand exactly what was included and what was intentionally excluded.
Scope also directly determines what risks you address and what you don't. If your risk assessment is scoped to systems you own and operate but excludes systems that vendors manage on your behalf, then the risks from vendor systems aren't addressed in your assessment. That doesn't mean vendor risk disappears — it means you've excluded it from this particular assessment's scope. In practice, you'd typically have a separate risk assessment or vendor management process addressing those systems, and you'd have Business Associate Agreements with those vendors. The boundary must be explicit and documented, because the threats you evaluate within that boundary need to reflect your actual operating environment.
Identifying Threats Specific to Your Environment
The assessment must identify realistic threats — the things that could actually go wrong with the systems you've identified. Common threats in healthcare include unauthorized access from external attackers, unauthorized access from malicious insiders, accidental disclosure from sending patient data to the wrong recipient, system failures where hardware or software corrupts or deletes data, ransomware attacks that encrypt data and demand payment, and simple negligence where data is left unsecured because nobody followed procedure.
For each system in your assessment, identify the threats that actually apply to your situation. An on-premises data center protected by your own security team faces very different threats than a cloud system managed by a vendor. A system accessed by hundreds of clinical staff has different insider threat profiles than a system accessed by three administrative people. The Verizon 2023 Data Breach Investigations Report found that in healthcare, 35% of breaches involved internal actors and the most common attack patterns were basic web application attacks, miscellaneous errors, and system intrusion. Your threat identification should reflect these patterns for your specific systems rather than creating a generic list of every bad thing that could possibly happen in healthcare IT.
Vulnerabilities are the weaknesses in your current environment that enable those threats. Unencrypted data is a vulnerability that enables unauthorized access if data is intercepted or devices are stolen. Unpatched systems are a vulnerability that enables external attackers to exploit known security flaws. Weak access controls are a vulnerability that enables insider misuse. Default credentials still in place on systems are a vulnerability that enables unauthorized access. The assessment should identify vulnerabilities in your current environment so you can evaluate whether they're creating unacceptable risk. Once you've mapped threats to vulnerabilities, you need to quantify them.
Evaluating Likelihood and Impact
For each threat you identify, the assessment must evaluate two dimensions: likelihood (how probable is this threat in your situation) and impact (how bad would it be if the threat materialized). A threat with low likelihood and low impact is acceptable risk that you probably don't need to invest in controls. A threat with high likelihood and high impact is unacceptable risk that must be addressed. A threat with high likelihood and low impact might be acceptable depending on the cost of controls. A threat with low likelihood and high impact requires judgment — low probability but catastrophic if it happens means you probably need controls anyway.
The critical part: the assessment must document your reasoning, not just your conclusion. Don't just list "ransomware" as a threat. Explain your evaluation: "We evaluated the threat of ransomware affecting the EHR database. Likelihood: Medium, because we're a healthcare organization (known target for ransomware attacks — HHS reported a 278% increase in large breaches involving ransomware between 2018 and 2022) with remote employee access from home (potential infection vector), but we have firewalls, intrusion detection, and regular backups in place (mitigating factors). Impact: High, because a successful attack would prevent patient care delivery, expose patient data during encryption, and potentially violate our HIPAA obligations. Therefore overall risk is High and requires controls." That documented reasoning explains to an auditor why you made the control decisions you did. It shows rational decision-making even if the auditor might have weighted likelihood and impact differently. And it leads directly to what you do about each identified risk.
Four Treatment Options for Each Risk
After identifying risks, the assessment must document how you're treating each one. You have four options: mitigate the risk by implementing controls, accept the risk as tolerable, transfer the risk to insurance or a vendor, or avoid the risk by changing operations.
Most risks are mitigated through controls. You can't eliminate the threat of external attacks, so you mitigate through firewalls, intrusion detection, and network hardening. You can't eliminate insider risk, so you mitigate through access controls and monitoring. Mitigation is the most common risk treatment, and your assessment should document what controls address what threats.
Some risks are accepted. You might determine that a specific insider theft scenario is very low probability in your organization because you conduct background checks on all staff, have low employee turnover, and have strong security culture. You'd document the reasoning, the mitigating controls in place, and the organizational decision to accept the residual risk.
Risks can sometimes be transferred to insurance. Cyber liability insurance transfers some financial risk of a breach — it might cover notification costs, forensic investigation, or legal defense. But insurance doesn't transfer regulatory risk. If HHS finds that you violated HIPAA, the insurance doesn't prevent enforcement — it might cover some financial costs, but HHS still has authority to fine you and require remediation. Insurance is a financial mechanism for managing breach costs, not a compliance mechanism for managing regulatory risk.
Risks can be avoided by deciding not to do something that creates the risk. Don't store patient data longer than absolutely required — shorter retention means less data exposure. Don't allow remote access to sensitive systems if it's not operationally necessary. Avoidance is sometimes the right answer, though it's rarely practical in healthcare where patient care often requires data retention, remote access, and cloud-based systems. Whatever treatment you select, the documentation quality is what determines whether it survives scrutiny.
Documentation That Survives HHS Review
Documentation quality is what separates a reasonable compliance decision from non-compliance during an audit. Your risk assessment must be written clearly enough that an HHS auditor reviewing it can understand your environment, your threat analysis, your risk evaluations, your control selections, and your residual risk acceptance.
Document each step thoroughly. Identify the systems you assessed and the business purpose each serves. For each system, document the data types it handles, the threat vectors it faces, and its physical location and access points. Identify the threats you evaluated and your reasoning for likelihood and impact assessments. Document your current controls and how they address each threat. Document your residual risk — the risk that remains even after your current controls are in place. Document your treatment decision for each risk and explain the reasoning. If you're accepting a risk, document the business justification explicitly.
The assessment must be dated and signed by appropriate organizational leadership — typically the Chief Information Officer, Chief Compliance Officer, or Chief Executive Officer. That signature shows organizational awareness and intentional decision-making. The assessment shouldn't be something IT created in a vacuum and handed to leadership as a compliance checkbox.
HIPAA explicitly requires annual updates to the risk assessment. Your environment changes constantly. New systems are added, old systems are retired, the threat landscape evolves, your controls improve or degrade. Many organizations conduct a risk assessment once and never update it, which is a form of non-compliance. HHS resolution agreements consistently cite failure to conduct or update risk assessments — the Ponemon Institute found that only 59% of healthcare organizations conduct annual risk assessments despite it being an explicit regulatory requirement.
Why This Is the Foundation of Everything Else
The risk assessment justifies every other compliance decision you make. Why did you decide to require multi-factor authentication? Because your risk assessment identified unauthorized access as a high-probability, high-impact threat. Why did you implement encryption for patient data at rest? Because your assessment identified data theft as a credible threat. Why did you implement comprehensive audit logging? Because your assessment identified insider misuse and accidental disclosure as threats.
Organizations that skip the risk assessment or do it superficially typically end up in one of two bad places: either they over-control and spend enormous budgets on controls they don't actually need, or they under-control and miss critical threats. The risk assessment also protects the organization during regulatory review. If an HHS audit finds a gap in your controls, you can explain your documented reasoning and demonstrate rational decision-making. Without a risk assessment, you have no justification for your controls — just guesswork and hope.
The risk assessment is the essential first step that determines what controls you actually need, justifies your control decisions to regulators, and protects your organization if something goes wrong. Annual updates ensure the assessment evolves as your environment changes. This is the bedrock of everything that follows in your compliance program.
Frequently Asked Questions
Can we conduct the risk assessment in-house or do we need a consultant?
HIPAA does not require external consultants. The regulation requires a "thorough and accurate" risk assessment. Organizations with qualified internal staff can conduct the assessment themselves. The advantage of external consultants is objectivity and specialized methodology. The disadvantage is cost ($10,000 to $50,000+ depending on scope) and the risk that a consultant's report becomes a shelf document nobody references. In-house assessments conducted by people who understand the systems often produce more actionable results.
What format should the risk assessment take?
HHS does not mandate a specific format. Spreadsheets, formal reports, and GRC platform outputs are all acceptable. The critical requirement is completeness and traceability — an auditor must be able to follow your reasoning from system identification through threat evaluation to control selection. The HHS Security Risk Assessment Tool (SRA Tool) is free and provides a structured framework, though it's designed primarily for small to medium practices.
How detailed do likelihood and impact ratings need to be?
HHS expects documented reasoning, not just a number. A three-tier scale (low, medium, high) is acceptable if each rating includes written justification. A five-tier or quantitative scale provides more granularity but isn't required. What matters is that an auditor can read your evaluation and understand why you rated a threat as you did. A rating without justification is indefensible.
What happens if our risk assessment identifies risks we can't afford to address?
Document the risk, document the business justification for accepting it, document any compensating controls that partially address it, and get organizational leadership to sign off on the acceptance. Identified but accepted risk is far better than unidentified risk. HHS recognizes that resources are finite and expects reasonable decisions, not perfect ones. What they won't accept is unidentified risks or risks that were identified but ignored without documentation.
Does a risk assessment protect us from penalties if a breach occurs?
A documented risk assessment demonstrating reasonable decision-making is a mitigating factor in HHS enforcement. It doesn't prevent penalties entirely, but it demonstrates that the organization was managing compliance proactively rather than ignoring it. HHS resolution agreements consistently impose higher penalties on organizations that lacked risk assessments than on those that had them but experienced breaches despite reasonable controls.
Fully Compliance provides educational content about IT compliance and cybersecurity. This article reflects general information about HIPAA risk assessment as of its publication date. HIPAA requirements evolve and interpretations vary. Consult a qualified compliance professional for guidance specific to your organization.