HIPAA Security Risk Analysis Requirements for Independent Practices
A HIPAA Security Risk Analysis is required of every practice that creates, receives, maintains, or transmits electronic protected health information, and its absence is the single most common finding in HHS Office for Civil Rights enforcement actions against small practices. OCR launched a dedicated Risk Analysis Enforcement Initiative in October 2024 specifically because so many covered entities either never performed one or performed one once and never updated it. Settlements under that initiative against practices with fewer than 10 providers have run in the $25,000 to $100,000 range plus a two-year or three-year corrective action plan, and the corrective action plan is usually the more expensive half.
HIPAA compliance requirements vary based on your covered entity type and business associate relationships. Consult your HIPAA compliance officer or a healthcare attorney before implementing privacy practices.
Credentialing and enrollment requirements vary by payer and change frequently. Verify current requirements directly with each payer.
The Short Answer
A Security Risk Analysis is a documented, practice-wide assessment of every place ePHI lives and every threat to it, required under 45 CFR 164.308(a)(1)(ii)(A). It is not a checklist, not a vendor certificate, and not a one-time project: it must be reviewed and updated whenever the practice changes systems, vendors, locations, or staffing, and at minimum annually.
What the Regulation Actually Requires
The Security Rule language is short and frequently misread. 45 CFR 164.308(a)(1)(ii)(A) requires 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." Three words in that sentence carry the enforcement weight.
Accurate means the analysis reflects the systems you actually run, not a template's assumptions. An SRA that lists a server room when the practice is fully cloud-hosted is inaccurate on its face and OCR treats it as evidence the assessment was never really performed.
Thorough means every system, device, and vendor holding ePHI is in scope. The systems small practices most often omit are the ones not purchased as clinical software: the scheduling text-reminder service, the answering service, the billing company's portal, staff personal phones with the EHR app installed, the copier's internal hard drive, and cloud backups.
Held by the covered entity includes ePHI held on your behalf by business associates. A signed Business Associate Agreement transfers some liability but does not remove the vendor's systems from your risk analysis scope.
Risk Analysis Is Not Risk Management
The Security Rule creates two separate obligations that practices routinely collapse into one. 164.308(a)(1)(ii)(A) requires the analysis, which identifies and rates risk. 164.308(a)(1)(ii)(B) requires risk management, which is the documented decision about what you did with each identified risk. A practice that runs an assessment, files the report, and takes no documented action has satisfied neither requirement, because the analysis obligation is judged partly by whether it fed a management decision.
Addressable Does Not Mean Optional
Security Rule implementation specifications are labeled either "required" or "addressable." Addressable means you must implement the specification, or document why it is not reasonable and appropriate for your practice and implement an equivalent alternative. Encryption of data at rest is the specification most often misread as optional. Choosing not to encrypt laptops is defensible only if the reasoning is written down and an alternative control is in place. Note that HHS published a Security Rule notice of proposed rulemaking on January 6, 2025 that would remove the addressable category entirely and make most specifications mandatory; that proposal was not final as of this writing, so the current addressable framework still governs, but practices building a program now should not architect around the flexibility surviving.
What the Analysis Has to Cover
An SRA that will survive an OCR document request has six components. The table below maps each to who typically performs it in an independent practice, since the answer is rarely one vendor.
| Component | What It Must Show | Who Usually Owns It |
|---|---|---|
| ePHI inventory | Every system, device, and vendor that touches ePHI, with data flow between them | Practice administrator with EHR vendor input |
| Threat and vulnerability identification | Realistic threats per asset: ransomware, insider access, lost device, vendor breach | Security assessor or managed IT provider |
| Current security measures | Controls actually in place today, not those planned or assumed | Managed IT provider |
| Likelihood and impact rating | Each risk scored on both axes, producing a ranked list | Security assessor |
| Risk level determination | Documented risk level per finding, with rationale | Security assessor with practice sign-off |
| Documentation and review date | Dated report, named participants, and the next scheduled review | Practice compliance officer |
The ePHI inventory is where most assessments fail before they start. A practice cannot analyze risk to systems it has not enumerated, and OCR's first document request in an investigation is typically the inventory, not the risk report.
Implementation: What Practices Actually Do
The practical sequence for a solo or small group practice performing its first defensible SRA:
- Build the ePHI inventory first: list every system before assessing any of them. Walk the actual workflow from appointment booking through claim submission and name every place data stops. Expect to find three to six systems nobody counted as clinical.
- Reconcile the inventory against your BAA list: every vendor in the inventory needs a signed BAA, and every BAA on file should map to a vendor in the inventory. Gaps in either direction are findings. Practices commonly discover BAAs signed with vendors they stopped using years ago, and active vendors with no BAA at all.
- Decide who performs the assessment: the Security Rule does not require an outside assessor. A practice may self-assess using the HHS and ONC Security Risk Assessment Tool, which is free and produces a dated report. Outside assessors typically quote in the low four figures for a small practice. Self-assessment is defensible when the practice has in-house technical familiarity with its own systems; it is not defensible as a way to avoid finding problems.
- Rate each risk on likelihood and impact separately: a single combined severity score is the most common methodological weakness. OCR guidance expects both axes documented.
- Write the risk management plan the same week: for each risk above your acceptance threshold, record the decision, the owner, and the target date. For risks you accept, record why. This is the 164.308(a)(1)(ii)(B) obligation and it is what converts a report into a program.
- Calendar the review before you close the project: set the next review date and the trigger events that would force an earlier one. A practice that reviews the analysis annually and after each material change is meeting the standard.
Practices building this alongside a broader compliance program will find the control-by-control walkthrough in the HIPAA compliance checklist a useful cross-reference, since the checklist covers the Privacy Rule obligations that sit beside the Security Rule work described here.
What Goes Wrong
- Buying a certificate instead of an analysis: vendors selling "HIPAA certification" produce attestations that carry no regulatory weight. HHS does not certify anyone. An attestation is not a risk analysis and will not satisfy a document request.
- Scoping to the EHR only: an analysis covering the EHR and nothing else omits the billing portal, the reminder service, and staff mobile devices. Partial scope is treated as no analysis for the systems left out, which is where breaches typically originate.
- Confusing the EHR vendor's compliance with yours: a HITRUST-certified or SOC 2-audited EHR reduces risk in the vendor's environment. It says nothing about your workstations, your access controls, or your staff. The obligation is on the covered entity and is not delegable.
- Performing it once: a 2019 analysis produced during EHR implementation and never revisited is worse than none, because it documents that the practice knew the obligation existed and then stopped. Willful neglect carries the highest civil monetary penalty tier under the HITECH tier structure.
- No documented remediation: an analysis identifying twelve risks with no corresponding management decisions is an admission of known, unaddressed vulnerabilities.
What Should You Do?
If your practice has never performed a Security Risk Analysis, or performed one more than twelve months ago, that is the highest-value compliance work available to you right now, ahead of policy templates and staff training refreshers. Start with the ePHI inventory, because it is the component you cannot outsource and the one that determines whether everything after it is accurate. The free HHS and ONC Security Risk Assessment Tool is adequate for a defensible first-pass self-assessment at a solo or small group practice; the cost of an outside assessor is worth it primarily when the practice lacks technical familiarity with its own systems or wants third-party documentation ahead of a known audit exposure. Whichever path you take, the risk management decisions matter as much as the analysis, and both need dates and names on them. Practices ready to formalize the surrounding program can work through the HIPAA compliance self-assessment next.
Get the full practice management guide at GetPracticeHelp -- with billing benchmarks, credentialing checklists, and revenue cycle best practices.
Frequently Asked Questions
- How often does a HIPAA Security Risk Analysis need to be updated?
- At minimum annually, and additionally whenever the practice changes EHR or practice management systems, adds or drops a vendor that touches ePHI, opens or closes a location, experiences a security incident, or makes a material change to how staff access records. There is no fixed calendar interval in the regulation itself; the standard is that the analysis must remain accurate, which in practice means an annual review plus event-driven updates.
- Can a practice perform its own Security Risk Analysis, or is an outside assessor required?
- The Security Rule does not require an outside assessor. A practice may self-assess, and HHS and ONC publish a free Security Risk Assessment Tool designed for small practices that produces a dated, documented report. Outside assessors typically quote in the low four figures for a solo or small group practice. The choice should turn on whether the practice has in-house technical familiarity with its own systems, not on cost alone.
- Does a HIPAA-compliant EHR mean the practice does not need its own analysis?
- No. A vendor's certifications apply to the vendor's environment. The risk analysis obligation under 45 CFR 164.308(a)(1)(ii)(A) sits with the covered entity and covers the practice's own workstations, mobile devices, network, access controls, staff behavior, and every other vendor in the environment. It cannot be delegated to a software vendor.
- What is the difference between a Security Risk Analysis and a HIPAA compliance checklist?
- A checklist confirms whether specific policies and safeguards exist. A risk analysis identifies what could go wrong across the practice's actual systems, rates each risk on likelihood and impact, and feeds a documented risk management decision. A completed checklist does not satisfy 164.308(a)(1)(ii)(A); the analysis is the specific artifact OCR requests.
- What happens if OCR requests the analysis and the practice does not have one?
- Absence of a risk analysis is typically treated as a compliance failure in its own right rather than a technical oversight, and it is the most frequently cited finding in enforcement actions against small practices. Resolution agreements combine a monetary settlement with a corrective action plan running two to three years, under which the practice performs the analysis, submits it to OCR for review, and reports on remediation on a fixed schedule. The corrective action plan is usually the larger long-term cost.