HIPAA Incident Response Plan Template (2026)

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 Nine Sections We Recommend

§164.308(a)(6) requires policies and procedures that address security incidents, and an implementation specification to identify and respond to them, mitigate what can be mitigated, and document what happened and what came of it. It does not prescribe sections. Nine is what we have found a defensible plan for an independent practice needs; 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 is what we would treat as the floor — §164.308(a)(6) prescribes no number:

• 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: Initial Triage

The opening moves after an incident is identified follow a sequence. The plan lists it step-by-step:

First, containment. Disconnect affected systems from the network if active intrusion is suspected. Do not power off (preserves forensic state). Document the time of containment.

Then scope assessment. What systems are affected. Which patient records or accounts may have been involved. Who first identified the event. Document with timestamps.

Then the Incident Commander. If not already involved. Decision: is this likely a breach? Decision: do we engage outside counsel and forensic vendors?

Then 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.

Once containment is under way, the formal documentation log gets activated.

Section 6: The Breach Determination

Where an impermissible use or disclosure is not covered by one of the three §164.402 exclusions, it is presumed to be a breach. The four-factor assessment is how a practice rebuts that presumption — it is not required in every case, and a practice may also elect to notify without performing it. The four factors:

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, notification is required — and the clock for it has been running since discovery, not since the assessment concluded.

The plan documents who performs this assessment (typically the Incident Commander with input from the Technical Lead and Legal/Compliance Coordinator), the timeline for completing it, and the standard for documentation (written, attributed, retained for six years under §164.316(b)(2)(i)).

Section 7: Notification Obligations and Timelines

If the determination is breach, three notification streams begin:

Individual notification. Without unreasonable delay, and no later than 60 calendar days from 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. For breaches affecting 500 or more individuals, contemporaneously with the individual notice — without unreasonable delay and no later than 60 calendar days from discovery — via the OCR portal. For breaches affecting fewer than 500, the report is due no later than 60 days after the end of the calendar year in which the breach was discovered, though a practice may file sooner, as soon as one is discovered.

Media notification. Only for breaches affecting more than 500 residents of a State or jurisdiction — a different threshold from the 500-or-more-individuals test that triggers HHS reporting. Notice to prominent media outlets serving the area, on the same standard as the individual notice.

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. §164.316(b)(2)(i) and §164.530(j) require the documentation the rules call for to be kept six years from creation or last effective date — the plan itself, the policies, and the incident documentation §164.308(a)(6) requires. The list below is what we would retain; useful to hold, and not every line separately mandated:

• 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 — annually is our recommendation; §164.308(a)(8) requires periodic evaluation without fixing an interval
• Trigger events that require interim review (any actual incident, any organizational change, any new system or vendor)
• Tabletop exercise frequency — annually for an independent practice, quarterly if you can. HIPAA does not require tabletop exercises at all; this is our recommendation
• Workforce training frequency — annually with documentation is our recommendation; §164.530(b) requires training for new workforce members and on material change, and sets no annual cadence

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 triage was never rehearsed. Plans document the steps but nobody has walked them. When an incident happens, the response sprawls because nobody has done it before and nobody is tracking where they are in the sequence, so steps get repeated and others get skipped. The fix is not a stopwatch — it is having run it once before it mattered. This is what a tabletop exercise is for, and thirty minutes of one is worth more than another page of plan. Reviewing after the fact tells you where the sequence broke down, which is the only reliable way to find out that it will. Practices that discover this during a real incident find out expensiveles. 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 gives this template somewhere to happen. Security Alerts surfaces conditions inside the platform that should not persist and holds the disposition of anything a person did; the Event Log keeps the record, with Resolved and Reported as independent fields and Time Occurred separate from Time of Action, which is where a notification clock actually runs from. Incidents are entered by a person — the platform does not ingest them from your network, endpoints or other systems, and it does not determine whether something was a breach or send your notices. What it does is keep the documentation §164.316 asks you to retain.

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.