HIPAA security risk analysis: cost, steps and who does it

What a HIPAA security risk analysis involves and what changes its cost

The HIPAA Security Rule requires an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of electronic protected health information, under 45 CFR 164.308(a)(1)(ii)(A). The rule sets no fixed price or duration for that work, so the cost and timing of a risk analysis follow from its scope: how many systems hold ePHI, how many locations and vendors touch it, and how much current documentation already exists. The organization owns the analysis, its findings and the decisions that follow from them. An implementation partner can prepare asset inventories, data flow maps and draft documentation, but only an independent assessor or auditor issues a report, and no assessor's sign-off on a risk analysis amounts to a HIPAA certificate. The urgency comes from enforcement. OCR's Risk Analysis Initiative makes the risk analysis the first document investigators request, and recent settlements show how often the analysis is the failure. In its August 18, 2025 settlement with BST & Co. CPAs, OCR cited a ransomware investigation and counted it as the tenth action under the initiative. In its September 17, 2026 settlement with Ambry Genetics, OCR cited failure to conduct an accurate and thorough risk analysis, and Ambry agreed to a two-year corrective action plan that began with a new risk analysis and risk management plan. Before scoping, confirm with your own environment which systems create, receive, maintain or transmit ePHI, including SaaS tools, backups and endpoints, where that data moves between them, and whether a current analysis and risk management plan already exist and when each was last updated. Plan for the cost drivers before you request quotes. The largest variables are the number of systems and data flows in scope, the condition of existing records, whether staff can run the analysis internally using the free HHS Security Risk Assessment Tool or need outside help, and how much remediation work follows the findings. Ask any provider for a written scope that lists the systems, sites and vendors covered, the methodology used (for example, NIST SP 800-30 concepts as drawn on in NIST SP 800-66 Rev. 2), the deliverables including the risk register and risk management plan, who signs off, and whether retesting or an annual refresh is included. Remediation is usually a separate line item and is worth estimating separately from the analysis itself.

Who gets paid for what in a HIPAA risk analysis

This table lists each cost component of a HIPAA security risk analysis, who is paid for it, whether it is one-time or recurring, and what drives it up or down. Use it to build a quote request that compares like with like. No dollar amounts or hours are given because none are supplied for this topic, so ask each provider to price every row separately.

Cost component	Who is paid, or who does the work	One-time or recurring, and what drives it
Security official and system owner time	Your own staff: the security official, IT leads and the owners of each system that holds ePHI	Recurring. Drivers are the number of systems, how many people must be interviewed, and how often the analysis is refreshed
Scoping and ePHI mapping	Your staff, optionally with an outside assessor, to document where ePHI is created, received, maintained or transmitted	One-time at first, then recurring as systems change. Drivers are the number of locations, cloud accounts, devices and vendors
External assessor or consultant	An outside firm paid under a written scope, if you choose to use one	Usually one-time per cycle. Drivers are environment size, complexity, on-site work and whether the firm also reviews remediation
Partner for inventory and remediation planning	An implementation partner paid for asset inventory, network documentation and a risk management plan, separate from the assessor's independent work	One-time build, then recurring upkeep. Drivers are how current your asset records already are and how many fixes you need to plan
Free HHS SRA Tool	No license fee; your staff or a contractor spends time completing it	One-time setup per cycle. The tool is aimed at small and medium-sized practices and business associates, so larger environments usually need more analysis than it captures
Commercial scanners and analysis software	Software vendors, plus staff time to run and interpret results	Recurring license and maintenance. Drivers are asset count, scan frequency and whether scanning output feeds the written analysis
Updating the analysis after changes	Your staff, and any assessor or partner you retain for re-review	Recurring. Triggers include new systems, mergers, incidents, new vendors and major configuration changes
Six-year documentation retention	Your staff or records system; storage costs depend on your infrastructure	Recurring for the full retention period. The rule requires six years from creation or last effective date, whichever is later

What makes a risk analysis larger, costlier and slower

A HIPAA risk analysis grows with how many places ePHI lives, how many systems and people touch it, and how well the organization already knows its own environment. The cards below cover the drivers that most often stretch timelines and budgets, along with the controls that keep each one manageable.

Scope of ePHI locations

The analysis must cover all ePHI the organization creates, receives, maintains or transmits, in every form of electronic media. Cloud tenants, laptops and mobile devices, backup copies, email archives and test environments each add locations to document. Start by tracing ePHI flows from intake to disposal, then limit the scope to systems where ePHI actually resides or passes. Confirm with each data owner that no copies exist outside the mapped flows.

Number of sites and workforce

Each clinic, office, data center or remote workforce location adds devices, network segments and access paths that someone must assess. Workforce size drives the volume of accounts, workstations and access grants to review. Group sites by shared configuration and common controls, then assess one representative site in depth and verify the rest against a short checklist. Ask providers to price per site and per user, not as a flat fee.

System count and age

Legacy applications, unsupported operating systems and undocumented interfaces take longer to assess because staff must find out how they work before they can judge the risk. Each system needs its data types, owners, access model and patch status recorded. Sort systems into current, aging and end-of-life groups before scoping interviews, so the effort goes where the unknowns are. Ask whether any system is kept only for a single report or integration.

Quality of the asset inventory

A current inventory of hardware, software and network connections is the input that makes threats and vulnerabilities assessable. When it is missing or stale, analysts spend most of their time reconstructing it through interviews and scanning. The proposed 2025 Security Rule revision would require a written technology asset inventory and network map, so the same artifacts will matter even if the rule is not final. Collect the inventory and network diagrams before engaging a provider.

Maturity of prior documentation

Earlier risk analyses that record methods, assumptions, findings and the status of each risk make the next cycle faster, because the team can verify changes instead of starting over. Documents that exist only as spreadsheets with no rationale, or that lack dates and owners, force a full rebuild. Confirm that prior analyses were retained for six years, as 45 CFR 164.316(b)(2)(i) requires, and identify which findings were closed, accepted or still open.

Business associates touching ePHI

Every business associate whose systems create, receive, maintain or transmit ePHI belongs in the analysis, because its controls affect the covered entity's risk. Hosting providers, billing companies, clearinghouses and managed IT firms each need their security posture described and assessed, and some will push back on sharing detail. Request each vendor's security documentation and business associate agreement early, and record which safeguards the vendor owns and which the organization retains.

How to run the risk analysis from scope to documented results

The risk analysis moves in a fixed order: define what is in scope, map where ePHI lives, identify threats and vulnerabilities, rate the risks, document the results and turn them into a risk management plan. Each phase produces a named artifact that the next one depends on, and the cycle repeats when conditions change.

Set the scope to all ePHI
Define the boundary of the analysis to cover all electronic protected health information the organization creates, receives, maintains or transmits, in every form of electronic media. Leadership, the security official and system owners should sign off on the scope in writing, and the scope should name the business associates and hosting environments that touch ePHI. The output is a scope statement that a reviewer can read and check against the systems you say you have. Ask your assessor or implementation partner to include a phase schedule in the written scope before work begins, since no timeline applies to every organization.
Document where ePHI lives
Trace every path ePHI takes through the environment: applications, databases, endpoints, mobile devices, removable media, backups, email, integrations with partners and cloud services. OCR expects the organization to document where ePHI is stored, received, maintained and transmitted, so this step produces an ePHI inventory and data flow records. Owners of each system confirm their entries, and gaps found during interviews are logged for follow-up. The step is complete when every system in the scope statement has an owner, a data classification and a documented flow, and when nothing in the inventory lacks a source.
Identify reasonably anticipated threats and vulnerabilities
List the threats that could reasonably act on each system in the inventory, such as ransomware, phishing, credential theft, insider misuse, lost devices and misconfigured cloud storage, along with the vulnerabilities that threats could exploit. Sources include vulnerability scan results, asset and configuration records, incident history, vendor advisories and the threat sources named in NIST SP 800-30. The output is a threat and vulnerability register linked to specific assets. Confirm with the team that the list covers both technical and human sources, because OCR's guidance treats both as in scope.
Assess the current security measures
For each threat and vulnerability, record the safeguards already in place, including access controls, encryption, logging, backup, monitoring, training and vendor agreements, and state how well each one works in practice. Evidence comes from configuration exports, policy documents, test results and interviews, not from a checklist alone. The output is a current-state record that links each measure to the risk it is meant to address. Gaps between documented and operating controls are flagged here, because OCR's guidance requires the analysis to document current security measures.
Rate likelihood and impact of each risk
Using the NIST SP 800-30 definitions, treat risk as a function of the likelihood that a threat exploits a vulnerability and the impact on confidentiality, integrity or availability of ePHI if it does. Assign a likelihood and impact rating to each pairing, using a scale the organization defines and documents, and combine them into an overall risk level. The rule does not prescribe a method, so the scale and its rationale should be recorded so a reviewer can follow the logic. The output is a ranked risk register. NIST SP 800-66 Rev. 2 Section 3 and its Appendix C offer supporting tables you can adapt, and the free HHS SRA Tool is a practical option for smaller organizations.
Document results and build the risk management plan
Write up the analysis as a single report covering scope, method, inventory, threats, measures, ratings and conclusions. Then convert the ranked risks into a risk management plan that states, for each high-priority risk, the chosen treatment, the owner, the planned action and the evidence that will show it is done. Leadership should review and approve the plan, and approval should be recorded. Documentation must be retained for six years from creation or last effective date, whichever is later, under 45 CFR 164.316(b)(2)(i). The output is an approved analysis report and an owned risk management plan.
Set update triggers and review cycle
Define the events that require the analysis to be revisited, such as a new system or vendor that handles ePHI, a major change to architecture, a security incident, a breach, or a significant change in staff or leadership responsibilities. Record these triggers and a regular review cadence in the policy that governs the analysis. The proposed January 2025 rule would require a written analysis reviewed, verified and updated at least once every 12 months, but that change is not final as of October 2026, so confirm the current expectation with counsel. The output is a documented trigger list and review schedule that the security official tracks.

Choosing a method: the HHS SRA Tool, NIST SP 800-66 Rev. 2 or SP 800-30

The Security Rule does not prescribe a risk analysis methodology, and OCR's guidance states that no single method or best practice guarantees compliance. The method should therefore fit the organization's size, complexity and capabilities. A small practice with a handful of systems and a part-time security official needs something very different from a health system with hundreds of applications, multiple clouds and an internal security team. The choice matters less than whether the method reaches every location where ePHI is created, received, maintained or transmitted, and whether the output is written down in a form an investigator can follow.

The HHS Security Risk Assessment (SRA) Tool is the most accessible starting point. It was developed by ONC with OCR and is aimed at small and medium-sized health care practices and business associates. It walks the user through questions about assets, threats, vulnerabilities and existing safeguards and produces a report, but it does not replace judgment about your own environment. Larger organizations usually need a method with more depth. *NIST SP 800-66 Rev. 2*, published in February 2024, is a resource guide for implementing the Security Rule. Its Section 3 gives risk assessment guidance, and its Appendix C contains supporting risk assessment tables. HHS lists this guide as informational, not legally binding, so it supports a defensible method rather than defining one.

Underneath either choice sits the vocabulary of *NIST SP 800-30*, which OCR's guidance draws on for the definitions of vulnerability, threat and risk. Risk is a function of the likelihood that a threat exploits a vulnerability and the resulting impact. Before any assessment starts, confirm with your assessor which method they will use, how likelihood and impact will be rated, and where the results will be recorded, since the output must support your risk management plan and six-year retention. Ask them to show a sample of the documentation they produce. If you use the SRA Tool, check that its output is extended with the asset inventory, data flows and rationale that your environment requires.

In-house, tool-led or outsourced: which option fits

This table compares three ways to run the HIPAA risk analysis: in-house with the security official, in-house with outside support for specific tasks, and fully outsourced to an external assessor. Read each row against your own staffing, environment and contract requirements, because the right model depends on what you must own and what you can delegate. None of the three options removes the obligation to own the analysis and its results.

Factor	In-house, led by the security official	In-house with outside partner support	Fully outsourced to an external assessor
When it fits	Small team, simple environment with few systems and locations, and a documented method such as the HHS SRA Tool or a NIST SP 800-30 based approach	Complex or multi-site environment with limited staff, where inventory, threat modeling or documentation needs more hands than the team has	A contract or customer requires an independent assessment, or the organization lacks anyone able to run the analysis credibly
What the organization keeps owning	Scope, asset and ePHI data flow inventory, threat and vulnerability identification, risk ratings, decisions and the signed record	Scope, risk decisions, risk acceptance, sign-off and the final documentation, even where a partner drafts sections	Accountability for scope, supplying accurate information, acting on findings, and the risk management plan that follows
What the outside party does	Nothing required, although a peer review or advisory session may be useful	Prepares inventory, runs threat modeling workshops, drafts documentation and checks completeness	Performs the analysis, interviews staff, reviews systems and writes findings for the organization to adopt
Main risk	Incomplete scope or inconsistent ratings when the security official lacks time, data or method training	Partner work is accepted without challenge, so the organization cannot defend the results or explain its risk decisions	A report that does not reflect how ePHI actually moves, or a pass-through document the internal team never understands
Independent assurance	False, since internal analysis is not independent by default	False, since the partner supports the work but does not certify it	True only where the assessor is independent of the organization, though it does not make the analysis a certification
Ongoing upkeep	Recurring internal effort to update the analysis when systems, vendors or ePHI flows change	Recurring partner support can be scoped, but updates still depend on internal staff reviewing changes	Recurring external fees for each update cycle, with internal staff still maintaining the inventory and risk plan

What must exist before the analysis starts

A risk analysis is only as accurate as the inventory and context behind it. The items below are the inputs an assessor will expect to see the organization already holds, and each one feeds the scope decision that OCR's guidance requires to cover all ePHI in every form of electronic media.

A named security official with authority

The Security Rule requires a designated security official who is responsible for the security program. Before the analysis starts, confirm the person is named in writing, has budget and authority to pull in system owners, and can accept or reject risk. Check that the appointment date and the official's contact details are on file. An assessor will ask for the designation memo, the job description, and evidence that the official reviewed the prior analysis.

Inventory of ePHI systems and accounts

The scope must cover every system, cloud account, application and device that creates, receives, maintains or transmits ePHI. Build the list from finance, procurement, identity directories and cloud billing, not only from the IT asset register, because shadow SaaS and personal devices often hold PHI. Record the data type, owner and location for each entry. An assessor will compare this list against network traffic, cloud resource tags and vendor contracts to test whether anything is missing.

Current network diagrams and data flows

Diagrams show where ePHI enters, moves between, and leaves the environment, including interfaces to clinics, labs, payers and clearinghouses. Check that diagrams cover on-premises networks, cloud virtual networks, remote access paths and backup targets, and that each one carries a revision date. An assessor will trace a sample patient record from intake to storage and ask whether the diagram shows every hop. Gaps found at this stage are cheaper to close before scoring begins.

Existing policies and prior risk analysis

Gather the current security policies, the last risk analysis, and the risk management plan that followed it. Note which findings were closed, which were accepted, and which were never addressed. Confirm that the prior analysis is retained, since documentation must be kept for six years from creation or last effective date. An assessor will ask for the earlier analysis first to see whether the new one builds on it, explains changes in scope, and tracks follow-up actions to completion.

Business associate list and access

List every business associate and subcontractor that creates, receives, maintains or transmits ePHI for the organization, with the signed business associate agreement and the kind of access each holds, such as hosted systems, remote support, or data exchange. Confirm that each agreement is current and covers the systems in scope. Vendors with standing administrative access carry risks that belong in the analysis. An assessor will ask how each vendor's access is granted, reviewed and revoked, and whether vendor risk appears in the findings.

Sign-off authority for the final analysis

Decide before work begins who reviews the draft, who accepts the residual risk, and who signs the final document. The rule does not prescribe a method, so the decision-maker should agree to the scoring approach and the likelihood and impact criteria up front. Record the names and roles in the analysis plan. An assessor will look for evidence that leadership reviewed the results and approved the risk management plan, not only that a technical team produced the spreadsheet.

Who owns the analysis, who prepares it and who assesses it

The covered entity or business associate owns the risk analysis. The Security Rule requires the organization to conduct an accurate and thorough assessment of risks to the confidentiality, integrity and availability of the ePHI it holds, and it is the organization that decides how to manage each risk. Outside help can inform these decisions but cannot make them, and the organization remains liable for the outcome whoever did the technical work.

Analysis ownership: Leadership approves the scope, the methodology and the final risk ratings, and the named security official is accountable for keeping the analysis current.
Risk management plan: The organization decides which measures reduce each risk to a reasonable and appropriate level, sets owners and dates, and records the reasons for accepting any residual risk.
Security official role: The organization designates a security official. This can be an internal employee or, where contracted, an outside person, but the accountability and sign-off stay with the covered entity or business associate.
Six-year retention: The organization keeps the risk analysis documentation for six years from creation or last effective date, whichever is later, and must be able to produce it on request.

Before accepting any outside work, confirm which decisions the organization will still make itself and who will hold the retained records.

How to choose a risk analysis consultant or assessor

A risk analysis is the first thing OCR asks for, so the person who runs it needs to know the Security Rule and the methods behind it. The cards below cover the checks that separate a useful engagement from an expensive document, and each one ends with a question to put to the provider before work starts.

Named methods and Security Rule depth

OCR's guidance does not prescribe a method, so a provider should be able to name the approach it uses and explain why it suits your size and complexity. Ask which parts of NIST SP 800-66 Rev. 2 and NIST SP 800-30 the method draws on, and how it defines likelihood, impact and risk. Ask for a sample of prior risk analysis work, with identifying details removed, to see whether the threat and vulnerability identification is specific to ePHI systems.

Independence from remediation work

A provider that finds gaps and then sells you the fixes has a financial reason to find more gaps or to scope the findings narrowly. Ask whether the firm will remediate what it identifies and, if so, how it separates the assessment team from the implementation team. Ask who signs off on the risk rating, and whether the rating can be changed after remediation is quoted.

Written scope and deliverables

The scope must cover every location where ePHI is created, received, maintained or transmitted, in every electronic form. Before work starts, ask for a written scope that lists the systems, cloud accounts, endpoints, business associates and media included, along with the deliverables and the dates for each. Ask what is excluded and who decides when a system is added mid-engagement.

Documentation that meets 164.316

The output must be written documentation that you can retain for six years from creation or last effective date, whichever is later. Ask for a sample report and check that it records the threats and vulnerabilities considered, the current security measures assessed, the risk determinations, and the date of each review. Confirm who owns the report and how the provider will deliver the files for retention.

Handling of ePHI during the engagement

Assessors often need access to configurations, logs and sometimes sample records that contain ePHI. Ask whether the provider will sign a business associate agreement with you before any access, where its staff and tools process the data, how long it keeps evidence, and how it disposes of it at the end. Ask whether testing data is minimized or de-identified where the assessment does not need the real values.

What the provider will not do

No assessor can issue a HIPAA certificate, and HHS does not recognize private certifications. A reputable provider will say in writing that it will not issue an attestation of HIPAA compliance, will not guarantee that OCR accepts its work, and will not declare you compliant. Ask the provider to put these limits in the statement of work, and ask who in your organization remains the security official accountable for the risk analysis.

Questions buyers ask before hiring outside help

How much effort does a HIPAA risk analysis take, and what does the organization have to supply?

The effort depends on how much ePHI the organization creates, receives, maintains or transmits and how many systems hold it. OCR's guidance says the scope must cover all ePHI in every form of electronic media, so the work starts with an inventory of where ePHI lives. The organization must supply people who know its systems: application owners, IT administrators, the security official, HR for workforce access, and vendors that host or process data. Expect to provide existing policies, network diagrams, prior risk analyses, incident records, vendor contracts and access lists. Ask any outside party for a written list of the inputs they need from you before work starts, so the effort is visible in the scope rather than discovered midway.

Can a small practice complete a HIPAA risk analysis without a consultant?

Yes, a small practice can do the analysis itself, because the rule does not prescribe a methodology and expects methods to match the organization's size, complexity and capabilities. The HHS Security Risk Assessment (SRA) Tool, developed by ONC with OCR, is aimed at small and medium-sized health care practices and business associates, and it is free. Doing it internally still requires someone accountable who understands the systems and can judge likelihood and impact under the NIST SP 800-30 definitions of threat, vulnerability and risk. Many practices bring in a consultant for a review or a gap check rather than the whole exercise. Whichever path you choose, the organization remains responsible for the result and the documentation.

How long does a HIPAA risk analysis take, and what drives the timeline?

The duration is set by the size of the environment and the state of existing documentation, not by a fixed rule. Drivers include the number of locations and systems, how many cloud and business associate environments hold ePHI, whether an earlier analysis exists to build on, how quickly staff can answer questions, and how much remediation planning is included. Analysis and risk management plan work are separate phases, and a risk analysis that only lists findings is not the full job. Ask for a written phase schedule in the statement of work that shows discovery, analysis, risk ratings, the risk management plan, sign-off and handover, with the dependencies on your staff named for each phase.

Can a HIPAA risk analysis be outsourced, and what stays with the organization?

Preparation and facilitation can be outsourced, but the organization cannot transfer ownership of the analysis or the decisions that follow. An implementation partner can gather evidence, map ePHI flows, run the assessment method, draft the documentation and propose a risk management plan. The organization still has to confirm the scope and accuracy, accept or reject risk levels, decide which measures to fund, assign owners and dates, and approve the final record. Under the Security Rule the entity must keep the documentation for six years, and OCR looks to the covered entity or business associate for it. Make the division of labor explicit in the written scope so the internal security official knows what they must review and sign.

Is a third-party HIPAA risk assessment a HIPAA certificate?

No. There is no official HIPAA certification, and HHS states that it does not endorse or recognize private organizations' certifications. A third-party risk assessment is evidence that a qualified party reviewed your analysis and found it reasonable, but it is not a certificate, a seal or a pass. It also does not prevent HHS from later finding a violation. Ask the provider to state in writing what the engagement covers, who performed it, the method used, what was excluded, and that it does not constitute HHS approval. Customers who ask for a certificate are usually better served by a current risk analysis, its risk management plan and evidence that remediation is progressing.

How often must the HIPAA risk analysis be updated, and how long are records kept?

The current Security Rule requires an accurate and thorough risk analysis and does not set a fixed review interval, so updates are driven by changes in the environment, new threats, incidents and new systems. Documentation of the analysis must be retained for six years from its creation or last effective date, whichever is later, under 45 CFR 164.316(b)(2)(i). The January 2025 proposed rule would require a written analysis reviewed, verified and updated at least once every 12 months, but as of October 2026 that change is proposed, not final. Plan for the six-year retention now and confirm the status of the proposal with counsel before committing to an annual cycle in a contract.

How DeployOpen scopes, prepares and documents the analysis

DeployOpen does not perform the risk analysis or issue any HIPAA attestation. The organization owns its risk analysis and its conclusions, and DeployOpen prepares the systems, inventories and evidence that the analysis depends on for self-hosted open-source platforms in the client's own infrastructure.

How we scope

Engagements are fixed-scope, with the systems, locations and ePHI flows covered agreed in writing before work starts.
The written scope lists every platform that creates, receives, maintains or transmits ePHI within the client's environment.
Scope documents where ePHI is stored, received, maintained or transmitted, so the analysis has a defined boundary to assess.

How we build

We deploy self-hosted platforms with documented configurations for access control, audit logging, encryption and backups inside the client's infrastructure.
We build a technology asset inventory and network map for the in-scope platforms, recording owners, data flows and dependencies.
We run security testing against in-scope systems so the analysis can weigh likelihood of threats and exploitable vulnerabilities.

How we hand over

We deliver the asset inventory, data flow records, configuration baselines and test results as documentation the client's security official can review.
We provide working materials that map current safeguards to the analysis elements, for the client to validate and adopt.
Documentation is delivered to the client, who keeps it for six years from creation or last effective date, as the Security Rule requires.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, which can keep inventories and evidence current between analysis cycles.
We can help update platform documentation when systems change, so the client can meet its own reassessment triggers.
Questions about which findings the organization must act on remain with the client's security official and, where needed, its legal counsel.