Nov 05, 2026

Cybersecurity Incident Response Plan Template for ISO 27001

It's Sunday at 2 a.m., and attackers are moving through your network. Who in your company can order the website taken offline right now? Who calls the cyber insurer? Who decides whether regulators need to be told?

When an incident happens, people should know who to contact straight away. If it takes more than a minute to find the right person, your incident response plan may have a gap. Some laws also set short reporting deadlines, including requirements to notify regulators within 24 hours of discovering an incident.

You do not want to work out roles and procedures during an incident. This template helps you set them in advance, covering eight key areas of incident response and the relevant ISO 27001 Annex A controls.

What Is a Cybersecurity Incident Response Plan? A Written Playbook for the First Hours of an Attack

A cybersecurity incident response plan gives your team a clear process for handling an incident. It covers how to detect and contain the incident, who handles each task, what happens next, and who needs to be notified.

Incident response plans are written before an attack happens. During an attack, your team follows the plan instead of making decisions from scratch, and in haste.

Your Plan Must Separate Security Events From Cybersecurity Incidents

ISO 27001 control 5.25 requires you to assess each security event and decide whether it counts as an incident. The plan treats the two differently:

A security event is something that might signal a problem. Examples include a failed login, an antivirus alert, or a suspicious email reported by an employee.
A cybersecurity incident happens when an event puts your systems or data at risk. For example, ransomware may encrypt a file server, or customer records may be copied to an unknown external address.

Most events never become incidents. Your plan should state the criteria for declaring an incident. It should also name the person with the authority to declare one. Information security incident management covers the full process, from the first report to closure.

The Cybersecurity Incident Response Plan Template Has Eight Sections, Each Tied to an ISO 27001 Control

You can use the eight sections below as your template. Each section maps to the ISO 27001 control an auditor will check it against.

Eight Sections of a Cybersecurity Incident Response Plan

Section	What to include	ISO 27001 control
1. Purpose, scope, and activation criteria	The systems, sites, and data covered, and the conditions that trigger the plan	5.24
2. Roles and contacts	Named people, their deputies, phone numbers, and external contacts	5.24
3. Severity levels	Each level with examples and a target response time	5.25
4. Reporting channels	How any employee reports a suspected event, at any hour	6.8
5. Response procedures	Steps for containment, eradication, and recovery, with a playbook for each incident type	5.26
6. Notification requirements	Regulators, customers, and insurers to notify, with deadlines	5.5 and 5.26
7. Evidence collection	What to preserve, who handles it, and a chain-of-custody log	5.28
8. Post-incident review	Root cause, lessons learned, corrective actions, and plan updates	5.27

Severity Levels Tell Your Team How Fast to Move

Define four levels, each with an example and a target response time. For example:

Severity 1 (critical): Ransomware spreading across production systems, or confirmed theft of customer data. The response starts within 15 minutes, and executives are told within 1 hour.
Severity 2 (high): A compromised administrator account, or malware on a single server. The response starts within 1 hour.
Severity 3 (medium): Malware found on one laptop, or a phishing link clicked by one employee. The response starts within 4 hours.
Severity 4 (low): A blocked phishing attempt, or a policy breach with no data exposed. The response starts within 1 business day.

Every Role on the Response Team Needs a Named Person and a Deputy

The incident response lead declares the incident and coordinates the response.
IT and security analysts contain affected systems and collect evidence.
Legal counsel decides which notifications the law requires.
The communications lead prepares messages for customers, staff, and the media.
An executive sponsor approves major decisions, such as taking systems offline.
External contacts include your forensics firm, your cyber insurer, and law enforcement.

Clear information security roles and responsibilities prevent two people from giving the same instruction, or nobody giving it.

Notification Deadlines Start Before You Know the Full Story

Several laws require you to report a cybersecurity incident within a fixed time. The clock usually starts when you discover the incident or decide it is serious. Your investigation will often still be running at that point.

Law or rule	Who it applies to	Deadline
Securities and Exchange Commission (SEC) Form 8-K, Item 1.05	US public companies	4 business days after deciding an incident is material
General Data Protection Regulation (GDPR)	Organizations handling personal data of people in the EU	72 hours after becoming aware of a personal data breach, unless the breach is unlikely to put people at risk
NIS2 Directive	Essential and important entities in the EU, for significant incidents	Early warning within 24 hours, incident notification within 72 hours, final report within one month of the notification
Health Insurance Portability and Accountability Act (HIPAA) Breach Notification Rule	US healthcare providers, health plans, and their business associates	Without unreasonable delay, and no later than 60 calendar days after discovering a breach
Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA)	US critical infrastructure operators	72 hours for covered cyber incidents, 24 hours after a ransom payment, once the final rule takes effect

The Cybersecurity Incident Response Process Runs in Six Phases

Most incident response plans follow the same six phases:

Preparation. You build the team, write the playbooks, and set up monitoring before anything happens.
Detection and analysis. Your team confirms the incident, judges its severity, and works out which systems are affected.
Containment. You isolate affected systems to stop the attack from spreading.
Eradication. You remove the malware, close the entry point, and reset compromised accounts.
Recovery. You restore systems from clean backups and watch them for signs of reinfection.
Post-incident review. You record the root cause and assign corrective actions.

Test Your Incident Response Plan at Least Once a Year

A plan that has never been tested usually fails on small details during a real attack. Testing shows you those gaps while there is still time to fix them.

Metrics That Show Whether Your Incident Response Plan Works

The simplest test is a tabletop exercise. It works like this:

Gather your response team in one room for one to two hours.
Pick a realistic scenario, such as ransomware locking your file servers on a Monday morning.
Walk through the plan step by step, and ask each person what they would do.
Note every point where the plan is unclear, out of date, or missing a step.

Typical gaps include a deputy's phone number that no longer works, or nobody with the authority to take systems offline.

After each test, turn every gap into a corrective action with an owner and a due date. Update the plan after every test, every real incident, and every major system change. ISO 27001 control 5.27 requires you to learn from incidents and improve your controls. A structured incident report records those lessons in a form an auditor can check.

Effivity Keeps Every Incident Record, Playbook, and Corrective Action in One System

Effivity's incident management software runs your incident response plan inside your ISO 27001 system. With it, you can:

Hold each incident's report, severity, tasks, evidence, and timeline in one record
Route each response step to the right role automatically
Time-stamp every action for a complete audit trail
Keep playbooks under version control, with approval history
Track corrective actions from tests and real incidents through to closure
See open incidents, aging cases, and overdue actions on one dashboard

Visit the Effivity website to learn more about managing information security incidents in one system.

Frequently Asked Questions

What is a cybersecurity incident response plan?

A cybersecurity incident response plan is a written guide for detecting, containing, and recovering from a cyberattack. It names the response team and the order of actions. It also lists the notification deadlines that apply to you.

Does ISO 27001 require an incident response plan?

Yes. ISO 27001 control 5.24 requires you to plan and prepare for information security incidents. You must define your incident management processes, roles, and responsibilities. You must also communicate them to the people involved. Auditors expect to see this written down, usually as an incident response plan.

How often should incident response plans be tested?

Test them at least once a year. You should also review them after every real incident and every major system change.

SivaSankarVikranth B

QA Manager at Effivity

SivaSankarVikranth has extensive 7 years of experience in IT, helping clients achieve top-quality software solutions. His dedication to quality and strong technical skills drive Effivity’s success and customer satisfaction.

View All Posts

Improve Workflow & Profitability with Superior Integrated Management System Software free-demo

Schedule a Free Demo