HHS SRA Tool: what it does and when to outsource

Is the HHS Security Risk Assessment Tool enough for HIPAA risk analysis?

The HHS Security Risk Assessment Tool is a free, informational aid for small and medium-sized practices and business associates, and it does not guarantee HIPAA compliance. It can structure a risk analysis and prompt questions you might otherwise skip, but the Security Rule does not treat any tool as the analysis itself. Whether it is enough depends on your organization's size, the number of systems and locations where electronic protected health information (ePHI) lives, and how many vendors and subcontractors touch that data. A solo practice with one electronic health record and a single cloud email account faces a very different analysis from a business associate running hosted applications across several environments. The tool's disclaimer says it may not identify all risks, is not legal advice, and that the NIST resources it references are not required for HIPAA risk analysis compliance.

The organization still owns the analysis. Someone with authority must decide the scope, document the threats and vulnerabilities, assess current safeguards, and choose how to reduce each risk to a reasonable level. The tool records answers, but it does not make those judgments for you, and it does not issue a report, attestation or certificate that you can hand to a customer or regulator. Confirm the current release before you start: the HealthIT.gov SRA Tool page lists version 3.7 as of a September 18, 2026 update, delivered as a 64-bit Windows application and as an Excel workbook with a user guide. Check which format your team can run and whether the version you download matches the one on that page.

Before you rely on the tool, check three things. First, confirm that it covers your systems, such as cloud-hosted platforms, self-hosted servers, mobile devices and third-party integrations, and add those items yourself where it does not prompt for them. Second, decide who will record and approve the answers, since the Windows version keeps data on the local computer, so backup and access control of that file become your responsibility. Third, if your environment has grown beyond a small practice's footprint, or a customer has asked for independent evidence, plan for outside help. A third-party assessment can test what you documented, but it cannot replace your own analysis, and any firm you hire should be asked exactly what it will and will not sign.

What the HHS SRA Tool does and does not do

The HHS Security Risk Assessment Tool guides you through a structured set of questions and helps you document your answers. The cards below separate what the tool supports from the work it leaves to your organization, so you can plan the rest of the risk analysis before you start.

Structured questionnaire and documentation aid

The SRA Tool walks you through questions that map to the Security Rule's safeguards and records your answers and notes in one place. It is developed by ONC with OCR for small and medium-sized practices and business associates. Its value is structure: it prompts you to consider each area and keeps a written record. It does not decide which answers are correct for your environment, so each response still needs someone who knows your systems to check it.

ePHI inventory discovery

The tool asks questions about systems and practices but does not find where ePHI actually lives. Your team must identify every application, device, database, backup, email account and vendor service that creates, receives, stores or transmits ePHI. Confirm that the inventory covers shadow IT, removable media and cloud accounts before you rely on any answer the tool produces.

Technical testing of your environment

Answering yes to a question about patching, encryption or access control is not the same as verifying it. The tool does not scan networks, review configurations or test controls. Plan for technical evidence such as configuration exports, vulnerability scan results and access reviews, and ask whoever performs the assessment how they will confirm each answer.

Threat modeling for your environment

OCR's guidance expects a risk analysis to identify reasonably anticipated threats and vulnerabilities to ePHI. The tool offers general prompts, but it cannot model the threats facing your specific systems, vendors, staff and locations. Document the threat scenarios you considered, the vulnerabilities behind them and the current measures that address each one.

NIST references in the disclaimer

The tool references NIST standards, but its disclaimer states that those standards are not required for HIPAA risk assessment compliance. Do not treat NIST references as a checklist you must fully satisfy. If you want a deeper method, NIST SP 800-66 Rev. 2 is a resource guide that HHS lists as informational, not legally binding. Confirm with your compliance lead which reference set you will use and record that decision.

Risk management plan and follow-through

The tool produces findings, but it does not turn them into decisions. The risk management plan must set which risks you reduce, to what level, with which measures, who owns each one and when it is due. The tool cannot track that work. Ask whether your risk management process records owners, deadlines and evidence of completion for every finding.

Choosing between the Windows application and the Excel workbook

The Windows application is the version most practices and business associates pick first. It is a 64-bit Windows program at version 3.7, and it guides the user through the assessment with its own interface, drop-down choices and generated report. HealthIT.gov states that information entered in the Windows tool stays on the user's computer and is not collected, viewed, stored or transmitted by HHS, which makes it the format most teams associate with keeping answers local.

Operating system: The tool is built for 64-bit Windows. Confirm the supported Windows versions on the HealthIT.gov tool page before installing on a workstation.
Storage: Answers are saved on the local machine, so the file lives where the tool is installed. Decide where that machine is backed up.
Sharing: Because data stays local, multi-person review requires a controlled way to pass files or reports between users.
Administrative rights: Check with your IT team whether installation and file saving are permitted on managed endpoints.
Best fit: Small teams with a designated Windows workstation and a single owner for the assessment.

Before installing, confirm the operating system and install permissions in the HealthIT.gov materials and with your IT administrator.

How the Windows SRA Tool handles the data you enter

HHS states that information entered in the Windows version of the SRA Tool stays on the computer where you run it. According to HHS, the information is not collected, viewed, stored or transmitted by HHS. That statement describes HHS's handling of the data. It does not tell you how your own environment treats the file. Before you enter anything, confirm where the application writes its working files, whether those files sync to a shared drive or cloud folder through your operating system, and whether your endpoint backup or monitoring tools capture them. The Excel workbook version and its user guide, both listed on the HealthIT.gov SRA Tool page, should be checked the same way, because a spreadsheet is easy to copy, email or save to a personal location.

Decide now who will hold the completed analysis and how copies move internally. A risk analysis describes your systems, locations and weaknesses, so the file itself is sensitive. Limit the number of copies, store the master version in a access-controlled repository with version history, and record who may open or edit it. If a practice or business associate sends the file to an outside reviewer, confirm the transfer method and the reviewer's own handling obligations in writing before sending. Treat any internal sharing as a disclosure your own policies must govern.

Plan retention from the start. HIPAA documentation, including the risk analysis and its updates, must be retained for six years from the date of creation or the date it was last in effect, and made available to the people who need it. Confirm that the version you keep is a dated, complete record, not just the most recent edit, and that your storage can keep it readable for that full period, including after you upgrade to a newer SRA Tool release. The disclaimer on the tool also states that it is informational only and not legal advice, so your retention decisions should be checked with counsel or your compliance lead.

How to run the SRA Tool in a way OCR can follow

This sequence turns the SRA Tool's questionnaire into a dated, reasoned record that shows how your organization identified and assessed risks to ePHI, which is the core of the risk analysis OCR expects. The output is an input to the risk management plan, not the plan itself.

Confirm the ePHI scope and asset list
Before opening the tool, the privacy or security lead defines which systems, applications, devices, media and vendor services create, receive, maintain or transmit electronic protected health information. The list should cover the environments where ePHI actually lives, including cloud services and paper-to-electronic workflows. Under 45 CFR 164.306(a)(2), the analysis must address all ePHI the organization creates, receives, maintains or transmits, so this list defines the boundary of the analysis. You know this step is done when a named owner has signed off on the scope and every system on the list has an accountable person.
Gather input from system owners
The person running the SRA Tool should not answer technical questions alone. Schedule working sessions with the people who administer systems, manage vendors, handle backups and control access, and record who contributed to each section. Their answers about configuration, patching, logging and access reviews are what make the answers in the tool accurate. Note the date and participants for each session, since OCR looks for evidence of who performed the analysis. The step is complete when each in-scope system has been reviewed by someone who runs it day to day.
Complete the tool's questions for each area
Work through the tool's questions section by section, answering against the scope list and the input gathered from system owners. Where an answer is uncertain, record the uncertainty instead of choosing the most favorable option, because an unverified answer is weak evidence. The tool is informational only and does not identify every risk, so treat its questions as a structure for your own review rather than a complete checklist. The step is complete when every in-scope system has answers and each open question has a named owner.
Record threats, vulnerabilities and current measures
For each in-scope system, document the reasonably anticipated threats to ePHI, the vulnerabilities that could be exploited, and the security measures already in place. OCR's guidance lists identifying and documenting threats and vulnerabilities, and assessing and documenting current security measures, as elements every risk analysis must include, citing 164.308(a)(1)(ii)(A) and 164.316(b)(1). Write these as specific statements tied to a system, for example which access path to a database is exposed, rather than generic categories. You know this step is done when every system on the scope list has at least one recorded threat, the vulnerabilities behind it, and the controls currently in place.
Assign a rating and rationale for each risk
For each recorded threat and vulnerability, assign a likelihood and impact rating using a scale your organization defines and writes down before rating. Then record the reasoning behind each rating, including the evidence used, such as log reviews, prior incidents or vendor documentation. The rule does not prescribe a methodology, so the scale is your choice, but it should be applied the same way across systems. The step is complete when every risk has a rating, a stated rationale and a named reviewer who has checked the ratings for consistency.
Save and date the output
Export or save the tool's output and your supporting worksheets together, with the version of the tool used and the date of completion. Store the record in your compliance repository with access controls, because it describes weaknesses in your environment. Keep the signed scope, the list of contributors and the rating rationale with it. The retention and documentation expectations in 45 CFR 164.316 apply to the risk analysis record, so confirm your retention period with counsel. You know this step is done when the package can be reopened and read by someone who did not perform the analysis.
Hand findings to the risk management plan
The risk analysis identifies and rates risks; it does not decide how to reduce them. Pass the rated risks to the team responsible for the risk management plan, which is a separate deliverable under 164.308(a)(1)(ii)(B) and must document the security measures chosen to reduce risks to a reasonable and appropriate level. Note which findings are open, which were accepted with a documented reason, and which need a decision from leadership. The step is complete when each rated risk has a named owner in the plan or a recorded acceptance decision.

When a practice needs more than the tool

The HHS SRA Tool walks an organization through questions about its safeguards, but it does not discover systems, test controls or review vendors on its own. The situations below are where the tool's answers need outside data, technical evidence or a second reviewer to hold up under scrutiny.

Multiple sites and mixed hosting

When ePHI sits across several locations, a cloud tenant and an on-premises server room, a single questionnaire answered from memory tends to miss systems. Each site and hosting environment needs its own asset list, data flows and safeguard answers before the tool's results reflect reality. Ask who owns each system and confirm that the in-scope inventory was built from configuration data, not recollection. Your IT or platform team usually builds this inventory, with a security reviewer checking it.

Business associate relationships

The SRA Tool asks about your own environment, so it does not show whether a business associate that stores or transmits ePHI for you has adequate safeguards. Each vendor that touches ePHI needs its contract terms, its own risk review and evidence such as security documentation or independent reports. Check whether each business associate agreement reflects the safeguards you rely on. Vendor security reviews are usually led by the compliance lead with input from procurement and legal.

Custom and self-hosted applications

The tool's questions are general, so they rarely capture risks in an application your team built or customized, such as an internal patient portal, an integration engine or a self-hosted open-source platform. These systems need threat modeling, code and configuration review and a check of authentication, logging and encryption against the safeguards they must support. Confirm who maintains each component and how patches reach it. Application security testers or platform engineers typically perform this work.

Prior findings or ransomware exposure

If OCR has investigated your organization, or if you have suffered a ransomware event or a phishing-driven breach, the tool's generic answers will not show whether the specific weakness that caused the problem has been fixed. OCR's enforcement record repeatedly cites risk analyses that failed to identify realistic threats. Document how each prior finding was analyzed, what changed and how you verified the change. Independent security testers and incident response specialists are often brought in for this review.

Technical testing and evidence collection

A tool-based risk analysis records what you believe about your controls, while an assessor or OCR may ask for proof that the controls work. Vulnerability scans, configuration checks, log samples and penetration tests give that proof for high-risk systems. Decide which tests are needed, retain their results and link each finding to the risk analysis and risk management plan. Testing is often performed by an independent firm, and the organization keeps the evidence and the decisions.

Independent review of the analysis

The SRA Tool's disclaimer states that it is informational, may not identify all risks and is not legal advice. For a larger or more complex organization, a qualified reviewer can test whether the risk analysis covers all ePHI, applies sound likelihood and impact reasoning and drives the risk management plan. Ask any reviewer what they will check and what they will not certify, because no HIPAA certification exists. Legal counsel and an experienced HIPAA security advisor usually share this review.

Who owns the analysis, who prepares evidence, and who reports

The covered entity or business associate owns the risk analysis under 45 CFR 164.308(a)(1)(ii)(A). That means the organization decides which threats and vulnerabilities are reasonably anticipated, judges how likely and how severe each risk is, and chooses which measures to adopt. OCR's guidance says the rule does not prescribe a methodology, so the organization must be able to explain the method it used and why it fits its size and complexity. No consultant, tool vendor or implementation partner can take over these decisions or the accountability for them.

Analysis decisions: Leadership, the security official and the people who run the systems decide the scope, the risk ratings and the accepted residual risk.
Documentation: The organization keeps its own written analysis and the record of how each finding was resolved.
Policy and sign-off: Management approves the risk management plan and the policies that follow from it.
Ongoing review: The organization schedules updates when systems or operations change, since no outside party monitors this for it.
Tool output: The SRA Tool produces a worksheet, but the organization must review and adapt its answers.

Before relying on any outside help, confirm in writing which decisions stay with your staff.

Questions practices ask about the SRA Tool

Is the HHS Security Risk Assessment Tool free, and who is it for?

Yes. The HHS Security Risk Assessment (SRA) Tool is free, and HHS aims it at small and medium-sized health care practices and business associates. It was developed by ONC with OCR and is available as a 64-bit Windows application and as an Excel workbook with a user guide. The current version listed by HealthIT.gov is 3.7, from a September 18, 2026 update, so confirm you have the latest download before you begin. Larger organizations can use it too, but its questions are written for smaller environments, so they may need to add assets, locations and systems the tool does not prompt for. The cost you will still carry is staff time, and possibly outside help for the parts the tool cannot answer for you.

Does using the SRA Tool alone satisfy the HIPAA risk analysis requirement?

Not by itself. The tool helps you work through a risk assessment, but the Security Rule requires an accurate and thorough risk analysis of the potential risks and vulnerabilities to your electronic protected health information, plus a risk management process that acts on the results. The tool's own disclaimer says it is informational only, is not legal advice, may not identify all risks and is not a guarantee of compliance. OCR's guidance says the rule does not prescribe a methodology. Your analysis must still document the threats and vulnerabilities you identified, the current security measures you assessed and your risk determinations, and it must be kept current. The tool produces a starting point. Your organization owns the conclusions, the decisions and the evidence behind them.

How long does a first SRA Tool pass take, and what drives the effort?

The tool's documentation, not this page, is the right place to confirm how long a first pass takes, because no reliable figure has been published here. Effort depends mostly on how much you must inventory before answering questions. Expect more work where ePHI sits in many systems, where cloud and vendor services are involved, where policies are missing, or where several people must answer for different departments. Staff who already maintain an asset list and a list of business associates will move faster. Ask whoever runs the work to break the effort into inventory, interviews, answering the questions, documenting results and drafting the risk management plan, since the last step is the one most often skipped.

Do staff need technical skills to use the SRA Tool?

Basic computer and office skills are enough to complete the questionnaire, but answering it accurately is harder than operating it. Many questions ask about encryption settings, access controls, backups, logging and how systems connect, and staff who cannot answer them will guess. Plan for an IT or security person to verify the technical answers and for a privacy or compliance lead to review administrative and physical safeguards. Practices without internal IT often rely on a managed service provider, which should be listed as a business associate if it handles ePHI. The user guide explains the mechanics, so read it before the first session.

What does OCR expect to see in a risk analysis?

OCR expects documented evidence that you looked at your environment and considered how ePHI could be harmed. Its guidance lists elements every risk analysis must include, among them identifying and documenting reasonably anticipated threats and vulnerabilities, and assessing and documenting your current security measures. Under 45 CFR 164.308(a)(1)(ii)(A), the analysis must be accurate and thorough. Investigators typically ask for the scope, the inventory of systems that create, receive, maintain or transmit ePHI, the threats and vulnerabilities considered, the rationale for ratings, and the dated record of what changed. A completed tool export with no supporting inventory or follow-up decisions is a weak answer to that request. Confirm the current expectations against OCR's Guidance on Risk Analysis before you rely on this list.

Does the SRA Tool store or send my practice's data to HHS?

According to HHS, information entered in the Windows version of the SRA Tool stays on the user's computer. HHS states that it does not collect, view, store or transmit that information. Because the data stays local, you are responsible for protecting the file itself, including its storage location, access rights, backups and disposal, since it describes your security gaps. Treat the exported report as sensitive internal documentation. Confirm how the Excel workbook handles data on your own systems before you enter anything, because its handling is a separate question from the Windows application.

When should a practice hire a consultant or implementation partner?

Hire outside help when the tool cannot answer your questions or when you lack capacity to carry the work through. Common triggers include ePHI spread across cloud services and custom applications, unclear business associate relationships, a previous incident, or a finding you cannot fix internally. A consultant can perform or review the analysis, while an implementation partner can build the systems, logging, backups and documentation the risk management plan calls for. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and HHS does not recognize any HIPAA certification. Ask any provider for a written scope, deliverables and the roles each party keeps, and confirm that you still own the risk decisions.

What to do this week if an audit or contract requires proof

Start by confirming that the SRA Tool fits your organization before you spend time on it. The tool was developed by ONC with OCR and is aimed at small and medium-sized health care practices and business associates. If you are a large health system, a multi-state health plan or a vendor with complex cloud estates, the tool may still help with a first pass, but it will not by itself meet the risk analysis requirement for your environment. Decide this week which group you fall into, and write down the reason, because an auditor or counterparty will ask how you chose your method. Also note that OCR does not prescribe a methodology, so the choice has to be defensible for your size and complexity.

Next, pull together the ePHI inventory before you open the tool. The SRA Tool asks questions about systems, locations and safeguards, and answers are only as good as your knowledge of where electronic protected health information is created, received, stored and transmitted. List the applications, databases, endpoints, backup targets, email, portals and any business associate systems that touch ePHI. Choose the format at the same time: the current version, 3.7 as of its September 18, 2026 update, is offered as a 64-bit Windows application and as an Excel workbook with a user guide. Confirm which format your staff can run and where the completed file will be stored, since the Windows version keeps entered information on the user's computer. Assign one named owner, usually your security official, who is accountable for completing the assessment, approving answers and keeping the file current.

Finally, decide early whether an outside partner will help prepare systems and evidence. A partner can help you map ePHI, document existing safeguards, close gaps and assemble the records an assessor will request, but the organization still owns its risk analysis and the decisions in it. If an audit or contract requires proof, the final report or attestation must come from an independent assessor, since HHS does not certify compliance and the SRA Tool's disclaimer states that it is not a guarantee of compliance. Ask a prospective partner for a written scope that lists the deliverables, the evidence they will prepare and the items you must supply, and confirm with your counterparty which document they will accept as proof.

How DeployOpen prepares risk analysis evidence

DeployOpen is a Chainscore Labs company that plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure. For the HHS Security Risk Assessment (SRA) Tool, we help a practice prepare the systems, records and supporting evidence its own risk analysis depends on, while the organization keeps ownership of the analysis, its conclusions and its decisions.

How we scope

We agree a written, fixed scope listing which systems, locations and ePHI flows the risk analysis will cover.
We confirm which SRA Tool version and format the practice will use, and who on staff answers each question.
We record what the tool does not cover, such as legal review, so the practice knows which gaps it must fill itself.

How we build

We help assemble the inventory of systems and devices that the SRA Tool questions refer to.
We document current safeguards in each area the tool covers, so answers rest on configuration records rather than memory.
We test technical controls named in the answers, such as access settings and backups, and record the results as evidence.

How we hand over

We deliver the completed working files, configuration records and test results in formats the practice can keep and retain.
We provide a written summary of open items, with owners the practice must assign for each one.
We transfer ownership of all documents so the practice's security official can maintain them without us.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial engagement ends.
We can help update the analysis when systems change, but the organization decides when an update is required.
Confirm with us in the written scope whether an independent HIPAA assessor will review the work before you rely on it.

Using the HHS Security Risk Assessment (SRA) Tool