HIPAA risk management plan: what it must contain and who writes it

What a HIPAA risk management plan must do and who owns it

When a risk analysis is finished and findings are still open, the question becomes what the organization must do next. The risk management specification in 45 CFR 164.308(a)(1)(ii)(B) is a required implementation specification. It requires security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level, and the covered entity or business associate owns it. No vendor, consultant or cloud provider can accept that obligation on the organization's behalf, even when they carry out parts of the work.

The right plan is not the same for every organization. Under 45 CFR 164.306(b)(2), the entity must consider its size, complexity and capabilities, its technical infrastructure, the costs of security measures, and the probability and criticality of potential risks to electronic protected health information. In practice, that means each open finding needs a named measure, an owner, a target date and a written reason for the chosen approach. A small practice with one hosted electronic health record and a large health system with on-premises imaging servers will reach different decisions about the same risk, and both decisions must be explainable to an assessor.

HIPAA has no certification. HHS states in its 2003 FAQ that no standard requires certifying compliance and that it does not endorse private certifications. Only an independent assessor can issue findings about your controls. An implementation partner can prepare systems, document measures and collect evidence, but it cannot attest to the result. Ask any provider who claims otherwise what they are certifying and under which authority.

How findings become a risk management plan

The sequence turns a completed risk analysis into a dated, owned and verified set of measures that reduces risks to a reasonable and appropriate level. Each phase produces a record that an OCR investigator or independent assessor can follow from finding to outcome.

Rank risks by likelihood and impact
The security official, with system owners and clinical or operational leads, takes each risk recorded in the risk analysis and scores how likely it is to occur and how much harm it would do to ePHI, availability and patient care. The output is a ranked risk register that states the scoring method, the assumptions behind each score and the threats and vulnerabilities considered. You know this step is done when every risk in the analysis has a score and a rank, and the scoring method is written down so someone outside the team could repeat it.
Identify candidate security measures
For each ranked risk, the team lists the measures that could reduce it, such as configuration changes, access restrictions, monitoring, training, encryption or contract terms. Where a Security Rule implementation specification is addressable, the team also records whether the specification is reasonable and appropriate and what equivalent measure would be used if it is not. The output is a candidate measure list linked to specific risks. You know this step is done when each high-ranked risk has at least one candidate measure and each addressable specification has a recorded decision.
Select measures against the reasonableness factors
The team chooses measures using the factors in the Security Rule: organization size, complexity and capabilities, technical infrastructure, the cost of each measure, and the probability and criticality of the risk to ePHI. Leadership approves the selection, and any measure rejected for cost or capability is documented with the reason and any alternative chosen. The output is an approved measure set with a short rationale for each choice. You know this step is done when a reviewer can trace every selected measure to a ranked risk and to the factors that justified it.
Assign owners and target dates
Each approved measure receives a named owner who is accountable for delivery, along with a target completion date set by the organization. Owners confirm whether the work is internal or will be carried out by a vendor or implementation partner, and the contract or statement of work is linked to the plan. The output is a risk management plan with an owner, a status and a date for every measure. You know this step is done when no measure lacks an accountable person and each outside party has a written scope that matches its assigned measures.
Implement measures and record changes
Owners carry out the measures, and the team records each change in change tickets, configuration baselines or system documentation so the work can be traced to the plan item it satisfies. Where a measure cannot be completed on schedule, the owner records the delay, the interim control in place and the revised date, and the security official reviews the change. The output is a set of implementation records linked to each plan item. You know this step is done when each completed measure has evidence attached that shows what changed, when and by whom.
Verify that measures reduce the risk
Someone other than the implementer checks that each measure works as intended, for example by reviewing configuration exports, access reviews, test results or log samples, and updates the risk register to show the residual score. Where a measure does not reduce the risk to a reasonable and appropriate level, the item returns to the selection step. The output is a verification record for each measure and an updated residual risk score. You know this step is done when every closed item has an independent check and each remaining risk has a documented residual level and an accepted decision.
Approve, document and schedule review
The organization's leadership formally approves the completed plan, the residual risks it accepts and the schedule for review. The approved plan, its rationale, its verification records and the approval are kept as documentation under the Security Rule's documentation requirements. Confirm the retention period and review frequency with counsel and your current regulatory obligations, because the proposed rule would add a specific review cycle that is not yet final. The output is an approved, retained plan with a review schedule. You know this step is done when a new investigator could reconstruct from the records why each measure was chosen, who delivered it and what risk remains.

Which factors justify a security measure

The point of this section is that a security measure is justified by a documented reasoning process, not by a checklist. Under 45 CFR 164.306(b)(2), an entity must consider its size, complexity and capabilities, its technical infrastructure, the cost of security measures, and the probability and criticality of potential risks to ePHI. These factors shape which measure reduces each risk to a reasonable and appropriate level under 164.308(a)(1)(ii)(B). In practice, the reasoning should name the specific system, the threat scenario, the factor or factors that drove the decision, and the residual risk left after the measure. A decision memo that says only "cost too high" will not hold up when an assessor asks why an identified risk remained open. Record who approved the decision, the date, and when it will be revisited.

Addressable implementation specifications need the same discipline, with an extra step. For each addressable specification, the entity must decide whether it is reasonable and appropriate in its environment. If it is not, the entity must document why and implement an equivalent alternative measure if one is reasonable and appropriate, as 45 CFR 164.306(d) requires. Illustrative example: a clinic with a small number of workstations may find a dedicated audit log review tool disproportionate, so it documents the reason and adopts a scheduled manual review of a defined set of logs, with a named owner. Confirm with counsel or your assessor how they expect that documentation to read, because an undocumented "not applicable" is one of the weakest positions an entity can be in.

Network devices running obsolete firmware are a concrete case for these factors. HHS's ransomware fact sheet says the risk analysis should address risks such as devices running obsolete firmware, even though no standard names firmware updates directly. Treat unsupported firmware on routers, firewalls, imaging systems and medical devices as a finding to be analyzed for likelihood and impact, then reduced through patching, replacement, segmentation or compensating controls. Where the vendor no longer supplies updates, the factor analysis should show why replacement is not yet feasible and what interim measure lowers the probability of exploitation. Ask your device vendors which models are past end of support and record the answer in the risk management plan.

What enterprise-wide risk reduction covers

Risk reduction under a HIPAA risk management plan rarely fits in one project. The areas below are where OCR's recent settlements and recommendations most often point, and each one should be sized against the risks your risk analysis actually recorded for ePHI. Treat them as areas to decide on, not a checklist the Security Rule names.

Access control and MFA

Access to systems holding ePHI is where many OCR cases started, including credential-based attacks on patient accounts. Your plan should record who can reach each system, which accounts can be used remotely, and where multi-factor authentication is in place or still missing. Check whether the measures you choose would have stopped the threats your analysis rated as most likely, and document the reasons for any gap.

Patching and firmware on network devices

HHS's ransomware guidance says the risk analysis should address network devices running obsolete firmware, even though no standard names firmware updates. Routers, firewalls, medical device gateways and remote access appliances all belong in the inventory. For each device class, the plan should set who owns updates, how exceptions are approved, and how a device that cannot be patched is isolated or replaced.

Audit controls and activity review

The Warby Parker settlement included findings on information system activity review, so logs that nobody reads do not reduce risk. The plan should name which systems generate audit records, who reviews them, how often, and how suspicious activity is escalated. Confirm that log retention matches the documentation period in your policies and that reviewers can tell a sign of credential misuse from normal use.

Encryption where appropriate

OCR's recent recommendations call for encryption in transit and at rest when appropriate. The Security Rule treats encryption as an addressable specification, so the plan must record your assessment of whether it is reasonable and appropriate for each data store and transmission path. If you decide against it, document the reason and any equivalent measure, and revisit that decision when systems or data flows change.

Workforce training

OCR's settlement recommendations call for role-specific training, which means the people who handle billing, clinical systems and IT administration need different content. The plan should tie each training topic to a risk it addresses, such as phishing for front-desk staff or privileged account handling for administrators. Record who completed which module and when, so that training effort can be shown against the risk register.

Business associate oversight

Vendors that create, receive, maintain or transmit ePHI add risk that sits outside your own network. The plan should list each business associate, the ePHI it handles, the security measures its contract requires, and how you check that those measures operate. Confirm which vendors have provided evidence of their own safeguards and which have only signed an agreement, since the two are not the same.

What OCR penalized when risk management failed

OCR imposed a $1,500,000 civil money penalty on Warby Parker after credential stuffing between September and November 2018 gave attackers access to the accounts of 197,986 individuals. The case is useful because OCR did not stop at the attack itself. It found failures in the organization's risk analysis, its risk management and its information system activity review, which together show how the three obligations depend on each other.

Risk analysis gap: OCR found the organization had not conducted an accurate and thorough assessment of risks to ePHI in the accounts that were attacked.
Risk management gap: OCR found the organization had not implemented security measures sufficient to reduce those risks to a reasonable and appropriate level.
Activity review gap: Failing to review information system activity meant suspicious logins that repeated across many accounts were not detected while the attack was underway.
Link between the three: A risk analysis that never identified credential stuffing leaves no basis for choosing controls such as multi-factor authentication or login monitoring.
Illustrative example: A login portal with no rate limiting or anomaly alerts would be a risk the analysis should name and the plan should treat.

Check whether your risk analysis names account takeover and credential reuse as threats, and whether each one has a recorded measure and a review step that would show the activity.

What the proposed written risk management plan would require

The January 6, 2025 proposed Security Rule revision (90 FR 898) would make a written risk management plan an explicit requirement, reviewed at least once every 12 months. That requirement is proposed, not final. As of October 2026 no final rule has been published, and the latest Unified Agenda entry for RIN 0945-AA22 lists final action as projected for July 2027. Until a final rule appears in the Federal Register, the current rule still governs, and the only binding obligation is the required specification in 45 CFR 164.308(a)(1)(ii)(B) to implement security measures that reduce risks to a reasonable and appropriate level. Any statement that a written plan is mandatory today would overstate the law.

Building the plan now is still sound practice, because OCR asks what you did to reduce identified risks, and a dated, signed document is the simplest way to show it. A plan that would satisfy the proposed text would name each risk from the analysis, the measure chosen, the reason it was chosen, the owner, the target date and the status, with an annual review recorded against it. Confirm the current wording of the proposal against the Federal Register text before you fix your own template, since the comment period closed in March 2025 and the final text may differ.

Before relying on any future requirement, check three things: whether a final rule has been published, whether its effective and compliance dates have been set, and whether the revised text changed the review interval or the documentation duties. Ask your compliance lead and outside counsel to record that check with a date, and reassess the plan's format when the final text appears. Treat the review cycle you adopt as a governance choice you can defend, not as a deadline the rule has imposed.

What a risk management plan costs and who is paid

This table compares who is paid for each part of a HIPAA risk management plan, whether the cost is one-time or recurring, and what drives it up. No fee figures are supplied for this topic, so treat the table as a checklist of cost lines to price in a written scope, not as a budget. Ask every bidder to price each row separately so you can see where the money goes.

Cost component	Who is paid or who carries it	One-time or recurring	What drives the cost
Internal staff time for decisions and ownership	Your own staff, such as the security official, privacy officer, IT leads and business owners who accept residual risk	Both: initial plan build, then recurring reviews	Number of systems in the risk analysis, number of open findings, and how many owners must sign off
Implementation partner work on systems and evidence	External firm paid under a fixed-scope written agreement to configure systems, close gaps and document the results	Mostly one-time for each remediation project, with some recurring follow-on work	Size of the ePHI environment, number of findings to remediate, and whether hosting is cloud, on-premises or hybrid
Tooling and licenses	Software vendors or open-source support providers, paid through subscriptions or support contracts	Usually recurring; some tools carry a one-time setup cost	Number of users, endpoints or log sources, and whether you need vendor support or only community tools
Hardware and infrastructure changes	Your hardware vendors, cloud providers or data center operators	Mostly one-time, with ongoing operating costs	Obsolete firmware or devices identified in the analysis, encryption needs and backup capacity
Independent assessor fees	An outside assessor paid for an independent view of the plan and its evidence. Note that HHS does not certify compliance, so an assessor's report is an opinion, not a HIPAA certificate	Typically one-time per engagement, repeated when you re-assess	Scope of systems tested, depth of testing and how much evidence you prepare in advance
Recurring review and plan updates	Your staff, plus any partner or assessor you retain for periodic reassessment	Recurring	Frequency of reviews, changes to systems or operations, and any new findings from incidents or audits
Documentation and retention	Your staff, with support from a partner if you outsource drafting	Recurring, because records must be kept and kept current	Volume of policies, change records and evidence you must retain and make available

What makes the plan more or less costly

The cost of a HIPAA risk management plan follows from how much ePHI exists, where it sits, and how many open findings already compete for budget. Each card below is a driver you can check before asking for a quote, because it changes the scope of work and the recurring effort that follows.

Scope of ePHI systems

The number of applications, databases, endpoints, backups and integrations that store, process or transmit ePHI sets the size of every measure in the plan. A plan that covers one electronic health record and its interfaces is far smaller than one covering a patient portal, a data warehouse, analytics exports and shadow spreadsheets. Ask the organization to confirm which systems are in the ePHI inventory before any quote is written, because unlisted systems are the most common source of unplanned work.

Number of locations

Each clinic, hospital campus, branch office or remote site adds workstations, network segments, physical access controls and device handling that the plan must address. Costs grow with the number of sites that need their own configuration, local procedures and staff training, not just with the number of people. Confirm which sites connect to central systems and which keep local servers or medical devices.

Third-party dependencies

Hosting providers, billing companies, managed IT firms, clearinghouses and software vendors that touch ePHI can each hold part of a measure. Where a vendor signs a business associate agreement and supplies evidence such as audit logs or encryption attestations, some work moves out of the organization's plan, but oversight of that vendor stays with the covered entity. Ask which vendors hold ePHI, what they have contractually committed to, and what evidence they will provide.

Age of infrastructure

Systems running unsupported operating systems, end-of-life firmware or legacy interfaces usually need replacement, isolation or compensating controls rather than routine patching. HHS's ransomware guidance specifically names network devices running obsolete firmware as a risk the analysis should address. Inventory the version and support status of each ePHI system, since the oldest components often drive the largest one-time spend.

Existing evidence and documentation

Current policies, a recent risk analysis, configuration baselines, access reviews and logs make it faster to decide which measures are reasonable and to document why an addressable specification was handled a particular way. Missing or stale documentation means the plan must first recreate what the organization believes it does. Ask what evidence exists today and how old it is.

Open findings and their backlog

Every unresolved finding from a risk analysis, audit, penetration test or incident competes with new measures for the same staff and budget. A long backlog of open items with no owners or dates increases the work needed before new risk reduction can begin. Ask how many findings are open, their severity, which have named owners, and which already have approved funding.

Who owns each part of the plan

The covered entity or business associate remains responsible for HIPAA Security Rule compliance. Under 45 CFR 164.308(a)(1)(ii)(B), the organization must implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level. No vendor, consultant or assessor can make that determination on the organization's behalf. Leadership owns the decisions that shape the plan and must be able to explain them to OCR.

Risk acceptance: Leadership decides which residual risks the organization accepts, defers or transfers, and records the reasoning and the person who approved it.
Measure selection: The organization chooses measures using the factors in 45 CFR 164.306(b)(2), including size, complexity, cost and the probability and criticality of risks to ePHI.
Addressable specifications: For each addressable specification, the organization documents whether it is reasonable and appropriate and, if not, what equivalent measure it adopted.
Sign-off and budget: Named owners approve the plan, fund the work and review progress on a schedule the organization sets.
Security official role: The organization designates a security official who holds these decisions, whether the person is an employee or a contracted service.

Check that each decision in the plan has a named owner, a date and a written rationale that someone outside the project team could follow.

Why risk management plans fail under review

Most risk management plans that fail under OCR review do not lack a risk analysis. They break at the handoff from findings to action. The four gaps below are the ones reviewers return to most often, and each has a practical check the organization can run before an assessor or investigator asks.

No link from findings to measures

A risk register that lists threats and ratings but never names the security measure that addresses each one leaves the reviewer unable to see reduction at all. The 45 CFR 164.308(a)(1)(ii)(B) specification asks for measures sufficient to reduce risks to a reasonable and appropriate level, so each finding needs a traceable line to a control, a configuration or a procedure. Check that every high or medium rated risk maps to at least one named measure and that the measure can be tested. Illustrative example: an unpatched remote access appliance should point to a patching procedure, a vulnerability scan and a change record.

Risk acceptance without rationale

Accepting a risk is a legitimate decision under the Security Rule, but an acceptance with no written reasoning looks like an omission. The rule expects entities to weigh size, complexity, infrastructure, cost and the probability and criticality of harm to ePHI, and reviewers will ask how those factors were applied. For each accepted risk, record who approved it, which factors drove the decision and when it will be revisited. Avoid blanket acceptances of whole asset classes, since reviewers treat them as unanalyzed risk.

No owners or dates

A plan with no named owner for each action cannot show that anyone is responsible for reducing a risk, and an undated action cannot show progress. OCR investigations regularly examine whether risk management was carried out or only described. Assign a single accountable person, a target completion date and a status to every action, and keep a record of when each was closed and what evidence proves it. Confirm that the security official and system owners agree to their assignments before the plan is finalized.

Plans not refreshed after change

A plan written for last year's network will fail once a new cloud tenant, vendor integration or remote clinic is added. HIPAA sets no fixed interval, but the risk analysis and the plan built from it must reflect environmental and operational change, and OCR's findings in recent cases have cited plans that stayed static. Tie plan review to change management: every significant system, vendor or site change should trigger a check of affected risks and actions. The January 2025 proposed rule would require a written plan reviewed at least every 12 months, but that remains proposed, so confirm the current obligation with counsel.

Common questions about HIPAA risk management plans

Does a HIPAA risk management plan have to be written today?

Yes, in practice you should have one in writing now, although the current rule does not use the phrase. The Security Rule requires security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level under 45 CFR 164.308(a)(1)(ii)(B), and that specification is required, not addressable. Regulators judge whether you did this, so a plan that exists only in people's heads is hard to defend. The January 2025 proposed rule would add a written risk management plan reviewed at least once every 12 months, but that change was proposed, not final, as of October 2026. Confirm the current status in the Federal Register proposal before you rely on any new deadline.

How long does it take to build a HIPAA risk management plan?

No duration has been established for this, and the rule does not set one. The time depends on how many systems hold ePHI, how many risks your risk analysis recorded, how many owners must approve measures, and whether your environment already has controls in place. Ask any provider for a written timeline tied to a defined scope, and ask what assumptions it depends on, such as access to staff, system documentation and change approvals. Plan for the work to be iterative: the first plan usually reveals gaps in the risk analysis that must be fixed before measures can be chosen.

Can our own team write the risk management plan without outside help?

Yes, the Security Rule does not require an outside firm, and the security official and workforce can write the plan. The organization owns the decisions, including which measures to accept, which to fund and what residual risk leadership will tolerate. Small teams often struggle with three parts: ranking risks consistently, estimating the cost of each measure, and documenting why an addressable specification was not adopted. An outside implementation partner can prepare systems, draft the plan and gather evidence under a written scope, but it cannot issue a compliance determination.

What does the work need from staff and system owners?

The work needs named owners for each system and risk, time from IT, clinical and business leaders, and a decision-maker who can accept or fund measures. Expect requests for current asset lists, network and data-flow diagrams, configuration details, vendor contracts and records of past incidents. Each measure should have an owner, a due date and a way to show it works, such as a configuration export or a test result. Without those owners, the plan tends to list measures that nobody implements or reviews.

Can a consultant certify that our HIPAA risk management plan is compliant?

No. There is no HIPAA certification, and HHS states that it does not endorse or recognize private certifications, which do not prevent a later finding of violation. A consultant can help you build the plan, test controls and prepare evidence, but the organization owns its compliance. Any report from a third-party assessment describes what was tested and found within its scope. Ask a provider to state in writing what its work does and does not show, and be cautious of anyone who offers a HIPAA certificate as proof of compliance.

How does the risk management plan relate to the risk analysis?

The risk analysis comes first. Under 45 CFR 164.308(a)(1)(ii)(A), you identify threats and vulnerabilities to ePHI and estimate their likelihood and impact. The risk management plan then takes those findings and selects measures to reduce them to a reasonable and appropriate level, as described in 45 CFR 164.308(a)(1)(ii)(B). The plan must consider your size, complexity, infrastructure, the cost of measures, and the probability and criticality of each risk under 45 CFR 164.306(b)(2). If the analysis is incomplete, the plan will miss risks, so regulators often treat the two documents as one body of evidence.

How DeployOpen supports the plan

DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, whether that is their cloud accounts, data centers or air-gapped networks. For a risk management plan, that help usually means building the technical measures the plan selects, such as access control, audit logging, encryption and patching workflows on systems the organization already runs, and then writing down how each measure is configured, owned and reviewed. The organization still decides which risks are accepted, which measures are chosen and who is accountable for them. DeployOpen does not make those decisions for the client and does not issue audit reports, attestations or certificates. Only an independent assessor or auditor can give an opinion on the plan or the safeguards it describes.

Work is fixed-scope. Before any engagement starts, the parties agree in writing which systems are in scope, which measures will be implemented, what documents and evidence will be delivered and on what timeline. A useful scope for this topic lists each measure from the plan, the system or environment it applies to, the configuration baseline, the test that shows the measure works and the artifact that records it. Ongoing support, upgrades and periodic review can be arranged as a retainer after the initial scope is delivered. Ask any provider, DeployOpen included, to show how deliverables map to the plan's named risks and owners, and to confirm who keeps the written configuration records after the engagement ends.

DeployOpen does not publish a price list. A quote follows from the written scope, so the inputs that drive cost are the number of systems, the number of measures being implemented, how much existing configuration must be reviewed or rebuilt, and how much evidence collection is needed. Before requesting a quote, confirm with your own team which systems hold ePHI, which risks the risk analysis rated highest, and who will sign off on accepted residual risk. Those answers set the scope, and a clear scope is the basis for a quote that you can compare with other proposals.

HIPAA risk management plan: reducing risks to a reasonable level