The fastest way to find out what a risk analysis engagement really involves is to ask what you get at the end of it, and to ask before you sign rather than after. Scope language in a proposal is written to sound complete. A sample deliverable is harder to dress up: it either contains a scope statement, an evidence trail, and findings with a defensible risk level attached, or it does not. This is a buying question, and it is also a compliance question, because the report is the artifact you will still be holding six years from now.
Why the deliverable is the best question you can ask
Most comparison questions in this category are hard to evaluate from the outside. Methodology descriptions sound similar across vendors. Credentials are difficult to weigh. Timelines are estimates.
The deliverable is different because it is a finished object. Asking for a redacted sample costs you one email, and it answers questions the proposal is structured to leave open: how deep did the work go, what did it look at, what did it decline to look at, and can anyone tell from reading it.
It also inverts the usual dynamic. A proposal describes the work a vendor intends to sell you. A sample report shows the work a vendor has already done for someone else, which is a considerably better predictor.
Seven things the report should contain
Working from what the regulation requires and what HHS guidance describes, a risk analysis deliverable should be able to show you all seven of these. Use it as a checklist against any sample you are handed.
| # | Element | The question it answers |
|---|---|---|
| 1 | Scope statement | What was assessed, which locations and systems, and what was excluded |
| 2 | ePHI inventory and data flow | Where ePHI is created, received, maintained, and transmitted |
| 3 | Threats and vulnerabilities identified | What could go wrong, specific to this organization |
| 4 | Current security measures assessed | What is already in place, and whether it works |
| 5 | Likelihood and impact, producing a risk level | How each finding was rated, and on what basis |
| 6 | Evidence of how each finding was reached | Reported, observed, or tested |
| 7 | Date, author, and version | Who stands behind it, and as of when |
HHS's risk analysis guidance describes the substance of items one through five as elements a risk analysis must incorporate, drawing on the requirement at 45 CFR 164.308(a)(1)(ii)(A) to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI. Items six and seven are what make the first five checkable a year later by someone who was not there.
The scope statement, and why it goes first
If you read one section of a sample report, read the scope, and read it for what it excludes.
Scope is where an engagement's real shape lives. A report can be thorough within its scope and still leave an organization exposed, because the exposure sits outside the boundary that was drawn on day one. Common boundaries worth looking for:
- Locations. If you operate four sites, does the report cover four, or one plus an assumption that the others are similar?
- Systems. The EHR is the obvious one. Billing, imaging, backups, email, and the practice management system all hold or move ePHI too.
- Categories of safeguard. Administrative, physical, and technical are three separate sections of the rule. A scope that covers one is a third of an assessment.
- Business associates. Your vendors' handling of your ePHI is your risk, whether or not it is in scope.
A good scope statement is specific about what it left out and says why. Silence is the thing to notice, because an exclusion nobody wrote down is indistinguishable, in the finished file, from a question nobody asked.
The difference between reported and verified
This is the distinction that separates two engagements that produce documents of the same length.
A questionnaire captures what somebody said. That is a legitimate and necessary input. The question is what happened next. If the answer "yes, workstations lock automatically" was recorded and never checked, the report contains a belief. If someone confirmed the setting, the report contains a finding. Both look the same in a PDF.
A report that distinguishes them is doing you a service, and the marker is usually a per-finding notation of method:
- Reported by staff during an interview.
- Observed directly, on a screen or in a room.
- Tested, meaning someone tried it and recorded what happened.
You do not need every finding tested. You need to be able to tell which is which. A report where every item is implicitly "reported" is a self-assessment with a vendor's logo on it, and it is worth knowing that going in rather than discovering it during an investigation.
Three categories of safeguard, not one
The Security Rule splits safeguards into three sections, and the split is the whole reason scope matters here.
| Section | Category | Examples of what it covers |
|---|---|---|
| 45 CFR 164.308 | Administrative | Risk analysis and management, sanction policy, workforce security, training, contingency plan, evaluation |
| 45 CFR 164.310 | Physical | Facility access controls, workstation use, workstation security, device and media controls |
| 45 CFR 164.312 | Technical | Access control, audit controls, integrity, authentication, transmission security |
The risk analysis requirement sits at 164.308(a)(1)(ii)(A) and is not limited to any one of the three. It asks about risks to ePHI, wherever those risks live.
That has a practical consequence for what an assessment can be conducted from. Technical safeguards are conditions inside systems, and a tool with access to those systems can evaluate many of them directly. Physical safeguards at 164.310 are conditions in a building: whether the records room door latches, where a workstation screen points, whether a departed employee's key was returned, whether the room housing the server is also the supply closet. Administrative safeguards are largely conditions in how an organization behaves, which is assessed by asking people and reading what they wrote.
So the honest read on any assessment is: which of the three did it reach, and by what means? A report covering all three from a single remote questionnaire has covered them on paper. That may be adequate for your risk profile. It is a decision worth making with the facts in front of you rather than discovering later.
Where a risk level comes from
Findings usually arrive with a rating attached: high, medium, low, or a number. The rating is only as good as the reasoning behind it, and the reasoning is what to look for.
HHS guidance describes assessing the likelihood of a threat occurring and the potential impact if it does, and combining them into a level of risk. Two things follow.
First, a risk level with no likelihood and no impact recorded is an assertion. It might be a good one. You cannot tell, and neither can anyone reading the file after you leave.
Second, both inputs are specific to your organization. The likelihood of an unauthorized person reaching a workstation is a different number in a locked suite than in a shared building with a public corridor. A report where the ratings could have been written without visiting is a report where they probably were.
Ask a sample report a simple question: for one high finding, can you reconstruct why it is high? If the answer is on the page, the methodology is real.
You are buying a six-year record
The commercial framing of this purchase is an engagement. The compliance framing is a document you will hold for years, and the second one is what determines how much the quality matters.
Under 45 CFR 164.316(b)(2)(i), documentation required by the Security Rule is retained for six years from the date of its creation or the date when it last was in effect, whichever is later. Under 164.316(b)(2)(ii), documentation is made available to those persons responsible for implementing the procedures to which it pertains, and under 164.316(b)(2)(iii) it is reviewed periodically and updated as needed in response to environmental or operational changes.
Read that as a buying criterion. The report has to be legible to somebody who was not in the room, possibly years from now, quite possibly after everyone involved has left. A deliverable that only makes sense to the consultant who wrote it fails a requirement that has nothing to do with its analytical quality.
It is also worth asking a question people forget: in what format do you receive it, and do you keep it if the relationship ends? A findings dashboard inside a platform you stopped paying for is not a record you hold. Ask whether you get an exportable, self-contained document, and confirm the answer before signing rather than at renewal.
What to ask before you sign
- Can I see a redacted sample of the deliverable from an organization of similar size and structure?
- What is in scope, and what is explicitly out? Put the exclusions in writing.
- Which of the three safeguard categories does this cover, and how is each one assessed?
- For a given finding, how would I tell whether it was reported, observed, or tested?
- How are likelihood and impact determined, and are both recorded per finding?
- Who signs the report, and what are their qualifications?
- Do I receive an exportable document I keep independently of any subscription?
- If we add a location next year, what happens to scope and price?
- What is not included that organizations like mine commonly assume is?
The last one is the most useful question on the list and the one least often asked. A vendor who answers it directly is telling you where the edges are. A vendor who says nothing is not included has not answered.
Common questions
What should a HIPAA risk analysis deliverable include?
At minimum it should state the scope it covered and what it excluded, inventory where ePHI is created, received, maintained, and transmitted, identify threats and vulnerabilities, assess current security measures, and record a likelihood and impact determination producing a risk level for each finding. HHS guidance describes these as elements a risk analysis must incorporate. The deliverable should also be dated and attributable. Under 45 CFR 164.316(b)(2)(i), documentation is retained for six years from creation or from when it was last in effect, whichever is later, so the report is a record you will hold for a long time.
Is a completed questionnaire a risk analysis?
Not on its own. 45 CFR 164.308(a)(1)(ii)(A) requires an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI. A questionnaire records what someone believed and answered. Whether those answers were verified is a separate question, and it is the one that decides whether the assessment was accurate and thorough. A questionnaire is a legitimate instrument for gathering input. The gap appears when self-reported answers are never checked against the systems and spaces they describe, because a wrong answer and a right answer look identical in the finished file.
Should a risk analysis cover physical safeguards?
Yes, if the analysis is meant to support Security Rule compliance. The Security Rule requires administrative safeguards at 45 CFR 164.308, physical safeguards at 164.310, and technical safeguards at 164.312. The risk analysis at 164.308(a)(1)(ii)(A) covers risks to ePHI without limiting itself to any one category. Physical safeguards include facility access controls, workstation use and security, and device and media controls. An assessment that reviews only system configuration has looked at one of three categories, and the report will not say so unless you check the scope section.
How often does a HIPAA risk analysis need to be done?
There is no federal calendar. HHS states plainly that the Security Rule does not specify how frequently to perform risk analysis, and notes some entities perform it annually or as needed. What the rule supplies instead is a trigger: 45 CFR 164.308(a)(8) requires periodic evaluation in response to environmental or operational changes affecting the security of ePHI, and HHS guidance says the process should be ongoing, naming a security incident, a change in ownership, turnover in key staff or management, or planned new technology as examples. Anyone citing a specific federal deadline for a risk analysis has invented it.