The HIPAA risk analysis the Security Rule actually requires
Most "risk assessments" are a templated PDF that maps to nothing. Ours maps every place ePHI lives, scores real threats by likelihood and impact, and produces an evidence package built to withstand OCR scrutiny. Done by people who only work in healthcare.
A HIPAA Security Risk Assessment (often called a security risk analysis, or SRA) is the evaluation required by the HIPAA Security Rule at 45 CFR 164.308(a)(1)(ii)(A): an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of all electronic protected health information (ePHI) your organization creates, receives, maintains, or transmits. Done correctly, it inventories every system and location holding ePHI, scores each risk by likelihood and impact, and produces a remediation roadmap and documentation that hold up to review by the HHS Office for Civil Rights (OCR).
What a real HIPAA Security Risk Assessment is, and what the Security Rule requires
The HIPAA Security Rule names the risk analysis as a required implementation specification at 45 CFR 164.308(a)(1)(ii)(A), under the Security Management Process standard. The language is specific: you must conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of all ePHI your organization creates, receives, maintains, or transmits. "All" is the operative word. "Accurate and thorough" is the bar.
A risk analysis is not a policy template, a questionnaire, or a one-page attestation. It is the foundational step that every other Security Rule safeguard depends on, you cannot reasonably decide which controls you need until you understand where your ePHI is and what threatens it. HHS guidance says as much: the risk analysis is the first step in identifying and implementing safeguards that comply with the rule.
It is also among the most frequently cited failures in OCR enforcement. Organizations get penalized not because a breach happened, but because they could not produce an accurate, organization-wide risk analysis that actually accounted for the system that was breached. A checkbox PDF that ignores your imaging modalities, your infusion pumps, or your cloud BAAs is not a defense. It can become evidence against you.
Scope done right: mapping ePHI everywhere it actually lives
The most common reason an SRA fails review is incomplete scope. ePHI does not live only in the EHR. In a real healthcare environment it sits in many systems and flows between them constantly, and every one of those locations is in scope.
We build the asset inventory and data-flow map the rule expects, covering the full footprint of where ePHI is created, received, maintained, and transmitted.
For IoMT and imaging specifically, generic IT assessments routinely miss the mark. A connected medical device often cannot be patched on a normal cycle, runs an unsupported OS, and speaks proprietary protocols, so the risk has to be characterized and compensated for, not ignored. According to Cynerio's 2022 research, roughly 53% of connected medical devices have at least one known critical vulnerability. That gap is exactly the part of healthcare we specialize in.
- EHR and practice-management systems, plus their integrations and interfaces (HL7, FHIR, APIs)
- Medical imaging, PACS, DICOM archives, and modality workstations that store and transmit studies
- Connected medical devices and IoMT, infusion pumps, monitors, ultrasound, lab analyzers, and other clinical equipment that touches or transmits ePHI
- Cloud and SaaS, hosting, backup, telehealth, transcription, analytics, and email
- Endpoints, servers, and storage, workstations, shared drives, mobile devices, and removable media
- Vendors and business associates, every third party that creates, receives, maintains, or transmits ePHI on your behalf, with BAAs and downstream risk accounted for
Methodology aligned to NIST and OCR expectations
A defensible risk analysis follows a repeatable, recognized methodology, not a vendor's proprietary score. We align to NIST Special Publication 800-30 for the risk assessment process and use NIST SP 800-66, the HHS-referenced guidance for implementing the HIPAA Security Rule, as the bridge between the framework and the regulation. We map findings to the NIST Cybersecurity Framework where it helps leadership see the whole posture.
In practice that means doing what OCR looks for: identify the threats and vulnerabilities to each asset, identify the security measures already in place, and then determine the likelihood, impact, and resulting risk level for each threat-vulnerability pair. That likelihood-and-impact reasoning is the difference between a risk analysis and a list of findings.
Every conclusion is tied to evidence, interviews, configuration reviews, scans, and documentation, so the result is repeatable and explainable. If an investigator asks how you arrived at a risk level, the answer is in the record, not in someone's head.
The proposed HIPAA Security Rule overhaul, and why to get ahead of it now
On January 6, 2025, OCR published a Notice of Proposed Rulemaking in the Federal Register proposing the most significant overhaul of the HIPAA Security Rule in two decades. As of mid-2026 it remains proposed, not finalized, and it could be narrowed, delayed, or withdrawn. But the direction is clear, and the smart move is to get ahead of it rather than scramble later.
The proposed rule would remove the distinction between "required" and "addressable" implementation specifications, meaning controls that many organizations have treated as optional would become mandatory, with flexibility remaining in how you implement them rather than whether you do. It would explicitly require a written technology asset inventory and network maps showing how ePHI moves, kept current on an ongoing basis. And it would sharpen the risk analysis itself to require documented identification of threats and vulnerabilities and a determination of the likelihood, impact, and risk level of each.
Several of the controls it would make explicit, multi-factor authentication for ePHI access, encryption of ePHI at rest and in transit, network segmentation to limit lateral movement, are already widely regarded as best practice. We scope every assessment to today's rule while flagging the gaps that the proposed update would turn into hard requirements, so you are not caught flat-footed if and when it is finalized.
What you get: deliverables built for auditors and OCR
The point of an SRA is not the engagement, it is the evidence and the roadmap it leaves behind. You get artifacts your board, your auditors, and an OCR investigator can all use.
Because the risk analysis is meant to be an ongoing process, we structure the deliverables so your team, or ours, can keep them current as systems, devices, and vendors change, rather than starting from zero every year.
- A complete ePHI asset inventory and data-flow map across EHR, imaging, IoMT, cloud, and vendors
- A risk register scoring every identified threat-vulnerability pair by likelihood and impact, with the resulting risk level and the rationale behind it
- A prioritized remediation roadmap, what to fix first, why, and a realistic path, sequenced by risk and effort rather than by vendor convenience
- An OCR-ready evidence package: methodology, scope, findings, and supporting documentation organized to demonstrate an accurate and thorough, organization-wide analysis
- An executive summary leadership can act on, translating technical risk into business and patient-safety terms
How it works
- 01
Scope and asset discovery
We work with IT, security, and clinical/biomedical engineering to identify every system, device, vendor, and location where ePHI is created, received, maintained, or transmitted, building the asset inventory and data-flow map the rule expects, including the IoMT and imaging assets generic assessments miss.
- 02
Threat and vulnerability identification
For each in-scope asset we identify the realistic threats and the vulnerabilities that expose it, drawing on interviews, configuration and architecture reviews, vulnerability data, and the specific failure modes of healthcare environments, unpatchable devices, flat clinical networks, weak vendor controls.
- 03
Risk determination (likelihood and impact)
Using a NIST SP 800-30-aligned method, we score each threat-vulnerability pair by likelihood and impact to determine its risk level, and document the security measures already in place. This is the analysis OCR looks for, not a list of findings, but reasoned, evidence-backed risk ratings.
- 04
Prioritized remediation roadmap
We translate the risk register into a sequenced plan: what to remediate first, the controls that close the most risk for the least disruption to care, and where the proposed Security Rule update would raise the bar. Practical, prioritized, and built for a healthcare operating reality.
- 05
Evidence package and review
We deliver the full documentation set, methodology, scope, findings, risk register, and roadmap, and walk your leadership and compliance team through it so the results are understood, owned, and ready to produce on demand for an auditor or OCR.
Frameworks & standards we align to
Every finding maps back to the standards your auditors, board, and cyber-insurer already speak.
Frequently asked questions
Is a HIPAA Security Risk Assessment actually required by law?
Yes. The HIPAA Security Rule requires a risk analysis as a required implementation specification at 45 CFR 164.308(a)(1)(ii)(A). Every covered entity and business associate must conduct an accurate and thorough assessment of the risks and vulnerabilities to all ePHI it creates, receives, maintains, or transmits. It is also a prerequisite for other obligations, including the security risk analysis required under the Medicare and Medicaid Promoting Interoperability programs, and it is among the failures most frequently cited in OCR enforcement actions.
How often do we need to do one?
There is no fixed calendar interval written into the rule, but the risk analysis is meant to be an ongoing process, not a one-time event. The practical standard is at least annually, and additionally whenever something material changes: a new EHR or system, a major new medical device or IoMT deployment, a move to cloud, a merger or new location, a significant change in operations, or after a security incident. Many organizations refresh annually and update the risk register as the environment changes throughout the year.
What's the difference between an SRA, a gap assessment, and SOC 2?
They answer different questions. A HIPAA Security Risk Assessment (SRA) is the risk analysis the law requires, it identifies your ePHI, the threats to it, and the likelihood and impact of each risk. A gap assessment is narrower: it measures your current controls against the HIPAA Security Rule's specifications to show where you fall short, which is useful but is not itself the required risk analysis. SOC 2 is a separate, voluntary attestation against the AICPA Trust Services Criteria, typically used to demonstrate security to customers; a SOC 2 report does not satisfy your HIPAA risk-analysis obligation. Many organizations need the SRA for compliance and use a gap assessment and/or SOC 2 alongside it for different audiences.
What does OCR actually look for in a risk analysis?
OCR looks for evidence that the analysis was accurate, thorough, and organization-wide. In practice that means a complete inventory of every place ePHI lives (not just the EHR), identification of the threats and vulnerabilities to each, documentation of the security measures in place, and a determination of the likelihood, impact, and risk level of each threat. The most common findings against organizations are that the analysis was incomplete, it missed systems, devices, or locations, or that it was a generic template never tied to the actual environment. We build the assessment specifically to withstand that scrutiny.
Does one assessment cover multiple locations or related entities?
It can, if scoped correctly. The risk analysis must account for ePHI across the entire organization, so a multi-site clinic group or health system can be covered by a single, organization-wide assessment, provided every site, system, and data flow is actually included in scope. Separate legal entities each carry their own obligation, though the work can be coordinated. The danger is assuming a single location's assessment covers the rest; if a site or system is left out of scope, it is effectively unassessed in the eyes of OCR. We define scope deliberately so coverage is complete and defensible.
How long does a HIPAA Security Risk Assessment take?
It depends on the size and complexity of your environment, the number of locations, systems, connected medical devices, and vendors in scope. A small single-site clinic is a very different effort from a multi-site group with extensive imaging and IoMT. We scope each engagement up front so you get a clear timeline and a fixed expectation before we begin, rather than an open-ended project. The free Security Rule gap assessment is the fastest way to get an accurate scope.
Further reading
Field notes from our research that go deeper on this work.
Start with a free HIPAA Security Rule gap assessment
See where you stand against the HIPAA Security Rule before you commit to a full risk analysis. We'll review your current posture, show you the highest-priority gaps, and scope a proper SRA, no obligation. Healthcare-only, based in Tampa Bay, FL.
Request your free gap assessment →