Is Your Organization Ready for a HIPAA Security Incident?

A ransomware attack, compromised account, lost device, or malicious insider can turn into a major operational problem within minutes.

When that happens, there is no time to start deciding who should lead the response, whether systems should be taken offline, or how breach notification deadlines are calculated.

Those decisions need to have been made in advance.

Healthcare organizations, including both Covered Entities and Business Associates, need more than an incident response policy sitting in a compliance folder. They need practical procedures that people understand, reliable backups they know they can restore, evidence that can survive a forensic investigation, and a team capable of making difficult decisions under pressure.

The HIPAA Security Rule establishes the foundation for those preparations. However, satisfying the rule requires more than producing a document and reviewing it once a year. An effective response program must connect security incident procedures, contingency planning, breach assessment, business associate coordination, workforce training, and continuous improvement.

What Does HIPAA Require for Security Incidents?

The HIPAA Security Rule does not use “Incident Response Plan” as the formal name of a required document. Instead, 45 CFR § 164.308(a)(6) requires covered entities and business associates to implement security incident policies and procedures.

Those procedures must enable an organization to:

• Identify and respond to suspected or known security incidents.
• Mitigate harmful effects to the extent practicable.
• Document security incidents and their outcomes.

HIPAA also requires security policies and procedures to be maintained in written or electronic form. Supporting documentation generally must be retained for six years under 45 CFR § 164.316.

In practical terms, organizations need a documented and workable method of managing an incident from the first alert through investigation, recovery, breach assessment, and corrective action. HHS guidance recommends having a response team, clearly assigned roles, established communication methods, procedures for preserving evidence, and regular testing of the response process. HHS incident response guidance also emphasizes that a plan must be usable during an actual emergency, not merely available for an auditor to inspect.

A Security Incident Is Not Necessarily a Data Breach

The terms “security incident” and “breach” are sometimes used interchangeably, but they have different meanings under HIPAA.

A security incident can include an attempted or successful unauthorized access, use, disclosure, modification, or destruction of information. It can also involve interference with the operation of an information system. Examples include:

• An employee clicking a phishing link.
• Malware being detected on a workstation.
• Repeated unauthorized login attempts.
• A former employee attempting to access an account.
• A server becoming unavailable during a cyberattack.
• An unencrypted device containing electronic protected health information being lost.
• An employee accessing patient records without a business reason.

Some of these events may be contained without Protected Health Information (PHI) being exposed. Others may involve an impermissible use or disclosure and require a HIPAA breach risk assessment.

Unless an exception applies, an impermissible use or disclosure is presumed to be a breach. An organization may rebut that presumption by documenting a risk assessment that demonstrates a low probability that the information was compromised. That assessment must consider the nature of the information, the unauthorized person involved, whether the information was actually acquired or viewed, and the extent to which the risk was mitigated.

This distinction matters because every suspected security incident needs to be investigated and documented, but not every incident must be reported to HHS or affected individuals.

Incident Response Begins Before the First Alert

The first hours of an incident often determine how disruptive and expensive it becomes. Organizations that have not assigned roles in advance may lose valuable time identifying decision-makers, contacting outside specialists, and determining whether clinical or administrative systems should be disconnected.

A useful incident response structure should identify:

• Who can activate the incident response process.
• Who has authority to isolate systems or suspend access.
• Who will direct the technical investigation.
• When privacy, compliance, legal, human resources, and senior management must be involved.
• Who will communicate with patients, employees, business partners, regulators, and the media.
• When cyber insurers, forensic investigators, law enforcement, or other outside specialists should be contacted.
• How decisions, evidence, findings, and corrective actions will be documented.

The response team should not be limited to the IT department. A serious healthcare security incident can affect patient safety, clinical operations, payroll, communications, legal obligations, insurance coverage, and the organization’s reputation.

Someone must also be responsible for maintaining a reliable incident record. Investigators may later need to reconstruct what happened, when it was discovered, which decisions were made, who approved them, and what actions were taken to limit harm.

Make Sure Incidents Are Reported Quickly

An incident response process cannot work if employees do not recognize incidents or do not know how to report them.

Workforce members should have a simple way to report suspicious emails, lost devices, unusual access, accidental disclosures, malware alerts, and other security concerns. Reporting channels should remain available if normal email or telephone systems are disrupted.

HIPAA Training should also make clear that employees are expected to report suspected incidents promptly, even if they are unsure whether protected health information was involved. Delays caused by embarrassment or fear of disciplinary action can give an attacker more time to access systems, spread malware, or remove data.

Organizations should integrate incident response with their workforce sanction policies. Deliberate misuse of information and negligent conduct may require disciplinary action, but the possibility of sanctions should not discourage good-faith reporting of mistakes or suspicious activity.

Coordinate Incident Response with Business Associates

A healthcare organization’s response capability is only as strong as the vendors and business associates that create, receive, maintain, or transmit protected health information on its behalf.

Business associate agreements should define:

• What types of security incidents must be reported.
• Who must receive the notification.
• How quickly the business associate must provide notice.
• What information must be included.
• Who will investigate the incident.
• Who will conduct the breach risk assessment.
• How the parties will coordinate notifications and public communications.
• Who will preserve logs, system images, and other forensic evidence.

Simply requiring “prompt” notification may not provide enough certainty during a major incident. The parties should understand how they will work together before an emergency occurs.

Contact details must also be kept current. An incident is a poor time to discover that the only vendor contact listed in the response plan left the company two years ago.

Preserve the Evidence Needed to Understand What Happened

Responding quickly does not mean acting without considering the effect on evidence. Immediately shutting down an infected device, deleting suspicious files, or reinstalling a system may destroy information needed to determine the scope of an attack.

Organizations should establish procedures for:

•  Isolating compromised systems from the network.
• Preserving volatile data when appropriate.
• Collecting relevant access, application, security, and network logs.
• Protecting evidence against alteration or deletion.
• Recording who collected, transferred, and examined evidence.
• Maintaining a defensible chain of custody.
• Coordinating forensic work through legal counsel when appropriate.

HIPAA’s audit control standard requires mechanisms capable of recording and examining activity in systems that contain or use electronic protected health information. Logs provide limited protection if they are retained for only a short period, can be changed by an attacker, or are stored solely on a compromised system.

Centralized logging and protected or immutable storage can help investigators reconstruct an incident. Organizations should determine in advance which records will be required, where they are stored, how long they are retained, and who can access them.

External forensic, legal, communications, and ransomware recovery specialists may also be needed. Establishing those relationships in advance can reduce delays and allow organizations to confirm that contract terms, confidentiality requirements, and insurance conditions are understood.

Incident Response Must Include Business Continuity

Stopping an attack is only part of the response. Healthcare organizations must also maintain essential operations and restore systems safely.

The HIPAA contingency plan standard requires covered entities and business associates to establish procedures for responding to emergencies or other events that damage systems containing electronic protected health information. Required elements include a data backup plan, disaster recovery plan, and emergency mode operation plan.

Organizations should be able to answer several practical questions:

• Which systems must be restored first?
• How long can each critical application remain unavailable?
• Can clinicians continue providing care if the electronic health record system is offline?
• Are paper downtime procedures available and understood?
• How will information recorded during downtime be entered into restored systems?
• Can critical personnel access systems if normal authentication services fail?
• How will employees communicate if email, messaging, and VoIP services are unavailable?
• When should an affected network be disconnected?

A current inventory of applications and data is essential. Systems should be ranked according to their importance to patient care, safety, legal obligations, and business operations. Without that analysis, recovery efforts may focus on systems that are easy to restore rather than those the organization needs most urgently.

Backups Must Be Recoverable, Not Merely Available

Backups are a central part of ransomware resilience, but the existence of a backup does not guarantee that recovery will succeed.

Attackers increasingly attempt to encrypt, corrupt, or delete backups before deploying ransomware. Organizations should therefore consider maintaining encrypted, offline, air-gapped, or immutable copies of critical data.

They must also test restoration procedures.

A backup that has never been restored is an assumption, not a recovery capability. Testing should confirm that the data is complete, encryption keys are available, applications can use the restored data, and recovery can be completed within an acceptable time.

Restoration exercises may also identify unexpected dependencies. A critical clinical application, for example, may rely on identity services, databases, network configurations, or third-party connections that were not included in the original recovery sequence.

Breach Notification Deadlines Can Start Before the Investigation Ends

One of the most dangerous incident response mistakes is assuming that the HIPAA notification clock begins after a forensic investigation is complete.

A breach is generally considered discovered on the first day it is known, or reasonably should have been known, to the organization. HHS has warned that the notification clock does not wait for an organization to complete every aspect of its investigation.

When notification is required, affected individuals must be notified without unreasonable delay and no later than 60 calendar days after discovery. Breaches affecting 500 or more individuals must also be reported to HHS without unreasonable delay and within the same 60-day limit. Smaller breaches may be reported to HHS annually, no later than 60 days after the end of the calendar year.

Media notification is required when a breach affects more than 500 residents of a state or jurisdiction. A business associate must notify the covered entity of a breach without unreasonable delay and no later than 60 days after discovery.

The full notification requirements are explained on the HHS Breach Notification Rule page.

The 60-day period is an outer limit, not an automatic waiting period. Depending on the circumstances, delaying a notification until day 60 may still be considered unreasonable.

Organizations should begin the legal and regulatory assessment as soon as reliable facts become available. The incident team, privacy officer, legal counsel, and forensic investigators must communicate throughout the investigation so notification decisions are not left until the deadline is approaching.

A Plan That Has Never Been Tested Is Still a Theory

Even a detailed incident response plan can fail if employees have not practiced using it.

Tabletop exercises allow the incident response team to work through a realistic scenario without disrupting live systems. Exercises can reveal unanswered questions, unclear authority, missing contact information, weak vendor coordination, inaccessible documents, and unrealistic recovery expectations.

A useful ransomware exercise might ask:

• Who declares the incident?
• Who can authorize network isolation?
• How will clinical staff continue working?
• How will the organization communicate if email is unavailable?
• When will the cyber insurer and legal counsel be contacted?
• Who decides whether ransom negotiations will be considered?
• How will evidence be preserved?
• When does the breach assessment begin?
• Who approves patient, media, and regulatory notifications?

Exercises should involve leadership, IT, security, privacy, compliance, legal, human resources, communications, clinical operations, and key vendors. The results should be documented, assigned to responsible owners, and used to update the response plan, contingency procedures, and organization-wide risk analysis.

OCR Enforcement Shows Why Procedures Matter

HIPAA enforcement actions frequently identify weaknesses that existed long before an incident occurred.

In 2025, Plastic Surgery Associates of South Dakota agreed to pay $500,000 following a ransomware investigation. OCR identified several potential violations, including the failure to implement policies and procedures for responding to security incidents. The corrective action plan required extensive changes to the organization’s security incident procedures.

Heritage Valley Health System agreed to a $950,000 settlement after OCR investigated a NotPetya malware incident. The investigation identified potential failures involving risk analysis, access authorization, and contingency planning.

Gulf Coast Pain Consultants paid $1.19 million after a former contractor continued accessing protected health information after the relationship ended. OCR identified potential failures involving access termination, activity review, and policies designed to prevent and detect unauthorized access.

Montefiore Medical Center agreed to pay $4.75 million after an employee stole and sold patient information over an extended period. The case highlighted the importance of risk analysis, audit controls, system activity review, and procedures for detecting inappropriate access.

The incidents were different, but the underlying lesson was similar: The consequences were made worse by procedural and control weaknesses that existed before the incidents were detected.

Download the FREE HIPAA Incident Response Checklist

A healthcare security incident can affect far more than the confidentiality of patient information. It can interrupt care, disable communications, delay treatment, expose business partners, and create regulatory deadlines that continue running while the organization is still trying to understand what happened.

The HIPAA Incident Response Checklist provides a practical framework for reviewing:

• Incident response governance and reporting.
• Business associate and external specialist coordination.
• Technical logging and forensic readiness.
• Evidence preservation and chain of custody.
• Backup, recovery, and emergency operations.
• Workforce training and tabletop exercises.
• HIPAA breach assessment and notification procedures.
• Documentation, corrective action, and continuous improvement.

Use the checklist to identify which safeguards are already in place, where gaps remain, who owns each corrective action, and which improvements should be prioritized.

The checklist is not a substitute for a comprehensive HIPAA Security Risk Analysis or advice based on your organization’s particular circumstances. It is a practical starting point for determining whether your organization can respond decisively when a security incident occurs.