In my experience, auditors have zeroed in on incident response processes time after time.

An effective incident response plan is one of the clearest signals to an ISO 27001 auditor that your ISMS is actually being used, not just written.

When an incident happens, you need to be prepared to take action, and to be able to:

• Spot it quickly
• Decide how serious it is
• Contain and fix it
• Communicate clearly
• Learn from it

This article walks through how to build an ISO 27001-aligned incident response plan, using the components already in my ISO 27001 toolkit:

• Incident & Major Incident process
• Cyber Security Incident Response Plan
• Major Incident Report template
• BCP & Disaster Recovery Plan

You can lift the structure straight into your ISMS documentation.

---

1. Why you need an incident response plan

ISO 27001 expects you to manage incidents end-to-end, not just “log them and hope”. Annex A makes this explicit with a collection of controls:

• A.5.24 – Information security incident management responsibilities and procedures
• A.5.25 – Assessment and decision on information security events
• A.5.26 – Response to information security incidents
• A.5.27 – Learning from information security incidents
• A.5.28 – Collection of evidence

Your incident response plan is the practical expression of these controls. It should help you:

• Detect and report incidents consistently
• Make clear decisions about what to escalate and when
• Respond in a structured way (contain → eradicate → recover)
• Capture evidence and lessons learned
• Show auditors and customers that you can handle problems calmly, not chaotically

Think of it as the “playbook” to allow you to ‘break glass in case of emergency’ that connects alerts, people, procedures and business continuity.

---

2. How it links to Business Continuity and Disaster Recovery

Not every security incident is a disaster. A password reset after a phishing attempt is very different to a ransomware outbreak or loss of a cloud region. These things still need logging, and tracking, but they have very different responses.

The relationship should look like this:

• All information security incidents follow the incident response process
• Some incidents are serious enough to be declared major incidents
• Only the worst cases (prolonged service loss, serious data compromise) trigger BCP/DR

You can capture that with a simple rule in the plan, for example:

“All information security incidents follow the incident response process. Where the incident causes prolonged loss of service or threatens RTO/RPO, the Incident Manager may activate the BCP & Disaster Recovery Plan.”

Auditors like to see that link: incident → (major) incident → BCP/DR if needed.

---

3. Building blocks of an ISO 27001 incident response plan

A workable plan doesn’t have to be long, but it should be complete.

At minimum it should cover:

Your existing incident procedures and cyber incident response plan already provide the building blocks – your job is to pull them together into a single, coherent plan.

---

4. Step-by-step: creating your incident response plan

Step 1 – Define scope and triggers

First, be clear what this plan actually covers.

Typical scope wording:

“This plan covers cyber and information security incidents affecting confidentiality, integrity or availability of in-scope systems and data, including but not limited to: malware infections, account compromise, unauthorised access, data loss or disclosure, service outages caused by security events, and suspected privacy or regulatory breaches.”

Then define simple triggers, for example:

• Security event that materially affects confidentiality / integrity / availability → Incident
• Service outage > X minutes or any event where customer data may be at risk → Major incident
• Major incident with prolonged outage or high business impact → Consider BCP/DR activation

This gives staff a clear path from “odd alert” to “we’re in major incident mode”.

---

Step 2 – Set roles and responsibilities

Lift these from your existing IR and BCP/DR documents and bring them into one “Roles” section, for example:

Make sure it’s crystal clear who can declare a major incident and who can trigger BCP/DR.

---

Step 3 – Document the process flow

Your process doesn’t need to be complicated; it just needs to be consistent and documented. A text version that maps neatly to Annex A might look like:

1. Identify
   • Event is reported or an alert is raised (tooling, user report, supplier notification).
2. Log
   • Record the event in your service desk / ticketing tool or incident log.
   • Capture basic details: who, what, when, systems affected.
3. Assess & classify (A.5.25)
   • Decide: is this an information security incident?
   • Decide: is it minor, significant, or a major incident?
   • Consider impact on customers, services and regulatory obligations.
4. Respond – contain and eradicate (A.5.26)
   • Contain: isolate affected systems, revoke access, block malicious sources.
   • Eradicate: remove malware, close vulnerabilities, change credentials, harden controls.
5. Recover (A.5.26 + BCP/DR)
   • Restore from clean backups, rebuild systems if needed, test that services work.
   • If normal recovery isn’t enough, invoke the BCP/DR plan.
6. Communicate
   • Keep staff, management and (where needed) customers and regulators informed.
7. Lessons learned (A.5.27)
   • Within an agreed timeframe (e.g. 10 working days), run a post-incident review.
   • Identify what went well, what didn’t and what needs to change.
8. Evidence & forensics (A.5.28)
   • Preserve relevant logs, screenshots, system images and notes.
   • Maintain chain of custody if there’s any chance of legal action.

You can support the flow with a simple diagram from your “Incident & Major Incident Processes” slide in your toolkit.

---

Step 4 – Add playbooks for common scenarios

Most incidents fall into a handful of patterns. Having short, focused playbooks makes response faster and less stressful.

Common playbooks include:

• Suspected account compromise (e.g. password reuse, suspicious logins)
• Malware / ransomware on endpoint or server
• Suspected data breach (lost laptop, mis-sent email, exposed bucket)
• Service outage due to cyber event (DDoS, misconfiguration, failed change)

Each playbook should outline:

• Typical indicators
• First containment steps
• Who to involve
• Key decisions (e.g. when to inform customers, when to notify the ICO)
• Evidence to preserve

Your Cyber Security Incident Response Plan is effectively a “break glass” playbook for serious cyber events – reference it directly in the main plan as the detailed guide for those scenarios.

---

Step 5 – Include reporting and documentation

From an ISO 27001 point of view, your records are just as important as your actions. The plan should tell people:

• Where to log all incidents and near misses
• When to complete a Major Incident Report (e.g. any customer-impacting incident or anything that triggers BCP/DR)
• Where incident reports and reviews are stored and who can see them

Your major incident report template already includes:

• Incident details and timing
• Impacted services and users
• Timeline of key events and actions
• Root cause analysis
• Follow-up actions and owners
• Evaluation of the process and lessons learned

Spell out that this report is mandatory for major incidents and forms part of your audit evidence and management review input.

---

Step 6 – Integrate with BCP/DR

In the “Recovery” or “Escalation” section of your plan, explicitly point to your BCP & Disaster Recovery Plan.

For example:

“Where recovery cannot be achieved through normal incident response, or where customer-facing services are materially degraded, the Incident Manager will consider activation of the BCP & Disaster Recovery Plan. Once invoked, incident response and BCP/DR activities will be coordinated to minimise downtime and restore normal operations.”

This shows that major security incidents are handled in a joined-up way, not in silos.

---

Step 7 – Close the loop in the ISMS

Finally, bring it back to ISO 27001’s continual improvement requirements.

Your plan should say that every significant incident:

• Is reviewed within a defined timeframe (e.g. 10 working days)
• Has corrective actions raised and tracked to completion (clause 10.2)
• Feeds into risk assessment and Statement of Applicability updates where relevant
• Is summarised into management review (clause 9.3) so leadership can see patterns and trends

That’s what turns incidents from “bad news” into improvement opportunities – and it’s what auditors expect to see.

---

5. Suggested structure for your incident response plan

You can use this as the contents list for your formal plan:

1. Purpose – Ensure timely and coordinated response to information security incidents, aligned to ISO/IEC 27001 Annex A 5.24–5.28.
2. Scope – People, systems and locations covered.
3. References – ISO 27001, Incident Policy, Cyber Security Incident Response Plan, BCP/DR, related SOPs.
4. Definitions – Event, incident, major incident, data breach, etc.
5. Roles and responsibilities – Incident Manager, Incident Response Team, ISMS Lead, Technical Lead, Comms, etc.
6. Incident lifecycle – Identify → Log → Classify → Respond → Recover → Close → Lessons learned.
7. Classification and triggers – Event vs incident vs major incident; when to invoke BCP/DR.
8. Communication and external reporting – Customers, regulators (ICO), law enforcement if relevant.
9. Evidence and forensics – How evidence is preserved and chain of custody maintained.
10. Testing and training – Exercises, scenario tests, awareness.
11. Records and audit trail – What’s kept, where and for how long.

Drop your existing diagrams and templates into the relevant sections so everything is joined up.

---

6. Using my ISO 27001 toolkit to shortcut the work

If you don’t want to build all of this from scratch, my ISO 27001 Toolkit includes:

• An Incident & Major Incident process you can adopt and tweak
• A detailed Cyber Security Incident Response Plan you can treat as your “break glass” playbook
• A Major Incident Report template for consistent post-incident reviews
• A combined BCP & Disaster Recovery Plan that hooks into the same process

Together, they give you a complete, ISO 27001-friendly incident response setup that you can implement quickly and then refine over time, rather than reinventing every piece yourself.