HHS says risk analysis is a required implementation specification under the Security Rule. HHS also says there is no single required methodology for doing it.
That is why the SRA Tool exists.
HealthIT.gov says the desktop application walks users through the security risk assessment process with multiple-choice questions, threat and vulnerability assessments, and asset and vendor management. The workbook version uses the same content and scoring approach for teams that need more flexibility than the Windows application.
But the same page also says the tool is provided for informational purposes only, is not required, and does not guarantee compliance with federal, state, or local laws.
That disclaimer matters. A completed workbook is not the same thing as a defensible HIPAA program.
What the HIPAA risk analysis actually has to cover
HHS's risk-analysis guidance is the key anchor here.
The scope is not just your EHR. HHS says the analysis has to consider potential risks and vulnerabilities to the confidentiality, integrity, and availability of all ePHI the organization creates, receives, maintains, or transmits.
That means your scope usually includes:
- The EHR or practice management platform
- Microsoft 365 or Google Workspace mailboxes
- File shares and scanned documents
- Cloud backup
- Local endpoints and laptops
- Remote access tools
- Vendors or consultants who create, receive, maintain, or transmit ePHI
This is where many teams use the tool too narrowly. They answer for the server room they remember, not the actual environment they run.
As of May 28, 2026, the HealthIT.gov page lists SRA Tool version 3.6.1.
The current tool stack gives you three things that matter in practice:
1. A structured question path
The tool breaks the work into sections rather than forcing you to invent a methodology from scratch. That lowers the chance that a small practice skips entire safeguard families.
2. Local-only data handling
HealthIT.gov says all information entered into the desktop tool is stored locally on the user's computer and HHS does not collect, view, store, or transmit it. For a healthcare practice, that makes adoption easier because you are not pushing your self-assessment data into a government portal.
3. A usable workbook option
The Excel Workbook version is not an afterthought. HealthIT.gov says it contains the same content and formulas in a spreadsheet format, which is useful when the owner, office manager, outside IT, and compliance lead need to review findings together.
The current 3.6.x release line also includes review-and-approval tracking, updated report content, and risk-scale language aligned to NIST's "moderate" terminology (introduced in version 3.6, with 3.6.1 a maintenance update).
The wrong way is to open it alone on a Friday afternoon and click through from memory.
The right way is to use it as a working session tool.
Step 1: build the ePHI map first
Before answering questions, list every system, device, location, workflow, and vendor touching ePHI. HHS's guidance specifically tells organizations to identify ePHI they create, receive, maintain, or transmit, including external sources such as vendors and consultants.
If the map is thin, the assessment will be thin.
Step 2: involve the people who actually run the environment
That usually means some combination of:
- Practice owner or administrator
- IT provider
- EHR or practice management owner
- Office manager
- Compliance or privacy lead
The tool is easy to misuse when one person guesses at everyone else's systems.
Step 3: answer based on what is implemented now
If MFA is purchased but not enforced, it is not done. If backup exists but nobody has tested a restore, the risk is still there. If a vendor says they are HIPAA-ready but no one has confirmed the contract and the access path, that is not closure.
This is where the tool becomes useful. It highlights gaps. It does not close them for you.
Step 5: keep the output with the rest of your evidence
The assessment belongs beside your asset inventory, vendor list, policies, training records, incident log, and remediation tracker. A tool file by itself is not a compliance file.
For a small or medium-sized practice, it is genuinely useful for:
- Getting a first pass on scope
- Forcing discussion of overlooked safeguards
- Documenting repeatable questions from one year to the next
- Making risk discussions less vague
- Giving a business associate or practice owner a workable starting structure
This is why HHS's own risk-analysis guidance still points readers to the tool as useful for small and medium-sized practices and business associates.
This is where people get themselves in trouble.
The tool is not enough when the issue is not "how do I organize the questions?" but "how do I untangle the environment?"
Multi-location or multi-entity environments
If you have multiple clinics, a parent entity, or shared systems across locations, scoping becomes architectural, not clerical.
Email and cloud identity are part of the real risk
Most modern healthcare compromise starts with identity, mailboxes, and remote access. The tool will ask about safeguards, but it does not independently verify whether your Microsoft 365 or Google Workspace tenant is actually hardened.
Vendors are numerous or poorly documented
The moment you have a practice management vendor, cloud backup, imaging platform, outsourced billing, IT support, secure messaging, and a handful of smaller apps, vendor risk becomes a project of its own.
An incident already happened
If you are doing the assessment after a phishing event, ransomware scare, or mailbox compromise, you do not just need a questionnaire. You need an honest remediation plan and evidence trail.
You need evidence that will survive scrutiny
The hardest part is not producing an SRA file. The hardest part is showing that the answers match reality.
That is one reason the larger HIPAA operations article for dental practices, HIPAA cybersecurity for dental practices: what the Security Rule actually requires, spends so much time on the difference between paperwork and actual control state.
When I would tell a practice to get help
Get outside help if any of these are true:
- You are unsure what is actually in scope
- You rely on several vendors and do not have a clean vendor inventory
- Your email tenant handles ePHI and nobody can explain current identity controls
- Laptops, home devices, or remote work are involved
- You cannot tell whether backups are tested and recoverable
- You are preparing for an OCR inquiry, payer scrutiny, or acquisition diligence
- The assessment is exposing gaps you know your team cannot close alone
The trigger is not size alone. The trigger is complexity plus consequences.
What "get help" should actually mean
It should not mean buying a binder.
It should mean getting help with:
- Scoping the real ePHI environment
- Validating the answers against the actual systems
- Prioritizing remediation
- Improving identity, endpoint, and backup controls
- Documenting the changes so next year's assessment starts from fact, not memory
For many practices, the most urgent control gaps are the same ones that show up in other evidence-heavy environments: MFA coverage, monitored endpoints, backup testing, vendor access, and role clarity. That overlap is why pages like what controls do cyber insurers require in 2026 often feel familiar even outside insurance.
A practical way to split the work
Here is the split I usually recommend.
- You are a genuinely small, simple environment
- You know your systems and vendors
- You mainly need structure and documentation
- You can act on the findings quickly
Bring in help when:
- The answers are uncertain
- The environment is messy
- Ownership is split between the practice and third parties
- The remediation backlog is real
- You need the assessment to stand up to outside review
Where Obsidian Ridge fits
We do not act as your lawyer or your HIPAA Privacy Officer.
Where we fit is the technical safeguard side after or alongside the assessment: hardening Microsoft 365 identity, improving endpoint coverage, getting visibility into suspicious account activity, and turning backup and incident-response claims into evidence. That usually means some combination of managed ITDR, managed detection and response, and support building a cleaner operational baseline before the next annual review.
If you are in dental specifically, start with the bigger compliance picture in HIPAA cybersecurity for dental practices.
FAQ
No. HHS says it is informational, not mandatory, and it does not guarantee compliance.
No. HealthIT.gov says the desktop application stores information locally on the user's computer and HHS does not collect, view, store, or transmit that data.
Yes. HealthIT.gov offers an Excel Workbook version for users who need more flexibility than the Windows desktop application.
No. It helps you perform one, but the actual requirement is the risk analysis itself and the remediation work that follows.
When should I stop self-serving this and bring in help?
Bring in help when scope is unclear, vendors are numerous, cloud identity and email are in play, an incident already happened, or you need evidence that your answers are real and your gaps are being closed.
What does a HIPAA risk assessment cover for a dental practice?
It covers every system that creates, receives, maintains, or transmits ePHI — the practice-management and imaging platform, Microsoft 365 or Google Workspace email, file shares and scanned charts, cloud backup, operatory workstations and laptops, remote access, and any vendor that touches patient data. Scoping to only the server room is the most common mistake. For the full dental picture, see HIPAA cybersecurity for dental practices.