HIPAA for the Clinician, Part 2 The Security Risk Analysis You’re Probably Not Doing Correctly
Introduction
The questionnaire arrives in your inbox from your EHR vendor. It’s labeled something like “Annual HIPAA Security Assessment” or “Compliance Review Checklist.” You spend twenty minutes clicking through it. Yes, you have antivirus software. Yes, you use passwords. Yes, you have a firewall. You submit it, receive a completion confirmation, and file it somewhere you’ll never find it again.
You have not completed a Security Risk Analysis. You’ve completed a vendor satisfaction survey dressed up in compliance language. The distinction is the difference between a documented, defensible compliance posture and a piece of paper that will make your situation worse, not better, when OCR comes asking.
The Security Risk Analysis is the single most frequently cited deficiency in OCR HIPAA investigations. It’s been that way for years, consistently, across practices of every size and specialty. That pattern is not an accident. It reflects a systemic misunderstanding of what the SRA requires, compounded by a market full of vendors selling watered-down substitutes to covered entities who don’t know what they’re buying.
This piece is about what the SRA requires. Not the checkbox version. The real one.
What the Law Requires
The Security Risk Analysis requirement lives at 45 CFR 164.308(a)(1)(ii)(A), under the administrative safeguards section of the HIPAA Security Rule. The regulatory text requires covered entities to “[c]onduct 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.”
Four words in that sentence carry most of the weight: accurate, thorough, risks, and vulnerabilities.
“Accurate” means the assessment reflects your actual environment, not a generic template someone downloaded from the Interwebs. “Thorough” means it covers the full scope of ePHI in your organization, which is broader than most practices realize. “Risks” means you’ve identified the realistic threat scenarios that could compromise your ePHI. “Vulnerabilities” means you’ve evaluated the specific weaknesses in your systems, processes, and physical environment that those threats could exploit.
OCR has published guidance clarifying that a compliant SRA must address nine specific elements:
- The scope of the analysis covering all ePHI regardless of format or location.
- Data collection on where ePHI is stored and transmitted.
- Identification of threats to ePHI and identification of vulnerabilities.
- An assessment of current security measures.
- Determination of the likelihood that each threat will occur.
- Determination of the potential impact of each threat.
- A risk rating or prioritization of identified risks.
- Documentation of findings and corrective actions.
- Periodic reviews and updates to the SRA.
If the assessment you’ve been running doesn’t address all nine of those elements with specificity to your organization, it doesn’t qualify.
The Scope Problem
The most common SRA failure isn’t the methodology. It is the scope. Practices consistently underestimate the number of systems and workflows that touch ePHI, and the SRA only covers what’s in scope. What’s left out creates unexamined risk and, in an OCR investigation, undefended exposure.
ePHI lives in more places than your EHR. It’s in the emails your providers send to referring physicians. It’s in the voicemails on your answering service. It’s in the appointment reminders your scheduling software sends via text. It’s in the spreadsheet your billing coordinator built to track claim denials. It’s on the personal device your office manager uses to check the practice portal from home. It’s in the cloud backup your IT contractor set up three years ago that nobody has audited since.
Your SRA has to cover all of it. Not just the systems your IT vendor manages. Not just the systems covered by your signed BAAs. All of it. Every asset that creates, receives, maintains, or transmits ePHI is in scope under 45 CFR 164.308(a)(1)(ii)(A), and the assessment that ignores half your environment is worse than useless. It creates a false record of due diligence that an OCR investigator will take apart line by line.
The Threat and Vulnerability Assessment
Once you’ve mapped your ePHI environment accurately, the SRA requires you to identify the threats to that environment and the vulnerabilities those threats could exploit. This is where most “checkbox” assessments completely break down.
A threat is any reasonably anticipated circumstance that could compromise ePHI. The category includes malicious actors (ransomware, phishing, insider threats, unauthorized access), environmental hazards (natural disasters, power failures, hardware failures), and human error (accidental disclosure, misconfiguration, improper disposal). Your threat assessment needs to reflect the realistic threat landscape for a healthcare organization of your size and type, not a generic list of possibilities someone copied from an NIST framework overview.
A vulnerability is a weakness in your systems, processes, or environment that a threat could exploit. Examples include:
- Un-patched software
- Shared login credentials
- Insufficient workforce training
- An unlocked workstation in a waiting area
- A lack of a formal termination process for departing employees
The SRA’s role is to identify these specific vulnerabilities for your organization, focusing on real issues rather than generic assumptions.
The relationship between threats and vulnerabilities drives your risk ratings. A high-likelihood threat combined with a significant vulnerability and a high-impact potential ePHI asset produces a high-risk finding that requires documented corrective action under 45 CFR 164.308(a)(1)(ii)(B). That risk management obligation is where the SRA connects to your ongoing compliance program. The SRA isn’t a standalone exercise. It’s the foundation for everything that follows.
Why “Addressable” Doesn’t Mean Optional
The Security Rule distinguishes between implementation specifications that are required and those that are addressable. Required specifications must be implemented. Full stop. Addressable specifications must be implemented, or the covered entity must document why an equivalent alternative measure was adopted instead and implement that alternative.
That second path is narrower than it sounds. It’s not permission to skip inconvenient controls. It’s a documented business decision with a documented rationale and a documented alternative. If your SRA has identified a vulnerability that an addressable specification would address, and your response is to note that you’ve decided not to implement it, you need to document why that decision is reasonable for your organization and what you’re doing instead to manage the risk. Vague rationale doesn’t survive scrutiny. “Not applicable” with no explanation doesn’t survive scrutiny at all.
OCR has been explicit on this point across multiple guidance documents, and enforcement actions have cited inadequate response to addressable specifications as a contributing factor. If your SRA process doesn’t include a systematic review of implementation specifications, it’s incomplete.
The Documentation Requirement
The SRA is not just an assessment. It’s a document. Under 45 CFR 164.316(b)(1), covered entities are required to maintain written policies, procedures, and documentation of required activities, including the SRA. The documentation must include the findings of the analysis and any actions taken to address identified risks.
In practice, this means the SRA needs to exist as a written record that demonstrates the methodology used, the scope covered, the threats and vulnerabilities identified, the risk ratings assigned, and the corrective actions planned or completed. If it lives only in someone’s head or in a series of informal conversations with your IT contractor, it doesn’t exist for compliance purposes.
This also means the SRA is a living document, not a one-time project. Your risk environment changes as your organization changes. New systems, new workflows, new staff, new vendors, new threat actors. The Security Rule requires covered entities to update their risk analysis in response to environmental or operational changes under 45 CFR 164.308(a)(8). Annual review is the practical minimum, and mid-cycle updates are appropriate whenever significant changes occur.
A compliant SRA is a documented, organization-specific assessment that an outside reviewer can pick up, read, and conclude: this practice accurately identified its ePHI environment, assessed realistic threats and vulnerabilities with appropriate specificity, assigned defensible risk ratings, and established a documented plan to address the highest-priority findings.
It covers every system that touches ePHI, not just the EHR. It identifies threats that are credible for a healthcare organization of your size and type. It evaluates the vulnerabilities you actually have, documented with sufficient specificity so that corrective action can be assigned and tracked. And it connects to a risk management plan with assigned ownership and timelines.
If your current SRA doesn’t meet that description, you have a gap that an OCR investigation will find. The good news is that it’s a fixable gap. The SRA is documentation work, not infrastructure work. You don’t need to rebuild your systems to get compliant. You need to conduct the analysis, document it properly, and implement the risk management plan that follows.
The practices that end up in enforcement proceedings aren’t usually the ones with the worst security. They’re often the ones with the thinnest documentation. Don’t let that be you.
Recent Articles – Will Evertsen 
GlobalRPh Articles
Integrative Perspectives on Cognition, Emotion, and Digital Behavior
