What a HIPAA Security Risk Assessment Actually Covers

Most healthcare organizations have done something they’d call a HIPAA assessment. A checklist got filled out. A vendor sent over a questionnaire. Somebody in IT confirmed the firewall was on. That’s not nothing. But it isn’t a HIPAA Security Risk Assessment — and the gap between the two is exactly where OCR audits and breach investigations tend to land.

A real assessment is a specific, defined exercise with a specific legal basis. It has a required scope and produces required documentation. It’s also the one HIPAA obligation almost every enforcement action circles back to. If your organization is shopping for one — or trying to figure out whether the one you already have actually qualifies — here’s what should be in it.

Key Takeaways

• The requirement comes straight from the Security Rule: 45 CFR § 164.308(a)(1)(ii)(A) requires “an accurate and thorough assessment of the potential risks and vulnerabilities” to electronic protected health information (ePHI).
• A proper assessment covers three domains — administrative, physical, and technical safeguards — not just a network scan.
• The output isn’t a pass/fail grade. It’s a risk register, ranked findings, and a remediation plan you’re expected to act on.
• OCR doesn’t set a fixed calendar, but it does expect reassessment on a regular cycle and after any material change to your systems, staff, or vendors.
• No assessment “makes you HIPAA compliant.” Compliance is an ongoing posture; the assessment is how you find out where you actually stand.

The Requirement Behind the Assessment

The HIPAA Security Rule doesn’t ask covered entities and business associates to buy specific products or hit a checklist of technologies. It asks them to know their own risk. That requirement comes from the Risk Analysis implementation specification — 45 CFR § 164.308(a)(1)(ii)(A) — which 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 or business associate.” That single sentence is the legal anchor for everything else in this article.

HHS’s Office for Civil Rights has published formal guidance on risk analysis that spells out what “accurate and thorough” means in practice. It means identifying where ePHI lives, identifying realistic threats and vulnerabilities, assessing the likelihood and impact of each, and documenting the current security measures already in place. It’s worth reading directly. Most of the confusion we see about what an assessment “should” cover traces back to organizations working from someone’s paraphrase of this guidance rather than the guidance itself.

Administrative, Physical, and Technical — What Each One Actually Means

The Security Rule organizes its requirements into three safeguard categories, and a complete assessment tests all three. Skipping one isn’t a shortcut — it’s an incomplete assessment, whatever the report calls itself.

Administrative safeguards are the policies, training, and accountability structures around ePHI. That includes who’s designated as your security official, whether workforce members are trained and how often, how access is granted and revoked when someone changes roles or leaves, and whether your business associate agreements actually reflect what those vendors do with your data.

Physical safeguards cover the tangible environment — locked server rooms, workstation placement in patient-facing areas, device and media disposal procedures, and facility access controls. It’s an easy category to underestimate. A laptop left logged in at a nurses’ station is a physical-safeguard failure, even though the fix looks technical.

Technical safeguards are what most people picture when they hear “security assessment”: access controls, audit logging, encryption of ePHI at rest and in transit, and authentication mechanisms. This is the category most vulnerability scans actually test. That’s one reason a vulnerability scan and a HIPAA risk analysis aren’t the same deliverable, even though the two get confused constantly.

What a Proper Assessment Actually Examines

Walk into a well-run assessment and you’ll see the assessor working through a sequence, not a single scan:

• Asset and data-flow inventory — where ePHI is created, received, stored, and transmitted, including systems people forget: backup drives, fax servers, third-party billing platforms, texting apps clinicians use informally.
• Threat and vulnerability identification — realistic threats to those assets, from phishing and ransomware to lost devices and insider misuse, mapped against actual technical weaknesses, not generic industry lists.
• Likelihood and impact scoring — each identified risk rated for how likely it is and how bad it would be if it happened, which is what turns a long list of problems into a prioritized one.
• Existing controls review — what’s already protecting each asset, and whether that control is actually working, not just installed.
• Workforce and process review — training records, access-review cadence, incident-response procedures, and whether the people using the systems actually follow the documented policy.
• Business associate exposure — which vendors touch ePHI, whether agreements are current, and whether their security posture creates risk that’s technically outside your network but still your regulatory responsibility.

NIST’s SP 800-66 Revision 2 walks through this same structure in more technical depth. HHS references it as an implementation resource for the Security Rule, and it’s a reasonable next read for anyone who wants the underlying cybersecurity framework rather than the plain-English version.

What the Deliverables Look Like

A finished assessment isn’t a single “compliant/non-compliant” verdict — that framing is itself a sign an assessment was done too loosely. Expect, at minimum:

• An executive summary that translates findings into business terms — what’s most exposed, and why it matters, for people who don’t need the technical detail to make a decision.
• A risk register or matrix listing every identified risk, its likelihood/impact score, and the safeguard category it falls under.
• A prioritized remediation roadmap — not a flat list, but an order of operations based on risk severity and what’s realistic to fix first.
• Supporting documentation — the policies reviewed, interviews conducted, and technical testing performed, kept as your evidentiary record if OCR ever asks to see it.

That last point matters more than it sounds. In an OCR investigation, the assessment itself — not just your remediation afterward — is often the first document requested. An assessment nobody can produce documentation for is, in OCR’s eyes, functionally the same as an assessment that never happened.

The Gaps Assessors Find Most Often

A few patterns show up again and again, across healthcare organizations of very different sizes. ePHI often lives in places nobody officially tracks — a shared drive, a legacy system someone forgot to decommission. Access rights don’t always get revoked when an employee changes roles. Business associate agreements are sometimes years out of date, or missing entirely for a newer vendor. Encryption gets enabled for some systems but not applied consistently across the environment. And probably the most common single finding: a risk analysis that technically exists but hasn’t been updated since the last major system change. None of these are exotic. They’re the ordinary consequence of a growing organization that hasn’t circled back to redo the analysis as things change.

How Often You Need to Reassess

HIPAA doesn’t specify an exact interval — there’s no “every 12 months” line in the regulation. What OCR does expect, consistent with its risk analysis guidance, is that the assessment stays current. That means reviewing it on a regular schedule (annually is the common industry practice) and repeating it after any material change — a new EHR system, a merger or acquisition, a significant staffing shift, a new remote-work policy, or a security incident. An assessment from three years ago that predates half your current vendor list isn’t protecting you. It’s a paper trail showing you knew things had changed and didn’t look again.

What Happens After the Assessment

The assessment itself doesn’t fix anything — it tells you where to point resources. What comes next is a corrective action plan. That means assigning owners to each finding, setting realistic timelines based on severity, and tracking remediation to completion, rather than treating the report as the finish line. Worth saying plainly: no assessment, and no vendor performing one, can make an organization “HIPAA compliant” as a one-time achievement. Compliance is a continuing practice. The assessment is the mechanism for knowing, at a given point in time, where that practice actually stands and what’s still open.

This is also where a lot of organizations decide whether to run the next cycle internally or bring in an outside team. DYOPATH has performed assessments against HIPAA, NIST, and related compliance frameworks, drawing on the same GRC practice that supports our broader managed security work. If you’re trying to figure out whether your last assessment actually meets the “accurate and thorough” bar OCR expects — or whether it’s time for the next cycle — talk to our team about a cybersecurity assessment.