HIPAA and the the Security Risk Analysis: What OCR Asks for First (Part 3 of 5)

If the Business Associate Agreement is the contractual foundation of HIPAA compliance, the Security Risk Analysis is the operational one. It is required by the Security Rule for every covered entity and business associate, it is the first document the Office for Civil Rights (OCR) requests in any investigation or audit, and its absence or inadequacy is cited as a central finding in the great majority of OCR enforcement actions resulting in significant settlements. If an organization gets only one piece of its compliance program right, this should be it.

It is also the piece that small organizations most commonly skip, attempt to satisfy with a checklist, or delegate to a vendor whose product is not actually a Security Risk Analysis under the regulation's definition. Understanding what the SRA is — and what it is not — is essential to building one that holds up under scrutiny.

What the Security Rule Actually Requires

The relevant regulation is 45 C.F.R. § 164.308(a)(1)(ii)(A), which requires every covered entity and business associate to conduct 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 regulated entity. The companion provision at § 164.308(a)(1)(ii)(B) — risk management — requires implementation of security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level.

Six words in the analysis requirement carry most of the weight: accurate, thorough, potential risks and vulnerabilities. OCR has elaborated on each in its formal Guidance on Risk Analysis Requirements under the HIPAA Security Rule, available at hhs.gov/hipaa/for-professionals/security/guidance/guidance-risk-analysis. The guidance, originally issued in 2010 and reaffirmed in subsequent OCR communications, identifies nine elements OCR expects every risk analysis to address:

1.     Scope of the analysis (all ePHI created, received, maintained, or transmitted)

2.     Data collection (where ePHI is stored, received, maintained, or transmitted)

3.     Identification and documentation of potential threats and vulnerabilities

4.     Assessment of current security measures

5.     Determination of the likelihood of threat occurrence

6.     Determination of the potential impact of threat occurrence

7.     Determination of the level of risk

8.     Documentation of the risk analysis

9.     Periodic review and updates to the risk analysis

These nine elements are the framework OCR uses to evaluate whether a risk analysis is compliant.

The SRA is not a one-time deliverable. The Security Rule's evaluation requirement at § 164.308(a)(8) requires periodic technical and nontechnical evaluation, in response to environmental or operational changes, to establish the extent to which the security policies and procedures meet the Security Rule's requirements. Most organizations should plan to revisit the SRA at least annually and after any material change — new systems, new vendors, significant staffing changes, office moves, mergers.

Why This Matters: OCR's Risk Analysis Initiative

In October 2024, OCR launched its formal Risk Analysis Initiative, explicitly focused on enforcement of § 164.308(a)(1)(ii)(A). The initiative was announced in connection with OCR's first settlement under it: the resolution agreement with Bryan County Ambulance Authority of Oklahoma ($90,000), arising from a ransomware attack that affected 14,273 patients. See HHS OCR, Resolution Agreement and Corrective Action Plan, Bryan County Ambulance Authority (Oct. 31, 2024), available through the OCR Resolution Agreements page at hhs.gov/hipaa/for-professionals/compliance-enforcement/agreements.

The initiative has continued under the new administration. By mid-2025, OCR had announced at least ten enforcement actions under or related to the initiative, with combined settlement payments approaching $1 million. Subsequent settlements have included Elgon Information Systems ($80,000, January 2025), Health Fitness Corporation ($227,816, March 2025), Guam Memorial Hospital Authority (April 2025), Vision Upright MRI ($5,000, May 2025), Comstar (May 2025), and others. In every announced settlement, OCR specifically cited the regulated entity's failure to conduct a compliant risk analysis as a central finding.

The breach data driving this enforcement attention is striking. According to OCR's December 2024 Report to Congress and the December 27, 2024 NPRM preamble (90 Fed. Reg. 898), large breach reports increased 102 percent between 2018 and 2023, and the number of individuals affected by large breaches grew by approximately 1,002 percent during the same period — exceeding 167 million individuals affected in 2023 alone, before the 2024 Change Healthcare breach. OCR explicitly identified inadequate risk analyses as a recurring deficiency contributing to these breaches.

OCR's third phase of HIPAA compliance audits, which began in December 2024 and is examining 50 covered entities and business associates, also has the Security Rule's risk analysis and risk management requirements as a primary focus.

The cumulative message from OCR is unambiguous: regulated entities should expect that any breach investigation will include scrutiny of the risk analysis, and that an absent or inadequate analysis will be treated as an independent violation regardless of the breach's other causes.

What an SRA Looks Like in Practice

A complete SRA typically runs from 30 to well over 100 pages depending on organizational complexity. The core sections, mapped to OCR's nine-element framework and to NIST guidance, include:

Scope statement. Defines what is being assessed — which entities, locations, systems, and data flows are within scope. This sounds administrative but is consequential: an SRA that excludes a location or system where ePHI actually lives is incomplete on its face.

Data inventory. Catalogs every system, application, device, and physical location that creates, receives, stores, or transmits ePHI. This includes obvious systems (EHR, billing, email) and the often-overlooked (mobile phones, voicemail, fax machines, paper records that get scanned, backup systems, archives, departing employees' personal devices). NIST SP 800-66 Rev. 2 § 5.2 (discussed below) addresses this inventory in detail.

Data flow mapping. Documents how ePHI moves between systems, between people, and between the organization and outside parties. Maps should identify every transmission point and the security controls protecting each.

Threat identification. Catalogs the threats reasonably anticipated to affect ePHI. The standard taxonomy, drawn from NIST SP 800-30 Rev. 1 (Sept. 2012), includes natural threats (fire, flood, earthquake), environmental threats (power loss, equipment failure), human threats (intentional — hackers, malicious insiders, theft; and unintentional — phishing victims, misdirected emails, lost devices), and technological threats (malware, software vulnerabilities, system failures).

Vulnerability identification. Catalogs the specific weaknesses in the organization's environment that the threats could exploit. Vulnerabilities are organization-specific — outdated software on a particular server, lack of multi-factor authentication on a specific system, untrained staff in a particular role.

Risk determination. For each threat-vulnerability pair, assesses the likelihood of occurrence and the impact if it occurred, producing a risk rating. Most SRAs use a qualitative scale (high/medium/low) or a numerical scale based on the methodology in NIST SP 800-30 Rev. 1.

Control assessment. Evaluates the current safeguards in place against each identified risk and determines whether they reduce the risk to an acceptable level.

Risk management plan. Sometimes a separate document, sometimes integrated into the SRA. Prioritizes the identified risks for remediation, assigns responsibility, and sets target completion dates. This satisfies the companion risk management requirement at § 164.308(a)(1)(ii)(B).

Methodology and standards. Documents the framework used. The two foundational NIST publications are:

•      NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments (Sept. 2012) — the federal standard for risk assessment methodology, available at nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf

•      NIST SP 800-66 Rev. 2, Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide (Feb. 2024) — NIST's HIPAA-specific guidance, finalized February 14, 2024, available at doi.org/10.6028/NIST.SP.800-66r2

NIST SP 800-66 Rev. 2 was developed in collaboration with HHS OCR and is the most authoritative non-regulatory guidance on Security Rule implementation. It includes detailed mappings between the Security Rule's standards and implementation specifications and the NIST Cybersecurity Framework Subcategories and NIST SP 800-53 Rev. 5 security controls. Any defensible SRA in 2026 should reference this document.

What an SRA Is Not

A surprising number of products and services are marketed as Security Risk Analyses but do not satisfy the regulatory requirement. Knowing what to avoid is as important as knowing what to look for.

A security questionnaire is not an SRA. Software products that walk a user through a series of yes/no questions and produce a "compliance score" generate a useful starting inventory but do not constitute an analysis. An analysis requires evaluation of likelihood and impact for identified risks (OCR Guidance, elements 5–7), not just a checklist of controls.

A penetration test is not an SRA. Penetration tests are valuable security exercises, but they assess a narrow technical question — whether specific systems can be compromised — not the full scope of risks and vulnerabilities affecting ePHI. An SRA may incorporate penetration test findings; it cannot consist of them.

A SOC 2 report is not an SRA. A SOC 2 assesses controls against the AICPA's Trust Services Criteria from the perspective of service organization users. It overlaps with HIPAA in places but does not address the Security Rule's specific requirements.

An IT vendor's "HIPAA assessment" is often not an SRA. Many managed services providers offer to perform a HIPAA assessment as part of their service. The quality varies enormously. A meaningful assessment requires healthcare compliance expertise on top of technical security expertise; many MSPs have the latter without the former.

Last year's SRA, unchanged, is not this year's SRA. OCR's enforcement record repeatedly cites organizations for relying on outdated risk analyses. See OCR Guidance on Risk Analysis (risk analysis is a "continuous process" requiring periodic review and updates). Annual review is the floor, not the ceiling.

Who Can Perform an SRA

The Security Rule does not require an external assessor — an organization can perform its own SRA. In practice, the choice depends on the organization's size, complexity, internal expertise, and risk tolerance.

External compliance consulting firms. The most common path for small to mid-size organizations. Firms specializing in healthcare compliance offer SRAs as a core service, typically delivering a written report, a risk management plan, and a remediation roadmap. Cost ranges from approximately $5,000 for a very small organization to $25,000 or more for a complex one. Look for firms that reference NIST SP 800-30 and NIST SP 800-66 Rev. 2 methodology, have healthcare-specific experience (not just generic cybersecurity backgrounds), and can provide references from clients in your sector.

Healthcare-focused cybersecurity firms. For organizations with significant technical complexity — substantial cloud infrastructure, custom applications, multi-site operations — a firm with deeper security engineering capability may be appropriate. These engagements cost more, often $20,000 to $75,000, but produce more technically rigorous output.

Law firm-led assessments. Some healthcare law firms coordinate SRAs by engaging a compliance consultant as a subcontractor under the attorney's engagement letter. This structure can provide attorney-client privilege protection for the working papers and findings under Upjohn Co. v. United States, 449 U.S. 383 (1981), which is valuable if the organization anticipates litigation or regulatory action. See also In re Kellogg Brown & Root, Inc., 756 F.3d 754 (D.C. Cir. 2014) (analyzing privilege protection for internal investigations). The cost is higher than a direct consulting engagement, but for sensitive situations the privilege protection can be worth it.

Managed services providers. Some healthcare-focused MSPs include SRAs in their service offerings. This can be efficient but creates an independence concern: an MSP assessing the adequacy of controls it also implements and maintains is not a fully independent evaluator. For organizations where independence matters — particularly business associates demonstrating compliance to sophisticated covered entity partners — a separate assessor is preferable.

Self-assessment using federal tools. HHS and ONC jointly publish a free Security Risk Assessment Tool, downloadable from HealthIT.gov at healthit.gov/topic/privacy-security-and-hipaa/security-risk-assessment-tool. It is explicitly endorsed by HHS for small organizations and produces a real document. For a very small organization with limited PHI and minimal complexity, it is a defensible starting point. For an organization that needs to demonstrate compliance to institutional partners, it is rarely sufficient on its own — sophisticated compliance teams will ask who conducted the SRA, and "we used the HHS tool ourselves" tends not to satisfy them.

Questions to Ask Any Prospective Assessor

Before engaging any party to perform an SRA, an organization should be able to get clear answers to:

•      What methodology will you use? (NIST SP 800-30 Rev. 1 and NIST SP 800-66 Rev. 2 are the answers you want to hear.)

•      Will the deliverables cover all nine elements identified in OCR's risk analysis guidance?

•      What will the deliverables include? (Risk Analysis Report, Risk Management Plan, remediation roadmap at minimum.)

•      Have any of your past SRAs been reviewed by OCR? What was the outcome?

•      How much time will my staff need to commit? (Real answer: meaningful — interviews, document collection, system access.)

•      Will you assess our actual environment, or work from a questionnaire? (You want actual environment assessment.)

•      What is your healthcare-specific experience?

•      How do you handle subcontractors and remote work environments?

•      What is your fee structure, and what is in scope versus out of scope?

What Staff Time the Organization Should Expect to Contribute

The SRA is not something the consultant can do to the organization. It requires substantial cooperation from inside. For a small organization, expect:

•      20 to 40 hours of senior leadership time for interviews and decisions

•      10 to 30 hours of IT or operational staff time for system inventories and access

•      Document production: BAAs, vendor contracts, prior assessments, policies, incident logs

•      Active participation in scoping, methodology selection, and final review

Organizations that try to minimize their own involvement get the assessment they pay for: a generic deliverable that does not actually reflect their environment and would not survive scrutiny.

What to Do With the Findings

The SRA is the beginning, not the end, of risk management. The required follow-through includes:

Implementing the Risk Management Plan. OCR's expectation, drawn from § 164.308(a)(1)(ii)(B), is that identified risks are actively remediated, with progress documented. The single most common enforcement finding in OCR's Risk Analysis Initiative is not the absence of an SRA but the failure to implement risk management measures responsive to the SRA's findings.

Documenting remediation decisions. Some identified risks will not be fully remediated — the cost may exceed the benefit, or the residual risk may be acceptable. These are legitimate decisions, but they must be documented as risk acceptance decisions by appropriate leadership, not left implicit. Documentation must be retained for six years from creation or last effective date, whichever is later. See 45 C.F.R. § 164.316(b)(2)(i).

Updating policies and procedures. SRA findings often drive policy updates. The updates need to actually happen and need to be reflected in workforce training under § 164.308(a)(5).

Re-assessing periodically. At minimum annually, and after material changes. The SRA should be a living document.

Pending Regulatory Change

The December 2024 Security Rule NPRM (90 Fed. Reg. 898) would significantly expand the risk analysis requirement. Among other changes, the proposed rule would require regulated entities to develop and maintain a written technology asset inventory and network map, conduct risk analyses at least every 12 months and after specified events, and explicitly document the methodology used. The proposed rule would also eliminate the addressable/required distinction, making all currently-addressable specifications mandatory. While the proposed rule has not been finalized, its substantive requirements largely reflect OCR's current enforcement expectations, and organizations building SRAs in 2026 should design programs that would substantially satisfy the proposed framework.

What This Means Practically

For an organization standing up HIPAA compliance, the SRA should be one of the first major operational deliverables — after the threshold analysis and the BAA template work, but before significant investment in technology or training. The SRA findings drive what training is needed, what technology controls are appropriate, what vendor contracts must be renegotiated, and how the policy library should be prioritized.

Budget realistically. For a small organization, the SRA itself will cost $5,000 to $25,000, and the remediation work it identifies will cost meaningfully more — often two to five times the SRA's own cost in the first year. Organizations that do not budget for remediation produce SRAs that sit on shelves, which is among the worst possible outcomes: documented knowledge of risks the organization has not addressed. Under OCR's current enforcement posture, that documentation can support a finding of willful neglect.

Up next in Part 4: Administrative, Physical, and Technical Safeguards — translating the Security Rule's three safeguard categories into specific operational steps your organization can actually take.

Selected Authorities and Resources

Statutory and regulatory:

•      45 C.F.R. § 164.306 (security standards: general rules)

•      45 C.F.R. § 164.308(a)(1) (security management process)

•      45 C.F.R. § 164.308(a)(1)(ii)(A) (risk analysis — required implementation specification)

•      45 C.F.R. § 164.308(a)(1)(ii)(B) (risk management — required implementation specification)

•      45 C.F.R. § 164.308(a)(8) (evaluation)

•      45 C.F.R. § 164.316 (policies and procedures and documentation requirements)

•      HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information, 90 Fed. Reg. 898 (Jan. 6, 2025) (proposed)

HHS/OCR guidance:

•      HHS OCR, Guidance on Risk Analysis Requirements under the HIPAA Security Rule (rev. 2010 and following), hhs.gov/hipaa/for-professionals/security/guidance/guidance-risk-analysis

•      HHS OCR, Risk Analysis Initiative announcement (Oct. 2024), and subsequent Resolution Agreements at hhs.gov/hipaa/for-professionals/compliance-enforcement/agreements

•      HHS OCR, Report to Congress on HIPAA Privacy, Security, and Breach Notification Rule Compliance for Calendar Year 2022 (Feb. 2024)

NIST guidance:

•      NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments (Sept. 2012)

•      NIST SP 800-66 Rev. 2, Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide (Feb. 2024)

•      NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (Sept. 2020, with updates)

•      NIST Cybersecurity Framework 2.0 (Feb. 2024)

Federal SRA tool:

•      HHS and ONC, Security Risk Assessment Tool, healthit.gov/topic/privacy-security-and-hipaa/security-risk-assessment-tool

Privilege authority for counsel-led assessments:

•      Upjohn Co. v. United States, 449 U.S. 383 (1981)

•      In re Kellogg Brown & Root, Inc., 756 F.3d 754 (D.C. Cir. 2014)

Representative recent enforcement actions citing inadequate risk analysis:

•      Bryan County Ambulance Authority Resolution Agreement (Oct. 31, 2024) ($90,000)

•      Elgon Information Systems Resolution Agreement (Jan. 7, 2025) ($80,000)

•      Health Fitness Corporation Resolution Agreement (Mar. 21, 2025) ($227,816)

•      Vision Upright MRI Resolution Agreement (May 15, 2025) ($5,000)

•      Comstar, LLC Resolution Agreement (May 30, 2025)