HIPAA Incident Response Plan Template (2026)

The HIPAA incident response plans available in template form online were mostly written for organizations that have a Security Operations Center, a CISO with 24/7 reachability, and a dedicated incident response team. Independent practices have a Practice Manager, a CTO who is also the IT vendor, and a clinical staff whose primary job is patient care.

The right incident response plan for an independent practice is one that names actual people, fits on three pages, and triggers actions a four-person office can actually execute at 7:42 PM on a Tuesday. This is the template.

What HIPAA Requires

§164.308(a)(6)(i) Security Incident Procedures requires the covered entity to "implement policies and procedures to address security incidents." The implementation specification at §164.308(a)(6)(ii) requires the covered entity to "identify and respond to suspected or known security incidents; mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity; and document security incidents and their outcomes."

The Breach Notification Rule (§§164.400-414) layers on top: when a security incident becomes a breach, the practice has specific notification obligations to affected individuals, HHS, and (sometimes) media outlets, on specific timelines.

An incident response plan must address both: how the practice handles a suspected incident from minute one, and what triggers the notification obligation.

The 9 Required Sections

A defensible incident response plan for an independent practice has nine sections. Anything shorter is incomplete; anything longer is generally not read by the staff who'd execute it.

Section 1: Purpose and Scope

What this plan covers. Two sentences typically: this plan applies to any security incident potentially affecting ePHI maintained by, processed by, or transmitted through systems operated by [Practice Name]. The plan applies to all workforce members regardless of role.

Section 2: Definitions

The five terms that produce the most confusion when an incident actually happens:

• Security incident — an attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations
• Breach — an impermissible use or disclosure of unsecured PHI that compromises its security or privacy
• Unsecured PHI — PHI that is not rendered unusable, unreadable, or indecipherable to unauthorized persons through encryption or destruction per HHS guidance
• Workforce member — employees, volunteers, trainees, contractors, and other persons whose conduct is under the practice's direct control
• Business associate — a person or entity that creates, receives, maintains, or transmits PHI on behalf of the practice

Section 3: Roles and Responsibilities

Names, not titles. Three roles minimum:

• Incident Commander — typically the Practice Manager or owner. The single decision-maker during an incident. Responsibilities: initial triage, scope determination, communication coordination, breach determination decision.
• Technical Lead — typically the IT vendor's primary contact or in-house IT. Responsibilities: technical containment, forensic preservation, system restoration.
• Legal/Compliance Coordinator — typically the practice's compliance attorney or designated compliance consultant. Responsibilities: notification timeline tracking, regulatory communication, documentation review.

Each role has a named primary and a named backup. Contact information for both is in the plan.

Section 4: Incident Identification — What Counts

The plan should list the categories of events that trigger an incident response. Concrete categories that catch what independent practices actually encounter:

• Suspected ransomware or other malware infection
• Unauthorized access to a workstation, email account, or clinical system
• Loss or theft of a device (laptop, phone, tablet) potentially containing ePHI
• Loss or theft of physical records
• Unauthorized disclosure of PHI (wrong recipient on email, fax, message)
• Failed phishing attempt that compromised credentials
• Unusual system behavior suggesting a compromise
• Notification from a business associate that they have experienced an incident affecting your PHI

Each item is a separate event class. The response below applies to all of them; the triage decision determines which are reportable.

Section 5: The 60-Minute Initial Triage

The first 60 minutes after an incident is identified follow a specific sequence. The plan lists the sequence step-by-step:

Minute 0-10: Containment. Disconnect affected systems from the network if active intrusion is suspected. Do not power off (preserves forensic state). Document the time of containment.

Minute 10-25: Scope assessment. What systems are affected. Which patient records or accounts may have been involved. Who first identified the event. Document with timestamps.

Minute 25-40: Notification of Incident Commander. If not already involved. Decision: is this likely a breach? Decision: do we engage outside counsel and forensic vendors?

Minute 40-60: Workforce communication. Brief affected staff. Suspend non-essential activity on affected systems. Initiate evidence preservation: full disk images, log exports, message captures, photos of physical evidence.

The 60-minute mark is the trigger for activating the formal documentation log.

Section 6: The 72-Hour Breach Determination

§164.402 requires a breach risk assessment when an impermissible use or disclosure occurs. The four-factor assessment:

1. The nature and extent of the PHI involved (identifiers, sensitivity of clinical content)
2. The unauthorized person who used or received the PHI
3. Whether the PHI was actually acquired or viewed (vs merely accessible)
4. The extent to which the risk has been mitigated

If the assessment concludes that there is a "low probability" the PHI was compromised, no breach notification is required. If the assessment concludes otherwise, the breach notification clock starts.

The plan documents who performs this assessment (typically the Incident Commander with input from the Technical Lead and Legal/Compliance Coordinator), the timeline (within 72 hours of incident identification), and the standard for documentation (written, signed, retained for six years).

Section 7: Notification Obligations and Timelines

If the determination is breach, three notification streams begin:

Individual notification. Within 60 days of breach discovery. Written notice (first-class mail or, if individual has agreed, email). Must include description of breach, types of information involved, steps to protect themselves, what the practice is doing to investigate, and contact information.

HHS notification. Within 60 days for breaches affecting 500+ individuals (immediate via OCR portal). For breaches affecting fewer than 500, annual report due within 60 days of end of calendar year.

Media notification. Only for breaches affecting 500+ individuals in a state or jurisdiction. Notice to prominent media outlets serving the area. Same 60-day timeline.

The plan lists which staff member coordinates each stream and the specific channels (OCR portal URL, media contact list, notification letter template location).

Section 8: Post-Incident Documentation

After the immediate response, the documentation requirement is substantial. The plan lists what must be retained for six years:

• Full incident timeline with timestamps
• Root cause analysis
• Affected individuals list (with PHI fields)
• Breach risk assessment with named decision-maker
• Notification records (proof of delivery for individual notices, screenshot of OCR submission)
• Corrective action plan
• Workforce sanction documentation (if applicable)
• Updated risk analysis reflecting lessons learned

Section 9: Plan Maintenance

The plan itself needs maintenance. The maintenance section names:

• Review frequency (at least annually)
• Trigger events that require interim review (any actual incident, any organizational change, any new system or vendor)
• Tabletop exercise frequency (at least annually for an independent practice; quarterly is better)
• Workforce training frequency (annually, with documentation)

The Template Itself

The full template — sections 1 through 9 with prompts for the specific names, contact information, system names, and timelines an independent practice needs to fill in — is available at patient-protect.com/free-tools in our incident response template library. It is built for the four-to-fifty-employee independent practice, not the hospital system.

Five Common Failure Modes

Watching practices respond to actual incidents, five patterns produce the worst outcomes.

The plan exists in a drawer. A plan staff has never seen is not a plan. Annual tabletop exercise — even 30 minutes walking through a hypothetical — is the single most valuable maintenance activity.

The named Incident Commander left two years ago. The plan references "Sarah Chen, Practice Manager." Sarah left in 2024. The current Practice Manager has never seen the plan. The first incident is the introduction.

The 60-minute triage was never timed. Plans document the steps but not the time. When an incident happens, the response runs 4-6 hours because nobody is tracking minutes. Documentation is reconstructed from memory afterward.

The breach determination is performed by the wrong person. Practices sometimes have the IT vendor perform the breach risk assessment. The IT vendor is not the covered entity; the determination must be made by the covered entity with their input. Misallocating this role is a common finding.

No evidence preservation. Affected systems are wiped and reinstalled in the rush to "get back to work." The forensic evidence is gone. The post-incident root cause analysis is impossible.

How Patient Protect Helps

Patient Protect's incident response module operates as an integrated workflow on top of this template — automatic incident logging from the practice's other monitored systems, time-stamped triage tracking, breach determination workflow with documented decision rationale, notification timeline automation, and the documentation retention that satisfies §164.316.

For independent practices that have downloaded incident response templates and never quite finished adapting them — or never quite trained their staff on them — the platform provides the operational scaffolding the template alone does not.

An incident response plan is one document. The incident response program is the discipline of keeping it current and the staff trained on it. The template is the start of that work; the platform is what keeps it running.