The HIPAA risk assessment, done properly

Why the risk assessment is where HIPAA enforcement starts

If OCR ever investigates you — after a breach report, a complaint, or a compliance review — the first document request will almost certainly include your risk analysis. The Security Rule makes it a required implementation specification at 45 CFR §164.308(a)(1)(ii)(A): you must "conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information."

Three words in that sentence do the heavy lifting. Accurate — it has to reflect your actual environment, not a generic template. Thorough — it has to cover all ePHI you create, receive, maintain, or transmit, wherever it lives. Potential — it's forward-looking, not a recap of incidents you've already had.

The absence or inadequacy of risk analysis is, year after year, among the most common findings in OCR resolution agreements — it appears in settlements across hospitals, insurers, and business associates alike, and OCR has run an explicit Risk Analysis Initiative focused on exactly this failure. The reason is structural: the risk analysis is the foundation the rest of the Security Rule sits on. Every "addressable" specification you decide to implement, partially implement, or substitute is supposed to be justified by it. No risk analysis means every other safeguard decision is undocumented guesswork — and OCR treats it that way.

For a SaaS company, there's a second forcing function: your customers. If you sign BAAs, you are a business associate directly subject to the Security Rule, and enterprise healthcare buyers ask for your current risk assessment during due diligence. "We're working on it" reads the same as "we don't have one."

What a compliant risk analysis must contain

HIPAA itself is one sentence; the operational detail comes from OCR's Guidance on Risk Analysis Requirements under the HIPAA Security Rule, which draws heavily on NIST SP 800-30. OCR's guidance identifies the elements an assessment must include, regardless of the methodology you choose:

Scope

All ePHI, in every form and location — production databases, backups, logs, file storage, laptops, SaaS tools, vendor systems. Nothing is out of scope because it's "just dev" or "just a vendor."

Data collection

An inventory of where ePHI is created, received, maintained, and transmitted — your asset list and PHI data-flow map, documented.

Threats and vulnerabilities

Identification of reasonably anticipated threats (external attackers, insiders, vendor failure, natural events) and the vulnerabilities they could exploit.

Current security measures

An honest accounting of the controls already in place — and whether they're configured and used correctly, not just purchased.

Likelihood and impact

For each threat/vulnerability pair, a rated probability of occurrence and a rated impact on confidentiality, integrity, or availability of ePHI.

Risk levels

A risk determination (typically likelihood × impact) producing a prioritized register — which risks are critical, high, medium, low.

Documentation

The whole exercise written down: methodology, inventory, findings, ratings, and rationale. Retained six years per §164.316(b)(2)(i).

Periodic review

Evidence the analysis is ongoing — reviewed and updated as the environment and threat landscape change.

Notice what's not on the list: a mandated format, a specific scoring scale, or a required third-party assessor. HIPAA is methodology-agnostic. What it is not agnostic about is completeness.

The seven-step walkthrough for a SaaS company

Step 1 — Define scope and pick a methodology

Write down what the assessment covers: which products, environments, offices, devices, and vendors. The honest answer for most SaaS companies is "everything," because ePHI sprawls — it's in the production database, but also in error logs, support tickets, analytics events, email threads, and an engineer's local test dump. State your methodology (NIST SP 800-30 is the safe default — it's what OCR's own guidance references) and your rating scales up front.

Step 2 — Inventory assets and map PHI flows

List every system that creates, receives, maintains, or transmits ePHI, then draw the flows between them: ingestion (API, upload, integration) → processing → storage → transmission to third parties → backup → deletion. For each asset record the owner, the data classification, and the safeguards attached. This is the step that exposes surprises — the forgotten S3 bucket, the logging tool capturing request bodies, the BI tool with a read replica connection. If you can't produce this inventory, you don't have a risk analysis; you have a form.

Step 3 — Identify threats and vulnerabilities

For each asset, ask what could reasonably go wrong. Cover all three categories: technical (unpatched dependencies, missing encryption, weak access control, exposed endpoints), administrative (no offboarding process, untrained staff, vendors without BAAs), and physical/environmental (stolen laptops, data center failure). Use real inputs — pen test results, vulnerability scans, incident history, vendor reviews — not just imagination.

Step 4 — Assess current controls

Document what's already in place against each threat, and be honest about effectiveness. "We have MFA" is different from "MFA is enforced for all workforce accounts including contractors, verified quarterly." The gap between purchased and enforced is where breaches live. The technical safeguards guide maps the Security Rule's specifications to concrete controls you can check against.

Step 5 — Rate likelihood and impact, derive risk levels

A simple 3- or 5-point scale for each is fine — what matters is consistency and rationale. Likelihood reflects threat capability and how exposed the vulnerability is; impact reflects how much ePHI is affected and how badly (confidentiality, integrity, availability). Multiply or matrix them into a risk level. Resist the temptation to rate everything "medium" — a register with no highs is a register nobody believed.

Step 6 — Build the risk register

The register is the deliverable that drives everything downstream. Here's what realistic SaaS entries look like:

Each row carries its own remediation owner and target date once it moves into risk management — which brings us to the distinction that trips people up.

Step 7 — Document, get sign-off, and schedule the next one

Write the report: methodology, scope, inventory, findings, register, and the date. Have leadership formally accept it — risk acceptance is a management decision, and OCR expects to see that management was in the loop. Then put the next review on the calendar before you file this one. Retain everything for six years (§164.316(b)(2)(i)), including superseded versions: the version trail is your proof that risk analysis is "ongoing."

Risk analysis vs. risk management — two requirements, not one

The Security Rule splits this into two separate required specifications, and OCR enforces them separately:

• Risk analysis — §164.308(a)(1)(ii)(A): the assessment itself. Identify and rate the risks.
• Risk management — §164.308(a)(1)(ii)(B): "implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level." Act on what you found.

A beautiful risk register that nobody actioned satisfies the first and violates the second — and in some ways it's worse than no assessment, because it documents that you knew. Every high and critical risk needs a treatment decision (mitigate, transfer, accept, avoid), an owner, and a date. Accepted risks need a written rationale signed by someone with authority to accept them. Your register should show movement between assessments: risks closed, levels reduced, new risks added.

How often to redo it

The rule sets no interval — it requires the process to be ongoing. The working standard that satisfies auditors and customers:

• Full refresh annually. Re-validate the inventory, re-walk the flows, re-rate the register.
• Targeted update on material change: a new product surface touching PHI, a major vendor swap, a new cloud region or architecture change, an acquisition, or a security incident that revealed something the last assessment missed.
• Continuous register maintenance. The register is a living document — findings from pen tests, vulnerability scans, and incident post-mortems should land in it as they occur, not wait for the annual cycle.

The failures that turn assessments into findings

• Template-filling without analysis. Downloading a generic questionnaire, ticking boxes, and calling it done. OCR's word is "accurate and thorough" — an assessment that doesn't reflect your real systems fails on its face. The HHS SRA Tool is a fine input, never the output.
• Scoping out vendors. Your cloud provider, logging stack, support desk, and subprocessors all hold or touch your ePHI. Pretending the boundary of your risk is the boundary of your VPC is one of the most common — and most consequential — scoping failures. Every PHI-touching vendor needs a BAA and a row in your thinking.
• Incomplete ePHI inventory. Assessing the production database while ignoring backups, logs, analytics, email, and endpoints. Breaches disproportionately come from the systems people forgot were in scope.
• No documentation. "We discussed risks at an offsite" is not a risk analysis. If it isn't written down with dates, ratings, and rationale, it doesn't exist for compliance purposes.
• One-and-done. A single assessment from three years ago, never updated. Staleness is treated as absence.
• Analysis without management. Identifying high risks and leaving them open with no treatment plan — a documented violation of §164.308(a)(1)(ii)(B).

Related reading

• HIPAA for SaaS & digital health — the full resource hub
• HIPAA SaaS readiness checker — free instant gap readout
• HIPAA compliance guide — the complete walkthrough
• HIPAA technical safeguards — the Security Rule mapped to real controls
• HIPAA incident response & breach notification — what happens when a risk materializes
• HIPAA penetration testing — feeding technical findings into the risk analysis

Common questions

Is a HIPAA risk assessment actually required?

Yes. Risk analysis is a required implementation specification of the Security Rule at 45 CFR §164.308(a)(1)(ii)(A) — not addressable, not optional. It applies to covered entities and business associates alike, which means a SaaS company handling PHI under a BAA must perform and document one. It is consistently among the first documents OCR requests in an investigation.

How often should a HIPAA risk assessment be done?

HIPAA says risk analysis must be an ongoing process but sets no fixed interval. The de facto standard is a full refresh at least annually, plus an update whenever the environment changes materially — a new product feature touching PHI, a new cloud region, a major vendor swap, an acquisition, or a security incident. An assessment dated three years ago reads as a violation in practice.

What is the difference between risk analysis and risk management under HIPAA?

They are two separate required specifications. Risk analysis (§164.308(a)(1)(ii)(A)) is the assessment: identifying threats, vulnerabilities, and risk levels to ePHI. Risk management (§164.308(a)(1)(ii)(B)) is what you do about it: implementing security measures sufficient to reduce those risks to a reasonable and appropriate level. A risk register full of high risks with no remediation plan satisfies the first and fails the second.

Can I just use the HHS Security Risk Assessment (SRA) tool?

The free HHS/ONC SRA Tool is a legitimate starting point, especially for small organizations, and using it shows good faith. But it is a questionnaire-driven aid, not a substitute for analysis — it won't inventory your actual systems, map your PHI flows, or evaluate your specific cloud architecture. For a SaaS company, treat it as a checklist input to a real assessment, not the deliverable.

Does a HIPAA risk assessment cover my cloud and SaaS vendors?

Yes. Any vendor that creates, receives, maintains, or transmits ePHI on your behalf is inside scope: your cloud provider, logging and analytics tools, email, support desk, subprocessors. Scoping vendors out is one of the most common assessment failures. Each one needs a BAA, and the residual risk of relying on them belongs in your register.

Who should perform the risk assessment — can we do it ourselves?

HIPAA does not require an external assessor. A self-performed assessment is fully valid if it is thorough and documented — many startups do their first one internally using OCR's guidance and NIST SP 800-30 as the methodology. Third parties add value when you lack security expertise in-house or when customers and auditors want independent validation, but outsourcing doesn't transfer the compliance obligation.

What does OCR look for in a risk analysis?

OCR's Guidance on Risk Analysis lays out the expected elements: defined scope covering all ePHI, data collection showing where ePHI lives and flows, identification of threats and vulnerabilities, assessment of current security measures, likelihood and impact determinations, risk level assignments, documentation of the whole exercise, and evidence of periodic review. Missing elements — especially an incomplete ePHI inventory — are what turn investigations into findings.

Is a penetration test the same as a risk assessment?

No. A penetration test probes specific technical weaknesses at a point in time; a risk analysis is a comprehensive evaluation of all risks to ePHI — technical, administrative, and physical — across your entire environment. Pen test results are excellent input to the risk analysis, but neither replaces the other. See our HIPAA penetration testing guide for how the two fit together.

How long should I retain risk assessment documentation?

Six years from the date of creation or the date it was last in effect, whichever is later — the Security Rule's documentation retention requirement at §164.316(b)(2)(i). Keep prior versions, not just the current one; the version history is itself evidence that risk analysis is an ongoing process.

Do I need a risk assessment before signing my first BAA?

Legally the obligation attaches once you handle ePHI as a business associate, but practically you want the assessment done before the first PHI flows. Enterprise healthcare customers routinely ask for it during vendor due diligence, and signing a BAA while knowingly out of compliance with the Security Rule is a bad position. Doing it pre-launch is cheaper than doing it under deadline pressure during a deal.

Last updated: June 12, 2026 · Reviewed by the LukaGRC compliance team