HIPAA Risk Assessment: What OCR Actually Checks

A HIPAA risk assessment is the written, enterprise-wide analysis of where your electronic protected health information lives, what threatens it, how likely each threat is, how bad it would be, and what you are doing about it. The Security Rule calls it a risk analysis, makes it Required, and puts a second Required duty right beside it: act on what you found. When OCR opens an investigation, the risk analysis is the first document it asks for, and in its own 2024 report to Congress it named risk analysis as the number one Security Rule area needing improvement.

Here is what you get from the next twenty minutes. The exact regulatory text, so you stop arguing about what is required. OCR's own list of what a compliant analysis contains, which most guides quietly shorten. A scored example with real values, using the method NIST publishes. The enforcement record, entity by entity, with amounts. And the honest answers to the questions everyone asks: how often, who does it, what it costs, and whether the free federal tool is enough. If you want the workbook to fill in as you read, it is the free HIPAA risk assessment template. If you are still working out whether HIPAA reaches you at all, start with covered entities and business associates and come back.

Two Required duties, not one assessment

Most articles on this subject describe a single thing called an assessment. The regulation does not. 45 CFR 164.308(a)(1) is one standard, the security management process, with four Required implementation specifications underneath it. Two of them are the entire subject of this page, and they are separate.

Risk analysis (Required). Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate.

Risk management (Required). Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with 164.306(a).

The first produces a finding. The second produces a control. Writing the assessment and filing it satisfies nothing about the second duty, and OCR charges them separately. When it imposed a $1,500,000 civil money penalty on Warby Parker in February 2025, it found three distinct violations: a failure to conduct an accurate and thorough risk analysis, a failure to implement security measures sufficient to reduce risks to a reasonable and appropriate level, and a third under a different provision. Two line items. Two duties.

The word Required is doing real work. The Security Rule sorts its implementation specifications into two kinds at 164.306(d). Required ones must be implemented. Addressable ones require you to assess whether the specification is a reasonable and appropriate safeguard in your environment, then implement it, or document why it would not be reasonable and appropriate and implement an equivalent alternative measure if reasonable and appropriate. OCR's guidance states it flatly: an addressable implementation specification is not optional. Risk analysis is not addressable at all. It is Required, and the word appears in the regulation itself. Any guide telling you a safeguard applies only if your assessment says so has misread the rule, and the misreading tends to surface during an investigation.

Three different things get called a HIPAA risk assessment

Before the steps, a terminology problem worth five minutes, because it causes real confusion in real investigations. Three separate obligations get the same nickname.

This article is about the first one. The second deserves a sentence, because the leading competitor article gets it wrong: the regulation lists four factors, not three. The nature and extent of the PHI, the unauthorised person who used it or received it, whether the PHI was actually acquired or viewed, and the extent to which the risk has been mitigated. The one that gets dropped, whether it was actually acquired or viewed, is the factor that decides most real cases. Logs showing a file was never opened, or a stolen laptop that was encrypted, turn on exactly that question. And the rule frames the whole thing as a presumption: an impermissible use or disclosure is presumed to be a breach unless you demonstrate a low probability of compromise. The burden is yours.

What OCR expects to find in the document

HHS does not endorse a methodology. Its guidance says so in as many words, and adds that following any particular framework does not prove compliance. What it does publish is a list of elements a risk analysis must incorporate regardless of the method employed. There are nine, and if your document is missing one, an investigator will notice before you do.

1. Scope of the analysis. All ePHI, regardless of the electronic medium in which it is created, received, maintained or transmitted, and regardless of source or location. That means the laptop in the sales director's bag and the analytics warehouse, not only the production database.
2. Data collection. Where ePHI is stored, received, maintained and transmitted. This is the asset inventory, and it is the part most people already have half of in a spreadsheet somewhere.
3. Identify and document potential threats and vulnerabilities. Reasonably anticipated threats, per system. Ransomware, phishing, a misconfigured storage bucket, a departing employee with credentials that still work.
4. Assess current security measures. What is already in place and whether it is configured and used correctly. Dropped by most guides, and it is the element that separates an analysis from a wish list.
5. Determine the likelihood of threat occurrence. A rated probability for each threat and vulnerability pair. Dropped by most guides.
6. Determine the potential impact. Rated separately from likelihood. Dropped by most guides, usually by folding it into the previous step.
7. Determine the level of risk. Likelihood against impact, per pair. OCR says the output should be documentation of the assigned risk levels and a list of corrective actions to mitigate each. Dropped by most guides.
8. Finalize documentation. The written analysis. The Rule does not prescribe a format, but it does require that it be written.
9. Periodic review and updates. On a schedule and on trigger events. More on this below, because it is where the most-asked question lives.

Compare that with the six steps on the page that currently outranks this one for the same query. Define scope, identify risks, perform a gap analysis, mitigate, document, audit. Four of OCR's nine are missing, and one step OCR never asks for, the gap analysis, has been added. It links to the OCR guidance. It reproduces none of it.

How to conduct the risk analysis, step by step

NIST SP 800-66 Revision 2, published February 2024, is the federal implementation guide for the Security Rule. It is guidance, not law, and it says the Rule does not prescribe any particular risk assessment methodology. It also gives you a seven-step method drawn from NIST SP 800-30 that maps cleanly onto OCR's nine elements, and it is the method an investigator will recognise. Here it is, with the part each step has to produce.

Step 1: Prepare, and set the scope in writing

Decide what the analysis covers and write it down before you start. NIST's scope guidance explicitly includes teleworkers, which means every laptop that opens the EHR from a kitchen table. For a company rather than a clinic, scope is the boundary of every system, service and vendor that creates, receives, maintains or transmits ePHI. If you have subprocessors, they are in scope. If you cannot list them, that is your first finding.

Step 2: Inventory the ePHI and the systems that hold it

One row per system. What it holds, where it runs, who administers it, who has access, how it connects. This is the data collection element. The January 2025 proposal to revise the Security Rule would make a written technology asset inventory and a network map mandatory standards in their own right, reviewed at least every twelve months, so building this now is building for where the rule is heading. Your risk assessment workbook has the columns.

Step 3: Identify threats and vulnerabilities per system

A threat is something that can cause harm: a ransomware operator, a phishing email, a flood, a careless contractor. A vulnerability is a weakness a threat can exploit: an unpatched server, a shared admin password, a backup that has never been restored. Pair them. The pairs are what you score, and unpaired threats are how analyses end up rating the weather without rating the server room.

Step 4: Assess the controls already in place

For each pair, what is currently stopping it? Multi-factor authentication, encryption at rest, network segmentation, a tested backup. Then the harder question: is the control actually configured, actually used, actually working? A control that exists on paper and not in the console is a vulnerability with a nicer name.

Step 5: Rate likelihood and impact, then the level of risk

This is the step almost every guide skips, and it is the step that makes a document an analysis. Rate how likely the threat is to be initiated and to succeed given the controls in place. Rate the impact on confidentiality, integrity and availability if it does. Then combine them. NIST supplies the scales and two worked examples, reproduced below.

Both examples are NIST's own, from SP 800-66r2, and they are worth studying because they show two threats landing at different risk levels for different reasons. An assessor reads the rating and then reads the reasoning. If the reasoning is missing, the rating is a guess with a colour.

Step 6: Document, and decide what you will do about each risk

Write it up: scope, inventory, pairs, controls, ratings, reasoning, and the list of corrective actions per risk. That last item is where the risk analysis hands over to the second Required duty. Every risk rated above your acceptance line needs an owner, an action and a date, and that plan is the artefact that satisfies 164.308(a)(1)(ii)(B). Filing the analysis without it is the exact failure OCR charged Warby Parker with as a separate violation.

Step 7: Review it, on a schedule and on triggers

Covered below in full, because how often is the question the search engines get asked most.

How often, and what forces a fresh one

The Security Rule does not specify how frequently to perform a risk analysis. OCR's guidance says that in one sentence, then names the situations that require an update: a security incident, a change in ownership, turnover in key staff or management, and a plan to adopt new technology. Elsewhere the same guidance gives annual as one reasonable rhythm, alongside bi-annual and every three years depending on circumstances. The January 2025 proposal would replace all of that with a hard floor of at least once every twelve months. That proposal is not law, see the status section, but it tells you where the floor is heading.

The practical answer for a company with engineering: annually as the floor, plus a fresh pass whenever one of the four triggers fires. A new cloud provider is a new system. A phishing email that got clicked is a security incident whether or not it became a breach. A change of security officer is key staff turnover.

Then keep every version. 45 CFR 164.316(b)(2)(i) requires you to retain documentation for six years from the date of its creation or the date when it last was in effect, whichever is later. For a risk analysis, the superseded versions are the evidence that the process was ongoing. A single current PDF proves one afternoon of work. Six dated versions prove a programme.

What a missing risk analysis has cost

Every guide says OCR takes this seriously. Almost none of them name a case. Here is the record, from HHS press releases, and every action on it cites failure to conduct an accurate and thorough risk analysis.

OCR launched a Risk Analysis Initiative on 31 October 2024, describing it as an effort to focus select investigations on compliance with the risk analysis provision, a key Security Rule requirement and the foundation for effective cybersecurity. By April 2026 OCR counted thirteen completed investigations under it, and the count has kept moving.

Three things the table shows that a paragraph of adjectives cannot. Business associates are on it, not only providers: an accounting firm, a wellness plan operator, an IT vendor. The two civil money penalties, Warby Parker and Children's Hospital Colorado, are imposed rather than negotiated, which is what happens when an entity does not settle. And the amounts do not track the number of records: fifteen million individuals for $10,000, ten thousand for $450,000. What tracks is what OCR found about the programme.

Cybersecurity threats affect large and small covered health care providers. Small providers also must conduct accurate and thorough risk analyses to identify potential risks and vulnerabilities to protected health information and secure them.

The penalty tiers, as adjusted for 2026

The base amounts in 45 CFR 160.404 have not changed since 2013, but they are adjusted for inflation every year, and the figures actually in force are the adjusted ones. The current adjustment was published on 28 January 2026 at 91 FR 3665. If a page quotes $100 to $50,000 per violation, it is quoting a table that is more than a decade stale.

One nuance that nearly everyone misses. In 2019 HHS issued a notification of enforcement discretion stating that it reads the HITECH Act as setting four different annual caps by tier, and that it will apply those lower caps in enforcement. That notification is effective indefinitely and the January 2026 adjustment does not mention it, so it stands. The regulation says one cap; OCR's stated practice is four. Both matter to your exposure.

The proposed rule, and where it stands

On 6 January 2025 HHS published a notice of proposed rulemaking to revise the Security Rule at 90 FR 898. On risk analysis it proposes three changes. Remove the distinction between required and addressable specifications and make nearly all of them required. Add a new standard requiring a written technology asset inventory and a network map, each reviewed at least every twelve months. And rewrite the risk analysis itself as an accurate and comprehensive written assessment with eight mandatory contents, including the risks of each business associate arrangement, on a twelve-month refresh floor.

Status as of September 2026: it is a proposal. No final rule has been published. The Unified Agenda lists it under long-term actions with a projected final action of July 2027, and Unified Agenda dates are planning estimates rather than deadlines. Several pages elsewhere describe it as a final rule. They are wrong, and building your programme on proposed text as if it were law is a mistake in the other direction. What the proposal does tell you is which way the floor is moving, and every one of its three risk analysis changes is something a well-run programme already does.

Who does it, and what it costs

The Security Rule requires you to designate a security official at 164.308(a)(2), and that person owns the risk analysis whether or not they do the work. In a small entity that is often one person wearing two hats. In a company it is the head of security or the compliance lead, with system owners supplying the inventory and engineering supplying the control evidence. External consultants are common and permitted, and the standard does not care who held the pen. It cares that the document exists, that it is accurate and thorough, that it covers all ePHI, and that someone accountable signed it.

On cost, most guides go quiet. The honest range depends on the size of the estate rather than the size of the company. A practice with one EHR and a handful of laptops can complete the free SRA Tool in a few working days of one person's time. A company with a cloud platform, a data warehouse, a dozen SaaS vendors and subprocessors is looking at two to six weeks of a security lead's time plus input from every system owner, and an external assessment for that shape of organisation runs from the low tens of thousands of dollars upward. Whatever the number, compare it with the table above.

Running it as a programme

Everything above can be done in a workbook, and the template is built for exactly that. The difficulty is not the first analysis. It is the fourth one, three years later, when the security officer has changed, the inventory lives in two places, and OCR asks for every version since 2023.

Venvera's HIPAA module holds the risk analysis as a record rather than a file: title, scope, methodology, the threats and vulnerabilities identified, the risk score and level, the mitigation plan, the residual risk, a status, a completion date and a next review date. The Security Rule safeguards sit alongside as controls with their own evidence, so the corrective actions from the analysis become tracked work rather than a paragraph in an appendix, which is the second Required duty made visible. The compliance calendar carries the annual risk analysis, the business associate agreement review, the contingency plan test and workforce training as recurring obligations with owners and dates, so the review that has to happen next year is already scheduled. And where HIPAA overlaps ISO 27001 or NIST CSF, the crosswalk shows the mapping so evidence produced once counts where it genuinely applies. If you want to see the gap first, the free compliance check takes a few minutes.

Frequently asked questions

What is a HIPAA risk assessment?

The written, enterprise-wide analysis of the risks and vulnerabilities to the confidentiality, integrity and availability of your electronic protected health information, required by 45 CFR 164.308(a)(1)(ii)(A). The regulation calls it a risk analysis. It must cover all ePHI regardless of where it lives, rate each risk, and feed a risk management plan that reduces those risks to a reasonable and appropriate level.

Is a HIPAA risk assessment required?

Yes. It is a Required implementation specification, and the word Required appears in the regulation. It applies to covered entities and to business associates. It is not addressable, and addressable specifications are not optional either.

How often is a HIPAA risk assessment required?

The Security Rule sets no interval. OCR's guidance names annual as one reasonable rhythm and requires an update after a security incident, a change in ownership, turnover in key staff or management, or a plan to adopt new technology. The January 2025 proposed rule would set a floor of once every twelve months; it is not yet law.

What is the difference between a HIPAA risk assessment and a risk analysis?

The regulation uses risk analysis for the Security Rule duty at 164.308(a)(1)(ii)(A). Risk assessment is the everyday name for the same thing, and also the name of two different obligations: the four-factor breach risk assessment at 164.402, which decides whether an incident is a reportable breach, and the periodic evaluation at 164.308(a)(8). NIST SP 800-66r2 uses risk assessment for the process of determining the level of risk within the analysis.

Who is responsible for conducting the HIPAA risk assessment?

The designated security official required by 164.308(a)(2) owns it. System owners, IT and engineering supply the inventory and the control evidence. External consultants may do the work. Accountability stays with the entity.

Does the free HHS SRA Tool satisfy the requirement?

Not on its own, and its own page says so: use of the tool is neither required by nor guarantees compliance, and version 3.7 added a reminder that the survey alone may not identify all risks. It is a good fit for the medium and small providers it names as its audience. It was not built to inventory a cloud platform with subprocessors.

What does a HIPAA risk assessment cost?

For a small practice, a few working days of one person's time with the free tool. For a company with cloud infrastructure and vendors, two to six weeks of a security lead's time with input from system owners, or an external assessment from the low tens of thousands of dollars upward. The settlements in the enforcement table above start at $5,000 and reach $3,000,000.

How long must risk assessment documentation be kept?

Six years from the date of creation or the date it was last in effect, whichever is later, under 45 CFR 164.316(b)(2)(i). Keep the superseded versions; they are the evidence the process was ongoing.

Do business associates have to do a HIPAA risk assessment?

Yes. The regulation names the covered entity or business associate in the text of the requirement, and the enforcement record includes an accounting firm, a wellness plan operator and an IT vendor.

Primary sources

• 45 CFR 164.308, Administrative safeguards, 2025 annual edition (govinfo)
• 45 CFR 164.316, Documentation requirements, 2025 annual edition (govinfo)
• HHS OCR, Guidance on Risk Analysis Requirements under the HIPAA Security Rule
• NIST SP 800-66 Revision 2, Implementing the HIPAA Security Rule, February 2024
• HealthIT.gov, Security Risk Assessment Tool, version 3.7
• HHS OCR, Annual Report to Congress on Breaches of Unsecured Protected Health Information, calendar year 2024
• 90 FR 898, HIPAA Security Rule to Strengthen the Cybersecurity of ePHI, proposed rule, 6 January 2025
• Unified Agenda, RIN 0945-AA22
• HHS, civil money penalty against Warby Parker, 20 February 2025
• HHS, four ransomware investigations resolved, 23 April 2026
• HHS, Vision Upright MRI settlement, 15 May 2025

Written from the regulation and HHS's own publications. Settlement figures are as published in HHS press releases. This is not legal advice. Checked in September 2026.