How to Conduct a Thorough and Accurate Security Risk Analysis

How to Conduct a Thorough and Accurate Security Risk Analysis

A HIPAA Security Risk Analysis (SRA) is not a software checklist, a cybersecurity scan, or a once-a-year paperwork exercise. It is the process of identifying where electronic protected health information (ePHI) exists, determining the threats and vulnerabilities that could impact it, evaluating existing safeguards, and prioritizing action to reduce risk to a reasonable and appropriate level.

The HIPAA Security Rule requires covered entities and business associates to conduct an "accurate and thorough" assessment of potential risks and vulnerabilities to the confidentiality, integrity, and availability of all ePHI they create, receive, maintain, or transmit.[1] Conducting an SRA is the foundation for the administrative, physical, and technical safeguards an organization is expected (and in some cases, required) to implement.

The Office of the National Coordinator for Health IT (ONC), along with the HHS Office for Civil Rights (OCR), created a Security Risk Assessment Tool to help regulated healthcare organization's structure and perform this crucial assessment. The current tool organizes the assessment into seven sections.[2] The guidance can be exceptionally helpful, especially for small and mid-sized organizations with limited funds and workforce to otherwise complete an SRA. However, completing the tool alone does not guarantee HIPAA compliance. The quality of the underlying fact-finding, documentation, and remediation work determines whether the analysis is meaningful and representative of an organization's true risks.

1. Security Risk Assessment Basics

The first section addresses the security management process, with topics such as whether the organization has performed an SRA before, identified its ePHI, documented risks, assigned security responsibilities to a workforce member(s), and established a process for managing identified risks.

The analysis starts with defining the scope correctly. The assessment must cover all ePHI, not just the EHR server or the computers in the billing office. The scope includes all ePHI created, received, maintained, or transmitted across every form of electronic media. This can include cloud applications, email, mobile devices, backup systems, patient portals, imaging systems, practice management platforms, connected medical devices, remote access tools, and data held by vendors.

A common failure is assessing only one application or location. A multi-location healthcare organization may have ePHI in a hosted EHR, office workstations, employee smartphones, cloud email, a billing vendor's platform, backup drives, and a document-scanning system. A risk analysis that omits any one of those environments is incomplete.

Pay special attention to:

• All physical locations, including remote and home-based work areas.
• All devices that can access ePHI, even if they do not permanently store it.
• Applications added outside the formal IT process, such as texting tools, AI transcription services, online forms, scheduling software, and file-sharing platforms.
• Former systems, old backups, retired devices, and archived data.
• Data flows between the organization, health plans, clearinghouses, laboratories, consultants, and business associates.

The ONC/OCR tool supports asset and vendor inventory, including how assets interact with ePHI, whether they are encrypted, where they are located, who is assigned to them, and whether they have been properly disposed of. Treat that inventory as evidence, not a formality. If you are unsure if you have captured all potential routes your ePHI takes, draw it out in a process flow document or even with pen and paper. You would be surprised how many additional places ePHI is stored when you map it out this way.

2. Security Policies, Procedures, and Documentation

An SRA should evaluate whether policies exist, whether they match current operations, and whether the organization can prove they are being followed. HIPAA requires policies and procedures designed to comply with the Security Rule, along with documentation of the SRA and related actions.

Written policies alone do not establish compliance. A policy stating that access is terminated promptly has little value if former employees retain active EHR, email, remote-access, or cloud-storage accounts. (You would be shocked at how often that happens.) Likewise, a policy requiring encryption is not proof that every laptop, removable drive, and mobile device is actually encrypted.

Focus on the connection between the written program and operational evidence:

• Is there a current SRA and a separate risk management plan?
• Are policy owners identified, and are policies reviewed when systems or workflows change?
• Can you produce evidence of access reviews, training, vulnerability remediation, backups, incident response, and device disposal?
• Are exceptions documented and approved, rather than managed informally?
• Do policies reflect the actual use of cloud services, personal devices, remote staff, vendors, and new technology?

The SRA Tool allows organizations to add details, attach or link supporting documentation, and create their own remediation plans. Examples of useful evidence include vulnerability scan results, penetration test reports, access review records, backup testing evidence, incident logs, and corrective action plans.

One area requiring special attention is the difference between an SRA and risk management plan. The analysis identifies and rates risk. The risk management plan is the follow through actions, such as assigning owners, selecting safeguards, establishing deadlines, tracking remediation, and validating the corrective action worked. The HIPAA Security Rule requires both documents.

3. Security and Your Workforce

People are central to healthcare security risk. Workforce members may accidentally disclose ePHI, fall for phishing attempts, use weak passwords, misdirect messages, retain access after changing roles, or even intentionally misuse information. A thorough SRA must evaluate both malicious and unintentional human threats.

The Security Rule requires safeguards related to workforce authorization, access management, security awareness and training, and security incident procedures. It also requires organizations to protect ePHI against reasonably anticipated impermissible uses or disclosures.

Start with the workforce lifecycle:

1. Before access: Are background, role, and authorization decisions documented?
2. During employment: Is access limited to the individual's job function and duties? Are accounts and access credentials unique to each user?
3. When roles change: Is access adjusted promptly when an employee transfers departments or takes on new duties?
4. At separation: Are accounts disabled promptly across every system, including email, EHR, vendor portals, messaging platforms, VPNs, and shared accounts?

A word of warning: Watch for shared accounts! They weaken accountability because audit logs cannot reliably show who viewed, changed, exported, or deleted information. Also examine key access controls like "break-glass" emergency access, generic administrative credentials, service accounts, and vendor support accounts.

An unassuming piece of an effective SRA is training. Workforce member training should be more than an annual acknowledgement. It should address the risks employees actually encounter, like phishing, password practices, multi-factor authentication, mobile device use, suspicious emails, patient identity verification, secure texting, workstation privacy, and how to report an incident or infraction. Workforce members need to know how to report potential security issues rather than work around them[3].

4. Security and Your Data

This section evaluates technical safeguards protecting ePHI and includes topics like access controls, authentication, audit controls, integrity protections, and transmission security. This is where many organizations focus first but it should follow (not replace) a complete inventory and SRA.

Key questions include:

• Who can access ePHI? Is access limited to what they need?
• Is multi-factor authentication used for remote access, email, privileged accounts, and other high-risk systems?
• Are audit logs enabled, retained, and reviewed regularly?
• Is ePHI encrypted when stored and transmitted where appropriate?
• Are systems patched, supported, securely configured, and protected against malware?
• Are user accounts, integrations, application programming interfaces, and automated data exports controlled?

Another major error when conducting an SRA is treating encryption as if it were the entire risk analysis. Encryption is an important safeguard; however, it does not address every risk. An encrypted laptop can still be compromised through a stolen password, a phishing attack, insecure remote access, excessive user privileges, an unpatched application, or an improperly configured cloud account.

The OCR's 2026 Cybersecurity Newsletter[4] specifically notes that the "risk analysis" requirement includes risks from unpatched software. It also states that vulnerability management and proper system hardening are methods organizations should use to identify and mitigate vulnerabilities.

Document the actual configuration and condition of systems, not simply that a product was purchased. A firewall, endpoint-protection tool, encrypted device, or cloud security feature only reduces risk if it is enabled, configured correctly, monitored, and maintained.

5. Security and Your Practice

The HIPAA Security Rule also includes physical safeguards, including facility access, workstations, device security, environmental conditions, and media controls. It asks a practical question: Could someone physically access, steal, damage, or improperly view ePHI?

Some of the most common physical risks include unlocked workstations at check-in desks, having charting screens visible to visitors, unescorted vendors in restricted areas, laptops left in vehicles, servers in unsecured/unlocked closets, improper disposal of devices, and unprotected paper-to-digital scanning workflows.

Evaluate each practice location, not just the primary office. This should include satellite clinics, shared office suites, temporary locations, employees' homes, and any offsite storage or IT areas. The risk profile of a front-desk workstation differs from that of a locked server room, but both may affect the confidentiality, integrity, or availability or ePHI.

Give special attention to device and media controls by:

• Maintaining an inventory of computers, tablets, phones, external drives, network equipment, and other assets with ePHI access.
• Documenting who has custody of portable devices.
• Requiring secure disposal or reuse procedures for devices and media.
• Verifying (not assuming) old hard drives, copier drives, USB devices, and retired equipment are cleared or destroyed appropriately.

The SRA's scope includes ePHI on all electronic media, including storage and transmission media. An old laptop in a storage closet can remain a HIPAA risk even when it is no longer used for patient care.

6. Security and Your Vendors

Vendor oversight is one of the most frequently underestimated portions of an SRA. Healthcare organizations commonly use vendors for EHR hosting, billing, cloud email, backups, IT support, patient communications, transcription, analytics, telehealth, document storage, cybersecurity, and artificial intelligence enabled workflows.

When a vendor creates, receives, maintains, or transmits PHI for a covered entity it is generally a business associate, and the covered entity must obtain "satisfactory assurances" through a compliant Business Associate Agreement (BAA)[5].

However, a signed BAA is not the end of the analysis. A thorough review of your Business Associate includes asking questions, such as:

• What ePHI does the vendor access, create, maintain, or transmit?
• Which systems and users accounts can access it?
• Does the vendor use subcontractors, and if so, how are they governed?
• Where is information stored, backed up, and processed?
• What security controls are contractually required?
• What is the vendor's incident notification process and timeline?
• How does the organization retrieve or securely destroy data at contract termination?
• Has the organization assessed risks created by vendor remote access, integrations, file transfers, and support tools?

The ONC/OCR SRA Tool includes vendor tracking, service type, contacts, satisfactory assurances, and documented vendor risks[6]. Use this information to create a living vendor inventory rather than a folder of BAAs no one revisits.

One specific area to watch very closely is "shadow vendor" risk. This includes staff adopting tools without formal review or governance over the use of said tools. An employee may connect an online form, transcription app, file-sharing site, chatbot, or AI tool to workflows involving patient information. If the organization does not know the service exists, it cannot determine whether a BAA, security review, or access restriction is necessary.

7. Contingency Planning

Contingency planning addresses whether the organization can maintain or restore access to ePHI during disruptions. This includes data backups, disaster recovery, emergency operations, downtime procedures, testing, and post-event evaluation.

Availability is just as important as confidentiality and integrity. A ransomware attack, power outage, internet interruption, server failure, cloud service outage, flood, fire, or lost device can prevent clinicians from accessing needed information. The SRA must consider the effect of those events on patient care and operations.

Your contingency plans should answer the following, at a minimum:

• Are backups performed, protected, and tested for restoration?
• Are backup copies isolated from the systems they protect, so they are less likely to be affected by the same incident?
• Can the organization operate safely during an EHR or internet outage?
• Are downtime forms, clinical workflows, patient contact procedures, and communication responsibilities defined?
• Are recovery objectives realistic for the organization's clinical needs?
• Has the organization tested its plan through tabletop exercises or actual restoration tests?

The ONC/OCR's SRA tool expressly includes backups and data recovery plans in its contingency planning section. The critical distinction is between having backups and proving recovery can actually happen. A backup strategy that has never been tested may fail when the organization needs it most.

Turning the SRA Into Action

A thorough and well conducted SRA produces more than a score or a completed questionnaire. It results in a defensible record and corrective action plan showing:

• The locations, systems, devices, people, vendors, and data flow within scope.
• Identifies reasonably anticipated threats and vulnerabilities.
• Existing safeguards and their effectiveness.
• Likelihood and impact ratings for each relevant risk.
• A prioritized remediation/risk mitigation plan with accountable owners and target dates.
• Evidence corrective actions were implemented and subsequently reviewed.

The HHS' guidance explains that organizations can use qualitative, quantitative, or mixed methods to rate likelihood and impact. The Security Rule does not mandate or recommend one specific methodology over the other. The essential point is to apply a consistent, documented method that fits your organization's environment and supports reasonable prioritization.

Healthcare Compliance Pros can assist organizations with conducting a comprehensive HIPAA Security Risk Analysis, documenting risks across all seven sections, and building a practical risk mitigation plan that goes beyond a checklist. Remember: The objective is not simply to complete an assessment, it is to identify the risks that matter, document sound decisions, and improve the protection of ePHI over time.