164.308(a)(1)(ii)(B) Risk management: evidence and cost

What HIPAA risk management requires after the risk analysis

164.308(a)(1)(ii)(B) is a required implementation specification that requires security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level. You already have a risk analysis. This standard asks what you did with it. It does not hand you a fixed list of controls to buy. It asks for action and a documented decision trail: which risks you chose to reduce, which measures you selected, who owns each one, what it cost, and when you checked whether it worked. Under 45 CFR 164.306(b)(2), those choices must account for your size, complexity and capabilities, your technical infrastructure, the cost of the measures, and the probability and criticality of each risk to ePHI. A measure that is cheap but leaves a critical risk open is hard to defend, and so is an expensive one that targets a low-probability risk while a likely one goes untouched.

The usual failure is not a missing tool. It is a risk analysis whose findings never become owned, funded tasks. A spreadsheet lists unencrypted backups, shared administrator accounts and unreviewed access, but nobody is named, no budget line exists, and no date is set. Before you buy anything, convert each finding into a ticket with an owner, a target state, a decision (mitigate, accept, transfer or avoid), and a review date. Where you accept a residual risk, record who accepted it and why. Ask your security official whether this trail exists for every high-rated finding from your most recent analysis, and confirm that the people named can actually fund the work.

The 2025 proposed rule would make this explicit by requiring a written risk management plan reviewed at least once every 12 months (90 FR 898). That change is proposed, not final, and no final rule had been published as of October 2026, so it is not current law. Today, the guidance that matters is OCR's Risk Management video presentation and the investigation findings it describes, which show OCR looking for evidence that identified risks were actually addressed. Keeping a written plan with dated decisions now costs little and will match the proposal if it is adopted. Confirm the current status of the rulemaking on the Federal Register and reginfo.gov before you rely on any timeline.

Which systems, vendors and teams fall under HIPAA risk management

Risk management can only reduce risks that the risk analysis has found, so the scope of the plan is set by the scope of the analysis. The cards below cover the decisions that define that scope, from the systems that hold ePHI to the people who accept what remains.

Every system that touches ePHI

Scope starts with every system that creates, receives, maintains or transmits electronic protected health information, including cloud tenants, SaaS applications, email, endpoints, interfaces and backups. Backup copies are easy to omit because they are not used day to day, yet they hold the same ePHI and carry the same risk. For each system, confirm the data flows in and out so the plan can show where safeguards apply. Illustrative example: a practice management database with a nightly export to an unlisted storage bucket is only partly in scope until the bucket is added.

Business associates and their subcontractors

A vendor that handles ePHI for you creates risk inside your analysis, even when its systems sit outside your network. List each business associate and the subcontractors it uses for ePHI, then record which of your data they hold and how they access it. Your plan should name the mitigations you rely on, such as contract terms, access limits or evidence you request each year. Ask vendors to confirm their subcontractor list, because a gap there is usually found late.

Workforce members and their devices

Staff, contractors, trainees and volunteers who can reach ePHI are part of the risk picture, as are the laptops, phones and removable media they use. Account sharing, unmanaged personal devices and remote work from home networks change the likelihood of a breach, so the plan has to address them. Check that your user list matches your identity provider and that departures are reflected in access records. The workforce security and device controls you choose should map back to specific findings.

Named owners of each risk

Each identified risk needs one accountable owner who can fund, reject or accept the proposed mitigation. Owners are usually the leaders of the affected service, such as the clinical systems lead or the head of IT operations, with the security official coordinating the plan. Write the owner into the risk register so the record shows who decided. Without named owners, mitigation items stall and assessors have little to test against.

Residual risk acceptance decisions

Residual risk is the risk that remains after security measures are applied, and the decision to accept it is where scope has the largest effect on work. Accepting a risk should record the reason, the compensating measures, the approver and a review date. Risks that are accepted without evidence are the ones most likely to be questioned by OCR. Confirm your organization's approval thresholds before work starts, since they determine which items reach executives.

Scope changes after system changes

Scope is not fixed at the start. New applications, mergers, cloud migrations and new vendors all add ePHI locations that the analysis must cover before the plan is updated. Treat each change request as a trigger to check whether the risk analysis and risk management plan still describe the environment. Record the trigger, the date of the update and the approver so the plan's history can be shown. Confirm with your security official how changes are routed to the analysis team.

How an OCR investigator or assessor tests HIPAA risk management

This table compares five test points an OCR investigator or outside assessor applies to the risk management specification, what each one asks to see, and where organizations typically fall short. Read it as a document and system review: the reviewer checks whether the risk analysis led to decisions that were carried out and verified. A clean review supports the organization's position but produces no HIPAA certificate.

Test point	Evidence requested	Common findings
Each risk has a documented treatment decision	Risk register showing every risk from the risk analysis with a chosen treatment: mitigate, transfer, accept or avoid	Plans list risks without any treatment decision recorded against them
Measures selected with the 164.306(b)(2) factors recorded	Selection rationale referencing size, complexity, capabilities, technical infrastructure, measure cost, and probability and criticality of harm to ePHI	Measures chosen with no record of how cost or organizational capability were weighed
Plan assigns owners, dates and funding	Risk management plan with named owners, target completion dates, budget approval and status history	Owners are job titles only, dates are missing or blank, and funding is never approved
Accepted risks have a rationale and approver	Signed risk acceptance records stating the reason, the residual exposure and the accountable executive	Risks are marked as accepted by default, with no rationale and no sign-off by leadership
Measures verified after implementation	Test results, configuration evidence, sample tickets or scan results confirming the control works and the risk was reduced	Treatments are marked complete on the plan, but no evidence shows the system changed or the risk level fell
Treatments progressed over time	Dated status updates, change records and the risk analysis refresh that followed implementation	Treatments that never progressed past the planning stage, with no review of the plan since it was written

How to build HIPAA risk management step by step

This sequence turns the risk analysis into a funded, owned and verified set of security measures that reduces ePHI risks to a reasonable and appropriate level, with a record of what remains and who accepted it.

Confirm the risk analysis is current and complete
The security official checks that the existing risk analysis covers every system, location and vendor that creates, receives, maintains or transmits ePHI, including cloud services and removable media. Compare the inventory against the last analysis and note any new systems, changed data flows or retired assets. The output is a dated confirmation memo listing the scope, the gaps found and the owner of each gap. Do not start treatment work until gaps in the analysis are closed, because treatment decisions depend on the risks they rest on.
Rank risks by likelihood and impact
Score each identified risk and vulnerability for likelihood and impact, using the factors in 45 CFR 164.306(b)(2): the entity's size, complexity and capabilities, its technical infrastructure, the cost of security measures, and the probability and criticality of potential risks to ePHI. Record the scoring method so an assessor can repeat it. The output is a risk register sorted by priority, with each entry showing the asset, the threat, the vulnerability, the score and the reasoning behind it.
Choose a treatment for each risk
For each ranked risk, decide whether to mitigate it with a security measure, transfer it through a contract or insurance, accept it, or avoid it by removing the activity or data. Mitigation is the usual choice for high-impact risks to ePHI, while acceptance needs a stated rationale. Note which safeguards from the other standards the chosen measure relies on. The output is a treatment plan that links every risk in the register to one treatment and a named measure.
Assign owners, deadlines and budget
Name one accountable owner for each treatment, someone with authority over the system or process affected, and set a target completion date agreed by leadership. Record the budget line or the cost approval needed for each measure, including recurring licenses, staff time and any outside services. Confirm who performs the work: internal staff, a managed service or an implementation partner. The output is an approved plan with owners, dates and funding signed off by the people accountable for resources.
Implement and verify each measure
The owner deploys the measure and the security official or an independent reviewer tests that it works as designed. Verification might include configuration checks, access reviews, restore tests or a scan showing the weakness is closed. Keep the raw evidence, such as configuration exports, test logs and screenshots, with the date and tester named. The output is a verification record for each measure that shows the risk was reduced, or an open item returned to the plan if it was not.
Record residual risk and approvals
After verification, re-score each risk to show what remains after treatment. Any residual risk that the entity chooses to keep needs a written risk acceptance memo stating the risk, the reason it is reasonable to accept, the compensating controls, and the name and role of the approver, usually a senior leader with authority over the risk. The output is an updated risk register with residual scores and a signed acceptance memo for each accepted risk. Acceptance without a named approver is a common gap in OCR reviews, so treat this record as required, not optional.
Set the review cycle and triggers
Define how often the risk management plan is reviewed and what events force an earlier review, such as a new system, a significant change in infrastructure, a security incident or a new vendor handling ePHI. Schedule the next review and assign who runs it. The proposed 2025 rule would require a written plan reviewed at least once every 12 months, but it is not final, so confirm current requirements before setting the interval. The output is a documented review schedule and trigger list added to the risk management plan.

What the risk management plan has to show an assessor

The current Security Rule does not prescribe a risk management plan template. Section 164.308(a)(1)(ii)(B) requires security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level, and the entity decides how to show that. An assessor will still look for a traceable record. For each risk identified in the risk analysis, the reviewer expects to see a decision (accept, reduce, transfer or avoid), a named owner, a dated action, and evidence that the action worked, such as a configuration export, a test result or a closed finding. A plan that lists risks and controls without linking them to owners and proof will struggle to show that the measures were chosen under 164.306(b)(2), which weighs size, complexity, infrastructure, cost, and the probability and criticality of each risk to ePHI.

The January 2025 proposed rule would go further by requiring a written risk management plan reviewed at least once every 12 months. That requirement is proposed only. Before you rely on it or write it into a contract, check the status of RIN 0945-AA22 in the Federal Register and on reginfo.gov, where the Unified Agenda shows the rulemaking's current stage. Confirm whether a final rule has been published and what its effective date is. Until then, treat an annual review as sound practice rather than a stated legal duty, and document any review your organization actually performs.

Keep the plan in a form that can be revised after each review cycle. A spreadsheet, a ticketing project or a governance repository all work if they preserve version history, the date of each change, the reviewer, and the reason a risk was re-rated or closed. An assessor reading a plan for the first time should be able to see how it changed between reviews and whether open actions were carried forward or closed with evidence. Confirm with your security official and counsel which format your organization will use, and decide who approves each revision before the first review cycle starts.

Which HIPAA risk management evidence passes review

Section 164.308(a)(1)(ii)(B) asks for security measures that bring identified risks down to a reasonable and appropriate level. An assessor will look for records that connect each risk to a decision, an owner, a date and proof that the fix worked. The cards below cover the documents and tooling that tie those records together.

Risk management plan with version history

The written plan lists each identified risk, the chosen measure, the owner and the target date, and states the level the organization considers reasonable and appropriate. Keep dated versions so an assessor can see how the plan changed after each risk analysis and after major system changes. Check that the plan explains how the organization set its acceptable risk level, since OCR asks how the decision was reached, not only what was decided. The January 2025 proposal would require an annual review, so the version history should show that cadence.

Risk register linked to the risk analysis

A risk register should carry one row per risk, with a reference to the finding in the risk analysis, the ePHI system affected, the likelihood and impact ratings, and the current treatment status. Links back to the analysis show that the register is a continuation of the assessment rather than a separate list. Confirm that every risk rated high in the analysis has a register entry, and that closed entries keep their history instead of being deleted.

Treatment records with owners and dates

For each risk, record the measure selected, the named owner, the planned completion date and the actual completion date. Attach the change ticket, configuration change or purchase record that implemented the measure. An assessor will ask who approved the work and whether the measure was completed on time, so vague entries such as ongoing or TBD are weak evidence. Where a measure was delayed, record the reason and the revised date.

Verification evidence from scans and exports

Show that a measure reduced the risk with data from the system itself, such as vulnerability scan results before and after remediation, MFA enforcement reports, encryption settings or access list exports. Date each artifact and tie it to the register entry it verifies. Ask the system owner to confirm the export came from the production environment and not a test copy, because an assessor will check the source.

Signed risk acceptance memos

Where the organization decides not to fix a risk, or to accept it at its current level, a signed memo should state the risk, the reason for acceptance, the compensating controls, the approving executive and the review date. This record is what separates a deliberate decision from an overlooked gap. Memos that lack a review date or a named approver are hard to defend, so require both before signature. Ask counsel or the security official to confirm the memo matches the organization's documented risk tolerance.

Review minutes and governance records

Minutes from risk review meetings show who reviewed the register, what changed since the last meeting, and which decisions leadership approved. Record attendance, the risks discussed, the decisions taken and the follow-up actions with owners. Regular minutes demonstrate ongoing management of risk, which is what the standard requires, rather than a single assessment performed once. Confirm the review cadence in writing so the minutes can be compared against it.

Open-source tools that hold this evidence

CISO Assistant (AGPL-3.0-only) can run risk and compliance assessments against more than 200 frameworks, with automatic mapping between them, which helps one risk register serve several obligations. DefectDojo (BSD-3-Clause) imports and deduplicates findings from more than 500 security tool report formats, so remediation status stays traceable from scanner output to closure. Greenbone Community Edition (AGPL-3.0-or-later) schedules scans, stores results in PostgreSQL and offers a web interface for review. Each tool supports the evidence above, but the organization still needs to confirm that its own process, roles and retention rules fit the way each tool works.

What HIPAA risk management costs in money and effort

This table breaks the cost of running risk management under 164.308(a)(1)(ii)(B) into its components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up. Read it before requesting quotes, since most of the effort sits in ongoing ownership and evidence upkeep rather than in the tools themselves. Ask every provider for an itemized written quote with scope, deliverables and timelines.

Cost component	One-time or recurring	Cost drivers	How to reduce it
Tooling and licenses	Recurring where paid subscriptions apply	Number of tracking tools, user seats and integrations with scanners or ticketing systems. Open-source options remove license spend but still need hosting and administration.	Standardize on fewer tools, and confirm in writing what the open-source platform does and does not cover before selecting it.
Engineering time to implement treatments	One-time for most treatments, recurring for patching and configuration changes	Number of high-rated risks, age of affected systems, and whether fixes need vendor coordination or changes to clinical workflows.	Group related treatments, prioritize by the risk analysis, and reuse configuration baselines across ePHI systems.
Staff time for risk owners and approvals	Recurring	Number of named risk owners, frequency of review meetings, and how many treatment decisions need sign-off from management.	Assign owners by system or business process, and set a documented approval threshold so routine treatments do not escalate.
Evidence upkeep and periodic review	Recurring	Number of ePHI systems, rate of change in infrastructure, and how often the risk register and treatment records must be refreshed to reflect current status.	Generate evidence from tooling where possible, and tie each treatment record to a specific system and due date.
External testing to validate treatments	Recurring or per engagement	Scope of systems, whether a treatment changes exposed services, and whether the testing firm must retest after fixes.	Limit external testing to treatments that carry the highest residual risk, and agree retest terms in the scope document.
Assessor sampling if an assessment follows	Per engagement	Number of risks and treatments selected for sampling, and the depth of evidence each sample requires.	Keep each risk entry traceable to its analysis, treatment and review record so samples can be answered quickly.
Vendor and third-party risk coordination	Recurring	Number of vendors that handle ePHI and the number of their risks that feed into your treatment plan.	Maintain a single vendor inventory and request standard security documentation at contract renewal rather than ad hoc.

Your team, a HIPAA partner and the auditor on risk management

The covered entity or business associate owns the risk management standard. The obligation under 45 CFR 164.308(a)(1)(ii)(B) sits with the organization, so the decisions about which measures to adopt, how much budget to commit and which residual risks to accept must be made by people inside it. The security official named under 164.308(a)(2) typically leads this work, with executive sign-off on funding and on any risk the organization decides to carry.

Risk decisions: Choosing which treatments to fund, defer or replace, and recording the reasoning against the risk analysis.
Risk acceptance: Deciding in writing which residual risks remain after treatment and who signed for them.
Funding and priorities: Approving budgets and ranking remediation work against other business demands.
Ownership of systems and data: Confirming which applications hold ePHI, who administers them and who is accountable for their configuration.
Ongoing operation: Reviewing the plan as systems, vendors and threats change.

Ask who signed the last risk acceptance and whether that person could explain the reasoning to an investigator without outside help.

Where HIPAA risk management breaks down and how to close it

Risk management under 164.308(a)(1)(ii)(B) fails less often because the analysis is missing than because its findings never turn into decisions, owners and proof. The cards below cover the most common breakdowns, with the evidence that closes each one for the organization and for an assessor reviewing the file.

Risks listed with no treatment decision

A risk register that names threats and assigns ratings but records no treatment choice leaves the analysis unfinished. Each risk should carry one decision: mitigate, transfer, accept or avoid, with the measure that will reduce it to a reasonable and appropriate level. Check that every high-rated item from the risk analysis appears in the plan with a named measure. The evidence is a risk management plan that maps each risk ID to its decision and its security measure.

Accepted risks with no approver

Accepting a risk is a legitimate decision only when a named person with authority accepts it and records why. Without an approver and rationale, acceptance looks like neglect. Ask who signed off, what compensating controls exist, and when the acceptance expires. The evidence is a signed acceptance record per risk, stating the owner, the basis for the decision and a review date.

Treatments never verified

A safeguard that was bought or configured is not the same as one that works. OCR expects an organization to show that its measures reduce risk, so the plan needs a verification step for each treatment, such as a configuration check, access test or restore test. Confirm that someone other than the implementer checked the result and recorded it. The evidence is test results or validation tickets linked to the plan entry, with dates and outcomes.

Plans not revisited after system changes

A plan written for last year's environment becomes inaccurate after a migration, a new EHR module or a shift to cloud hosting. The current rule requires an ongoing process rather than a one-time document, and the January 2025 proposal would require a written plan reviewed at least once every 12 months. Check whether change tickets trigger a risk review before go-live. The evidence is a change log that references the risk analysis and a dated plan revision history.

Vendors and cloud services left out

Business associates, hosting providers and SaaS tools that store, process or transmit ePHI are part of the environment the analysis must cover. Organizations often document their own servers and omit the vendor systems that hold the same data. Ask for an inventory that lists each external system with its ePHI flows and the contractual safeguards that apply. The evidence is an updated asset and data flow map, cross-referenced to business associate agreements and vendor security reviews.

Funding decisions made outside the plan

When budget owners approve or defer security work without reference to the risk plan, the plan stops describing what the organization actually does. Treatments then slip without anyone recording the trade-off. Confirm that high-rated risks have a funded treatment, or a documented decision to defer with an accountable owner. The evidence is budget requests and approval minutes that cite risk IDs from the plan.

HIPAA risk management questions buyers ask before hiring help

How much effort does HIPAA risk management take, and what drives it?

The effort depends mainly on how many systems hold or touch ePHI, how many vendors handle it, and how many risks the current risk analysis has already identified. No researched figure for typical effort is available for this page, so ask any partner to show the drivers in writing. The rule itself asks you to weigh your size, complexity, technical infrastructure, the cost of security measures, and the probability and criticality of each risk (45 CFR 164.306(b)(2)). Each identified risk then needs a chosen measure, an owner, a deadline and evidence that the measure works. Organizations with a short, well-documented list of systems and few open findings usually need far less than those with scattered ePHI, legacy applications or many business associates. Ask for effort estimates broken down by system and by risk, not one lump figure.

Can a small practice manage HIPAA risk management in-house?

Yes, a small practice can do much of this work in-house if one person owns the process and has enough time to follow it through. The Security Rule does not require outside help, and HHS publishes a free risk analysis tool that small teams commonly use as a starting point. The harder parts are judging whether a chosen measure is reasonable and appropriate, documenting decisions, and tracking remediation to completion. Practices often bring in a consultant for a first pass, then keep the risk register current internally. Confirm that whoever leads the work understands both the technical systems and the Security Rule requirements, and that they have authority to fund the measures the analysis calls for.

How long does HIPAA risk management take, and what sets the timeline?

No researched duration is available for this work, so treat any timeline you receive as an estimate that needs to be justified. The main drivers are the inventory of ePHI locations, how quickly the organization can obtain and document decisions from owners, the number of remediation items, lead times for hardware or vendor changes, and whether staff are available to test measures. Risk management is also continuous, because the Security Rule expects measures to be revisited when systems or threats change, so the timeline should separate the first cycle from ongoing upkeep. A fixed-scope engagement should show the phases, the deliverables for each phase and the dependencies on your staff in the written plan.

What does the work need from our staff?

The work needs named people from IT, security, operations, compliance and each department that uses ePHI, along with access to system documentation and decision-makers who can accept or reject residual risk. Your staff owns the decisions, the policies and the operation of every control. An implementation partner can prepare the analysis, draft the risk management plan, configure systems and collect evidence, but it cannot accept risk on your behalf. Ask the partner to list each role, the hours or meetings expected from it, and which artifacts each person must review. Staff who approve changes should be identified before the work starts, or the schedule will slip.

Can a consultant or partner certify that we are HIPAA compliant?

No. No one can issue a HIPAA certification, and HHS states that no Security Rule standard requires an entity to certify compliance. HHS also does not endorse or recognize private certifications, and such a certificate does not stop HHS from later finding a violation (HHS FAQ 2003). A consultant or partner can help you prepare, assess your own gaps and document your measures, but that work does not produce a certificate or an official finding. Be cautious with any vendor that offers a HIPAA seal or certificate as proof of compliance. Your evidence of risk management is what OCR will examine if it reviews your organization.

What should we ask for in a written scope for risk management help?

A written scope should state exactly what the partner will do, what you will own, and what will be delivered. Ask for the systems and locations in scope, the method used to identify and rate risks, and the list of deliverables such as the risk analysis, the risk management plan, the remediation backlog and evidence files. Confirm which measures the partner will implement, which your staff must implement, and who approves risk acceptance. Require a statement that the partner does not issue certifications or audit reports and that any third-party assessment will be performed by an independent assessor. Finally, ask how changes to scope are priced and approved, and what happens to the documentation at the end of the engagement.

Does the risk management plan have to be written down, and who keeps it current?

Under the current rule, the Security Rule requires documented policies and procedures, and the risk management measures you select should be written down so they can be shown to OCR. HHS's January 2025 proposal would require a written risk management plan reviewed at least once every 12 months, but that proposal was not final as of October 2026 (90 FR 898). Your organization owns the plan and must keep it current, even if a partner drafts it. Ask the partner to deliver it in an editable format and to explain how each measure links back to a specific identified risk, so your team can maintain it after the engagement ends.

How DeployOpen prepares HIPAA risk management evidence

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and prepares the technical measures and records that a risk management plan depends on. The covered entity or business associate owns its risk decisions and its Security Rule compliance, and an independent assessor reviews the outcome.

How we scope

Written scope lists which ePHI systems, environments and risks from the risk analysis the measures must address.
Scope states which security measures are in and out of the engagement, with each item tied to a named risk.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.

How we build

Security measures are implemented in the client's own cloud accounts, data centers or air-gapped networks.
Each measure is tested against its named risk, with test results recorded for the risk management file.
Open-source tools such as CISO Assistant or DefectDojo are configured where the client chooses them for tracking.

How we hand over

Deliverables include configuration records, test results and a register linking each measure to its risk.
Documentation states which risks remain open, who owns them and the decision basis for accepting them.
The client's security official receives the handover package and confirms it reflects the approved risk management plan.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainer work can refresh measures when the risk analysis changes or the proposed rule is finalized.
Confirm with DeployOpen in the written scope which review cadence and evidence refresh the retainer covers.