ISO 27001 Incident Response Plan: Template and Process
Every ISO 27001-certified organisation must have a formal incident response plan. Annex A.16 of the standard sets out requirements for managing information security incidents, from initial detection through to post-incident review. This article explains what your IR plan must include, provides a ready-to-adapt template structure, and walks through the complete incident response process.
Incident Response Requirements Under Annex A.16
Annex A.16 (incident management) has six controls, each of which places specific demands on your incident response plan:
- A.16.1.1 – Responsibilities and procedures: You must define management responsibilities and establish procedures for responding to incidents.
- A.16.1.2 – Reporting: All employees must know how and when to report security events.
- A.16.1.3 – Assessment: Each incident must be triaged, assessed for impact, and classified.
- A.16.1.4 – Response: Incidents must be contained, investigated, and resolved.
- A.16.1.5 – Lessons learned: Every incident must trigger a review and documented improvements.
- A.16.1.6 – Evidence collection: You must collect and preserve evidence in a legally admissible manner.
Your incident response plan is the operational document that brings these controls to life. It must be approved by management, tested regularly, and updated after each significant incident.
Core Components of an ISO 27001 Incident Response Plan
A compliant IR plan should include the following sections:
- Purpose and scope: What the plan covers and which systems, locations, and teams are in scope.
- Definitions: Clear definitions of security events, incidents, and breaches.
- Roles and responsibilities: The incident response team (IRT), their alternates, and escalation paths.
- Incident classification: Severity levels and corresponding response times.
- Reporting procedures: How users report potential incidents.
- Response procedures: Step-by-step actions for each incident type.
- Communication plan: Internal and external communication protocols.
- Evidence handling: Chain of custody and forensic procedures.
- Post-incident review: Lessons learned and corrective actions.
Incident Classification Framework
Not all incidents are equal. A classification framework ensures that resources are allocated proportionally to the severity of the incident.
| Severity | Definition | Examples | Response Time | Reporting Level |
|---|---|---|---|---|
| Level 1 – Low | Minor event, no data loss | Phishing email reported by user, single failed login attempt | Within 8 working hours | Team lead |
| Level 2 – Medium | Potential data exposure, limited impact | Malware detected on workstation, unauthorised access attempt | Within 2 hours | Information Security Manager |
| Level 3 – High | Confirmed data loss, service disruption | Ransomware infection, data exfiltration detected | Within 30 minutes | CISO, legal, senior management |
| Level 4 – Critical | Major breach, regulatory notification required | Large-scale PII leak, system-wide compromise | Immediate | Board, regulators, law enforcement |
Step-by-Step Incident Response Procedures
Your plan must define clear procedures for each phase of the incident response lifecycle, aligned with the NIST framework (Preparation, Detection, Containment, Eradication, Recovery, Lessons Learned).
| Phase | Objective | Key Actions | Annex A Control |
|---|---|---|---|
| Preparation | Ensure readiness | Train IR team, deploy tools, define playbooks | A.16.1.1 |
| Detection | Identify the incident | User reports, SIEM alerts, anomaly detection | A.16.1.2, A.16.1.3 |
| Containment | Limit damage | Isolate affected systems, preserve evidence | A.16.1.4, A.16.1.6 |
| Eradication | Remove the threat | Remove malware, patch vulnerabilities, reset credentials | A.16.1.4 |
| Recovery | Restore normal operations | Restore from backup, verify system integrity, monitor | A.16.1.4 |
| Post-Incident Review | Learn and improve | Root cause analysis, update policies, retrain staff | A.16.1.5 |
Communication Plan During an Incident
Annex A.16 does not explicitly mandate a communication plan, but auditors will expect one. Your plan should define who speaks to whom, when, and through which channels.
Escalation Procedures
Escalation ensures that incidents receive the appropriate level of attention as they develop. Your plan must define:
- Escalation triggers: When a Level 2 incident should be escalated to Level 3 (e.g. lateral movement detected, evidence of data exfiltration, involvement of privileged accounts).
- Escalation path: From IR analyst to team lead to ISM to CISO to board.
- Time-based escalation: If an incident is not resolved within a defined timeframe, it automatically escalates. For example, any Level 2 incident unresolved after 4 hours escalates to Level 3.
- Decision authority: Who can authorise system shutdowns, data disconnection, or public statements.
Evidence Collection and Chain of Custody
Annex A.16.1.6 requires that evidence be collected and preserved in a manner that is admissible in legal proceedings. This is particularly important for incidents that may lead to litigation or regulatory action.
- Imaging disks using write-blockers and hashing original media.
- Recording who handled evidence, when, and why (chain of custody log).
- Storing evidence in a secure, access-controlled location.
- Documenting all analysis steps with timestamps and tools used.
Post-Incident Review and Corrective Actions
Every incident must be followed by a formal post-incident review (PIR) within 30 days. The PIR should answer:
- What happened? (timeline of events)
- Why did it happen? (root cause)
- What worked well in the response? (strengths)
- What did not work well? (gaps)
- What corrective actions are needed? (prevent recurrence)
Corrective actions must be tracked in your ISMS corrective action log (aligned with A.16.1.5) and reviewed during management review meetings (A.9.3).
Testing Your Incident Response Plan
A plan that sits in a drawer is worse than no plan at all. Your IR plan must be tested regularly:
- Tabletop exercises (quarterly): Walk through scenarios with the IR team to identify procedural gaps.
- Drills (semi-annually): Simulate specific incident types such as ransomware or phishing.
- Full simulation (annually): A live exercise involving multiple teams, including non-security staff, to test end-to-end response.
ISO 27001 Incident Response Plan Template
Below is a simplified template structure you can adapt for your organisation:
- Document Control – Version history, approvers, review date.
- Purpose – Define the scope and objectives of the IR plan.
- Definitions – Incident, breach, event, near miss.
- Roles – IR team members, deputies, contact details.
- Classification – Severity matrix (Level 1–4).
- Reporting – How and where to report an incident.
- Response Procedures – Step-by-step for each incident type.
- Communication – Internal, external, regulatory, media.
- Escalation – Triggers, paths, decision authority.
- Evidence Handling – Chain of custody and forensic process.
- Review – Post-incident review and corrective action tracking.
- Testing – Schedule for exercises and drills.
Frequently Asked Questions
Is an incident response plan mandatory for ISO 27001 certification?
Yes. Annex A.16 requires documented procedures for managing incidents. Without an approved and tested incident response plan, you cannot demonstrate compliance with A.16.1.1, and a non-conformity will be raised during your certification audit.
How often should I update my incident response plan?
At least annually, and after every significant incident, major system change, or change in legal/regulatory requirements. Each update should be version-controlled and approved by management.
Can one IR plan cover all incident types?
One plan can establish the overall framework, but you should supplement it with specific playbooks for common incident types such as ransomware, phishing, insider threat, DDoS, and data breach. The master plan refers to the playbooks.
What is the difference between an incident and a breach under ISO 27001?
An incident is any security event that may compromise confidentiality, integrity, or availability. A breach is a specific type of incident where data is actually accessed or disclosed to an unauthorised party. Your IR plan should cover both, with additional procedures for breach notification obligations.
Do I need to notify regulators if I have an incident?
ISO 27001 does not mandate regulatory notification, but local laws might. For example, GDPR requires notification within 72 hours for personal data breaches. Your IR plan must reference applicable legal and regulatory notification requirements based on your jurisdiction and the data types involved.
What evidence should I retain for an ISO 27001 audit after an incident?
Retain the incident report, the chain of custody log, all communications related to the incident, the post-incident review report, and any corrective action records. Auditors will examine these as evidence that A.16 controls are operating effectively.
Get Your Incident Response Plan Ready for Audit
A robust incident response plan is not just an audit requirement – it is your organisation’s first line of defence when a security incident occurs. Whether you are building your IR plan from scratch or reviewing an existing one for ISO 27001 compliance, our consultants can help you design, document, and test a plan that meets Annex A.16 requirements and prepares you for real-world incidents.
