7 Steps to a Defensible HIPAA Risk Assessment for U.S. Providers & SaaS

A documented, accurate HIPAA security risk assessment is a legal requirement under 45 C.F.R. §164.308(a)(1)(ii)(A), not an optional best practice. The Security Rule doesn't mandate a specific tool or template, but it does demand a thorough, defensible analysis covering every place electronic protected health information (ePHI) lives. Your next move is simple: identify who owns this project internally, then start inventorying every system, application, and vendor that touches ePHI.

TL;DR:

Most organizations fail to update their risk assessment scope after major infrastructure changes, risking outdated documentation that no longer reflects current practices.

Mapping all data flows, cloud integrations, and vendor relationships, including AI and third-party APIs, is critical for accurate scope and effective risk management.

Using recognized frameworks like NIST SP 800-66 and maintaining detailed, version-controlled documentation enhances the credibility of your risk assessment process.

The risk scoring process is less important than comprehensive scoping, as most compliance issues stem from unassessed areas rather than misrated risks.

Preparing organized, current documentation, including signed BAAs, logs, policies, and snapshot files, is essential for efficient audits and defending your security posture.

What Does HIPAA Actually Require for a Risk Assessment?
How Do You Conduct a HIPAA Security Risk Assessment Step by Step?
How Do You Scope a Risk Assessment for SaaS and Cloud Vendors?
What Does the ONC SRA Tool Do, and Where Does It Fall Short?
How Do You Turn Risk Findings Into a Remediation Plan?
What Documentation Does OCR Expect to See in an Audit?
Where Can You Find Official HIPAA Risk Assessment Resources?
Why Healthcare SaaS Teams Need a Different Playbook
What Providers Get Wrong About Risk Assessments
Sources

What Does HIPAA Actually Require for a Risk Assessment?

The regulation itself is short. 45 C.F.R. §164.308(a)(1)(ii)(A) requires covered entities and business associates to "conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information." That's it. No prescribed template, no required software, no mandated scoring system. HHS has been consistent on this point in its own guidance on risk analysis: the law cares about the outcome, not the method.

That flexibility is a gift and a trap. It's a gift because a five-physician clinic and a 200-employee healthcare SaaS company can both meet the standard without buying the same product. It's a trap because "accurate and thorough" has teeth when the Office for Civil Rights (OCR) comes knocking after a breach, and vague, incomplete documentation rarely survives that scrutiny.

OCR expects the assessment to cover electronic protected health information (ePHI) you create, receive, maintain, or transmit, regardless of the media. That includes:

Electronic health record (EHR) systems and their databases
Practice management and billing platforms
Email, texting, and messaging tools used for patient communication
Mobile devices, laptops, and removable media
Cloud storage, backups, and disaster recovery environments
Third-party SaaS applications and APIs that touch patient data

Because the Security Rule doesn't specify methodology, most compliance teams anchor their process to NIST SP 800-66 and NIST SP 800-30. NIST SP 800-30 lays out a general risk assessment methodology built around threat sources, vulnerabilities, likelihood, and impact. NIST SP 800-66 translates that methodology specifically for HIPAA-covered entities, mapping Security Rule safeguards to operational controls. Neither is legally required. Both are what auditors, cyber insurers, and outside counsel will recognize as credible evidence that your process wasn't improvised.

If your organization has never formally adopted a framework, this is the moment to pick one and stick with it. A risk assessment built on an ad hoc checklist you invented last year looks very different to an investigator than one that maps cleanly to a recognized NIST structure.

How Do You Conduct a HIPAA Security Risk Assessment Step by Step?

A risk assessment fails most often not because the analysis is wrong, but because the process was never structured in the first place. Here's the sequence that holds up under scrutiny.

Assemble the right team before you touch a spreadsheet. You need someone from compliance to own the process, IT or security to inventory systems, a clinical lead who understands where PHI actually moves in daily workflows, and legal counsel if your organization has complex vendor relationships or prior incidents. Skipping the clinical voice is a common mistake. IT knows where the servers are; clinicians know where staff actually paste patient names into unsecured chat tools.
Define scope explicitly and in writing. List every system, interface, backup location, analytics tool, and mobile device that could touch ePHI. Vague scoping is one of the most common findings against organizations, because "we thought we covered everything" isn't a defense.
Map data flows and collect evidence. Document how ePHI enters, moves through, and exits each system. Pull system configuration files, access logs, and vendor contracts as you go. This evidence becomes the backbone of your documentation later.
Identify threats and vulnerabilities for each asset. Be specific: phishing susceptibility in a department that hasn't had training in 18 months, an EHR admin account still using a shared password, unencrypted backup drives stored in a supply closet. Generic threat lists ("hackers," "natural disasters") don't hold up. Real assessments name the actual gap.
Score each risk for likelihood and impact. A simple three-tier matrix (low, medium, high) tied to NIST SP 800-30's likelihood and impact categories is sufficient for most organizations and far more defensible than a purely qualitative gut-check.
Prioritize findings and assign owners. Every identified risk needs a named owner, a target remediation date, and a way to verify the fix actually happened.
Set your reassessment triggers. Annual review is the baseline HHS points to, but you also need a trigger list: new EHR implementation, a cloud migration, adding an AI-powered clinical feature, a merger, or any security incident. Waiting for the calendar to turn over while your infrastructure changes underneath you is how organizations end up with a risk analysis that's technically current but practically useless.

Pro Tip: Build your risk matrix in a shared, version-controlled document from day one, not a whiteboard photo. When OCR asks how your scoring methodology evolved over three annual assessments, "we have a spreadsheet with timestamps" beats "we remember doing it that way" every time.

The team composition question deserves a second look. Too many organizations treat this as an IT project and loop in compliance only for sign-off. That inverts the right order. Compliance should own the process end to end, with IT and clinical staff as essential contributors, because IT can tell you where the data sits but not always how it's actually used at the bedside or in the billing office. Cross-functional ownership isn't a nice-to-have here. It's the difference between an assessment that reflects paper policy and one that reflects reality.

How Do You Scope a Risk Assessment for SaaS and Cloud Vendors?

Healthcare SaaS companies and vendor-heavy provider organizations face a scoping problem traditional HIPAA guidance doesn't fully anticipate. Your ePHI doesn't sit in one building anymore. It flows through cloud infrastructure, third-party APIs, analytics platforms, and sometimes AI models you didn't build yourself.

Start by getting the legal relationship right. If you're a covered entity using a SaaS vendor that creates, receives, maintains, or transmits ePHI on your behalf, that vendor is a business associate and needs a signed Business Associate Agreement (BAA) before any data flows. If you're the SaaS company, you're the business associate, and your own subcontractors (cloud hosting, email delivery, analytics providers) need their own BAAs in a chain that traces all the way down.

A signed BAA is not a substitute for actually assessing the vendor. It shifts legal responsibility for certain safeguards; it does not verify the vendor implemented them.

Scoping for a SaaS-rich environment should include:

Every API integration and third-party connection mapped in your data flow diagrams, not just your primary systems
AI features and machine learning models that process PHI, with logging that tracks what data went into training or inference and where outputs are stored
Analytics tools, support ticket systems, and customer success platforms, which frequently contain PHI that nobody flagged during initial scoping
Backup and disaster recovery environments hosted by third parties

For vendor evidence, request a signed BAA, a SOC 2 Type II report or equivalent attestation, a summary of recent penetration testing, and documented incident response contacts with defined service-level agreements for breach notification. A health IT vendor readiness checklist is a useful reference point when building this evidence request into your standard vendor onboarding process, and due diligence practices used in healthcare SaaS M&A apply almost directly to vendor risk scoping, since both exercises ask the same underlying question: can this vendor prove what they claim about their security posture?

What Does the ONC SRA Tool Do, and Where Does It Fall Short?

The Security Risk Assessment (SRA) Tool from ONC and HHS is a free, downloadable application built specifically for small and medium-sized providers who need a structured way to start. It walks users through a wizard-based series of questions covering administrative, physical, and technical safeguards, then stores responses locally and generates a summary report along with a prioritized remediation plan.

The SRA Tool User Guide breaks the tool into distinct sections covering asset and vendor management, access controls, and contingency planning, with each section prompting the user to rate identified threats and vulnerabilities by likelihood and impact before generating a report. The guide is explicit that the tool is a point-in-time questionnaire, and it instructs organizations to document any risks or environments the tool's question set doesn't capture using supplemental evidence outside the application itself.

That limitation matters more than it sounds. The tool was built with a traditional single-location practice in mind: one EHR, one office network, a handful of workstations. It works well for that use case. It struggles when your environment includes a dozen SaaS integrations, a multi-region cloud architecture, or an AI diagnostic feature processing patient images. ONC's own overview materials note that the tool is intended for smaller organizations and that larger or more complex entities should supplement it with vendor-specific evidence and tailored assessments.

Here's a rough way to think about where the tool fits:

Small practice, single EHR, minimal third-party integration: the SRA Tool alone is likely sufficient, especially for a first pass.
Mid-size organization with several SaaS vendors: use the SRA Tool as your baseline, then layer in a vendor evidence matrix (BAAs, SOC 2 reports) as a supplement.
Healthcare SaaS company or complex multi-vendor provider network: the SRA Tool becomes one input among several. You'll likely need a custom Excel-based risk register or a commercial governance, risk, and compliance (GRC) platform to track the volume of vendors and integrations involved.

Vendor-neutral Excel-based HIPAA risk assessment templates that map line items directly to 45 C.F.R. citations can speed up documentation considerably, particularly for organizations that have outgrown the SRA Tool's question set but aren't ready to invest in a full compliance platform. Whatever format you choose, document explicitly why you selected it and how it maps back to the regulatory requirement. An assessment format nobody can explain the reasoning behind is itself a finding waiting to happen.

How Do You Turn Risk Findings Into a Remediation Plan?

A risk assessment that ends at the scoring stage is half-finished. OCR investigators consistently ask what happened after the risk was identified, and "we knew about it" without a corresponding action plan is one of the fastest ways to turn a manageable gap into an enforcement issue.

A workable risk-rating method doesn't need to be complicated. Score each identified risk as high, medium, or low based on the combination of likelihood (how probable is exploitation) and impact (how severe would the consequence be), consistent with the approach outlined in NIST SP 800-30. A high-likelihood, high-impact finding, like an unencrypted database with known access control gaps, gets addressed before a low-likelihood, low-impact one, like an outdated policy document nobody has referenced in years.

Not every risk gets fixed immediately, and that's fine as long as you document why. If you identify a gap but can't remediate it right away, record the compensating control you've put in place instead, the business rationale for the delay, and a target date for full remediation. An investigator reviewing your file should be able to see the reasoning, not just the gap.

Structure each remediation item with four fields: the finding itself, a named owner, the specific action being taken, and the due date, followed by the verification evidence once it's closed out. Common remediation items include:

Implementing multi-factor authentication (MFA) on remote access and administrator accounts
Encrypting data at rest and in transit for systems that were previously unencrypted
Updating vendor contracts to include current BAA language reflecting your actual data flows
Conducting targeted staff training where phishing susceptibility or password hygiene was flagged as a risk

Pro Tip: Close the loop with verification evidence, not just a checked box. "MFA enabled" is a claim; a screenshot of the enforced policy setting, dated and filed with the remediation record, is proof. That distinction is exactly what separates a remediation plan that survives an audit from one that doesn't.

What Documentation Does OCR Expect to See in an Audit?

When OCR investigates a complaint or breach, the file they request is fairly predictable, and organizations that scramble to assemble it after the fact are already behind. At minimum, keep a dated risk analysis showing the assessment period and methodology used, a remediation plan with status updates, signed BAAs for every relevant vendor, current security policies and procedures, training logs showing who completed what training and when, and a change history documenting major system or vendor changes since the last assessment.

Use consistent file naming and version control. A folder structure organized by year, with clearly dated snapshots (for example, "RiskAssessment_2026_v2_FINAL"), lets an investigator trace your compliance history without guesswork.
Keep a point-in-time snapshot for every completed assessment. Don't overwrite last year's file with this year's update. OCR may ask to see how your risk posture evolved, and only dated snapshots can show that.
Prepare two versions of your findings. A one-page executive summary for leadership and the board, and a detailed evidence bundle, including logs, contracts, and screenshots, for anyone conducting a formal review.
Bring in outside counsel or a third-party assessor when the stakes are high. If you've had a prior incident, operate in a high-risk specialty, or manage a complex multi-vendor SaaS environment, an independent review adds credibility that internal sign-off alone doesn't carry.

Document management platforms built specifically for regulated healthcare data, such as those covered in this comparison of HIPAA-compliant document management solutions, can help enforce the version control and access logging that a defensible audit trail requires.

Where Can You Find Official HIPAA Risk Assessment Resources?

Start with the primary sources rather than third-party summaries, since OCR investigators will reference the same originals.

HHS guidance on risk analysis explains the regulatory requirement in OCR's own words, including scope and acceptable methodology.
The ONC Security Risk Assessment Tool and its accompanying user guide give small and medium providers a structured starting workflow.
NIST SP 800-66 maps HIPAA Security Rule requirements to specific operational controls, and pairs well with the broader NIST SP 800-30 risk methodology for organizations that need a more rigorous scoring approach.
A vendor-neutral Excel risk assessment template mapped to 45 C.F.R. citations is worth keeping on hand for organizations that have outgrown the SRA Tool's scope but don't yet need a full GRC platform.

Why Healthcare SaaS Teams Need a Different Playbook

Paul Bergeron, MD, MBA, brings over 25 years of combined medical and business leadership experience to advising healthcare SaaS companies, offering a dual perspective on clinical operations and technology strategy that shapes how The StartupMD approaches compliance work with founders and executive teams.

Hands holding stethoscope and pen over table

Three practical patterns show up repeatedly in healthcare SaaS environments. First, hidden ePHI shows up in places nobody scopes initially: analytics dashboards, customer support tickets, database backups, and developer staging environments. Second, involving a clinical voice early changes what gets found, because clinicians see workflow shortcuts that pure technical audits miss. Third, treat vendor evidence collection as its own workstream with a dedicated owner, not an afterthought bolted onto the main assessment timeline.

Founders preparing for due diligence or a funding round often discover their risk assessment gaps during investor scrutiny rather than before it. That's the wrong order. Reviewing how healthcare SaaS revenue models hold up under investor evaluation makes clear how closely compliance readiness and fundraising readiness are linked in this sector.

What Providers Get Wrong About Risk Assessments

The most common mistake I see isn't a missing risk analysis. It's a stale one, dusted off annually to check a compliance box, with the same threats listed year after year because nobody updated the scope when the environment changed. A risk assessment written before your last cloud migration or before you added an AI intake feature isn't protecting you. It's documenting a version of your organization that no longer exists.

The conventional advice tells organizations to "use the SRA Tool and you're covered." That's incomplete for anyone running a SaaS platform, managing multiple vendor integrations, or processing PHI through AI models. The tool is a solid foundation, not a finish line.

If you take one thing from this guide, prioritize the scoping step over the scoring step. Most enforcement actions trace back to something that was never assessed at all, not something that was assessed and scored incorrectly. Get the inventory right first. The math is the easy part.

— Paul Bergeron MD, MBA