Every Arizona medical practice that creates, stores, or transmits electronic protected health information (ePHI) is legally required to run a HIPAA Security Risk Assessment — and to keep running one. Many practices assume their IT vendor already handles this because IT and security sound like the same job. They are not, and the gap between "we manage your network" and "we can produce a defensible risk analysis" is exactly where practices get exposed during an audit. Before hiring or renewing a managed IT services agreement, it’s worth knowing precisely what a HIPAA Security Risk Assessment is required to cover, so you can evaluate whether the vendor in front of you actually does it.
The Legal Requirement, in Plain Terms
The obligation to conduct a risk analysis isn’t a best practice recommendation — it’s written into the HIPAA Security Rule at 45 CFR § 164.308(a)(1)(ii)(A), enforced by the U.S. Department of Health and Human Services Office for Civil Rights (OCR). Every covered entity, which includes essentially every clinic, physician practice, and healthcare provider handling ePHI, must identify potential risks and vulnerabilities to the confidentiality, integrity, and availability of that data. The rule doesn’t specify a rigid template, which is part of why so many "assessments" sold to practices are thin. It does specify the outcome: a documented, defensible analysis a practice can produce if OCR ever asks for one.
What the Assessment Must Actually Cover
A risk analysis that would hold up under OCR scrutiny examines three categories of safeguards, not just the network firewall:
- Administrative safeguards — security management processes, workforce training, sanction policies, and who inside the practice is formally assigned security responsibility.
- Physical safeguards — how devices, workstations, and facilities that touch ePHI are protected from unauthorized physical access, theft, or environmental damage.
- Technical safeguards — the actual technology controls: access controls, encryption, audit logging, and how systems that store or transmit ePHI are configured and monitored.
Beyond identifying the systems and devices where ePHI lives, a complete assessment documents the threats and vulnerabilities specific to that environment, rates the likelihood and potential impact of each one, and produces a remediation plan with named owners and target dates. A PDF that lists generic cybersecurity tips is not a risk analysis. A spreadsheet that maps your specific EHR, billing system, fax server, and remote-access tools to specific, rated risks — and tracks remediation to completion — is.
How Often It Has to Happen
The Security Rule doesn’t set a fixed calendar interval, but OCR guidance and industry practice converge on conducting a comprehensive risk analysis at least annually, plus whenever there’s a significant change to the practice’s technology, staffing, or operations — a new EHR migration, a new remote-work arrangement, or a new billing vendor integration, for example. This is one of the most consequential differences between a good IT vendor and a healthcare-focused MSP: a general IT shop treats the assessment as a one-time deliverable at onboarding, while a healthcare-focused vendor treats it as a recurring, dated artifact that survives staff turnover and stays current as the practice’s systems change. OCR has repeatedly cited a missing or stale risk analysis as one of the most common findings in HIPAA enforcement actions — not a missing firewall, but a missing document.
A Checklist for Evaluating an MSP’s Risk Assessment Offering
| What to Ask | What a Healthcare-Focused Answer Sounds Like |
|---|---|
| Does the assessment cover administrative and physical safeguards, or only technical? | All three categories, documented separately, with named owners for remediation items. |
| How is likelihood and impact rated? | A defined methodology applied consistently across every identified risk, not a subjective gut check. |
| What happens after the assessment is delivered? | A remediation plan with target dates, tracked to closure — not a report that sits in an inbox. |
| How often is it refreshed? | At minimum annually, plus after any material change to systems or staffing. |
| Can they produce the documentation on request during an audit? | Yes, immediately, with a version history. |
Why This Belongs in the Vendor Conversation, Not After It
A risk assessment is only useful if the practice can act on it, and acting on it usually requires the same vendor that found the gaps to also close them — which is the actual argument for bundling security risk assessment work with ongoing managed IT support rather than buying them separately. A generic risk assessment consultant can hand a practice a list of findings and walk away; a healthcare-focused MSP that also manages the network, the endpoints, and the access controls day to day is positioned to remediate what the assessment surfaces without a second procurement cycle. That continuity — assessment, remediation, and ongoing management under one relationship — is the practical reason healthcare organizations increasingly look for MSPs that specialize in the vertical rather than general-purpose IT shops.
Conclusion
A HIPAA Security Risk Assessment isn’t a formality to check off during vendor onboarding — it’s a specific, legally required analysis of administrative, physical, and technical safeguards, refreshed at least annually, that a practice must be able to produce on demand. When evaluating a managed IT vendor for a clinic, ask to see how they actually structure and document this work before assuming it’s covered. A vendor that can walk through their methodology in specific terms, rather than gesturing at "security services," is the one equipped to keep a practice defensible.