// HIPAA compliance · 9 min read

HIPAA security risk assessment: a practical guide for medical practices

What the HIPAA security risk assessment requires, who must complete it, how often, and how technical testing turns it into a defensible record instead of a checklist.

Physician reviewing a glowing security risk assessment dashboard in a clinic

Every medical practice that handles electronic protected health information must complete a security risk assessment—and keep it current. It is one of the most commonly cited gaps in HIPAA enforcement actions, usually not because a practice ignored it, but because the assessment was treated as a questionnaire rather than an evidence-backed analysis of real risk.

What a HIPAA security risk assessment actually is

The HIPAA Security Rule (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 ePHI. In practice that means identifying every system that creates, receives, maintains, or transmits patient data, documenting the threats to each, judging the likelihood and impact of those threats, and recording the safeguards in place. A generic template with yes/no answers does not meet the standard on its own.

Who must complete one, and how often

Covered entities—medical practices, dental offices, surgery centers, hospitals—and their business associates are all responsible. There is no fixed calendar in the rule, but the expectation is that the assessment stays current: reviewed at least annually, and updated whenever something material changes. A new EHR, a cloud migration, a patient portal, a merged practice, a new billing vendor, or a security incident all trigger a fresh look.

The steps of a defensible assessment

Start with a data inventory: where ePHI lives, who touches it, and which vendors connect to it. Then identify threats and vulnerabilities for each asset, assess current safeguards, rate risk by likelihood and impact, and document a corrective action plan with owners and dates. Finally, record the evidence behind each conclusion. The written record is what regulators review—an assessment you cannot show is an assessment you did not do.

Where technical testing fits

Risk ratings are only as good as the evidence behind them. Penetration testing and cybersecurity analysis replace assumptions with proof: whether an attacker can actually reach patient records, whether staff accounts can be taken over, whether an EHR integration leaks data across practices. Findings feed straight into the risk analysis with real exploitability ratings, and retesting after remediation produces the closure evidence that auditors look for.

Common gaps we see in practices

The recurring ones: vendor and integration connections left out of scope entirely, an assessment covering the main clinic but not a satellite location, risk ratings with no supporting technical evidence, corrective action plans with no owner or date, and an assessment last updated before a major system change. Each of these is easy to fix once it is visible—and each is the kind of thing an auditor finds quickly.

Turning the assessment into a security program

The goal is not a document. It is a prioritized, owned list of corrections that reduces the chance of a breach affecting your patients—reviewed on a schedule, updated after every significant change, and backed by testing that shows the safeguards work. That is what makes the record defensible, and it is what actually protects the practice.