ISO 27001 Incident Response Plan: The Complete 2026 Guide

An ISO 27001 incident response plan is the documented procedure that tells your people exactly what to do in the first hour after something goes wrong, and it is one of the first documents a certification auditor asks to see. Most companies have something written down. Far fewer have something that survives a Stage 2 audit.

Part of the reason is that ISO/IEC 27001:2022 never uses the phrase in its clauses. The requirement is spread across five Annex A controls plus a separate event-reporting control, and the standard describes the outcome rather than the document. This guide sets out what the plan has to cover, which controls it satisfies, how to build one in seven steps, the regulatory clocks it has to respect, and the evidence auditors actually sample.

What an ISO 27001 Incident Response Plan Actually Covers

Your ISO 27001 incident response plan is the operational runbook for the window between something looks wrong and we have closed this out and improved the ISMS. It is not your incident management policy, and it is not a per-threat playbook. Auditors expect to see the difference, and collapsing all three into one forty-page file is a reliable way to fail evidence sampling, because nobody can find the containment steps under pressure.

Document	Answers	Typical length
Incident management policy	Why we do this, who owns it, what management commits to	2–4 pages
Incident response plan	Who does what, in what order, with what authority and timings	8–15 pages
Playbooks / runbooks	Exact technical steps for ransomware, BEC, data loss, DDoS	2–5 pages each

The plan sits in the middle. It is the layer an auditor reads end to end, and the layer your on-call engineer opens at 03:00.

The Annex A Controls Behind an ISO 27001 Incident Response Plan

ISO 27001:2022 lists 93 Annex A controls in four themes — 37 organizational, 8 people, 14 physical and 34 technological. Six of them drive the incident lifecycle, and your ISO 27001 incident response plan is the artefact that demonstrates all six.

Control	Title	What your plan has to show
A.5.24	Information security incident management planning and preparation	Defined process, roles, responsibilities, trained responders, agreed tooling
A.6.8	Information security event reporting	A channel every employee knows, with a target reporting time
A.5.25	Assessment and decision on information security events	Documented criteria for turning an event into a classified incident
A.5.26	Response to information security incidents	Containment, eradication, recovery and communication, executed to procedure
A.5.27	Learning from information security incidents	Root cause analysis feeding controls, risk assessment and training
A.5.28	Collection of evidence	Chain of custody and forensically sound handling of logs and images

Two supporting controls matter more than people expect. A.5.5 (contact with authorities) is what you cite when the plan names the regulator, CSIRT or law enforcement contact you will call, and A.5.29 (information security during disruption) is the hinge between incident response and continuity. Annex A is a menu rather than a mandate, so inclusion is justified in your Statement of Applicability under clause 6.1.3 — but in practice no organization credibly excludes the incident controls.

What an ISO 27001 Incident Response Plan Must Contain

There is no prescribed table of contents, but a certification auditor works through roughly the same checklist every time. A defensible ISO 27001 incident response plan contains all ten of the following.

1. Scope and definitions. Which systems, sites, entities and suppliers the plan covers, and a plain distinction between an event, an incident and a personal data breach.
2. Roles and authority. Named incident manager, technical lead, communications lead, legal and privacy contacts, and the executive sponsor. State who can authorise taking production offline — this single sentence saves hours.
3. Severity classification. A three or four tier scale with objective triggers, tied to response and escalation times.
4. Detection and reporting channels. How staff, customers, suppliers and researchers report, and how alerts from monitoring reach a human.
5. Triage and assessment criteria. The A.5.25 decision gate, with a documented owner.
6. Response procedures. Containment, eradication, recovery and validation, with links to the technical playbooks.
7. Evidence handling. What to preserve, how, and who maintains chain of custody.
8. Communication and notification. Internal escalation, customer messaging, regulator and CSIRT contacts, and the clocks in the next section.
9. Post-incident review. Timing, attendees, root cause method, and how actions land in the corrective action register under clause 10.2.
10. Testing and maintenance. Exercise schedule, review frequency, version history and approver.

If you want the wider documentation picture, our guide to the ISO 27001 mandatory documents shows where the incident set sits alongside the risk assessment, SoA and internal audit records.

How to Build an ISO 27001 Incident Response Plan in Seven Steps

Writing an ISO 27001 incident response plan takes a competent team about two working days, plus a fortnight of review. The order below keeps that effort from being wasted.

1. Map your incident scenarios to real risk

Start from your risk assessment, not from a generic template. If your register flags SaaS account takeover and supplier compromise as your top risks, the plan needs to handle those first. Auditors look for this thread.

2. Set the severity scale before you write procedures

Anchor each tier to something measurable: number of records, customer-facing downtime, regulated data involved, whether an attacker still has access. Vague scales such as “high impact” produce inconsistent decisions and audit findings.

3. Name people, not job families

“The IT team” is not a role. Name individuals with deputies, and publish an out-of-hours contact list that lives outside the systems that might be encrypted.

4. Write the first hour as a checklist

The opening page should be actionable without reading the rest: declare, assemble, contain, preserve, notify. Everything else is reference material.

5. Wire in the regulatory clocks

Put the notification deadlines that apply to your organization directly in the plan with the responsible owner. Do not make an engineer at 02:00 work out whether GDPR applies.

6. Test it before the auditor does

Run a tabletop within 90 days of approval. Record attendees, scenario, decisions, timings and actions. That record is often worth more to an auditor than the plan itself.

7. Close the loop into the ISMS

Lessons learned must visibly change something: a control, a risk score, a supplier clause, a training module. A.5.27 is where thin plans fail, because the review happens but nothing downstream moves.

The Reporting Clocks Your Plan Has to Respect

ISO 27001 itself sets no notification deadline. Your legal and contractual obligations do, and clause 4.2 requires you to identify them. Map whichever of these apply to you, then build them into the escalation table inside your ISO 27001 incident response plan.

Regime	Trigger	Deadline
GDPR (EU/UK)	Personal data breach with risk to individuals	Notify the supervisory authority within 72 hours of becoming aware
NIS2 (Art. 23)	Significant incident at an essential or important entity	Early warning within 24 hours, notification within 72 hours, final report within one month
DORA	Major ICT-related incident at a financial entity	Initial notification within 4 hours of classification and no later than 24 hours of awareness; intermediate at 72 hours; final within one month
HIPAA (US)	Breach of unsecured protected health information	Notify affected individuals without unreasonable delay and within 60 calendar days of discovery
Customer contracts	Security incident affecting customer data	Commonly 24–72 hours; check your signed DPAs, they are often tighter than law

Deadlines change and vary by member state, so treat this as an orientation table and confirm against your own obligations register. Our detailed walkthrough of breach notification requirements covers the GDPR mechanics in full.

ISO 27001 Incident Response Plan vs. Business Continuity Plan

These two documents are constantly confused, and the confusion causes real damage during a ransomware event when nobody knows which plan is running.

	Incident response plan	Business continuity plan
Question answered	What is happening and how do we stop it?	How do we keep operating while it happens?
Primary controls	A.5.24–A.5.28, A.6.8	A.5.29–A.5.30; ISO 22301 if certified
Owner	Security / incident manager	Business continuity or operations lead
Trigger	Any confirmed security incident	Disruption exceeding agreed tolerance
Key measure	Time to detect, contain and eradicate	RTO and RPO per critical activity
Ends when	Root cause removed and lessons captured	Normal operations resumed

They run in parallel, and the plan should say who declares the handover. If you are building both, start with the ISO 22301 business continuity plan structure so the two documents share one severity scale.

The Evidence Auditors Sample

• The approved plan with a version history and a dated management approval
• Training or briefing records for named responders (A.5.24)
• An incident register showing classification, timings and closure
• Two or three closed incident records end to end, including the triage decision
• Tabletop or live exercise notes with actions and owners
• Post-incident reviews linked to corrective actions in the clause 10.2 register
• Evidence that an action actually changed a control, a risk rating or a supplier requirement

Auditors sample, they do not read everything. A tidy register with three well-documented incidents beats a beautiful plan with no operating history. The same logic applies during your ISO 27001 internal audit, which is where you should find these gaps first.

Five Mistakes That Turn Into Nonconformities

1. The plan has never been exercised. Approved eighteen months ago, never tested. This is the most common finding.
2. No evidence of the A.5.25 decision. Incidents are recorded, but nothing shows how an event was assessed and classified.
3. Lessons learned that lead nowhere. Reviews are held, actions are listed, and no risk or control is updated.
4. Contacts stored only in the affected system. Your escalation list lives in the SharePoint tenant that is now encrypted.
5. Suppliers left out. The plan covers your staff but says nothing about how a managed provider or SaaS vendor reports an incident to you.

Frequently Asked Questions

Is an ISO 27001 incident response plan mandatory?

Not as a named document in the clauses. But A.5.24 and A.5.26 require documented, communicated processes for planning, preparing and responding, and clause 7.5 requires documented information where it is needed for effectiveness. In practice, no certification body will accept an ISMS without a written incident response procedure, so treat an ISO 27001 incident response plan as mandatory in all but name.

How often should we test the plan?

Test your ISO 27001 incident response plan annually at minimum, and after any significant change to your systems, suppliers or scope. Many certified organizations run one tabletop and one technical exercise each year. Real incidents count as tests if you document the review properly.

Who should be on the incident response team in a small company?

Three named people is workable: an incident manager who owns decisions and communication, a technical lead, and an executive who can authorise spend, downtime and external notification. Everyone needs a deputy. Below about fifteen staff, expect to name an external forensics or MSP contact as your escalation path.

Can we use NIST guidance instead?

You can use it alongside. NIST SP 800-61 Revision 3, published in April 2025, restructures incident response around the six functions of the NIST Cybersecurity Framework 2.0 and is a good source of practical detail. ISO/IEC 27035 is the ISO-side companion. Neither replaces the Annex A evidence your auditor needs, but both help you write better procedures.

What is the difference between an event and an incident?

An event is any observed occurrence that may be security relevant — a failed login spike, an alert, a report of a strange email. An incident is an event, or a series of events, that has been assessed as likely to compromise information security. The assessment that moves one to the other is control A.5.25, and your plan must state who makes that call and on what criteria.

Where to Start

If you are writing from scratch, build the severity scale first, then the first-hour checklist, then the roles. Everything else can be drafted around those three. If you are fixing an inherited plan before a certification or surveillance audit, test it once and let the exercise tell you what is missing — it usually takes two hours and finds more than a week of editing.

The ISO 27001 Toolkit includes a pre-written incident response plan, incident management policy, incident register and post-incident review form alongside 165 templates covering the full Annex A control set, for $99. If you want the wider route to the certificate first, start with our guide to ISO 27001 certification, and read the requirements in the standard itself at ISO/IEC 27001:2022.