What Is a Security Risk Analysis?

The Security Risk Analysis, often shortened to SRA, is one of the most important documents in a HIPAA compliance program. It is also one of the most frequently missing, incomplete, or out of date.

What the rule requires

Under the HIPAA Security Rule, covered entities and business associates must conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information they hold (45 CFR 164.308(a)(1)(ii)(A)).

The rule then requires risk management: implementing security measures sufficient to reduce those risks and vulnerabilities to a reasonable and appropriate level. The analysis identifies the risks; risk management addresses them.

HHS has published guidance on risk analysis describing what it expects the process to include.

What a useful risk analysis covers

Scope. Every place electronic PHI is created, received, stored, or transmitted. That includes the EHR, but also email, practice management and billing systems, imaging, patient portals, laptops and phones, backup media, cloud services, and vendors' systems.

Threats and vulnerabilities. For each part of the environment, what could go wrong and why. Examples include phishing, lost devices, former employees with active accounts, unpatched systems, and a vendor breach.

Current safeguards. What controls already exist, and whether they work as intended.

Likelihood and impact. How likely each threat is to occur, and how serious the result would be.

Risk level. A rating that combines likelihood and impact, so the organization can prioritize.

Documentation. A written record of the process and its findings.

Common shortcomings

• The analysis covers the EHR but not email, devices, or vendors.
• It is a questionnaire with yes or no answers rather than an assessment of risk.
• It identifies risks but has no plan or decisions attached to them.
• It was completed once and never updated.
• It describes a prior environment, before a new system, location, or acquisition.

An IT vulnerability scan or a security product report can be useful input, but it is not a risk analysis on its own. The analysis also has to consider people, workflows, physical security, and administrative processes.

From analysis to risk management

Each significant risk should have a documented response: a safeguard to implement, an owner, a target date, and a record of completion. Some risks may be accepted, but the decision and reasoning should be written down. This risk management record is what shows the analysis led somewhere.

How often to update it

The Security Rule does not set a fixed schedule for the risk analysis. HHS describes it as an ongoing process. Many organizations review it at least annually. It should also be revisited when the environment changes, for example after:

• Adopting a new EHR or major system
• Opening or acquiring a location
• Adding vendors with access to PHI
• Enabling remote work or new remote access
• A security incident

HHS has proposed updates to the Security Rule that would add more specific requirements. As of this article's date, they have not been finalized. Check current HHS guidance for the latest status.

Tools

HHS offers a free Security Risk Assessment Tool designed for small and medium-sized providers. It can help structure the process, though the quality of the result depends on the care taken in completing it.