ISO 27001 Incident Response: Requirements and Process
Every organisation will face a security incident. The question is not if, but when. ISO 27001 incident response requirements ensure that when a breach, attack, or security event occurs, you have a planned, tested, and documented process to contain the damage, restore normal operations, and learn from what happened. Without it, you are reacting blindly when every minute counts.
Incident Response Requirements: Clause 6.1.3 and Annex A
ISO 27001:2022 addresses incident response through a combination of Clause 6.1.3 (information security risk treatment) and Annex A controls specifically focused on incident management. The standard requires organisations to plan how they will respond to incidents before they happen, not after.
| ISO 27001 Reference | Requirement | What You Must Have |
|---|---|---|
| Clause 6.1.3 | Plan how to treat identified information security risks | Incident response plan as part of risk treatment strategy |
| Annex A 5.24 | Establish responsibility for incident management | Incident response team with defined roles |
| Annex A 5.25 | Define incident management processes | Documented incident response procedure |
| Annex A 5.26 | Respond to incidents consistently | Incident response playbooks and checklists |
| Annex A 5.27 | Learn from incidents | Post-incident review and improvement process |
| Annex A 5.28 | Collect evidence for legal or disciplinary action | Forensic evidence handling procedures |
These controls are not optional. If you are implementing ISO 27001, every one of these must be addressed in your ISMS. An external auditor will expect to see documented policies, assigned responsibilities, and evidence that the processes work.
The Incident Response Process: Six Phases
While ISO 27001 does not mandate a specific incident response framework, the industry-standard six-phase model aligns perfectly with the standard’s requirements. Each phase maps to specific Annex A controls.
1. Prepare
Preparation is the foundation of effective incident response. Before any incident occurs, you need an incident response policy, a trained team, communication plans, and the right tools. This phase addresses Annex A 5.24 (establishing responsibility) and 5.25 (defining processes). Preparation activities include writing playbooks, setting up logging and monitoring systems, and establishing relationships with external support (legal, PR, law enforcement).
2. Identify
Detection and identification determine how quickly you can respond. This phase covers Annex A 5.26 (responding to incidents) and depends on effective monitoring, logging, and reporting mechanisms. Employees must know how to report suspicious activity. Automated tools (SIEM, IDS/IPS, endpoint detection) should alert the response team. The goal is to identify the incident, classify its severity, and begin documenting evidence immediately.
3. Contain
Containment is about stopping the incident from spreading. Short-term containment might include disconnecting affected systems from the network, revoking compromised credentials, or blocking malicious IP addresses. Long-term containment applies temporary fixes to allow business operations to continue while permanent remediation is prepared. Every containment action must be documented to support forensic analysis and legal proceedings.
4. Eradicate
Eradication removes the root cause of the incident. This may involve removing malware, patching vulnerabilities, rebuilding compromised systems from clean images, or changing all affected passwords and access keys. This phase must include thorough verification that the threat is completely removed before moving to recovery.
5. Recover
Recovery restores normal operations. Systems are brought back online, data is restored from backups, and monitoring is increased to watch for signs of recurrence. The recovery phase must be methodical and tested. Rushing recovery can reintroduce vulnerabilities or allow the attacker to regain access.
6. Lessons Learned
This phase directly addresses Annex A 5.27 (learning from incidents). After the incident is resolved, the team conducts a post-incident review to identify what went well, what went wrong, and what needs to improve. The output is a set of action items that feed back into the ISMS continuous improvement cycle. Without lessons learned, you will repeat the same mistakes.
| Phase | Key Activities | Annex A Control |
|---|---|---|
| Prepare | Policy development, team formation, tool acquisition, training | 5.24, 5.25 |
| Identify | Detection, classification, evidence preservation, initial reporting | 5.26 |
| Contain | Short-term and long-term containment, communication | 5.26 |
| Eradicate | Root cause removal, system cleanup, vulnerability patching | 5.26 |
| Recover | System restoration, monitoring, business continuity verification | 5.26 |
| Lessons Learned | Post-incident review, reporting, process improvement | 5.27 |
The Incident Response Team
Annex A 5.24 requires the organisation to establish responsibilities for incident management. This means defining an incident response team with clear roles, regardless of the organisation’s size. In small organisations, these roles may be held by the same people wearing multiple hats. The important thing is that everyone involved knows their responsibilities before an incident occurs.
| Role | Responsibility | Typical Holder |
|---|---|---|
| Incident Response Manager | Overall coordination, decision-making, escalation | CISO, IT Manager, or senior manager |
| Technical Lead | Technical analysis, containment, eradication, recovery | Senior IT engineer or security analyst |
| Communications Lead | Internal and external communications, regulatory reporting | PR or legal team member |
| Legal Advisor | Legal and regulatory obligations, evidence preservation | In-house legal counsel or external solicitor |
| HR Representative | Employee-related matters, disciplinary actions if needed | HR manager |
| Business Continuity Lead | Business continuity and disaster recovery coordination | BCM coordinator |
The team must have the authority to make rapid decisions. If every action requires approval from senior leadership, the incident will run ahead of your response. Pre-delegated authority for specific actions (such as disconnecting systems) should be documented in the incident response policy.
Reporting Requirements
ISO 27001 and associated regulations (particularly GDPR) impose reporting obligations when certain types of incidents occur. The incident response process must include clear criteria for when and how to report to regulatory authorities, affected customers, and other stakeholders.
- Regulatory reporting – GDPR requires notification to the relevant supervisory authority within 72 hours of becoming aware of a personal data breach unless the breach is unlikely to result in a risk to individuals’ rights and freedoms.
- Customer reporting – Affected customers must be informed without undue delay when the breach is likely to result in a high risk to their rights and freedoms.
- Contractual reporting – Many contracts include specific SLAs for incident notification. These must be captured in the incident response plan.
- Internal reporting – All incidents, regardless of severity, should be reported internally through the established incident management process.
Testing and Drills
An untested incident response plan is a wish, not a plan. ISO 27001’s emphasis on continuous improvement means you must test your incident response capabilities regularly. Testing reveals gaps in the plan, weaknesses in team preparedness, and technical gaps in detection and response tools.
- Tabletop exercises – Walk-through scenarios with the incident response team discussing how they would respond. These are low-cost and effective for testing decision-making and communication.
- Simulated incidents – Realistic but controlled scenarios that test technical detection and response capabilities. Common simulations include phishing attacks, ransomware scenarios, and data exfiltration attempts.
- Full-scale drills – End-to-end tests that activate the entire incident response process, including business continuity and disaster recovery procedures. These are high-effort but reveal the most gaps.
Every test should result in a report with findings and improvement actions. The test schedule should be documented in the incident response policy, with at least one drill per year and quarterly tabletop exercises as best practice.
Frequently Asked Questions
What is the difference between an incident and a breach in ISO 27001?
An information security incident is any event that has compromised or could compromise the confidentiality, integrity, or availability of information. A breach is a specific type of incident where a security control has been defeated. All breaches are incidents, but not all incidents are breaches. Your incident response process should handle both.
Do I need a dedicated incident response team for ISO 27001 certification?
Not necessarily. The standard requires that responsibilities are assigned, not that you have a dedicated full-time team. In small organisations, the IT manager, HR manager, and a senior leader can form the incident response team. What matters is that the roles are defined, the team is trained, and the process is documented and tested.
How quickly must we report an incident under ISO 27001?
ISO 27001 itself does not specify a reporting timeframe for external notifications (that is governed by GDPR and other regulations). However, the standard requires timely internal reporting as part of the incident management process. Most organisations define internal reporting SLAs in their incident response policy, typically within one hour of detection for critical incidents.
What evidence must be preserved during incident response?
Annex A 5.28 requires evidence collection procedures. At minimum, preserve system logs, network traffic captures, memory dumps, disk images, email communications, and any other data that may be relevant to forensic analysis or legal proceedings. Evidence must be handled following forensic best practices to maintain the chain of custody and admissibility in court.
Can we outsource incident response?
You can outsource elements of incident response to managed security service providers (MSSPs) or incident response retainers, but you cannot outsource accountability. The organisation retains ultimate responsibility for incident management. If you use external providers, the incident response plan must clearly define the interface between internal and external teams.
How often should we test our incident response plan?
Best practice is a full test at least annually and tabletop exercises quarterly. High-risk industries or organisations with mature security programmes may test more frequently. The frequency should increase after significant changes to the IT environment, after major incidents, or when the incident response team changes.
Strengthen Your Incident Response Capability
ISO 27001 incident response is not just about passing an audit. It is about ensuring that when the worst happens, your organisation can respond quickly, effectively, and professionally. The time to prepare is now, not after a breach.
Contact Bitrixme today to review or build your ISO 27001 incident response framework. Message us on WhatsApp for an immediate conversation about your incident response needs.
