A HIPAA Security Risk Analysis on file at a clinic is one of two things. Either a defensible artifact — specific systems named, specific threats enumerated, specific controls mapped to specific evidence with specific owners — or a forty-page Word document downloaded from a vendor's resources page, with the clinic's name in the header and last year's date on the cover. The Office for Civil Rights sees both.
Their settlements over the last decade are unambiguous about which one keeps a clinic out of a Resolution Agreement. In Lifespan Health System Affiliated Covered Entity (2020, $1,040,000), the corrective action plan opened with: "conduct an accurate and thorough risk analysis of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of all of its ePHI." That language is verbatim from §164.308(a)(1)(ii)(A). It also appears, in nearly identical form, in the corrective action plans of dozens of other Resolution Agreements — Anthem ($16M), Premera ($6.85M), CHSPSC ($2.3M), Athens Orthopedic ($1.5M), and the smaller settlements that don't make the press cycle. The ask is always the same. The reason it's always the ask is that the SRAs OCR finds on file rarely do what the rule requires.
This piece is about what the rule actually requires, where the templates fail, and what a defensible scope looks like for a small clinic that does not have a CISO.
What §164.308(a)(1)(ii)(A) actually says
The text is short:
Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate.
Five terms do load-bearing work. Accurate. Thorough. Risks and vulnerabilities. Electronic protected health information. Held by.
Two of the five — accurate and thorough — are where templates die. A template can produce something that is neither, and OCR has explicitly said so. From the HHS guidance on risk analysis: "There is no single method or 'best practice' that guarantees compliance with the Security Rule. ... The output of a risk analysis is a documented assessment of risks." The word documented is doing more than it looks like. The output isn't a risk score on a page. The output is a body of evidence tying each risk to a system, a threat actor, a likelihood and impact judgment, and a chosen response.
The other three — risks and vulnerabilities, ePHI, held by — are where the scope decisions live, and where most templates start wrong.
Where the templates fail
Reading SRAs from clinics that have called for help, the same five failures show up.
1. The asset inventory is not an asset inventory.
Most templates have a section called Asset Inventory that lists categories — "workstations," "EHR," "email," "mobile devices." That is not an inventory. An inventory enumerates: model, owner, location, OS, encryption status, last patch date. An OCR investigator asking "show me the inventory underlying this SRA" is asking for the second thing. If the clinic produces the first thing, it has failed thorough.
The free HHS Security Risk Assessment Tool (SRA Tool, v3.5 as of 2026) does encourage device-level enumeration, and a clinic using it well will produce a defensible inventory. A clinic using a Word template downloaded from a vendor will not.
2. The threat list is generic.
Templates copy threat lists from NIST SP 800-30 Rev. 1 Appendix E and call it done. NIST 800-30 is a starting point, not an ending point. A cardiology practice has different threats than a behavioral-health group: the cardiology practice has a cardiac imaging vendor that ingests DICOM, the behavioral-health group has substance-use-disorder records subject to 42 CFR Part 2 in addition to HIPAA. The threat profile diverges immediately. A template threat list does not capture the divergence.
3. The likelihood and impact ratings are unjustified.
A defensible SRA shows its work: "Likelihood = Medium because we have MFA on email but not on the EHR; threat actors targeting our EHR vendor are documented in the IC3 2024 Annual Report, page 14." A template SRA writes "Likelihood = Medium" with no rationale. OCR investigators are explicit on this — see OCR Considerations for HIPAA Security Rule Risk Analysis (July 2024) — and it is the gap they cite most often.
4. The "controls in place" section is aspirational.
Templates have rows for every control in the Security Rule. A clinic fills them with what it intends to have. The audit field-test: pick three rows at random and ask the clinic to produce evidence — a screenshot, a config export, a signed policy. If two of the three fail, the SRA is fiction.
5. The remediation plan has no owner and no date.
"Implement encryption for all portable devices" is not a remediation item. "John Doe, Practice Administrator, will deploy BitLocker via Intune to the 17 clinic laptops by 2026-08-31; verification = Intune compliance report exported quarterly" is a remediation item. OCR Resolution Agreements consistently demand the second form. Templates produce the first.
A scope that survives an investigation
A defensible SRA for a small clinic — say, 8–25 staff, one EHR, one practice-management system, Microsoft 365 or Google Workspace, a few cloud point tools — has six artifacts behind it.
1. Device-level asset inventory with model, OS, owner, encryption status, MDM enrollment, and last patch date. A spreadsheet is fine. 200 rows for a 20-person clinic is realistic when phones, IoT (cameras, badge readers), and printers are included. 30 rows is suspicious.
2. Data flow diagram showing every place ePHI enters, rests, and leaves the practice. Patient intake → EHR → claims clearinghouse → payor. Patient → portal → EHR. Lab orders → Quest/LabCorp interface. The vendors named on the diagram are also the Business Associate Agreements that must be on file under §164.308(b)(1) — and a missing BAA is one of OCR's faster citations.
3. Threat enumeration tied to the data flow. For each system in the diagram, what are the realistic threat actors and what are their capabilities? A ransomware gang going after the EHR is different from a credential-stuffing bot going after the patient portal. Cite recent incidents at peer organizations — HHS Breach Portal entries in your specialty are a defensible source. The IC3 Annual Report and HC3 (HHS Health Sector Cybersecurity Coordination Center) bulletins are also appropriate.
4. Likelihood × impact rating per threat-asset pair, with rationale. A rating without rationale is a number. A rating with rationale is a judgment. OCR wants the second.
5. Controls mapped to evidence. For each control claimed, the evidence is named: the policy document with version, the technical config (e.g., "Conditional Access policy Require MFA for all users, Tenant ID 1234"), the screenshot, the report. If the control is "annual security awareness training," the evidence is "KnowBe4 completion report dated 2026-04-12 attached as Appendix C, 22/24 staff complete, 2 in remediation."
6. Remediation roadmap with owner and date. Every gap gets an owner, a date, and a verification mechanism. Quarterly reviews of the roadmap are themselves an evidence artifact.
These six artifacts compound. Year over year, an SRA built this way becomes shorter, not longer, because most of the work is already documented; what changes is the threat landscape, new vendors, and the remediation roadmap. A template SRA looks the same every year because nothing in it is real enough to change.
What changes in 2026
Three forces are pulling clinic SRAs toward the structured form whether the clinic wants it or not.
The first is the HIPAA Security Rule NPRM (89 FR 101638), published December 2024. Among other things, it proposes explicitly required asset inventories, network maps, technical safeguards encryption mandates, and 12-month risk analysis updates. The NPRM is not final; the comment period closed March 2025; the final rule is expected in calendar 2026. Even before finalization, OCR investigators cite the proposed text as the direction of travel, and the Resolution Agreements being signed today demand controls that match the NPRM.
The second is the cyber insurance market. Carriers renewing healthcare policies in 2026 are asking control questions that map directly onto a defensible SRA: device-level inventory, MFA coverage percentages, encryption-at-rest status, IR plan testing within the last 12 months. A template SRA cannot answer these without fiction. Carriers have started declining or non-renewing on the basis of fictional answers.
The third is AI-tooling adoption. Ambient documentation tools, AI scribes, and AI-assisted coding tools are entering clinics at speed, and each one is a new BAA, a new data flow, and a new threat surface that the prior year's SRA does not cover. A template SRA does not capture them. A structured SRA adds three rows and updates the diagram.
Standards mapping
- 45 CFR §164.308(a)(1)(ii)(A) — risk analysis requirement (the rule under review).
- 45 CFR §164.308(b)(1) — Business Associate Agreement requirement; missing BAAs are commonly cited alongside SRA findings.
- HHS OCR — Guidance on Risk Analysis Requirements under the HIPAA Security Rule (2010, reaffirmed in subsequent enforcement). Defines the elements of an "accurate and thorough" risk analysis.
- HHS Security Risk Assessment Tool (SRA Tool) v3.5 — free, regularly updated, the closest thing to an OCR-blessed reference implementation.
- NIST SP 800-30 Rev. 1 — Guide for Conducting Risk Assessments. Source of the threat / vulnerability / likelihood / impact framework HHS expects to see.
- NIST SP 800-66 Rev. 2 (Feb 2024) — Implementing the HIPAA Security Rule. Maps the Security Rule to NIST controls; section 5 on risk analysis is the most directly useful chapter for a clinic-scale program.
- HIPAA Security Rule NPRM, 89 FR 101638 (Dec 2024) — proposed amendments; signals direction of travel even before finalization.
Closing
The lesson is mechanical, not philosophical. An SRA that is accurate and thorough in OCR's sense is a body of evidence, not a document. The document is the index; the evidence is the work. Clinics that file the index without the evidence are filing fiction, and OCR's settlements over the last decade are an extended argument for why fiction does not survive an investigation.
Two things to do this quarter:
- Pull your last SRA and pick three rows in the controls in place section at random. Ask your IT contact to produce the underlying evidence. If two of the three cannot be produced, the SRA is the next thing on the remediation list, before any new control project.
- Reconcile your BAA list against your data flow diagram. Every vendor that touches ePHI must have a current BAA. The BAA list and the data flow diagram should reconcile. If they don't, the gap is OCR's first citation and the remediation is faster than any technical control.
If you want a second pair of eyes on what your last SRA does and doesn't actually say — or you'd rather have an SRA built as a body of evidence rather than a checklist — start with a consultation. For ongoing program ownership of this work, see vCISO services; for a one-time audit-ready SRA delivered as a fixed-bid engagement, see Compliance & Audit. The free HIPAA Compliance Checklist is the companion document that organizes §164.308/310/312 with the evidence requirements named.