164.308(a)(1)(ii)(A) Risk analysis: requirement and evidence

What the HIPAA risk analysis requirement asks for

164.308(a)(1)(ii)(A) is a required implementation specification that calls for an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of all electronic protected health information (ePHI) your organization creates, receives, maintains or transmits. If an audit, a customer questionnaire or an OCR inquiry is asking for your risk analysis, the reviewer wants to see a documented, current assessment that covers every system touching ePHI, not a generic security policy. OCR enforces this specification more than any other because it is the foundation the rest of the Security Rule depends on. Decisions about encryption, access, backup and personnel screening all trace back to what the risk analysis found, so a weak analysis tends to expose gaps across the whole rule. The Security Rule does not prescribe a method. OCR's guidance says methods vary with the size, complexity and capabilities of the organization, and no single approach guarantees compliance. What OCR does expect is that you identify and document where ePHI is stored, received, maintained or transmitted, the threats that are reasonably anticipated, the vulnerabilities that could be exploited, and the security measures already in place. Confirm your chosen method with your compliance lead or outside advisor, and be ready to explain why it fits your environment.

The hard part is usually finding the ePHI. Clinical applications, billing platforms, email archives, file shares, laptops, removable media, backup copies and vendor-hosted tools can all hold ePHI, and many of them are not in the official asset list. Shadow systems adopted by individual departments and stale inventories that predate a cloud migration are the usual reasons an analysis misses a location. Before scoping, ask IT, clinical operations and finance to name every system that handles patient or member data, then reconcile that list against network discovery and cloud account records. An analysis built on an incomplete map will look thorough on paper and still fail the accuracy test. Treat the risk analysis as a living document. Record the owner, likelihood, impact and current controls for each identified risk, and note which addressable specifications your results drive, such as whether encryption or personnel screening is reasonable and appropriate. Then confirm the analysis is refreshed when systems, vendors or data flows change, and keep dated versions so you can show how it evolved.

Which systems, data and third parties a HIPAA risk analysis must cover

The risk analysis under 164.308(a)(1)(ii)(A) covers every place ePHI is created, received, maintained or transmitted in electronic form, not only the systems IT already tracks. The cards below cover the scope decisions that most often leave gaps, starting with where the data actually goes.

Every electronic form of ePHI

The analysis must cover all ePHI the organization creates, receives, maintains or transmits, in every form of electronic media. Start from the data flows: intake forms, clinical and billing exports, email attachments, scanned documents, reports and spreadsheets. Ask each department where patient information lands after it leaves the core system. A data flow map built from those answers is the starting point for the rest of the scope.

Endpoints and mobile devices

Workstations, laptops, tablets and phones that open, cache or sync ePHI are in scope, including personal devices enrolled for work email or messaging. Check local downloads, browser caches, removable media and printers or scanners that store images. Confirm which devices are managed, which are not, and which can reach ePHI without any enrollment record.

Servers, cloud accounts and SaaS

On-premises servers, virtual machines, cloud accounts and SaaS applications that hold ePHI all belong in the inventory, including test, staging and reporting copies. Many organizations discover SaaS tools bought by a single department that store patient records. Record the account owner, hosting location and who administers each system, because those details drive the threat and vulnerability review.

Backup media and archives

Backup sets, replicas, snapshots, archived tapes and disaster recovery sites hold exact copies of ePHI and are in scope even when nobody uses them daily. Confirm where each copy sits, how it is encrypted, who can restore it and whether old media is retired and destroyed on a documented schedule. Restore paths are a common source of forgotten exposure.

Integrations and data pipelines

Interfaces between EHRs, billing platforms, imaging systems, laboratory feeds, patient portals and analytics tools transmit ePHI continuously. Each interface, API key, message queue and file transfer job is a transmission path that needs a documented threat and vulnerability assessment. Include integrations that run on service accounts, because those often lack owners and review cycles.

Workforce, contractor and third-party access

Every access path to ePHI counts, including employee accounts, contractor logins, vendor remote support sessions and shared administrator credentials. Map who can reach each system and through which route, such as VPN, remote desktop or a vendor portal. Business associates whose systems hold ePHI fall in scope, and their hosting, support and subcontracted services should appear in the analysis or in a documented assessment that the organization relies on.

How OCR and auditors test the HIPAA risk analysis

This table compares what OCR investigators and outside assessors check in a HIPAA risk analysis, the evidence they ask for and the findings they most often raise. Read each row as a question an assessor will ask, then confirm your own documents can answer it. An outside review of your analysis is useful preparation, but it does not produce a HIPAA certification, and only OCR can assess compliance.

Test area	Evidence requested	Common findings
ePHI location coverage	Inventory of systems, applications, devices, cloud services and media that create, receive, maintain or transmit ePHI	Analysis omits cloud SaaS, backups, mobile devices, medical devices or vendor-hosted systems
Threats and vulnerabilities tied to systems	Risk register linking each reasonably anticipated threat and vulnerability to a named asset or data flow	Generic lists of threats with no link to specific systems or ePHI flows
Current security measures documented	Written description of existing controls per system, with configuration or tool output where available	Measures described as policy only, with no evidence they are operating
Accurate and thorough, not a checkbox	Methodology, likelihood and impact ratings, rationale for scores and the people who performed the analysis	Template completed in one sitting, unchanged across years, or ratings with no supporting reasoning
Review when the environment changes	Dated revisions, change triggers such as new EHR or cloud migration, and records showing updates followed those changes	No revision history, or analysis predates major system changes such as an acquisition or new hosting model
Outcome feeds addressable decisions	Documented decisions on encryption, backup scope, workforce screening, authentication and transmission protection, each citing risk analysis results	Addressable specifications marked as implemented with no documented reasoning or alternative measure
Link to risk management	Risk management plan with prioritized treatments, owners and status for each identified risk	Risks identified but no treatment plan, or treatments that were never tracked to completion

What the HIPAA risk analysis document must contain

The risk analysis document has to show that the organization looked at every place it creates, receives, maintains or transmits electronic protected health information (ePHI) and reasoned about what could go wrong there. OCR's risk analysis guidance expects an inventory and map of where ePHI lives, covering every form of electronic media, including cloud services, endpoints, backups, removable media and connections to business associates. The map is the foundation. A risk analysis that omits a system holding ePHI is incomplete no matter how well the rest is written. Before drafting, confirm that your asset inventory and network diagrams are current, because the proposed 2025 rule would make a written technology asset inventory and network map mandatory, but that rule is not final.

For each location, the document should record the reasonably anticipated threats (for example, ransomware, misdirected email, lost laptops or an unpatched remote access service), the vulnerabilities that make those threats plausible, and the security measures already in place. It should also state the likelihood and impact the organization assigns to each risk, along with the rationale. OCR does not prescribe a method. The Security Rule leaves methodology to the organization, and the approach should match its size, complexity and capabilities. A small practice can use a simple scoring table, while a health system will need a more granular register. What matters is that the reasoning is traceable and repeatable.

The analysis must also drive decisions. OCR's guidance ties the outcome to the addressable specifications, such as whether personnel screening is needed for particular roles, how and how often data is backed up, whether encryption is reasonable for stored data and transmissions, and how transmissions are protected. Each addressable decision should cite a risk finding, or document why it is not reasonable and appropriate and what alternative measure replaces it. The HHS Security Risk Assessment (SRA) Tool, a free tool developed by ONC with OCR, can help small and medium-sized practices and business associates structure this work. It does not replace analyst judgment about your environment, so confirm that its questions fit your systems and document where you departed from them.

How to run a HIPAA risk analysis in sequence

The sequence moves from defining where ePHI lives to a signed report that names the risks, their ratings and an accountable owner. Each step produces an artifact you can check against your evidence list before moving on.

Define scope and map ePHI data flows
Start by setting the boundary of the analysis: every system, location and service that creates, receives, maintains or transmits ePHI, in any electronic form. Walk the data from intake through storage, processing, transmission and disposal, and record each point where it moves. Include business associates and cloud or hosting services that touch ePHI. The artifact is a scope statement and a data flow map that the security official and system owners have reviewed. The step is complete when someone outside the project team can trace a patient record from entry to deletion using only the map.
Build the asset and software inventory
Convert the data flow map into an inventory of the hardware, operating systems, applications, network devices and cloud resources that hold or move ePHI. Record the owner, location and purpose of each asset, and note which assets are in scope for vulnerability checks. Automated inventory tools such as Wazuh's Syscollector or GLPI's Assets module can collect much of this data, but someone must still confirm the results against the data flow map. The artifact is a reconciled asset register and a network map. The step is complete when every system named in the data flow map appears in the inventory and every inventory entry traces back to a data flow.
Identify threats and vulnerabilities
For each in-scope asset, list the reasonably anticipated threats, such as credential theft, ransomware, misconfiguration, unpatched software or physical loss, and the vulnerabilities that would let a threat act. Use vulnerability scanning and software matching where available. Fleet, for example, matches installed software on enrolled hosts against sources including the NVD and OSV, which gives you a starting list to verify rather than a finished one. Review results with system owners, because scanners miss configuration weaknesses and business logic flaws. The artifact is a threat and vulnerability register linked to assets. The step is complete when each in-scope asset has either a documented list of threats and vulnerabilities or a recorded reason why none apply.
Review existing security measures
Document the controls that already reduce each identified risk, including access controls, encryption, logging, backups, training and vendor agreements. Test or observe them where possible rather than relying on policy text alone, and note gaps between what the policy says and what the system does. Be precise about which controls protect which assets, because a control that covers one system may not cover another. The artifact is a current-controls register that records each control, its owner, how it was verified and any gaps. The step is complete when every threat and vulnerability from the previous step is paired with the controls that address it, or flagged as unaddressed.
Rate likelihood and impact with a documented method
Score each risk using a method the organization writes down before scoring begins. OCR does not prescribe one method, so choose a scale that fits your size and complexity, define each rating level, and apply it consistently across assets. Rate the likelihood of the threat exploiting the vulnerability given existing controls, and the impact on the confidentiality, integrity and availability of ePHI. Record the reasoning for each rating, especially for high and low results, so an assessor can follow it. The artifact is a risk register with ratings, the scoring method and the rationale. The step is complete when every risk has a rating produced by the documented method and a second reviewer has checked a sample of them.
Assign risk owners and prioritize treatment
Connect each rated risk to the person accountable for treating it and to the treatment decision: mitigate, accept, transfer or avoid. The risk analysis informs the addressable decisions the rule asks you to make, such as whether encryption, personnel screening or backup approaches are reasonable and appropriate for your environment. Record the decision and the reason for any risk accepted at its current level. The artifact is a prioritized risk list with owners and proposed treatments, which feeds the risk management plan. The step is complete when each risk above your acceptance threshold has an owner and a treatment, and each accepted risk has a documented reason and an approver.
Sign and date the analysis report
Compile the scope, data flow map, inventory, threat and vulnerability register, controls review, rating method, risk register and treatment decisions into one written analysis report. Have an accountable leader, usually the security official, review and sign it, and record the date of completion and the date of the next scheduled review. Keep the report with the policies and procedures that govern its use, and retain it as documentation. The artifact is the signed report with version history. The step is complete when the report can be handed to an internal reviewer or an independent assessor and they can trace every finding back to its evidence.
Set triggers for updating the analysis
Define when the analysis must be revisited, including after significant changes to systems, vendors, facilities or operations, and after security incidents. Assign who monitors those triggers and how the inventory and data flow map are kept current between full reviews. Ask your counsel or compliance lead to confirm the review interval your contracts or other obligations require, since the rule itself does not set one. The artifact is a maintenance procedure with named owners and a change log. The step is complete when the procedure is approved and the first update triggered by a real change has been logged and worked through.

Which open-source tools can produce risk analysis inputs

A risk analysis is only as accurate as the inventory, asset data and vulnerability picture behind it. The four self-hosted tools below each produce one kind of input, and none of them performs the analysis or decides what the risks mean.

Assessment tracking with CISO Assistant

CISO Assistant (AGPL-3.0-only) runs audits and compliance assessments against more than 200 frameworks and maps controls automatically between them. For 164.308(a)(1)(ii)(A) Risk analysis, it can hold the risk register, assessment records and evidence that show how threats and vulnerabilities were rated and tracked. Before relying on it, confirm in your installed version that HIPAA Security Rule coverage exists and matches the safeguards you need to document, since framework libraries change between releases.

Asset inventory with GLPI

The Assets module in GLPI tracks computers, monitors, software, network equipment, peripherals, printers, phones and racks. Records can be entered manually or pushed automatically by the GLPI Agent through native inventory, which has been built into GLPI since version 10. This gives the analysis a starting list of where ePHI-bearing devices sit. Check that the inventory covers every endpoint, server, mobile device and network component that creates, receives, maintains or transmits ePHI, not only the managed fleet.

Endpoint system inventory with Wazuh

The Syscollector module in Wazuh collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups, and Windows updates from each endpoint. The data is stored in the Wazuh indexer and shown in inventory views and reports. For the analysis, this shows which systems expose network services and which accounts can reach them, which feeds the threat and vulnerability sections. Confirm agent coverage on hosts that handle ePHI, because gaps here carry into every later decision.

Vulnerability matching with Fleet

Fleet (MIT) detects vulnerable software on enrolled hosts by matching installed software against sources including the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV. For risk analysis, this produces a dated list of known vulnerabilities by host, which supports the vulnerability side of the assessment. Ask which feeds are active in your deployment and how often they refresh, because a match only reflects the data source at the time it ran. Matches also need human triage to confirm exploitability in your environment.

In-house or with a partner: who does what in the risk analysis

Your team is the only party that can own the analysis. The Security Rule places responsibility on the covered entity or business associate, and under 164.308(a)(2) that starts with one named security official who is accountable for the Security Rule policies and procedures. System owners know which applications hold ePHI, how data moves between them and which threats matter for their operations, so they must validate what any outside party assembles.

Security official: Owns the risk analysis process, approves its scope and methodology, and signs off the final document.
System owners: Confirm where ePHI is created, received, maintained or transmitted for each system, including shadow tools and vendor-hosted services.
Inventory owners: Keep the asset inventory and network map current and decide what counts as a change that triggers an update.
Risk acceptance decision makers: Executives who decide which residual risks are reasonable and appropriate to accept, and record why.
Addressable specification decisions: Choices on personnel screening depth, backup scope, encryption and transmission protection stay with your organization.

Before accepting any partner draft, confirm that each system owner has checked the ePHI locations and that the security official can explain every acceptance decision without reference to the consultant.

Evidence that shows the HIPAA risk analysis is accurate and current

An assessor will test whether the risk analysis describes the environment as it actually is today, not as it was when the document was signed. The artifacts below connect to each other: the inventory feeds the data flow map, the scans check the inventory, and the change log decides when the analysis must be reopened.

Dated and signed risk analysis report

The report is the document an assessor reads first. It should state the scope as all ePHI the organization creates, receives, maintains or transmits, name the date of the analysis, identify who approved it, and list the threats, vulnerabilities and current measures considered. Keep prior versions so that the history of changes is visible. Between audits, set a review trigger in the change process so that a material change opens a dated addendum rather than an silent edit to the original.

ePHI data flow map and asset inventory

OCR expects the organization to identify every location where ePHI is stored, received, maintained or transmitted. The map should show systems, interfaces, cloud accounts, endpoints, backups and third parties, with a named owner for each asset. Check that every system on the map appears in the inventory and that every inventory entry traces back to a business process. Tie updates to the same change tickets that alter infrastructure, so the map does not drift.

Scan and inventory exports matched to the analysis

Exports from asset inventory and vulnerability tools show whether the environment still matches the analysis. Open-source options include GLPI for asset records, Wazuh Syscollector for host inventory and Fleet for vulnerable software detection. Compare exports against the analysis each cycle and record unexplained hosts, unmanaged software or open ports as findings. Confirm with each tool's documentation which fields it collects before you rely on it as evidence.

Methodology statement and rating criteria

OCR does not prescribe a method, so the organization must explain the one it chose and why it fits its size and complexity. The statement should define how likelihood and impact are rated, what counts as a reasonable and appropriate level of risk, and who scored each item. An assessor will test whether the scores follow the stated criteria. Keep the criteria stable between cycles, and record any change to them with a reason.

Log of environment changes and follow-up reviews

A change log linked to the risk analysis shows that the analysis was reopened when the environment moved. Record each new system, migration, vendor onboarding, major upgrade and access model change, with the date and the review outcome. Each entry should either reference an updated analysis section or state why the change carried no new risk. Assessors look for gaps between significant changes and the reviews that followed them.

Records of risk management and addressable decisions

The analysis only matters if it drives action. Keep evidence that each finding above the accepted level received a risk management measure with an owner and a due date, and that addressable specification decisions, such as personnel screening, backup scope and encryption use, follow from the analysis. Where a specification was judged not reasonable and appropriate, the documented reasoning and the alternative measure should sit beside the analysis. Confirm with counsel which records must be retained and for how long.

Cost of a HIPAA risk analysis in money and effort

This table breaks the cost of a 164.308(a)(1)(ii)(A) risk analysis into its components, showing who is paid or who spends time, whether each cost is one-time or recurring, what pushes it up or down, and how to keep it contained. No fee is stated because none is supplied; the main takeaway is that internal staff time and the scope of ePHI locations usually drive effort more than tool licenses.

Cost component	One-time or recurring	What drives it up or down	How to keep it down
Staff time from the security official and system owners	Both: full analysis is one-time, updates recur	Number of systems and ePHI locations, staff turnover, how many people must explain their systems	Name one accountable owner, assign system owners in advance, and reuse last cycle's inventory
Tooling	Recurring for hosting and upkeep; one-time for setup	The HHS SRA Tool is free. Open-source tools remove license spend but still need servers, storage and administrator hours	Start with the free HHS SRA Tool, then add open-source tools only where they answer a gap you can name
Discovery and inventory work	One-time build, recurring refresh	Shadow IT, cloud accounts, SaaS apps, medical devices and endpoints not yet tracked	Automate asset collection where possible and confirm the list with department heads before analysis starts
External assessment or facilitation	One-time per cycle, sometimes recurring	Scope breadth, number of sites, staff familiarity with the rule, and whether the firm reviews or only facilitates	Fix scope in writing, prepare inventories beforehand, and ask whether the firm co-writes or only reviews
Evidence upkeep	Recurring	Log retention needs, number of policies tied to findings, and how many risks need tracked evidence of treatment	Keep one register linking each risk to its owner, decision and evidence, and review it on a fixed schedule
Periodic review after environment changes	Recurring	New systems, mergers, cloud moves, vendor changes and the rate of change in your environment	Tie reviews to change management so a new system triggers a documented update, not an annual scramble
Quote scope and sign-off	One-time at engagement	Vague scope leads to extra work; unclear sign-off delays the analysis	Ask the quote to list systems, ePHI locations, deliverables and who signs the final analysis

Common questions about the HIPAA risk analysis

Can we do the HIPAA risk analysis ourselves?

Yes, in most cases a covered entity or business associate can perform its own risk analysis, because the Security Rule does not prescribe a specific method. OCR's guidance says methods vary with the size, complexity and capabilities of the organization, and no single method guarantees compliance. What matters is that the analysis is accurate and thorough and covers every location where electronic protected health information is created, received, maintained or transmitted. Internal staff need enough security knowledge to identify threats, vulnerabilities and existing safeguards, and they need to document the results and decisions. Small practices often start with the free HHS Security Risk Assessment Tool, while larger organizations usually combine internal work with specialist input for technical testing. Ask whoever signs the analysis to show the scope, the asset inventory and the reasoning behind each rating.

Does the HHS SRA Tool satisfy the risk analysis requirement?

The HHS Security Risk Assessment Tool helps organizations work through the risk analysis requirement, but using it does not by itself make an analysis complete. It was developed by ONC with OCR to help small and medium-sized health care practices and business associates. The tool guides you through questions about assets, threats and safeguards, but the output is only as accurate as the inventory and answers entered. OCR still expects you to identify where ePHI lives, reasonably anticipated threats and vulnerabilities, and current security measures, then document the likelihood and impact of each risk. Larger or more complex environments, including cloud services, medical devices and third-party integrations, usually need more detail than the tool captures. Treat the SRA Tool as a starting structure and confirm that its output covers your full environment.

How much effort does the risk analysis take, and what drives it?

Effort depends mainly on how many systems hold ePHI, how many locations and vendors are involved, and how much current documentation already exists. An organization with a single clinic and a few applications has a much smaller task than a health system running hospital information systems, imaging archives, remote access and many business associate connections. The work is largely one-time for the initial analysis, followed by recurring updates when the environment changes. Costs are mostly staff time, which can be internal, or fees paid to a consultant or assessor if you hire one. Ask any outside provider for a written scope that lists the systems, sites, interviews, technical testing and deliverables included, because scope is the main driver of any quote. No standard duration is set by the rule, so the timeline should follow from that agreed scope.

How often must the risk analysis be updated?

The current Security Rule does not set a fixed review interval for the risk analysis, but it requires an accurate and thorough assessment, which means it must stay current with the environment. In practice, organizations update it when systems, locations, vendors, data flows or threats change significantly, and after incidents that reveal gaps. The January 2025 proposed rule would add a written technology asset inventory and network map reviewed at least once every 12 months and whenever the environment changes, plus a risk analysis reviewed on a set cycle. That proposal was not final as of October 2026, so confirm its status before writing it into policy. Until then, build a documented review trigger list and a calendar review, and keep records of each update.

Do we need an outside auditor or a HIPAA certification?

No Security Rule standard requires an outside auditor, and there is no HIPAA certification. HHS states that no standard requires an entity to certify compliance, that it does not endorse or recognize private certifications, and that such certifications do not prevent HHS from later finding a violation. An independent assessment can still be useful for leadership assurance, for a contract that requires one, or for readiness before an OCR audit, but it does not replace the organization's own risk analysis. Be careful with any vendor who claims to issue a HIPAA certificate. Ask what the assessment covers, who performs it, what evidence it reviews and what the report can and cannot show.

What does the risk analysis need from our team?

The analysis needs named people who know the systems and the business, with a security official accountable for the result. Typically, a person from IT or infrastructure must supply the asset inventory and data flows, an application owner must describe how ePHI is used, and a clinical or operations lead must explain where information moves in daily work. Someone with security expertise should evaluate threats, vulnerabilities and existing controls, and leadership must review the findings and approve the risk decisions. Staff time for interviews, document collection and review is the largest internal requirement. Plan for a named owner, a set of source documents such as network diagrams, system lists and vendor contracts, and a place to store the signed record so OCR can see how the analysis was produced.

Which tools help collect the asset inventory for the analysis?

Open-source tools can collect much of the inventory evidence the analysis depends on, but none of them produces the risk analysis itself. GLPI's Assets module records computers, software, network equipment and other hardware, entered manually or pushed by the GLPI Agent. Wazuh's Syscollector collects hardware, operating system, software, open ports, services and users from each endpoint into dashboards. Fleet matches installed software on enrolled hosts against vulnerability sources such as the NVD and OSV. CISO Assistant can record the assessment and map evidence to frameworks. Confirm each tool's coverage against your own environment, especially medical devices, cloud services and unmanaged systems, which often need manual entries.

How DeployOpen works on this

DeployOpen helps organizations prepare the systems, inventories and evidence that a HIPAA risk analysis needs, while the covered entity or business associate keeps ownership of the analysis and its conclusions. Work is scoped in writing before it starts, and DeployOpen does not issue audit reports or certifications.

How we scope

We agree in writing which systems, applications and data stores holding ePHI fall inside the risk analysis scope.
Scope documents where ePHI is created, received, maintained or transmitted, so the analysis covers every electronic location.
Engagements are fixed-scope, with deliverables and timelines confirmed in writing before any work begins.

How we build

We deploy self-hosted asset inventory and network mapping tools inside your own infrastructure to record ePHI-bearing assets.
We configure vulnerability detection against inventoried software so threats and vulnerabilities feed the analysis with current data.
We test that inventory and vulnerability outputs are accurate and reviewable before the risk analysis relies on them.

How we hand over

We deliver a documented asset inventory, network map and risk register that your security official can review and maintain.
We document methods, assumptions and tool configurations so an assessor or auditor can trace how each finding was produced.
We hand over administration runbooks so your staff can repeat the analysis when systems or ePHI flows change.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer for keeping the risk analysis current.
Retainer support can cover refreshing the inventory and vulnerability data when your environment changes.
Confirm with DeployOpen which support and review tasks sit inside your retainer before signing the written scope.