Incident Response Plan Template: 6 Phases With Owners

Event, incident or crisis: define them first

Most plans fail at the first question: is this even an incident? Put three short definitions at the top of your template so everyone sorts alerts the same way.

The definitions decide who gets woken up. An event stays with the analyst. An incident goes to the incident commander. A crisis brings in the executive sponsor, legal and communications.

• Event: anything observable on a system, such as a failed login or a blocked email. Most events need no action.
• Incident: an event that threatens the confidentiality, integrity or availability of systems or data, such as a compromised account or ransomware on a laptop.
• Crisis: an incident that threatens the business itself, its customers or its reputation, and needs executive decisions.

Severity levels and who gets called

A severity scale turns a judgment call into a rule. Use four levels, and attach a response target and a call list to each. The targets below are a starting point. Adjust them to your team size and contracts.

Write one rule in bold in your plan: when in doubt, raise the severity. Lowering it later costs little. Starting too low costs hours.

• P1, critical: confirmed data breach, ransomware, or a core service down for all customers. Response within 15 minutes, around the clock. Call the incident commander, security, IT, legal, communications and the executive sponsor.
• P2, high: compromised privileged account, or a key service degraded for many users. Response within 1 hour. Call the incident commander, security and IT.
• P3, medium: malware on a single device or a successful phishing click with no sign of spread. Response within 1 business day. Handled by security or IT.
• P4, low: policy violation or blocked attack attempt. Handled in the normal ticket queue.

Roles and responsibilities, with backups

Each role needs a named person and a named backup, because incidents happen during holidays. Keep the list short and clear.

In a small company, one person can hold two roles. Never combine incident commander and hands-on technical lead, because someone has to keep the overview.

• Incident commander: runs the response, makes the calls, keeps the timeline. Does not do technical work.
• Security lead: investigation, evidence, threat analysis.
• IT operations lead: containment, eradication, restore.
• Legal counsel: notification duties, evidence handling, contact with the cyber insurer.
• Communications: messages to staff, customers and press, all approved by legal.
• HR: involved when an employee is a cause or a victim.
• Executive sponsor: approves big decisions such as shutting down a service or paying for outside help.

Incident response plan example: the first 72 hours

Take a fictional company: a 200-person logistics firm with offices in the US and the EU. On Monday at 8:40 a.m., an employee reports that files on a shared drive have strange extensions and a ransom note.

Under Article 33(1) of the GDPR, the controller must notify the supervisory authority "without undue delay and, where feasible, not later than 72 hours after having become aware of it". The clock starts at awareness, not at the end of the investigation. This is the timeline leadership wants to see on one page.

• Hour 0 to 1: the analyst confirms ransomware and sets P1. The incident commander opens the call, and IT disconnects the file server and the affected laptop.
• Hours 1 to 4: security images both machines. Legal calls the cyber insurer, as the policy requires. Communications sends a short internal note: do not open the shared drive, do not talk about it outside.
• Hours 4 to 24: the team finds the entry point, a phishing email that stole a password. All passwords for the affected team are reset. Legal checks whether personal data of EU residents was reached.
• Hours 24 to 72: personal data was exposed, so legal prepares the notification to the supervisory authority. IT restores clean backups by business priority.

Cybersecurity incident response plan template: notification duties

A cybersecurity incident response plan template must list every outside party you may have to notify, with the deadline and the owner. Legal owns this list. It is a starting point for your plan and does not replace advice from a lawyer for each country and sector you work in.

• GDPR (EU personal data): Article 33(1) of the GDPR requires notice to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of the breach. This does not apply when the breach is unlikely to result in a risk to people's rights and freedoms.
• SEC (US public companies): under the cybersecurity disclosure rules the SEC adopted in 2023, a material cybersecurity incident is disclosed on Form 8-K Item 1.05. That filing is generally due four business days after the company determines the incident is material. The SEC allows a delay only when the US Attorney General decides that immediate disclosure would pose a substantial risk to national security or public safety.
• HIPAA (US health data): the HHS Breach Notification Rule (45 CFR 164.400 to 414) applies to covered entities and their business associates. Affected individuals must be told without unreasonable delay and no later than 60 days after the breach is discovered. If a breach affects 500 or more people, HHS must be told within the same deadline.
• US state laws: many states have their own breach notification laws. List the states where your customers live and have counsel confirm the rules for each one.
• Cyber insurer: many policies set notice conditions and may require approved response firms. Read yours now, not during the incident.
• Customers under contract: many contracts set their own notice deadline. Pull those clauses into one list.

Communication templates to prepare in advance

Writing messages during a crisis wastes time and creates risk. Draft four short templates now and have legal approve them.

Set a fixed rhythm for updates, for example every two hours on a P1. When people know the next update is coming, they stop calling the incident commander for news.

• Internal alert: what happened in one sentence, what staff must do or avoid, who to contact.
• Leadership update: severity, systems affected, actions taken, next decision needed, time of next update.
• Customer notice: what happened, what data is involved, what you are doing, what they should do.
• Holding statement for press: you are aware, you are investigating, you will share more when you can.

Testing, metrics and yearly review

A plan that has never been tested is a guess. Run a tabletop exercise at least once a year and rotate the scenarios: ransomware, phishing with account takeover, data leak by an insider, outage at a key cloud vendor.

Track a few metrics after each incident and each exercise.

• MTTD (mean time to detect): from the start of the incident to detection.
• MTTR (mean time to respond or recover): from detection to normal service.
• Open actions: lessons learned items not yet closed.

How to present the plan to leadership or a client

Executives and auditors do not read a 40-page document. Show them a one-page visual: the six phases left to right, the owner under each phase, the P1 time targets and the notification deadlines. Put the detail in the appendix.

Prepare for three questions: who decides to shut down a service, how fast regulators and customers are told, and when the plan was last tested. If your one-page view answers all three, the meeting is about approval, not about gaps.