Skip Navigation
Copy Of Blog Headers (3)
  • Compliance

HIPAA Security Risk Assessment Checklist and Requirements 

There are many ways to perform a Security Risk Assessment, and neither HIPAA nor U.S. Department of Health & Human Services specifies a certain method.

Jeanne Varner Powell, JD


To help you protect patient information and ensure HIPAA-compliance, this article: 

  • summarizes HIPAA Security Risk Assessment (SRA) requirements, 

  • discusses regulatory enforcement of SRA requirements, and 

  • provides a HIPAA security risk assessment (SRA) checklist that identifies mandatory SRA elements.    

What is a Security Risk Assessment (SRA)? 

The HIPAA Security Rule requires medical practices and other covered entities to implement reasonable and appropriate security measures to protect electronic protected health information (ePHI).  

Okay, but what are “reasonable and appropriate security measures?” The answer varies according to the size of your organization and depends entirely on the results of your HIPAA-required SRA.  

HIPAA defines an SRA as an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information (ePHI) maintained by a medical practice or other covered entity. The U.S. Department of Health and Human Services’ Guidance on Risk Analysis (Guidance) says an SRA is the foundation for achieving compliance with all other requirements of the HIPAA Security Rule. 

Essentially, an SRA is an information gathering process. When you conduct an SRA, you determine where ePHI is located (servers, laptops, thumb drives, etc.) and how it could be lost, stolen, compromised, or made inaccessible (cybercrime, employee fraud, theft of devices in a robbery, power outages, fire, natural disasters, etc.). Once you complete the process, you use the results to determine what security measures are necessary, reasonable, and appropriate for your organization (i.e., a risk management plan).  

Who Must Conduct an SRA? 

An SRA is NOT optional. Regardless of size or specialty, HIPAA requires all physicians, advanced practice providers, medical practices, and other covered entities to perform and document SRAs.  

How is an SRA Performed? 

There are many ways to perform an SRA, and neither HIPAA nor U.S. Department of Health & Human Services (HHS) specifies a certain method. HHS recognizes that covered entities will conduct SRAs differently depending on the size, complexity, and capabilities of the organization. However, regardless of the method used, every SRA must contain certain essential elements (see Checklist below). 

Periodic Reviews and Updates are Required 

The SRA is a continuous process that requires regular reviews and updates. Practices that have conducted only one SRA in many years are likely not in compliance with HIPAA Security Rule requirements.  

In general, SRAs should be updated on a regular basis but also in conjunction with changes in operations or technology. HHS Guidance states, “A truly integrated risk analysis and management process is performed as new technologies and business operations are planned, thus reducing the effort required to address risks identified after implementation.”  

Some situations that should trigger an SRA update include: 

  • Change in practice ownership or personnel; 

  • After a security incident or breach; 

  • Acquisition of new technology which will access ePHI; and 

  • On a regular basis per your policy and procedure – consider annually. 

You Need Written Policies and Procedures Governing the SRA Process 

HIPAA covered entities are required to develop and maintain reasonable and appropriate written policies and procedures to ensure compliance with HIPAA requirements, such as the SRA requirements. Make sure policies are available to staff members responsible for implementing them. As with other HIPAA documentation, retain copies of all policies for at least six years, even if you revise or update a policy. 

The National Learning Consortium offers a sample SRA policy and procedure in a helpful resource called Information Security Policy Template. The Template is a collection of sample policies and procedures related to information technology security. The SRA policy is titled Security Management Process. 

Documenting Your SRAs 

HIPAA requires that you document your initial SRA and all updates and retain the documentation for at least six years. No specific format is required, but your documentation should include: 

  • Date of the SRA; 

  • Steps of your process or method; and 

  • Information you gathered and/or considered in each step of the process. 

Regulatory Investigations: Potential Consequences for Not Performing SRAs 

The HHS Office of Civil Rights (OCR) enforces HIPAA, including SRA requirements. Through routine audits, OCR has found that most HIPAA covered entities are non-compliant with SRA requirements. According to OCR, “the failure to implement basic HIPAA requirements, such as an accurate and through risk analysis and risk management plan, continues to be an unacceptable and disturbing trend within the health care industry.”  

OCR has repeatedly settled compliance investigations of large and small health care entities that lacked documentation to prove they properly conducted an SRA. OCR frequently discovers SRA non-compliance when it investigates breach reports filed by medical practices and other HIPAA covered entities.  

For example, OCR initiated a compliance review of a Utah GI physician who reported a breach. OCR found the physician and his practice had never conducted an SRA and still failed to complete one during the investigation even with technical assistance from OCR. The physician paid $100,000 to settle the matter and agreed to a corrective action plan and two years of OCR monitoring. 

The following is a list of similar settlements arising out of post-breach report compliance reviews. In all cases, OCR found the covered entity never conducted an SRA. In addition to monetary payments, each entity agreed to a corrective action plan and two years of OCR monitoring.  

If your practice hasn’t completed an SRA, or if you’ve completed one but didn’t properly document it, you could face a similar settlement situation. If you think you can fly under OCR’s radar, because you’ll never need to report a breach, think again. 

Several of the investigations listed above were triggered by ransomware or hacking-related breaches. Both types of incidents are increasing in frequency, with cybercriminals targeting large and small health care entities alike. As a result, large breaches (affecting over 500 individuals) reported to OCR are skyrocketing. Over the past five years, HHS says there has been a 256% increase in large hacking-related breaches reported to OCR and a 264% increase in large ransomware-related breach reports. In 2023, large breaches affected over 134 million individuals, a 141% increase from 2022. 

However, you don’t have to be ransomware or hacking victim to suffer a breach. Out of the investigations listed above, five involved breaches due to other causes. One breach involved a thumb drive full of unencrypted patient files stolen from an employee’s car. Another stemmed from theft of the practice’s server backup. The backup media was in a laptop bag stolen from an employee’s vehicle. Finally, one involved a former employee impermissibly accessing patient information. The practice failed to terminate her remote access credentials when it fired her.  

Conducting an SRA will help reduce the risk of breaches like these but won’t eliminate it. However, properly conducting and documenting an SRA with regular updates can keep you out of the OCR settlement headlines.  

Checklist of Mandatory SRA Elements 

Practices of any size or specialty can perform their own SRA or contract with an outside vendor.  The Office of the National Coordinator for Health Information Technology (ONC) offers a downloadable SRA tool and User Guide. However, some practices may feel more comfortable contracting with an experienced IT professional to perform the SRA. 

While organizations of different sizes may perform SRAs differently, HHS Guidance says all SRAs must include these key components. 

1. Scope: Assess potential risks and vulnerabilities to ALL ePHI 

The scope of the risk analysis goes beyond ePHI in your Electronic Health Record (EHR). When assessing potential risks and vulnerabilities, consider ALL ePHI created, received, maintained, or transmitted. This includes ePHI in all forms of electronic media such as: 

  • Network devices; 

  • Workstations; 

  • External hard drives; 

  • Laptops; 

  • Printers, fax machines, and scanners; 

  • Backup tapes; 

  • Storage devices like smart cards, flash drives, CDs, DVDs, etc.; 

  • Personal digital assistants and all mobile devices; and 

  • Software that stores, receives, or transmits ePHI.

2. Data Collection: Document all IT assets/information systems where ePHI is stored, received, maintained, or transmitted 

During this stage, you ask questions like: 

  • Where is ePHI is stored? 

  • Where does it flow to or from? (i.e., billers, payers, backup facility, other practices, patients, internally) 

  • How does it get there? (i.e., email, fax, shared network drives, Health Information Network exchange) 

Answering the questions involves a solid understanding of your practice operations and a detailed analysis of your information systems and electronic office equipment. HHS suggests potential information gathering techniques could include reviewing policies and procedures and interviewing office personnel and IT support staff.  

Regardless of how you gather the information, you must document your findings at each stage and retain for six years. In the event of a compliance investigation, OCR will always request your SRA documentation. Failure to provide appropriate documentation will result in a finding of non-compliance.  

Your documentation for this stage of the SRA might include: 

  • Hardware/software inventory - including date acquired, location, licenses, maintenance schedule, and function; 

  • Network diagram;
  • Facility map showing equipment, power sources, telecommunications equipment, network access points, fire and burglary alarm equipment, and hazardous material storage; 

  • List of authorized users by job title for each software application; 

  • For each software application, a description of data the app uses/stores and a list of applicable security controls and policies and procedures related to the app; 

  • Description of data the practice creates and receives; 

  • For data the practice receives, identify who sends it and how; 

  • Description of data the practice maintains internally; and 

  • Description of data the practice transmits to third parties, including names of third parties and how and why the practice sends it.

3. Identify and document vulnerabilities and potential threats to ePHI 

Once you know how your practice stores and uses ePHI, you can identify system vulnerabilities and potential threats to the confidentiality, integrity, and availability of ePHI.  

  • Vulnerabilities are flaws, weaknesses, or errors in the design, configuration, or implementation of your information system, including inadequate security policies and procedures. When vulnerabilities are exploited or accidentally triggered, they may result in unauthorized access to ePHI, inability to access ePHI to provide care, or unwanted deletion/modification of data. 

  • Threats can trigger or exploit vulnerabilities. There are natural, human, and environmental threats such as floods, earthquakes, employee fraud, cybercrime, power failures, and many more. 

Examples of threat-vulnerability scenarios include: 

  • Lack of password protection on workstations allows an unauthorized third party to steal ePHI, compromising confidentiality;
  • A practice doesn’t have policies and procedures governing employees’ mobile device use. An employee uses her mobile phone to access and store unencrypted emails containing ePHI. The phone lacks password protection. The phone is stolen, potentially compromising ePHI confidentiality.
  • A flood takes essential servers offline. The practice lacks a business continuity plan with procedures for backup and recovery and is unable to access ePHI to provide patient care. 

4. Evaluate the effectiveness of current security measures 

The Security Rule requires covered entities to implement administrative, physical, and technical safeguards to protect ePHI. Based on the vulnerabilities and threats you identify, evaluate the effectiveness of the practice’s current security measures.  

Has the practice implemented safeguards required by the Security Rule? Are these configured and used properly? Depending on practice environment and size, security measures necessary to reduce risks to reasonable and appropriate levels will vary. 

5. Determine the likelihood of a threat occurrence  

Medical practices and other covered entities must comply with the Security Rule by protecting against “reasonably anticipated” threats to the confidentiality, availability, and integrity of ePHI. To determine what threats on your list fall in this category, you must evaluate the probability a particular threat will occur.  

According to HHS Guidance, when documenting this stage of your analysis, you should assign a probability level for each threat/vulnerability combination. One way to quantify this might be: 

  • 3/Very likely = probable chance of occurrence 

  • 2/Likely = significant chance of occurrence
  • 1/Not likely = modest or insignificant chance of occurrence 

6. Rate the potential impact if a threat occurs 

Covered entities are required to consider the impact of a potential risk to ePHI confidentiality, integrity, and availability. HHS Guidance recommends documenting all potential impacts a particular threat/vulnerability combination could cause. One way of quantifying each impact for documentation purposes could be: 

  • 3/High = Catastrophic impact; significant number of lost/compromised medical records 

  • 2/Medium = Significant impact; moderate number of lost/compromised medical records 

  • 1/Low = Modest/insignificant impact; some lost/compromised medical records 

7. Assign a Risk Score 

Assign risk levels for all identified threat/vulnerability combinations. Develop a risk rating system that incorporates the probability and impact scores in steps 5 and 6. Risk levels could be assigned, for example, based on the average of the scores or by multiplying the scores. Whatever method is used, HHS Guidance says SRA documentation should include risk levels assigned to each threat/vulnerability combination and a list of corrective actions to mitigate each risk level. 

Action Plan 

Put SRA compliance at the top of your to-do list in 2024. Whether you’ve never conducted a single SRA, or if you need to improve your documentation or implement regular updates, don’t wait. SRA compliance reduces the risk of: 

  • An expensive settlement with OCR; 

  • Injury to patients whose protected health information is comprised due to lack of reasonable and appropriate security measures;  

  • Loss of patient trust; and  

  • Potential post-breach injury to your practice’s reputation.