What a HIPAA Security Risk Analysis Actually Requires (And Why Most Small Practices Have Never Done One)

When OCR investigates a small practice after a breach, one of the first things it asks for is documentation of the practice's Security Risk Analysis. Not a summary of security measures the practice believes are in place. Not a list of software installed. The actual documented risk analysis — the formal assessment of threats, vulnerabilities, and risks to electronic protected health information (ePHI) that the HIPAA Security Rule has required since 2005.

Most small practices do not have one. They know they are supposed to comply with HIPAA. They signed something when they installed the EHR. They may have even sat through a Privacy Rule training. But the Security Risk Analysis — the foundational document the Security Rule is built around — has either never been done, was done once years ago and never revisited, or was completed by a third party who called it an SRA but produced something that would not satisfy OCR.

Understanding what the requirement actually is, and what it is not, is the first step.

What the Security Rule Requires

The HIPAA Security Rule at 45 CFR §164.308(a)(1)(ii)(A) requires covered entities to "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."

That is the full text of the requirement. There is no prescribed format. There is no minimum length. There is no required vendor or tool. What OCR has made clear through guidance and enforcement is that a compliant SRA must:

• Identify the scope of ePHI in the organization — where it is created, received, maintained, and transmitted
• Identify threats to that ePHI — natural, environmental, and human threats
• Identify vulnerabilities — security weaknesses that could be exploited
• Assess the likelihood and impact of each threat/vulnerability combination
• Document current security measures and evaluate their effectiveness
• Identify the level of residual risk remaining after controls are applied

An SRA that stops at "we use antivirus software and the EHR has a login screen" would not satisfy this framework. OCR evaluates whether the practice actually assessed its specific environment, not whether it installed broadly accepted security tools. [verify: cite OCR SRA guidance from https://www.hhs.gov/hipaa/for-professionals/security/guidance/index.html]

The Size Exemption That Does Not Exist

A persistent belief among small practices is that HIPAA's requirements scale with practice size — that a solo physician or three-provider dental office faces a lower standard than a hospital. This belief is wrong.

The Security Rule applies to every covered entity. A solo physician with one front desk employee who sees 200 patients per year is subject to the same Security Risk Analysis requirement as an academic medical center. The rule does permit that the Security Rule's "addressable" implementation specifications can be met with equivalent alternatives when a standard implementation is not reasonable for the entity's size — but the SRA itself is a required specification, not an addressable one. There is no threshold below which the requirement does not apply. [verify: cite 45 CFR §164.306(b) scalability language from https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html]

What "One-Time" Does Not Mean

Even practices that have completed an SRA often treat it as a one-time project. The regulation requires ongoing review: 45 CFR §164.308(a)(1)(ii)(B) requires covered entities to "implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level" and to review and modify security measures as needed.

OCR's guidance has clarified that the SRA must be reviewed and updated when significant changes occur — when the practice moves to a new EHR, adds a location, changes IT vendors, adds remote work capabilities, or experiences a security incident. [verify: cite frequency guidance from https://www.hhs.gov/hipaa/for-professionals/security/index.html] A practice that completed an SRA in 2018 and has since changed its EHR, added telehealth, and had staff turnover has an SRA that does not reflect its current risk environment — even if the original document was thorough.

What OCR Actually Finds

The Office for Civil Rights publishes enforcement actions, and the pattern in smaller covered entities is consistent. A breach occurs — a ransomware attack, a stolen laptop, an unauthorized access by a former employee — OCR opens an investigation, and the investigation reveals one or more of the following: no documented SRA, an SRA that was completed by the EHR implementation vendor and never maintained, or an SRA that identified risks and then documented no action taken to address them. [verify: cite specific enforcement actions or settlement summaries from https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/agreements/index.html]

The SRA is not what OCR is investigating when it opens a breach inquiry. But the absence of a documented SRA is typically what expands the inquiry from a review of the breach to a broader investigation of the practice's Security Rule compliance program.

What a Useful SRA Looks Like for a Small Practice

HHS's Office of the National Coordinator for Health Information Technology maintains a Security Risk Assessment Tool (SRA Tool) designed specifically for small and medium-sized healthcare providers. It walks through the assessment framework in plain language, does not require IT expertise to use, and produces documentation that can be preserved as evidence of the review. [verify: cite tool availability and URL from https://www.healthit.gov/topic/privacy-security-and-hipaa/security-risk-assessment-tool]

A useful SRA for a small practice identifies all the places ePHI lives: the EHR, email if used for clinical communication, personal devices used for remote access, backup systems, fax servers, any billing or scheduling systems that touch patient data. It then works through the realistic threats to each of those systems — not hypothetical nation-state attacks, but phishing emails, shared passwords, unencrypted laptops, and no offsite backup — and documents what is in place to address each.

It does not need to be long. A thorough SRA for a three-provider practice might be fifteen pages. What it needs to be is honest about what the practice actually does, not what it aspires to do.

The Starting Point

If your practice has not completed a Security Risk Analysis, or has not revisited one in the last twelve months, that is the highest-priority gap in your HIPAA Security Rule compliance program. Not because of the fine risk, though that is real — but because the SRA is the document that tells you where the actual gaps are. Every other Security Rule requirement flows from it.

The HIPAA Security Readiness Checklist includes the SRA requirement as item 1 and item 2, and gives you a plain-language description of what each means. If you want to talk through where your practice stands, the free security review call is a 30-minute conversation — no commitment required.