Healthcare IT Compliance

What Does an Accurate and Thorough HIPAA Security Risk Assessment Actually Look Like?

Continuous ·

Many healthcare organizations can say they have completed a HIPAA Security Risk Assessment. The harder question is whether that assessment is actually accurate and thorough. A vulnerability scan, cybersecurity checklist, or list of technical findings may identify useful issues, but none of those alone provides a complete picture of risk to electronic protected health information (ePHI).

A defensible HIPAA Security Risk Assessment must look across the entire environment, identify where ePHI exists, examine threats and vulnerabilities, evaluate existing safeguards, determine likelihood and impact, assign risk levels, document the findings, and remain current as the organization changes. If any of those pieces are missing, the assessment may provide a false sense of security rather than a reliable foundation for risk management.

A Security Risk Assessment Is More Than a Vulnerability Scan

A HIPAA Security Risk Assessment evaluates risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI across the organization. A vulnerability scan may support that process by identifying technical weaknesses, but it does not address the full scope of people, processes, systems, threats, safeguards, and business risks that an accurate and thorough risk analysis should consider.

This distinction matters because security risk exists far beyond missing patches or vulnerable software.

An organization may have technically secure servers but still have excessive employee access. It may have encrypted laptops but no documented process for removing access when employees leave. It may have working backups but no clear understanding of how a prolonged outage would affect patient care or operations. It may use secure cloud applications without maintaining an accurate inventory of which platforms contain ePHI.

A vulnerability scan can identify some technical weaknesses. An SRA needs to connect those findings to the larger environment and determine what they actually mean for the organization.

Think of the SRA as the Foundation of Risk Management

The purpose of the assessment is not simply to generate a report. It should give leadership, compliance, and IT teams a clear picture of where ePHI exists, what could threaten it, which safeguards are already in place, where weaknesses remain, and which risks need attention first.

That requires more than a yes-or-no checklist. A useful SRA should be specific enough that the organization can turn its findings into an actionable remediation plan.

The Nine Elements of an Accurate and Thorough SRA

A thorough Security Risk Assessment follows a structured process. Each element builds on the one before it: define what is in scope, understand where ePHI exists, identify what could go wrong, evaluate current safeguards, determine likelihood and impact, assign risk, document the findings, and continue updating the analysis as the environment changes.

Element 1: Scope — All ePHI, Everywhere

The first step is determining what the assessment actually covers. The scope should include all ePHI the organization creates, receives, maintains, or transmits.

That means looking beyond the primary EHR system. Depending on the organization, ePHI may also exist in:

• Workstations and laptops
• Mobile devices
• Email systems
• Cloud applications
• File storage platforms
• Backup environments
• Billing or practice management applications
• Telehealth platforms
• Third-party vendor systems
• Remote-access workflows

If a system or workflow containing ePHI is left outside the assessment, the organization cannot accurately evaluate the risk associated with it.

Element 2: Data Collection — Know Where ePHI Lives

Once the scope is defined, the organization needs to identify and document where ePHI is stored, received, maintained, and transmitted.

An accurate technology and asset inventory plays an important role here. The organization should be able to connect ePHI to the systems, devices, applications, and transmission methods involved in handling it.

This is one of the reasons a generic questionnaire can fall short. Answering that the organization "uses encryption" does not show which devices are encrypted, which systems contain ePHI, whether every relevant device is included, or where the information moves after leaving the primary application.

Element 3: Identify and Document Threats AND Vulnerabilities

A thorough assessment looks at both threats and vulnerabilities.

Threats may be technical or non-technical and can originate from people, technology, natural events, or environmental conditions. Examples could include ransomware, employee mistakes, credential theft, equipment failure, lost devices, unauthorized access, power outages, or natural disasters.

Vulnerabilities might include outdated systems, weak access controls, untested backups, missing policies, excessive user permissions, inadequate training, poor vendor oversight, or gaps in physical security.

The important part is connecting the two. A vulnerability becomes meaningful when the organization understands the threat that could take advantage of it and the resulting effect on ePHI.

Element 4: Assess Current Security Measures

The assessment should document the safeguards that are already in place and evaluate whether they are functioning as intended.

This could include:

• Access controls
• Multi-factor authentication
• Endpoint protection
• Encryption
• Security monitoring
• Backup and recovery processes
• Security awareness training
• Incident response procedures
• Physical safeguards
• Vendor management processes

The key is not simply documenting that a safeguard exists. The assessment should help determine whether it is appropriate for the environment and whether it is actually working.

For example, an organization may have multi-factor authentication enabled for its primary EHR while leaving another system containing ePHI protected only by a password. A policy may require quarterly access reviews even though no review has occurred in the past year. Those distinctions matter.

Element 5: Determine the Likelihood of Threat Occurrence

Once threats and vulnerabilities are identified, the organization should evaluate how likely each threat-vulnerability combination is to result in an adverse event.

Likelihood does not need to be predicted with perfect certainty. The goal is to apply a consistent methodology for determining whether an event is relatively unlikely, possible, likely, or highly likely based on the organization's environment and circumstances.

A vulnerability affecting an internet-facing system, for example, may carry a different likelihood than a weakness in a disconnected system with extremely limited access.

Documenting how likelihood was determined helps make the final risk rating understandable and defensible.

Element 6: Determine the Potential Impact

Likelihood is only half of the risk equation. The organization also needs to consider what could happen if the event actually occurs.

Potential impact may include:

• Operational impact: Could systems become unavailable or interrupt patient services?
• Security impact: Could ePHI be accessed, altered, destroyed, or exposed?
• Financial impact: Could the organization face recovery costs, downtime, lost revenue, or other expenses?
• Regulatory impact: Could the event create HIPAA reporting, investigation, or compliance concerns?
• Business impact: Could the event affect patient trust, vendor relationships, contracts, or organizational reputation?

The same vulnerability can create very different levels of risk depending on the information, system, and business process involved.

Element 7: Assign Risk Levels

The organization should combine likelihood and impact to assign an overall risk level to each identified issue.

A simple methodology might categorize risks as low, medium, or high. More complex organizations may use a numerical scoring model or risk matrix. The exact model is less important than using it consistently and documenting how the organization reached each rating.

Risk Factor	Question to Answer
Threat	What could happen?
Vulnerability	What weakness could allow it to happen?
Likelihood	How probable is the event?
Impact	How serious would the consequences be?
Risk Level	How urgently should the organization respond?

Risk levels help organizations prioritize. A long report containing dozens of findings is much more useful when decision-makers can clearly see which items require immediate action and which can be addressed through longer-term risk management.

Element 8: Document Everything

An SRA should result in written documentation that explains the scope, methodology, findings, risk levels, and supporting information used during the analysis.

The organization should be able to understand:

• What was reviewed
• Which systems and ePHI were included
• Which threats and vulnerabilities were identified
• What safeguards were evaluated
• How likelihood was determined
• How impact was determined
• What overall risk level was assigned
• What supporting evidence was used

A spreadsheet showing red, yellow, and green findings without enough context to understand how those ratings were determined may be useful as a summary, but it should not be the entire analysis.

The documentation should tell the story behind the findings.

Element 9: Ongoing Review and Updates

A Security Risk Assessment should reflect the environment the organization actually operates today. Technology, people, vendors, threats, and workflows change constantly.

Changes that may require an organization to revisit its analysis include:

• Adding a new application or cloud platform
• Changing EHR or practice management systems
• Opening or relocating an office
• Adopting new remote-work or telehealth processes
• Adding devices or medical technology
• Changing vendors or subcontractors
• Discovering new security threats or vulnerabilities
• Experiencing a security incident
• Making significant changes to the network or IT environment

A risk analysis that accurately reflected the environment two years ago may no longer accurately describe the organization today.

That is what compliance support for healthcare practices from Continuous is structured to deliver: not a completed checklist handed back once a year, but an active approach to identifying changes, understanding risk, and maintaining the documentation needed to support ongoing compliance. For organizations that also need to strengthen the underlying security environment, cybersecurity built for healthcare operations addresses the network, endpoint, access, monitoring, and security controls that support that risk-management process.

How to Tell If Your Current SRA Is Incomplete

A risk assessment may be incomplete if it focuses primarily on technical vulnerabilities without documenting the full ePHI environment, threats, safeguards, likelihood, impact, and resulting risk levels.

Common warning signs include:

• It is really a vulnerability scan: The report focuses on patches, software versions, and technical findings but does not evaluate the broader organization.
• There is no clear ePHI scope: The organization cannot identify which systems, applications, devices, and vendors were included.
• There is no asset inventory: The organization cannot confidently identify the technology involved in creating, receiving, maintaining, or transmitting ePHI.
• Threats and vulnerabilities are treated as the same thing: Findings identify weaknesses without evaluating what could exploit them.
• Safeguards are assumed rather than validated: The assessment says controls exist but provides little evidence that they are functioning.
• There is no likelihood or impact analysis: Findings are labeled high or low risk without explaining why.
• There is no remediation connection: The report identifies problems but does not help the organization prioritize and manage them.
• It has not changed as the environment changed: Major systems, staff workflows, vendors, or technology have changed since the assessment was completed.

From Risk Analysis to Risk Management

The SRA identifies and evaluates risk. Risk management is what the organization does with those findings. A strong assessment should make it possible to create a clear remediation plan with priorities, owners, timelines, and documented progress.

A high-risk finding should not disappear into a PDF after the assessment is complete. The organization should decide how it will address the risk, assign responsibility, document the planned action, and track the issue through resolution or another documented risk-management decision.

This is where the difference between a checkbox SRA and a useful SRA becomes obvious.

A checkbox assessment tells you that you completed an assessment.

An accurate and thorough assessment gives leadership enough information to make informed decisions about security, compliance, budgeting, technology, and risk.

Frequently Asked Questions