HIPAA Risk Analysis: Map OCR's Nine to NIST for Compliance Officers

A HIPAA risk analysis is a required, written assessment that identifies where your ePHI lives, the threats and vulnerabilities to those systems, and the remediation you must track. It's the document OCR asks for first in almost every investigation, and it must follow the nine elements OCR outlines and get updated on a recurring basis. The ONC SRA Tool can get smaller practices started, but most organizations need more than a questionnaire. Start now: list every system that touches ePHI, and assign an owner to fix what you find.

TL;DR:

• The risk analysis must inventory all ePHI systems, including websites, mobile apps, backups, and cloud services, with assigned owners for remediation.
• Scoring risks involves evaluating threats, vulnerabilities, likelihood, and impact, then prioritizing highest risks for immediate action.
• External vendors handling ePHI require signed BAAs, thorough assessments, and continuous documentation to prevent scope gaps.
• Conduct the analysis annually or after significant changes, keeping detailed records, risk logs, and evidence of remediation to ensure audit readiness.
• Mapping findings to NIST controls enhances security justification, with outside support like vCISO services recommended for complex or multi-site organizations.

Table of Contents

• How Do You Conduct a HIPAA Risk Analysis?
• What Are OCR's Nine Elements of a Risk Analysis?
• Should You Use the ONC Security Risk Assessment Tool?
• Where Do HIPAA Risk Analyses Commonly Fail on Scope?
• How Often Should You Repeat a HIPAA Risk Analysis?
• How Do You Map HIPAA Risks to NIST Controls?
• What Documents Should You Keep During the Analysis?
• CISOSafe's Take: When Does a vCISO Beat DIY Risk Analysis?
• What Mistakes Undermine a HIPAA Risk Analysis Beyond Scope Gaps?
• What Does Effective Risk Analysis Implementation Look Like?
• How Should Different Covered Entities Tailor Their Risk Analysis?
• What Tools Help Beyond the ONC SRA Tool?
• How Do You Turn Risk Findings Into Ongoing Compliance Culture?
• What Actually Matters Most in a HIPAA Risk Analysis
• Get an Audit-Ready HIPAA Risk Analysis Without Building It Alone
• Where to Verify HIPAA Risk Analysis Requirements
• Sources
• FAQ

How Do You Conduct a HIPAA Risk Analysis?

A defensible HIPAA risk analysis follows a sequence, not a single form. OCR doesn't mandate a specific methodology, but it does expect the process to be accurate, thorough, and to touch every system that creates, receives, maintains, or transmits ePHI, according to HHS guidance on risk analysis. Here's the order that produces a document an auditor can actually follow.

1. Inventory every ePHI system and map the data flow. This means more than your EHR. Include your website's intake forms, patient portals, appointment scheduling widgets, backup storage, mobile devices, remote endpoints, and any cloud service that stores or processes patient data. If a system touches ePHI at any point, it belongs on the list.
2. Document current controls, threats, and vulnerabilities for each system. For every item in your inventory, record what protections already exist (encryption, access controls, logging) alongside the realistic threats it faces and the specific weaknesses that could let those threats succeed.
3. Rate likelihood and impact, then calculate a risk level. Use a consistent scale, whether that's a simple high/medium/low rating or a numeric scoring model. Multiply or combine likelihood and impact to produce a risk level you can sort by, so the highest-priority gaps rise to the top.
4. Build a remediation plan with named owners and dates. A risk analysis without a corresponding action plan is incomplete in OCR's eyes. Every identified risk needs a person responsible for fixing it, a target completion date, and criteria for what "fixed" actually looks like.
5. Set a review schedule and define triggers for early review. Annual review is the baseline. Material changes, such as a new EHR vendor, an office expansion, a security incident, or a new telehealth platform, should trigger an off-cycle reassessment.

The inventory step trips up more organizations than any other. Practices often catalog their EHR and practice management software carefully, then forget the marketing website that has a "request an appointment" form quietly emailing patient names and reasons for visit straight to a front-desk inbox. That inbox, and the form that feeds it, are both in scope.

Once your inventory is built, the documentation for each system should include:

• The system name and its role in handling ePHI
• Current safeguards, both technical (encryption, firewalls) and administrative (access policies, training)
• Identified threats specific to that system (phishing, unpatched software, lost devices)
• Vulnerabilities that make those threats more likely to succeed
• Calculated risk level and the reasoning behind it

Risk management plans and the underlying analysis are legally distinct steps. The HIPAA Security Rule requires the analysis under §164.308(a)(1)(ii)(A) and a separate risk management process under §164.308(a)(1)(ii)(B) that acts on what the analysis found. Skipping straight from a list of risks to "we'll deal with it eventually" is one of the fastest ways to fail an OCR review, because the regulation expects a documented plan connecting each finding to a fix.

Pro Tip: Assign remediation owners by role, not by name, whenever possible. When "IT Director" owns a fix instead of a specific employee, your risk management plan survives staff turnover without a documentation gap.

Frequency matters as much as thoroughness. A risk analysis performed once in 2022 and never revisited tells OCR that your organization isn't managing risk. It's producing a static compliance artifact. Treat the analysis as a living document that gets touched at least annually, with unscheduled updates whenever your technology or vendor relationships shift.

What Are OCR's Nine Elements of a Risk Analysis?

OCR points to nine components that a compliant risk analysis has to address, drawn from established guidance summarized in an overview of the requirement. Each element answers a specific question, and together they form the skeleton auditors expect to see filled in.

• Scope: Which ePHI, systems, and locations does the analysis cover, and does it include every place data is created, received, maintained, or transmitted?
• Data collection: How was information gathered, whether through interviews, technical scans, policy review, or vendor questionnaires?
• Threat and vulnerability identification: What could go wrong, and what weaknesses would let it happen?
• Assessment of current controls: What safeguards are already in place, and how effective are they against the identified threats?
• Likelihood determination: How probable is it that a given threat exploits a given vulnerability?
• Impact analysis: If the threat succeeds, how severe is the damage to confidentiality, integrity, or availability of ePHI?
• Risk level determination: Combining likelihood and impact into a single, sortable rating.
• Documentation: A written record detailed enough that someone outside the process could reconstruct the reasoning.
• Periodic review: A defined schedule for revisiting the analysis, not a one-time event.

Here's how those nine elements look applied to something almost every medical practice has: a patient intake form on the website. The scope entry names the form and the hosting platform it runs on. Data collection notes that the form was tested manually and its backend database was queried directly. Threat identification flags SQL injection and unpatched plugin vulnerabilities on the content management system running the form. The current controls assessment records that the form uses TLS encryption in transit but has no rate limiting or web application firewall. Likelihood gets rated "medium" because the plugin hasn't been updated in eight months. Impact gets rated "high" because the form captures full names, dates of birth, and reason for visit. That combination produces a "high" risk level, which lands the item at the top of the remediation queue. Documentation captures all of the above in a dated row, and periodic review flags the item for a recheck at the next quarterly cycle, not just the annual one, given its severity.

During compliance reviews, OCR typically asks to see the analysis itself, the remediation plan tied to it, and evidence that the organization acted on what it found. A risk analysis that identifies a problem but shows no follow up is arguably worse than not having found the problem at all, since it demonstrates the organization knew and did nothing.

Should You Use the ONC Security Risk Assessment Tool?

The ONC SRA Tool is a free, government-built starting point, and it's the right choice for practices that need a structured way to begin. It comes in two formats: a Windows desktop application and an Excel workbook, both designed to walk a practice through the same set of questions covering administrative, physical, and technical safeguards. Data entered into either version stays local to the device. Nothing gets transmitted to HHS or ONC, which matters for organizations wary of putting risk data anywhere near the internet before it's remediated.

The tool is aimed squarely at small and medium providers, and its own user guide for version 3.6.1 reflects that scope. It uses a NIST-aligned scoring approach to calculate risk levels, generates a summary report, and includes a section for tracking remediation. For a single-location practice with a handful of systems, it can produce a genuinely usable risk analysis.

Where the tool runs into limits is complexity. A multi-location health system, a hospital network with dozens of integrated vendors, or a law firm handling ePHI on behalf of healthcare clients will outgrow the tool's fixed question set fast. The SRA Tool is a point-in-time, questionnaire-driven aid, not a continuous monitoring platform, and larger organizations typically need a manual system inventory, data-flow diagrams, and evidence attachments that go beyond what the workbook can hold.

When you hit that ceiling, the fix isn't to abandon the tool. It's to supplement it:

• Use the SRA Tool's output as your baseline documentation for lower-complexity systems.
• Build a separate, detailed risk register for systems the tool's questions don't fully address (custom applications, complex vendor integrations, multi-site networks).
• Attach supplemental evidence, such as network diagrams, penetration test results, and vendor security questionnaires, directly to the risk rows they support.
• Cross-reference the SRA Tool's findings with your broader risk register so an auditor sees one coherent analysis, not two disconnected documents.

The tool's own user guide instructs organizations to document threats it doesn't capture and link that documentation as supplemental evidence rather than leaving gaps in the record.

Where Do HIPAA Risk Analyses Commonly Fail on Scope?

Scope failures are the single most common finding OCR reports, and nearly all of them trace back to one assumption: that "our systems" means only the clinical software. Websites, patient intake forms, analytics tags, backup storage, and third-party plugins are all in scope the moment they create, receive, maintain, or transmit ePHI, regardless of whether IT considers them part of the "real" network.

A practice's marketing website is a frequent blind spot. If it hosts a contact form asking "what brings you in today," that form is handling protected health information, and the hosting platform, the plugin powering the form, and the email inbox receiving submissions all belong in the risk analysis. Analytics and advertising pixels can create a similar problem if they capture information tied to health conditions or appointment behavior.

Vendor relationships create a second, closely related failure pattern. Any third party that handles ePHI on your behalf, from a billing service to a cloud backup provider to an IT support contractor with remote access, needs a signed business associate agreement on file. Auditors expect to see a register of every vendor touching ePHI, the BAA covering that relationship, and evidence that the vendor's own security posture was evaluated before the contract was signed. A missing BAA, or one that's expired, is an immediate red flag regardless of how strong the technical controls are elsewhere.

Use this checklist before calling your scope complete:

• Every website form, chatbot, or scheduling widget that could capture patient information is listed and assessed.
• Analytics and marketing tags on patient-facing pages have been reviewed for PHI exposure.
• Every vendor with any access to ePHI has a current, signed BAA on file.
• Backup and disaster recovery systems, including offsite and cloud backups, are included in the inventory.
• Remote access tools and any BYOD policies covering staff devices are documented.

Pro Tip: Name your website as its own line item in the risk inventory, complete with a one-sentence data-flow description and a specific remediation owner. That single habit closes one of OCR's most frequently cited gaps before an auditor ever asks about it.

How Often Should You Repeat a HIPAA Risk Analysis?

Annual review is the practical floor, not a suggestion buried in fine print. Beyond the calendar trigger, certain events should force an off-cycle risk analysis regardless of when the last one happened: a system redesign or new EHR rollout, a confirmed security incident, a new vendor gaining access to ePHI, an office expansion or new location, or a significant change in how patient data moves through the organization, such as adding telehealth.

Documentation retention matters just as much as frequency. Keep every version of the risk analysis, not just the most recent one, since OCR reviews often ask for a history showing the organization's process matured over time rather than a single static snapshot. Retain remediation evidence, including screenshots, vendor confirmations, and change logs, showing that identified risks were actually addressed and not just noted and forgotten.

When OCR opens a review, the request typically covers a specific package:

• The current risk analysis, dated and version controlled
• The remediation plan tied to that analysis, with named owners and completion status
• Signed BAAs for every vendor with ePHI access
• Evidence logs, such as vulnerability scan results or penetration test reports, supporting the controls assessment
• Prior risk analysis versions showing an ongoing process, not a one-time exercise

Organizations that keep this package assembled and current, rather than scrambling to reconstruct it after a breach notification triggers an investigation, consistently fare better in OCR reviews. The difference between a smooth review and a painful one usually comes down to whether this evidence already exists in one place.

How Do You Map HIPAA Risks to NIST Controls?

Mapping your risk analysis findings to NIST controls gives auditors a technical justification for every safeguard you choose, and it's the approach NIST SP 800-66 Rev.2 recommends for organizations that want a defensible security posture beyond the bare minimum. HIPAA's Security Rule tells you what to protect. NIST's control catalog, specifically SP 800-53, tells you specifically how.

The mapping is more straightforward than it sounds once you see it applied to actual findings:

Each mapped control becomes a line item in your remediation plan, showing not just "fix access control" but which specific NIST control your fix satisfies and why. This approach turns a vague remediation note into something an auditor, or a cyber insurance underwriter, can independently verify against a recognized standard.

For organizations building out a full HIPAA Security Rule compliance program, this mapping exercise typically happens once per major risk category rather than once per individual finding, since many findings cluster under the same control family. Present the mapping in the remediation plan itself, alongside owners and dates, so the connection between "here's the risk" and "here's the standard-based fix" is visible without extra explanation. It's the difference between a plan that reads as ad hoc and one that reads as engineered.

What Documents Should You Keep During the Analysis?

A repeatable, defensible risk analysis produces a specific set of artifacts, and building them in a consistent format from the start saves enormous rework at the next annual cycle.

The essential documents to maintain:

• System inventory spreadsheet listing every ePHI-touching system, its owner, and its role
• Data-flow diagrams showing how ePHI moves between systems, vendors, and physical locations
• Per-system risk rows capturing threats, vulnerabilities, controls, likelihood, impact, and risk level
• Remediation plan with named owners, target dates, and acceptance criteria for each finding
• BAA register tracking every vendor agreement, its effective date, and renewal status
• Test and scan logs from vulnerability assessments, penetration tests, or access reviews

If you're using the SRA Tool, export its summary report and remediation tracking output, then attach supplemental evidence for anything the tool's fixed question set didn't cover. That might include network diagrams, custom application assessments, or vendor security questionnaires that live outside the tool's structure.

To build this package efficiently:

1. Start with the system inventory before anything else. Everything downstream depends on it being complete.
2. Build data-flow diagrams for your three or four highest-risk systems first, then expand outward.
3. Populate risk rows directly from your threat and control assessment, keeping the format consistent across every system.
4. Draft the remediation plan alongside the risk rows, not after them, so nothing gets identified and then forgotten.
5. Review the full package quarterly, even if your formal risk analysis update is annual.

Lightweight automation and risk mitigation software tend to deliver the strongest return when they eliminate manual spreadsheet wrangling across dozens of systems, freeing your team's attention for the judgment calls, like rating impact and prioritizing remediation, that software can't make for you. For organizations juggling multiple locations or complex vendor networks, that's often where a vCISO relationship pays for itself fastest.

CISOSafe's Take: When Does a vCISO Beat DIY Risk Analysis?

CISOSafe works as a vCISO partner for regulated organizations across law, energy, and healthcare, which means our team has watched the same patterns repeat across dozens of HIPAA risk analyses. The pattern is consistent: organizations that treat the analysis as a compliance checkbox produce documents that look complete and fail the moment OCR asks a follow-up question.

CISOSafe combines hands-on vCISO leadership, including security assessments, risk roadmaps, policy development, and incident response planning, with an AI-driven SaaS portal that automates penetration testing and compliance reporting. That pairing matters because a risk analysis isn't a one-time deliverable. It's an ongoing program that needs both strategic judgment and consistent technical execution.

Here's how to think about when internal staff or the SRA Tool alone is enough, and when it isn't:

• Single-location practice, limited vendor network: The SRA Tool plus internal staff time can likely produce a defensible analysis.
• Multiple locations, complex vendor relationships, or prior OCR scrutiny: A vCISO engagement closes gaps the questionnaire format can't catch and keeps remediation on schedule.
• Limited internal security expertise: Outside advisory support prevents the common failure of identifying risks without the technical depth to prioritize them correctly.
• Board or investor reporting requirements: vCISO-produced reporting translates technical risk into language leadership can act on.

— vCISO

What Mistakes Undermine a HIPAA Risk Analysis Beyond Scope Gaps?

Scope failures get the most attention, but weak execution inside the correct scope causes just as much damage. Inadequate threat identification is the most common: organizations list generic threats like "hacking" without naming the specific attack vectors relevant to their actual systems, such as credential stuffing against a patient portal or unpatched software on a specific server.

Poor data collection methods compound the problem. A risk analysis built entirely from a single administrator's memory, without technical scans, interviews across departments, or a review of actual system configurations, misses risks that only surface when you look at how staff actually use the systems day to day. Relying on a template downloaded from a website and filling in generic answers without verifying they match your actual environment produces a document that looks thorough but describes a hypothetical organization, not yours.

Another frequent misstep: rating every risk as "medium" to avoid the work of genuine prioritization. When everything is medium, nothing gets fixed first, and the remediation plan becomes a flat list instead of a prioritized one. Likewise, treating the risk analysis and the risk management plan as the same document, rather than two connected but distinct deliverables, leaves auditors unable to see whether identified risks were actually addressed.

Finally, static documentation kills credibility fast. A risk analysis dated three years ago, with no evidence of interim review despite a known system migration in between, tells OCR the organization's compliance program exists on paper only.

What Does Effective Risk Analysis Implementation Look Like?

A mid-size medical group with locations in three cities offers a useful pattern. Rather than treating each office as a separate analysis, the group built one system inventory covering shared EHR infrastructure, then documented location-specific risks separately, such as differing physical security controls at each front desk and varying WiFi configurations. This structure let them see enterprise-wide risks (like a shared vendor with lapsed security certifications) alongside location-specific gaps without duplicating effort.

A specialty clinic handling a high volume of insurance intake found that its highest-risk item wasn't a server at all. It was a fax-to-email gateway that routed insurance verification requests, containing PHI, to a shared inbox accessible by eleven staff members with no individual access logging. Rating that gateway's risk level as high, rather than assuming faxes are inherently low-tech and low-risk, drove the remediation that mattered most: replacing the gateway with an access-controlled, logged alternative.

A behavioral health practice discovered during its risk analysis that its scheduling software vendor had subcontracted hosting to a third party without disclosing it, meaning ePHI sat on infrastructure the practice had never evaluated and had no BAA covering. Catching this during the vendor review step, rather than after a breach, let the practice renegotiate the contract and secure a proper BAA chain before any incident occurred.

What connects these examples isn't sophisticated technology. It's the discipline of documenting the actual, specific system rather than a generic category, and rating risk based on real exposure rather than assumptions about what looks technical and what doesn't.

How Should Different Covered Entities Tailor Their Risk Analysis?

A solo practitioner, a hospital system, and a business associate handling billing data face the same HIPAA requirements but need meaningfully different analyses. HHS guidance is explicit that methodology should scale to organizational size and complexity, and a one-size template applied uniformly across these entity types produces gaps in each direction.

Solo and small group practices typically have a compact system inventory, but they also tend to rely heavily on third-party vendors for everything from EHR hosting to billing, which means vendor and BAA review often deserves more attention than internal technical controls. The SRA Tool fits this profile well.

Hospital systems and large medical groups carry the opposite challenge: dozens of integrated systems, multiple physical locations, and internal IT teams managing custom infrastructure. Their risk analysis needs granular, system-by-system documentation and typically benefits from formal data-flow diagrams and dedicated risk management staff rather than a single questionnaire pass.

Business associates, such as billing companies, transcription services, or IT vendors serving healthcare clients, need a risk analysis focused on the ePHI they process on behalf of clients specifically, not their entire corporate IT environment. Their documentation should map cleanly to the terms of the BAAs they've signed, showing exactly which safeguards correspond to which contractual obligations.

Telehealth-heavy practices face a newer wrinkle: video platforms, remote monitoring devices, and home network security fall outside traditional office-based risk models and need their own dedicated assessment.

What Tools Help Beyond the ONC SRA Tool?

The SRA Tool covers the basics, but a comprehensive program typically draws on several additional resources. NIST SP 800-66 Rev.2 itself functions as a reference tool, not just a citation, since it includes implementation guidance and control mapping tables you can use directly when building your own risk register template.

Vulnerability scanning tools and penetration testing services fill a gap the SRA Tool's questionnaire format can't: actual technical verification of whether a stated control works as intended, rather than a self-reported yes or no. A firewall listed as "in place" during a questionnaire means little without evidence the configuration actually blocks the traffic it should.

Governance, risk, and compliance (GRC) platforms designed for healthcare organizations can centralize risk registers, remediation tracking, and BAA management in one place, replacing the spreadsheet sprawl that develops when multiple departments maintain separate documents. For organizations managing time-sensitive operational tools alongside compliance work, resources like this guide to HR time management tools for small clinics illustrate how operational software choices intersect with the vendor inventory a risk analysis has to cover.

AI-enabled compliance platforms, including the kind CISOSafe operates, can automate portions of the assessment process, such as continuous vulnerability scanning and automated compliance reporting across multiple frameworks simultaneously, reducing the manual burden of keeping documentation current between formal annual reviews.

How Do You Turn Risk Findings Into Ongoing Compliance Culture?

A risk analysis that lives in a folder, disconnected from daily operations, decays fast. The organizations that keep their compliance posture strong feed risk analysis findings directly into two ongoing programs: policy updates and staff training.

Every finding with a "high" risk level should trigger a review of the relevant policy. If the analysis found that staff routinely email patient information without encryption, that finding should immediately update both the technical controls (enabling encrypted email) and the written policy governing acceptable communication methods. Treating the policy and the technical fix as separate action items, rather than one connected update, is how organizations end up with a policy manual that no longer matches actual practice within a year.

Staff training needs the same direct connection. Generic annual HIPAA training satisfies a minimum requirement, but training built around your organization's actual risk analysis findings, such as a specific phishing pattern that targeted your front desk or a specific vendor access issue discovered during the assessment, sticks with staff far better than abstract scenarios. When the training reflects real findings from the practice's own environment, staff recognize the relevance immediately.

Building this loop, risk analysis feeding policy updates and targeted training, then training outcomes feeding back into the next risk analysis cycle, is what separates a compliance program that improves year over year from one that repeats the same findings every twelve months without progress.

What Actually Matters Most in a HIPAA Risk Analysis

The conventional advice treats the risk analysis as a documentation exercise: fill out the form, file it away, move on. That framing misses what OCR actually rewards, which is evidence of an active risk management process, not a static report. A beautifully formatted risk analysis with no remediation follow-through is arguably worse for an organization than a rougher one that shows real, tracked progress.

The gap most organizations underestimate is scope, specifically the website and vendor blind spots that feel peripheral to "real" IT systems but sit squarely inside HIPAA's definition of ePHI handling. Fixing that gap costs almost nothing. It just requires naming the website as its own line item and pulling every vendor contract into a BAA register.

If you take one thing from this guide, prioritize the connection between findings and remediation ownership. A risk analysis without named owners and dates is a list of problems, not a compliance program.

— vCISO

Get an Audit-Ready HIPAA Risk Analysis Without Building It Alone

Running a thorough HIPAA risk analysis internally takes time most compliance officers don't have, especially across multiple locations or a growing vendor network. A vCISO partner combined with an AI-enabled platform can provide regulated organizations with security guidance without the cost or timeline of hiring a full-time CISO.

CisoSafe's vCISO, compliance program management, and security risk assessment services cover the full lifecycle: scoping your ePHI systems, mapping findings to OCR's nine elements and NIST controls, building a remediation roadmap with named owners, and preparing board-ready reporting your leadership can actually use. Policy and controls development and audit and certification readiness support round out the engagement, so the risk analysis feeds directly into a broader, defensible compliance posture rather than sitting as a one-time deliverable. If your last risk analysis is more than a year old, or you've never mapped your website and vendors into scope, visit CisoSafe's about page to start a conversation about what an audit-ready risk analysis looks like for your organization.

Where to Verify HIPAA Risk Analysis Requirements

Government sources carry the most weight when you need to defend your methodology to an auditor or your own leadership.

• HHS/OCR Guidance on Risk Analysis: the primary explanation of the nine required elements and tailoring expectations.
• ONC Security Risk Assessment Tool: the free Windows and Excel-based assessment tool for small and medium providers.
• SRA Tool v3.6.1 User Guide: technical detail on sections, scoring, and supplemental documentation.
• NIST SP 800-66 Rev.2: the full guide for mapping HIPAA implementation specifications to NIST controls.

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

Sources

• Guidance on Risk Analysis - HHS/OCR
• Security Risk Assessment Tool - ONC
• Security Risk Assessment Tool v3.6.1 User Guide (ONC)
• SP 800-66 Rev.2, Implementing the HIPAA Security Rule - NIST (full guide)

FAQ

What Is the New HIPAA Rule in 2026?

HHS has proposed updates to the HIPAA Security Rule aimed at strengthening technical safeguard requirements, including more specific expectations around encryption and multifactor authentication. Check the HHS/OCR guidance page directly for the current rulemaking status, since proposed rules can shift before finalization.

What Are the Requirements for Conducting a Risk Analysis Under HIPAA?

A compliant risk analysis must address OCR's nine elements: scope, data collection, threat and vulnerability identification, assessment of current controls, likelihood, impact, risk level, documentation, and periodic review. There's no single required methodology, but the process must be accurate, thorough, and cover every system touching ePHI, per HHS/OCR guidance.

How Often Does HIPAA Require a Risk Assessment?

HIPAA doesn't specify an exact interval, but annual review is the widely accepted baseline, plus additional reviews after material changes like a new vendor, a system migration, or a security incident. Treating the analysis as a one-time document instead of an ongoing process is one of the most common findings in OCR reviews.

How Much Does a HIPAA Audit Cost?

Costs vary widely based on organization size, system complexity, and whether you handle the analysis internally, use the free ONC SRA Tool, or engage outside support. CisoSafe's vCISO and security risk assessment pricing is available directly through its about page, since costs depend on the scope of your environment.

Can the ONC SRA Tool Replace a Full Risk Analysis for a Larger Organization?

Not reliably. The SRA Tool works well for small and medium providers, but larger or more complex organizations typically need supplemental documentation, including data-flow diagrams and vendor-specific risk rows, that the tool's fixed questionnaire format doesn't capture.

Recommended

• The HIPAA Security Rule: A Compliance Guide for 2026
• HIPAA Breach Notification Requirements: What to Do Now
• Compliance Mapping: A Practical Guide for Risk Leaders
• Organizational Consent for Release of Information: 2026 Compliance Playbook