HIPAA Security Risk Analysis

Healthcare’s threat surface keeps expanding, but a proper HIPAA Security Risk Analysis helps keep patient data safe.

Cloud migrations, remote work, third-party platforms, and AI tools create more places where electronic protected health information (ePHI) is created, stored, processed, and transmitted. In this environment, the HIPAA Security Risk Analysis remains the control that anchors the program in reality.

Weak HIPAA security risk analyses correlate with enforcement findings, operational disruption, and documented patient risk. This article clarifies what a HIPAA Security Risk Analysis is, why it matters, and how to build one that holds up against scrutiny. 

What Is the HIPAA Security Risk Analysis?

A HIPAA Security Risk Analysis evaluates where ePHI is created, received, maintained, or transmitted, and how it could be compromised, then documents how the organization will reduce those risks to a reasonable and appropriate level.

In practice, that means:

• Scoping systems, identities, and data flows to support the HIPAA Security Risk Analysis
• Identifying reasonably anticipated threats and vulnerabilities supports the HIPAA Security Risk Analysis
• Estimating likelihood and impact,
• Recording both inherent and residual risks allows leaders to prioritize actions against real workflows and vendor pathways

HHS frames HIPAA Security Risk Analysis as foundational because it informs the selection of safeguards and technologies.

What Are the Legal Requirements of a HIPAA Security Risk Analysis?

The Security Rule requires two paired implementation specifications. Covered entities and business associates must conduct an accurate and thorough HIPAA Security Risk Analysis, then manage the risks to a reasonable and appropriate level.

These duties appear in 45 C.F.R. § 164.308(a)(1)(ii) (A) for HIPAA Security Risk Analysis and § 164.308(a)(1)(ii)(B) for Risk Management.

How Often Should Organizations Update Their HIPAA Security Risk Analysis?

HIPAA does not prescribe a fixed timetable. OCR explains that HIPAA Security Risk Analysis is an ongoing activity that must be reviewed and updated as needed, such as when environmental or operational changes affect the security of ePHI.

Common triggers include:

• Significant incidents – supports the HIPAA Security Risk Analysis
• New modules or systems – supports the HIPAA Security Risk Analysis
• Workflow changes – supports the HIPAA Security Risk Analysis
• Mergers or acquisitions
• Onboarding higher-risk business associates

Many teams run a formal update each year and perform targeted re-runs on these triggers. The key is to align updates with reality. 

Key Roles for the HIPAA Security Risk Analysis

Legally, the covered entity or business associate is responsible, including when third parties assist. The Security Rule also requires a designated security official who is responsible for developing and implementing the program described in Subpart C.

Effective HIPAA security risk analyses involve:

• Privacy and compliance leadership
• IT and security
• HIM or ROI teams
• Clinical leaders
• Legal counsel

This structure ensures that the scope, findings, and remediation reflect the entire enterprise rather than a single system or department. 

HIPAA Security Risk Analysis Outputs

Leaders should expect practical documentation they can use.

• A current ePHI data map and architecture view clarifies scope.
• A reconciled asset and identity inventory ties systems and accounts to ePHI.
• A living risk register captures owners, treatments, target dates, and residual scores.
• A dated remediation plan translates priorities into funded work.
• An indexed evidence pack proves controls operate with items such as access reviews, configuration baselines, vulnerability and patch cadence, backup and recovery tests, and training records.
• NIST SP 800-66 Rev. 2 maps these outputs to HIPAA safeguards for organizations of any size.

What “Reasonable and Appropriate” Means in Practice

The Security Rule uses flexibility of approach. Entities tailor safeguards based on size, complexity, capabilities, infrastructure, and the probability and criticality of risks.

Several technical safeguards, such as encryption, are addressable. Addressable means entities must implement the safeguard where reasonable and appropriate or document an equivalent alternative or a reason the safeguard is not reasonable.

Documentation and Retention

The Security Rule requires written policies and procedures and documentation of actions, activities, and assessments. That includes the HIPAA Security Risk Analysis, risk management (guided by the HIPAA Security Risk Analysis) decisions, and updates.

Documentation must be retained for six years from the date of creation or the last effective date, whichever is later, and must be available to those responsible for implementation. Clear traceability from risk to treatment to dated proof is what allows programs to withstand audits and investigations. 

Recognized Security Practices Can Mitigate Enforcement Exposure

Under the 2021 amendment to HITECH, Public Law 116-321, OCR must consider whether a regulated entity had recognized security practices in place for the prior 12 months when making certain enforcement and audit determinations.

OCR has described how entities can demonstrate those practices, such as NIST CSF aligned programs or 405(d) Health Industry Cybersecurity Practices, and has clarified this is a mitigating factor, not a safe harbor. Programs that operationalize recognized practices alongside a strong HIPAA Security Risk Analysis have better footing in investigations. 

Key Risks at a Glance

These are the risks that appear most often in audits, settlements, and sector research. Each subsection outlines the exposure and the shortcomings that keep HIPAA Security Risk analyses from passing muster. Use them to stress-test your current approach. 

Most Organizations Still Miss HIPAA Security Risk Analysis Fundamentals

OCR’s national audit of 166 covered entities and 41 business associates found only 14% of covered entities and 17% of business associates substantially met the HIPAA Security Risk Analysis requirement.

On Risk Management, the compliance ratings were 6% for covered entities and 12% for business associates. Recurring failure modes included partial ePHI scoping, reliance on templates without entity-specific analysis, and a weak or nonexistent link from identified risks to funded remediation. 

Common shortcomings include:

• Inventories that do not link systems or identities to ePHI
• one-time analyses with no triggers to re-run after material change
• Control descriptions without dated proof of operation
• Evidence limited to program attestations rather than an enterprise-wide view of risk and safeguards.

Poor HIPAA Security Risk Analyses and Cyber Events

A JAMA Network Open cohort study found hospital cyber events were associated with regional disruptions, including higher emergency department volumes and delays for time-sensitive care at neighboring hospitals.

Economic research linked ransomware attacks to higher hospital mortality among patients already admitted when an attack began, with the largest effects during severe incidents. Weak HIPAA security risk analyses often overlook downtime risks, backup and restore realities, and clinical workarounds. Those gaps translate to worse outcomes during real events.

Where HIPAA Security Risk analyses fall short:

• No explicit analysis of downtime risk for EHR, PACS, revenue cycle, imaging routing, or e-fax.
• Backups and disaster recovery plans without recent restore or failover test evidence.
• No documented tabletop drills that validate decision paths, communications, and clinical workarounds.

Third-Party Incidents Amplify Impact

Healthcare’s dependence on clearinghouses, cloud services, and niche vendors concentrates risk. In 2024, 41.2% of tracked third-party breaches affected healthcare organizations.

This underscores why business associate data flows and oversight belong within the scope of HIPAA Security Risk Analysis rather than in a separate vendor exercise.

Telltale gaps include:

• BAAs that are current on paper but misaligned with actual services and data flows.
• Reviews that collect reports yet do not track findings to closure with evidence.
• No tiering by ePHI sensitivity or service criticality

Breach Costs Continue to Climb

IBM’s 2024 report placed the global average breach cost at $4.88 million, with healthcare again the most expensive sector at $9.77 million per breach on average. These totals reflect disruption, response, and lost business, not just fines.

Even when penalties are modest, weak HIPAA Security Risk analyses show up later as prolonged recovery, extended downtime, and higher churn among patients and referring providers.

What weak programs share:

• No measurable link between the risk register and budgets.
• Risk acceptances without compensating controls or time-boxed reviews.
• KPI dashboards that count policies produced rather than evidence that controls operate or recoveries meet objectives.

Program Governance and Reporting

Programs depend on ownership. Name an executive sponsor and the required security official and involve privacy and compliance, IT and security, HIM, clinical leadership, and counsel.

Set a quarterly cadence with a standard agenda so scope, analysis, remediation, vendor oversight, and evidence stay current. Emphasize operational and outcome oriented metrics that leaders can act on.

Examples include:

• percent of high-risk items mitigated on time,
• restore success versus recovery time objective and recovery point objective,
• access review completion and exceptions closed,
• phishing failure trend and remedial training completion,
• and patch service levels by system class.

A one-page summary with these metrics gives leaders a reliable view of momentum and blockers. 

The 90 Day Turnaround Plan

When the HIPAA Security Risk Analysis is behind or scattered across systems and inboxes, a structured quarter can create visible progress and a defensible record.

Days 1 to 30. Finish scope and reconcile inventories.

1. Produce a one-page ePHI map that includes business associates and downstream services.
2. Reconcile the asset and identity inventory into a single list tagged for ePHI presence, location, and criticality.
3. Name business and technical owners for each critical system.
4. Confirm backup coverage and the last successful restore for those systems.

Days 31 to 60. Refresh the risk register and fund the top items.

1. Write asset linked risk statements in plain language.
2. Score inherent and residual risk with a simple rubric.
3. Assign owners and dates.
4. Map each high-risk item to a HIPAA safeguard and a recognized practice such as HICP or NIST 800-66, then request or allocate budget.
5. Define the operating evidence that will prove success.

Days 61 to 90. Implement high value controls and stage evidence.

1. Prioritize identity and endpoint hardening for accounts and devices that handle ePHI.
2. Complete at least one restore test for a critical system and log scope, results, and corrective actions.
3. Run one ransomware tabletop that includes a high risk business associate.
4. Build the evidence index with links to dated proof.
5. At day 90, provide a one-page summary of residual risk movement, controls implemented, and evidence staged.

Preparing for an OCR Request

Preparation shortens response time and reduces errors. Expedited requests are common. Letters often set deadlines within 10 to 30 days. Pre-stage a response playbook that names a coordinator, lists the document index, and describes version control and the secure workspace for collaboration. When a request arrives, freeze copies for the record while the team works from staged materials.

A tabletop drill once a year tests the process and yields practical improvements. Programs that can produce the scope pack, risk register, and evidence index on demand typically move through review faster.

More than one method can satisfy HIPAA if it is applied consistently, accurately scoped, and linked to prioritized, funded remediation.

What matters most are the outcomes. Complete scope, credible scoring, visible owners and dates, and evidence that controls operate. 

FAQ

Does a penetration test or EHR certification cover the HIPAA Security Risk Analysis?

No. A pen test is a useful input, not a substitute for an enterprise-wide HIPAA Security Risk Analysis and risk management (guided by the HIPAA Security Risk Analysis) program. EHR certification does not satisfy the Security Rule’s required implementation specifications at 45 C.F.R. § 164.308(a)(1)(ii)(A) and § 164.308(a)(1)(ii)(B).

How often is enough?

At least annually and after material change is a prudent practice. HIPAA’s requirement is an ongoing analysis updated as needed. Define re-run triggers in policy so updates occur when reality changes rather than only on a calendar. 

What evidence is enough?

Proof that controls operate, not just exist. Keep recent logs, exports, and test results and index them to specific risks and systems. Reviewers look for traceability from risk to control to dated proof.

Do recognized security practices reduce exposure in enforcement?

OCR must consider whether recognized practices were in place and operating during the prior 12 months. This can mitigate penalties and remedies, although outcomes remain discretionary. 

Protect Data, Prove Compliance, Move Faster

ChartRequest offers medical records exchange software and services to standardize requests and improve compliance.

When records move through ChartRequest, protection is built in and proof is easy to show. Our SOC 2 Type II and HITRUST-compliant systems safeguard sensitive information while your team works inside standardized, auditable workflows.

What you can rely on:

• Encryption in transit and at rest with strict, least-privilege access controls

• Unique logins and MFA with detailed audit logs for every action

• Standardized ROI steps that reduce errors and shorten turnaround times

• Exportable receipts and delivery records that make reviews straightforward

Meet with our team to review your compliance goals and see ChartRequest in action.