Security risk analysis

Editorial approval scope: The team checked current source fidelity, scope boundaries, dates, arithmetic, reader usefulness, practical workflow, and general-information limitations.

HIPAA requires an enterprise-wide analysis

The HHS Security Rule page describes national ePHI safeguards for covered entities and business associates. Current 45 CFR 164.308(a)(1)(ii)(A) makes risk analysis a required implementation specification within the security-management process.

HHS risk-analysis guidance says the scope includes potential risks and vulnerabilities to all ePHI the organization creates, receives, maintains, or transmits. A vendor's custody or control does not remove that ePHI from scope. Include vendor platforms, cloud storage, email, messages, recordings, spreadsheets, interfaces, backups, devices, remote work, physical sites, and inactive systems that retain data.

Begin with the legal entity and its role. An ABA organization may be a covered provider, a business associate for work on behalf of another covered entity, a hybrid entity with designated health care components, or outside HIPAA. Record the entity, role, transaction, contract, and any formal hybrid designation instead of informally partitioning activities.

Inventory data flows and dependencies

An asset list is a start. Map how ePHI enters, moves, changes, is accessed, is backed up, and leaves. For each flow, record:

A vendor questionnaire or certificate can inform the analysis. It cannot replace evidence about configuration, data flows, behavior, dependencies, and shared controls. The practice and a business associate may each have duties for the same service.

Connect threats to real vulnerabilities

A threat is a circumstance or event capable of harming ePHI or a system. A vulnerability is a weakness that the threat could exploit or trigger. Risk arises from their combination and the resulting impact.

Human threats can be intentional or accidental, including phishing, inappropriate access, or a misdirected export. Environmental threats include fire, flood, power loss, and connectivity failure. Technology threats include malware, software flaws, key loss, interface errors, hardware failure, and backup corruption.

Write risk statements that another reviewer can test. “Cyberattack” is too vague. A stronger record might state: “A stolen workforce password could exploit missing multifactor authentication on the payer portal, exposing client identifiers and authorization records and delaying scheduling.” Link the statement to affected systems, ePHI, existing controls, and evidence.

Evaluate safeguards before rating risk

Record which administrative, physical, and technical safeguards are operating now. Planned tools belong in the treatment plan rather than the current-control column. Evidence might include a configuration export, restoration result, access sample, alert, policy, training record, physical inspection, or vendor assurance.

HHS describes risk as a function of the likelihood that a threat will trigger or exploit a vulnerability and the resulting impact. The Security Rule permits an organization to choose a method suited to its size, complexity, capabilities, infrastructure, cost, and risk. A high-medium-low matrix can work when every level has a definition and reviewers apply it consistently. Numeric precision does not repair weak evidence.

Impact should consider confidentiality, integrity, and availability, including care continuity, client safety, record reliability, legal or contract exposure, affected scale, and recovery difficulty. Record uncertainty instead of forcing unsupported facts into a confident score.

Analysis and management have different outputs

The HHS analysis-versus-management FAQ separates assessment from implementation. Analysis identifies and rates risk. A risk management plan prioritizes measures, owners, deadlines, tests, and residual-risk decisions.

A vulnerability scan, penetration test, checklist, gap assessment, or audit examines only part of the picture. Each can provide valuable evidence. None is automatically an accurate and thorough analysis of all ePHI.

The security risk analysis also differs from the Breach Notification Rule's four-factor assessment after an impermissible PHI use or disclosure. Keep the enterprise analysis, incident investigation, and breach determination separate and connected.

Reassess when the environment changes

The current HHS Security Rule summary calls for regular reevaluation of potential ePHI risks and periodic evaluation of security measures. HHS guidance says the rule sets no single analysis frequency.

Define a cadence and event triggers. Reassess as material changes are planned, then update the record with implementation evidence. Examples include a new site, acquisition, vendor, integration, device fleet, record type, remote-work design, or major configuration. Incidents, failed restores, excessive access, new threats, and control-test failures also trigger updates.

Preserve the analysis version, scope, contributors, method, evidence dates, findings, assumptions, exclusions, approvals, and superseded records. A yearly document that omits a midyear acquisition remains incomplete for the enlarged environment.

Keep the January 2025 proposal separate

HHS identifies the January 6, 2025 notice as a proposed rule and says the current Security Rule remains in effect. Current Section 164.308(a)(1)(ii)(A) requires an accurate and thorough analysis; current HHS guidance prescribes neither one method nor a universal review frequency.

The NPRM would expressly require a written, comprehensive analysis with specified elements, a written technology-asset inventory and network map, and review at least annually and after relevant changes. Current guidance already expects identification and documentation of all ePHI. Treat the added details as proposal-readiness measures, not current-law duties.

A fictional scope review exposes gaps

A fictional ABA practice inventories 27 system and vendor records. Twenty-three directly create, receive, maintain, or transmit ePHI. Of four that do not, two affect identity, network, or backup controls and remain in the analysis; two are isolated and have documented no-ePHI, no-impact determinations. The locked cohort is 25.

Twenty-one of 25 have a current data flow, threat and vulnerability assessment, control evidence, likelihood and impact rating, and linked treatment decision. Documented coverage is 21 of 25, or 84%. Four stay open: a legacy portal, a mobile export, a new interface, and a vendor backup location.

The practice should not report 21 of 21 by excluding incomplete items after discovery. These figures measure documented coverage, not rating correctness or Security Rule compliance.

Measure scope and evidence quality

Useful measures include ePHI systems with current analysis records divided by ePHI systems in scope; material changes assessed by release divided by changes due; risk statements with current control evidence divided by statements reviewed; high-risk findings linked to owned actions divided by high-risk findings; and overdue analysis gaps closed by target divided by gaps due.

Report unassessed assets, stale evidence, unknown flows, vendor gaps, inconsistent ratings, and open assumptions. Define the inventory version, inclusion rule, date, trigger, numerator, denominator, exclusions, owner, and evidence standard before interpreting a rate.

The ONC Security Risk Assessment Tool is designed to help small and medium health care providers. ONC states that its use is optional, may not fit every organization, and does not guarantee compliance. Treat the tool as one possible workflow rather than a certificate.