October 2022 OCR Cybersecurity Newsletter

HIPAA Security Rule Security Incident Procedures

Every October, in recognition of National Cybersecurity Awareness Month, the federal government and its partners work to educate stakeholders on cybersecurity awareness and how best to protect the privacy and security of confidential data. Within the health care industry, the HIPAA Security Rule1 applies to covered entities2 and their business associates3 (“regulated entities”) and electronic protected health information (ePHI).4 Because ePHI identifies individuals and includes information relating to an individual’s health, treatment, or payment information, it is a valuable target for cyber-criminals.

Cybersecurity incidents and data breaches continue to increase across all industries. A 2022 cybersecurity firm report noted a 42% increase in cyber-attacks for the first half of 2022 compared to 2021, and a 69% increase in cyber-attacks targeting the health care sector.5 The number of data breaches occurring in the health care sector also continue to rise. Breaches of unsecured protected health information (PHI), including ePHI, reported to the HHS Office for Civil Rights (OCR) affecting 500 or more individuals increased from 663 in 2020 to 714 in 2021. Seventy-four percent (74%) of the breaches reported to OCR in 2021 involved hacking/IT incidents. In the health care sector, hacking is now the greatest threat to the privacy and security of PHI. A timely response to a cybersecurity incident is one of the best ways to prevent, mitigate, and recover from cyberattacks.

The HIPAA Security Rule requires regulated entities to “implement policies and procedures to address security incidents.”6  This means regulated entities need to have a plan in place and documented for responding to security incidents (suspected or known) that includes:

  • identifying security incidents;
  • responding to security incidents;
  • mitigating harmful effects of security incidents; and
  • documenting security incidents and their outcomes.

Security incidents will almost inevitably occur during the lifetime of a regulated entity. Having a plan established and documented is essential to being able to detect security incidents quickly in order to respond to and recover from security incidents effectively.

Forming a security incident response team

In preparing their security incident response process, regulated entities should consider forming a security incident response team that is organized and trained to effectively respond to security incidents.

There are many options to consider when it comes to forming a security incident response team. In Special Publication 800-61 Computer Security Incident Handling Guide, the National Institute of Standards and Technology (NIST) provides several areas to consider when forming a security incident response team, including:

  • Selecting a team structure and staffing (e.g., use a centralized or distributed model, staff with full-time employees or partially outsource, ensure team members have appropriate expertise – organizational and technical)
  • Establishing relationships and lines of communication between the security incident response team and other groups (both internal and external)
  • Identifying internal groups that may need to participate in incident handling (e.g., management, information technology support, legal, public affairs and communications, human resources, business continuity/disaster recovery, physical security, facilities management)
  • Identifying points of contact at external groups that may be helpful to include in the event of an incident (e.g., network service providers, software and hardware vendors, local and federal law enforcement, incident handling teams of business partners and customers)
  • Determining what services the security incident response team should provide (e.g., intrusion detection, advisory distribution, education and awareness, information sharing)

Once formed, the security incident response team should conduct regular testing of security incident procedures. This could involve conducting tests involving different types of potential security incident scenarios, for example, a malicious insider exfiltrating sensitive information, a cyber-criminal’s infiltration and deployment of ransomware, or a distributed denial of service (DDoS) attack that interrupts system operations. Security incident procedures should be updated with lessons learned from testing as well as from actual security incidents to improve the team’s response and effectiveness.

Within the HIPAA Security Rule regulation itself, there are many helpful steps that regulated entities must take to protect against cyber threats.  These steps are outlined further below.

Identifying security incidents

The HIPAA Security Rule defines a security incident as “the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system.”7

Having audit logs in place and regularly reviewing such logs are actions that regulated entities are required to take and greatly improve their ability to identify security incidents early. The HIPAA Security Rule audit controls standard requires that regulated entities, “[i]mplement hardware, software, and/or procedural mechanisms to record and examine access and other activity in information systems that contain or use electronic protected health information.”8 For example, log files9 may be able to help identify when and how a cyber-criminal entered an information system and what activities occurred. The HIPAA Security Rule information system activity review implementation specification also requires regulated entities to "[i]mplement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports."10

By recording information system events, alerts, user actions, and other activities in appropriate logs and conducting regular reviews of such logs, regulated entities will have mechanisms and procedures in place to record and review information system activity and be able to identify and respond to security incidents quickly.

Responding to security incidents

When responding to a security incident, a regulated entity should contain the security incident and any threat it may pose to ePHI and take appropriate action(s) to ensure the confidentiality, integrity, and availability of its ePHI. Failing to do so could have a wide range of negative repercussions, including identity theft, financial loss, or negative consequences to the reputation or safety of the individual.  Important steps to ensure that the threat is neutralized include: determining the nature and extent of the damage caused by the security incident; identifying and removing any malicious code and components that the security incident may have left behind; and mitigating any vulnerabilities that may have permitted the security incident to occur. Collecting and preserving data relevant to investigating the security incident, such as log files, registry keys, and other artifacts, should also be part of security incident response activities.

To be better prepared to respond to security incidents, regulated entities should consider including the following as part of their security incident procedures:

  • Designating appropriate personnel (qualified internal resources and/or external third parties) to be members of the security incident response team
  • A communication plan and contact information for notifying all members of the security incident response team, and others as required (e.g., management) when a security incident occurs
  • Processes to identify and determine the scope of security incidents
  • Instructions for managing the security incident
  • Creating and maintaining a list of assets (computer systems and data) to prioritize when responding to a security incident
  • Conducting a forensic analysis to identify the extent and magnitude of the security incident
  • Reporting the security incident to appropriate internal and external entities (e.g., the regulated entity’s IT and legal departments, local FBI Cyber Taskforce Field Office, federal and state regulatory authorities, and other individuals or entities as required)
  • Processes for collecting and maintaining evidence of the security incident (e.g., log files, registry keys, and other artifacts) to determine what was accessed during the security incident
  • Processes for conducting regular tests of the security incident response process

While each security incident has its own set of facts that require a well-tailored response, regulated entities should develop a process for security incidents that commonly occur. For example, a regulated entity might have a specific process for responding to a ransomware attack and other processes for responding to insider malicious activity, cyber-attacks from hackers, and phishing attacks. Specific processes addressing common types of security incidents can improve workforce members’ understanding of what to do and the regulated entity’s speed in responding to these security incidents.

Mitigating harmful effects of a security incident

After the security incident has been neutralized and any malware removed, the next steps should include mitigating the harmful effects of the security incident including recovery and restoration of systems and data to return to normal operations. A critical component of an effective recovery from a security incident is preparation. The HIPAA Security Rule requires that regulated entities establish a contingency plan.11  The cornerstones of any data centric contingency plan must include robust data backup and recovery processes.  Data backup and disaster recovery plans are required implementation specifications of the HIPAA Security Rule’s contingency standard.12

Frequent backups and verification of the integrity of the backed-up data are crucial to being able to recover data that may have been deleted or had its integrity compromised as a result of a security incident. Backup logs should be reviewed regularly, and test restorations of backups conducted periodically to ensure the integrity of backups and provide confidence in the regulated entity’s ability to restore its data. Because some malware, including some ransomware variants, are known to delete or otherwise disrupt online backups, regulated entities should consider maintaining at least some of their backups offline and unavailable from their networks.

When backing up data, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) recommends following the “3-2-1” backup strategy:13

  • Keep 3 copies of important data – 1 primary copy and 2 backup copies
  • Keep backups on 2 different media types (e.g., local disk, hosted cloud, removable media)
  • Keep at least 1 of your backup copies offsite

Depending on the nature of the security incident and damage caused, the recovery process may involve one or more of the following processes recommended by CISA in its Eradicate & Recover procedures for cybersecurity incidents:14

  • Reimage affected systems from clean backups
  • Rebuild systems from scratch (i.e., install operating system and application software from trusted media or vendor sources)
  • Rebuild hardware (especially if rootkit malware was found or suspected)
  • Replace compromised files with known good versions
  • Install current updates and patches
  • Reset passwords and implement multi-factor authentication

Documenting the security incident

Once a security incident has ended, systems and data have been restored, and operations have returned to normal, regulated entities should document their response and analysis into a record of the security incident.  This record can be used to synthesize lessons learned to improve future response activities and may be helpful for regulatory purposes if applicable. The HIPAA Security Rule requires regulated entities to document security incidents and their outcomes.15 A regulated entity’s security incident procedures should include a section on documenting security incidents and what information to include in the documentation (e.g., discovery of the security incident; systems and data affected; response and mitigation activities; recovery outcomes; root cause analysis; forensic data collected).

Understanding your breach reporting obligations

When considering their security incident procedures and how to respond to security incidents, regulated entities need to be mindful of their obligation to report breaches of unsecured PHI. The Breach Notification Rule requires covered entities to report breaches affecting 500 or more individuals to the affected individuals, to OCR, and (in certain cases) to the media without unreasonable delay and no later than 60 calendar days from the discovery of the breach.16 Covered entities are required to report breaches affecting less than 500 individuals to the affected individuals without unreasonable delay and no than 60 calendar days from the discovery of the breach and to OCR no later than 60 days after the end of the calendar year in which the breach was discovered.17 It is important for covered entities to note that the “the time period [for reporting] begins when the incident is first known, not when the investigation of the incident is complete, even if it is initially unclear whether the incident constitutes a breach as defined in the rule.”18 Further, 60 days is the outer limit for notification and, “in some cases, it may be an ‘unreasonable delay’ to wait until the 60th day to provide notification.”19

Recent resolution of OCR investigation

In July 2022, OCR announced the resolution of an investigation of Oklahoma State University – Center for Health Sciences concerning a hacker gaining unauthorized access to a web server that contained ePHI.  The hacker installed malware that resulted in the disclosure of the ePHI of 279,865 individuals, including their names, Medicaid numbers, healthcare provider names, dates of service, dates of birth, addresses, and treatment information.  OSU-CHS initially reported that the breach occurred on November 7, 2017, but later reported that the ePHI was first impermissibly disclosed on March 9, 2016.

OCR’s investigation found potential violations of the HIPAA Rules including impermissible uses and disclosures of PHI; failure to conduct an accurate and thorough risk analysis; failure to perform an evaluation, failures to implement audit controls, security incident response and reporting, and failure to provide timely breach notification to affected individuals and HHS.  OCR successfully resolved this investigation with a monetary settlement of $875,000, and a resolution agreement and corrective action plan that includes two years of OCR monitoring.20


The policies and procedures regulated entities create to prepare for and respond to security incidents can pay dividends in the long run with faster recovery times and reduced compromises of ePHI. A well thought-out, well-tested security incident response plan is integral to ensuring the confidentiality, integrity, and availability of a regulated entity’s ePHI.

Additional Resources

OCR Cyber Attack Quick Response Checklist:

Health Industry Cybersecurity Resources and Templates:

NIST Computer Security Incident Handling Guide:

NIST Guide to Integrating Forensic Techniques into Incident Response:

NSA’s Top Ten Cybersecurity Mitigation Strategies:

IT Disaster Recovery Planning:

* This document is not a final agency action, does not legally bind persons or entities outside the Federal government, and may be rescinded or modified in the Department’s discretion.


1 OCR administers and enforces the HIPAA Privacy, Breach Notification, Security, and Enforcement Rules at 45 CFR Part 160 and Part 164 Subparts A, C, D and E.  The Security Rule establishes national standards to protect electronic PHI (ePHI) created, received, transmitted or maintained by covered entities and their business associates. The Security Rule requires appropriate administrative, physical, and technical safeguards to ensure the confidentiality, integrity, and availability of ePHI.

2 See 45 CFR 160.103 (definition of “Covered entity”). 

3 See 45 CFR 160.103 (definition of “Business associate”). See also OCR’s Fact Sheet on Direct Liability of Business Associates, https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/business-associates/factsheet/index.htmlhttps://www.hhs.gov/hipaa/for-professionals/privacy/guidance/business-associates/factsheet/index.html.

4 EPHI is individually identifiable health information transmitted by or maintained in electronic media that identifies an individual or there is a reasonable basis to believe that the information can be used to identify an individual, that is created or received by a covered entity that relates to the past, present, or future physical or mental condition of an individual, the provision of health care to an individual, or the past, present, or future payment for the provision of health care to an individual. See 45 CFR 160.103 (definitions of “electronic protected health information” and “individually identifiable health information”)

5 See https://www.checkpoint.com/press-releases/check-point-softwares-mid-year-security-report-reveals-42-global-increase-in-cyber-attacks-with-ransomware-the-number-one-threat.

6 45 CFR 164.308(a)(6). Additionally, the Security Rule security management process standard requires regulated entities to “implement policies and procedures to prevent, detect, contain, and correct security violations”. 45 CFR 164.308(a)(i)

7 45 CFR 164.304.

8 45 CFR 164.312(b).

9 Log files are files on a computer or similar device that maintains a record of events occurring within an organization’s computer systems and networks.

10 45 CFR 164.308(a)(1)(ii)(D).

11 See 45 CFR 164.308(a)(7)(i).

12 See 45 CFR 164.308(a)(7)(ii)(A)-(B).

13 See https://www.cisa.gov/uscert/sites/default/files/publications/data_backup_options.pdf.

14 See https://www.cisa.gov/sites/default/files/publications/Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf.

15 45 CFR 164.308(a)(6)(ii).

16 45 CFR 164.400-414 and https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html.  Note, the Breach Notification Rule permits breach notification by covered entities or business associates to be delayed “if a law enforcement official states to a covered entity or business associate that a notification, notice, or posting required under this subpart would impede a criminal, investigation or cause damage to national security.” See 45 CFR 164.412 for the specific requirements applicable to this provision.

17 Id.

18 See Modifications to the HIPAA Privacy, Security, Enforcement, and Breach Notification Rules Under the Health Information Technology for Economic and Clinical Health Act and the Genetic Information Nondiscrimination Act; Other Modifications to the HIPAA Rules; Final Rule, 78 Fed. Reg. 5566, 5648 (January 25, 2013).

19 Id.

20 https://www.hhs.gov/about/news/2022/07/14/oklahoma-state-university-center-health-services-pays-875000-settle-hacking-breach.html.

Content created by Office for Civil Rights (OCR)
Content last reviewed