A hospital's HIPAA risk analysis covers all of the electronic protected health information the organization holds, in every department and at every location, on every system and device that creates, receives, maintains, or transmits it. It is not an EHR review. The most common way a hospital's analysis fails is not a wrong answer to a hard question. It is a scope that quietly stopped at the edge of the medical record system.
The short answer
Three things decide whether a hospital's risk analysis holds up, and none of them is the format of the report:
- Scope. Every system and location holding ePHI is in, including the ones no one has thought about since they were installed.
- Depth. The regulation asks for an assessment that is accurate and thorough, and the evaluation standard asks for it to be technical and nontechnical. Both words carry weight.
- Evidence. An assertion recorded on a form is not an observation. What was examined, by whom, and when is what makes the analysis defensible later.
The rest of this article is where those three come from in the regulation, and what each looks like inside a hospital rather than a clinic.
What the rule requires, in its own words
The risk analysis obligation is a Required implementation specification under the Security Management Process standard. There is no documented-alternative path for a Required specification.
Two words in that sentence are the whole standard: accurate and thorough. They are the criteria a regulator applies after an incident, and they are the reason a completed questionnaire is not automatically a completed risk analysis. A form can be filled in accurately and still be thorough about nothing, if the questions never reached half the organization.
The word held is the other one to notice. The obligation attaches to the information, not to a system, a department, or a contract. Wherever the ePHI is, the analysis follows it.
The sentence that sets the scope
OCR's Guidance on Risk Analysis is the clearest statement of how far the scope reaches, and it is worth reading slowly:
Regardless of the source or location. That phrase is what makes a hospital's analysis a different job from a clinic's, and the difference is not difficulty. It is surface area. A single-site practice can usually enumerate its ePHI in an afternoon because one person has seen all of it. Nobody has seen all of a hospital's.
Where a hospital's ePHI lives
The EHR is the system everyone remembers. It is rarely the only one holding ePHI, and in a hospital it is one of dozens. A scoping conversation that gets past the EHR usually surfaces some version of this list:
| Area | What holds ePHI there |
|---|---|
| Imaging | PACS, modality workstations, and imaging equipment that caches studies locally on its own drive |
| Laboratory and pathology | The LIS, analyzer interfaces, slide scanners, and results archives that predate the current EHR |
| Pharmacy | Dispensing cabinets, the pharmacy information system, and compounding records |
| Cardiology and monitoring | Telemetry, ECG carts, stress and Holter systems, device interrogation reports |
| Perioperative and anesthesia | Anesthesia records, surgical scheduling, implant logs |
| Biomedical devices | Infusion pumps, ventilators, and monitors with storage or network access, often managed by clinical engineering rather than IT |
| Administrative | Billing and coding, registration, scheduling, transcription and dictation, fax servers, email, patient kiosks |
| Adjacent operations | Employee health, research databases, quality registries, home health or hospice arms, foundation and outreach systems |
Half of that list is owned by someone who does not report to IT, and several items are managed by a vendor. None of that narrows the scope. The ePHI is still held by the hospital, so it is still in.
ONC's own overview material for the federal assessment tool makes the same point in a single line: “Regarding applications, be sure to look beyond just the EHR system,” listing practice management, scheduling, billing, telecommunications, email, and cloud apps as examples of platforms that can contain or access ePHI. The same slide asks organizations to “ensure an inclusive scope,” meaning risks to ePHI throughout the organization wherever it is created, maintained, received, or transmitted.
What the federal tool says about its own limits
ONC and OCR publish a free Security Risk Assessment Tool. It is a genuinely useful piece of software, and its documentation is unusually candid about where it stops. From the v3.6 User Guide:
Its FAQ repeats the point: the tool “was designed with small to medium sized practices in mind,” and “large organizations may find other methods more suitable to conducting an SRA.” The same guide is explicit that “use of this tool is neither required by nor guarantees compliance with federal, state or local laws,” and that “this is only a tool to assist an organization with its review and documentation of its risk assessment, and therefore it is only as useful as the work that goes into performing and recording the risk assessment process.” It closes the disclaimer by encouraging “providers, and professionals to seek expert advice when evaluating the use of this tool.”
Nothing there prohibits a hospital from using it, and plenty of hospitals do use it as a structuring device. The useful takeaway is narrower and more interesting: the federal government's own free questionnaire does not claim that answering its questions produces a compliant risk analysis at hospital scale. If the publisher of the tool will not make that claim, a reader should be slow to accept it from anyone else.
The word "nontechnical" is doing real work
Sitting next to the risk analysis specification is the Evaluation standard, and it is the provision most often skipped in a hospital program:
A vulnerability scan is a technical evaluation. It is not a nontechnical one. OCR's guidance defines the category directly, noting that vulnerabilities group into technical and non-technical, and that “non-technical vulnerabilities may include ineffective or non-existent policies, procedures, standards or guidelines.”
A nontechnical evaluation is somebody reading the sanction policy and asking when it was last applied. It is checking whether the termination procedure that exists on paper matches what happened when the last nurse manager left. It is asking the night shift what they do when the system is slow. Those answers do not come from a scanner, and they rarely come from the person filling in the form, because the person filling in the form is usually the person who wrote the policy.
Physical safeguards across a hospital campus
The Security Rule devotes an entire section to physical safeguards, and it is the section a questionnaire has the hardest time reaching. 45 CFR 164.310 sets four standards: facility access controls, workstation use, workstation security, and device and media controls.
Read that against a hospital. All workstations includes the one on a wheeled cart parked in a corridor, the one at the nurses' station facing the waiting area, the shared terminal in the ED where four people are logged in behind one badge, and the workstation in the imaging suite that a patient sits three feet from. The workstation use standard at 164.310(b) reaches further still, covering “the physical attributes of the surroundings of a specific workstation or class of workstation.” The surroundings are the requirement. A form cannot see surroundings.
Facility access controls at 164.310(a) ask who can physically get into the spaces where systems live, with implementation specifications covering a facility security plan, access control and validation procedures including visitor control, and maintenance records documenting repairs and modifications to walls, doors, and locks. All four of those are Addressable, which under 45 CFR 164.306(d)(3) means implement it if reasonable and appropriate, or document why it is not and implement an equivalent alternative measure where one is reasonable and appropriate. Addressable is a documented decision. It is not permission to skip.
The gap between the answer and the fact is the point here. A questionnaire asks whether the server room is locked, and someone types yes. That answer can be true and useless at the same time: the room is locked, and the door is propped for the HVAC contractor every Tuesday, and the badge list still includes two people who left in March, and the maintenance records at 164.310(a)(2)(iv) have never been kept. Every one of those is visible in ten minutes to someone standing in the corridor, and invisible forever to a form. Whether that walk happens, and who does it, is a reasonable thing to establish before an analysis begins rather than after.
One analysis, many facilities
Hospitals rarely occupy one building. There is a main campus, an outpatient center across town, a handful of employed physician practices, an infusion suite, maybe a rural clinic an hour away that was acquired three years ago and still runs its old scheduling system.
The rule does not resolve this by counting buildings. It attaches to the ePHI, and OCR's guidance is explicit that electronic media “includes a single workstation as well as complex networks connected between multiple locations.” Every location holding ePHI is in scope. Whether that produces one document or twelve is a matter of method.
The SRA Tool User Guide gives the practical test in its FAQ, in the context of a practice with multiple locations: the answer “depends on how much the locations differ with their policies, procedures, and infrastructure,” and where “question responses are not applicable to all locations, you may consider doing a separate SRA for each location.” That is permissive rather than prescriptive, and it is the right frame. A system where every site runs the same EHR, the same image, the same badge system, and the same policies can reasonably be assessed once with site-specific work layered where the sites diverge. A system that grew by acquisition, where site four still has its own domain and its own locks, has not been assessed once. It has been assessed once and assumed three times.
The honest question to ask of a single report covering many facilities is simply which of them somebody looked at.
Size changes the how, not the whether
The Security Rule is deliberately scalable, and the scalability provision is often misread as a discount:
Flexibility governs which security measures you choose. It does not shrink the scope of the analysis, and it does not lower the accurate-and-thorough bar. A 30-bed hospital and a 300-bed hospital may reasonably land on very different controls. Both have to have looked at everything they hold.
For a hospital the flexibility provision usually runs the other way from how it gets quoted. Size, complexity, and capabilities are factors that can raise expectations as easily as lower them. An organization with a security team, a budget, and a biomedical engineering department is not well placed to argue that examining its own imaging network was not reasonable and appropriate.
What you keep afterward
The Security Rule requires the risk analysis to be documented and does not prescribe a format (45 CFR 164.316(b)(1)). What survives contact with a regulator is generally not the report's design. It is whether the report shows its work:
- An inventory of where ePHI lives, because OCR's guidance states plainly that an organization must identify where the ePHI is stored, received, maintained or transmitted, and every later step depends on that list being real.
- Threat and vulnerability pairs with likelihood and impact, rather than a list of findings with no reasoning attached to them.
- A risk management plan, since 164.308(a)(1)(ii)(B) separately requires implementing security measures sufficient to reduce risks to a reasonable and appropriate level. An analysis with no plan behind it satisfies one specification and not the next one.
- The record of what was examined and how, including which sites were visited and which were not. A scope statement that names its own boundaries is stronger than one that implies it covered everything.
OCR's guidance also settles the cadence question, and it settles it against the calendar: “The Security Rule does not specify how frequently to perform risk analysis as part of a comprehensive risk management process.” The rule instead requires review and modification of security measures as needed (164.306(e)) and documentation review in response to environmental or operational changes (164.316(b)(2)(iii)). In a hospital those changes are constant: a new service line, an acquisition, a migration, a vendor swap, an incident. Many organizations review annually as a backstop, which is sensible practice rather than a federal deadline. Anyone who cites you a statutory annual requirement for the risk analysis itself is describing a rule that does not currently exist.
One note on what is coming. Updates to the Security Rule have been proposed and have not been finalized. Proposed requirements are not binding, and nothing described in this article depends on them. Everything above is current law today.
Common questions
Does a hospital's HIPAA risk analysis have to cover more than the EHR?
Yes. OCR's Guidance on Risk Analysis states that the scope includes the potential risks and vulnerabilities to the confidentiality, availability and integrity of all ePHI that an organization creates, receives, maintains, or transmits, and that an organization's risk analysis should take into account all of its ePHI regardless of the particular electronic medium in which it is created, received, maintained or transmitted or the source or location of its ePHI. In a hospital that reaches well past the EHR: imaging and PACS, laboratory and pathology systems, pharmacy, anesthesia records, cardiology and telemetry, dictation, fax servers, patient kiosks, research databases, and biomedical devices that store studies locally. An analysis scoped to the EHR alone is scoped to one system among many.
Can a hospital use the free federal SRA Tool for its risk analysis?
The tool's own documentation advises against relying on it at hospital scale. The SRA Tool v3.6 User Guide states that the target audience of this tool is medium and small providers; thus, use of this tool may not be appropriate for larger organizations. Its FAQ adds that large organizations may find other methods more suitable to conducting an SRA. The same guide states that use of this tool is neither required by nor guarantees compliance with federal, state or local laws, and encourages providers and professionals to seek expert advice when evaluating the use of this tool. The tool is a useful free resource and nothing prohibits a hospital from using it. Its publisher is simply clear that it was not built for that scale.
Does a health system with multiple facilities need one risk analysis or one per site?
The Security Rule does not answer this by counting buildings. It defines the obligation by the ePHI: 45 CFR 164.308(a)(1)(ii)(A) requires an accurate and thorough assessment of the risks and vulnerabilities to ePHI held by the covered entity, and OCR's guidance says electronic media includes a single workstation as well as complex networks connected between multiple locations. What matters is that every location holding ePHI is assessed. One analysis can cover a system with many facilities, provided the work behind it examined each of them. The SRA Tool User Guide FAQ frames the practical test as how much the locations differ with their policies, procedures, and infrastructure, noting that where question responses are not applicable to all locations, you may consider doing a separate SRA for each location. A single report covering twelve sites that were never separately examined is one report, not twelve assessments.
Who is supposed to perform a hospital's risk analysis?
The Security Rule does not name a job title or require an outside firm. It does require the work to be done to a standard. 45 CFR 164.308(a)(1)(ii)(A) requires the assessment be accurate and thorough. 45 CFR 164.308(a)(8) requires a periodic technical and nontechnical evaluation, which means the assessment reaches policies, procedures, and practices, not only systems. 45 CFR 164.308(a)(2) requires the organization to identify a security official responsible for developing and implementing the required policies and procedures. A hospital may perform the analysis internally, use outside help, or combine the two. The test OCR applies is the quality and completeness of the analysis, not who signed it.