A.5.24ISO 27001Last reviewed 19 February 2026

ISO 27001 A.5.24: Information security incident management planning and preparation

When a breach happens at 2am on a Saturday, you do not want people scrambling to figure out who does what. The time to plan your incident response is before you need it, not during the crisis.

Work through the ISO 27001 assessment, record supporting evidence and review the gaps in your answers.

Start my free ISO 27001 assessmentNo account · No credit card · Save when useful

Requirement summary

The organization shall plan and prepare for managing information security incidents by defining, establishing and communicating information security incident management processes, roles and responsibilities.

Check the source wording and scope in ISO/IEC 27001:2022. The guidance below explains how to approach a review.

In Plain Language

This control is about building a formal incident management framework: defining what counts as an incident, assigning clear roles and responsibilities, documenting the response procedures, and making sure everyone involved knows what to do. Preparation is what separates a controlled response from a chaotic one.

Beyond the plan itself, you need communication channels, a severity classification scheme, escalation procedures, the right tools, and regular testing. A plan that has never been exercised is just a document - you find the gaps by running simulations.

How to Implement

Build an incident response plan covering the full lifecycle: preparation, identification, containment, eradication, recovery, and lessons learned. Get management sign-off and make it accessible to everyone who needs it.

Define incident categories and severity levels. Create a classification scheme so responders can quickly categorise an incident and know how to respond. Common categories: malware, unauthorised access, data breach, denial of service, insider threat, physical security. Severity levels (Critical, High, Medium, Low) should map directly to response timeframes and escalation rules.

Stand up an incident response team with clear roles. You need an incident manager to coordinate, a technical lead for investigation and remediation, a communications lead for internal and external messaging, a legal liaison, a management representative, and subject matter experts as needed. Define on-call arrangements and escalation paths.

Write detailed playbooks for common incident types. Each should cover: how to detect it, initial response steps, containment strategies, evidence preservation, eradication procedures, recovery steps, and communication requirements. Make sure you address regulatory notification deadlines - GDPR gives you 72 hours, NIS2 has its own requirements.

Prepare your tooling and infrastructure. Get forensic tools, isolated investigation environments, secure comms channels for the response team, pre-drafted notification templates, stakeholder contact lists, and secure evidence storage in place. Set up an incident tracking system for logging and managing cases.

Test regularly. Run tabletop exercises and technical drills across different scenarios: data breaches, ransomware, insider threats, supply chain compromises. Use the results to fix gaps and update procedures. Train all staff on how to spot and report potential incidents.

Evidence to review

Documented incident response plan with defined processes and procedures
Incident classification scheme with severity levels and response requirements
Incident response team roster with defined roles and contact information
Records of incident response exercises and tabletop simulations
Incident response tooling and infrastructure documentation

Common Mistakes

Incident response plan exists on paper but has never been tested through exercises
Incident response roles are assigned but personnel are not trained in their duties
No incident classification scheme making it difficult to prioritize response efforts
Communication procedures are not defined for internal and external stakeholders
Regulatory notification requirements are not addressed in the incident response plan

Related Controls Across Frameworks

Framework	Control ID	Relationship
SOC 2	SOC 2 CC7.3: System Operations - Evaluation of Security Events	Related
SOC 2	SOC 2 CC7.4: System Operations - Incident Response	Related
GDPR	GDPR Art.33: Notification of a Personal Data Breach to the Supervisory Authority	Related
GDPR	GDPR Art.34: Communication of a Personal Data Breach to the Data Subject	Related
NIS2	NIS2 Art.23	Related

Frequently Asked Questions

How often should we test our incident response plan?

At minimum, one tabletop exercise and one technical drill per year. If you are in a high-risk industry, do more. After any real incident, review and update the plan based on what you learned. Also test when new threats emerge or when your infrastructure changes significantly. Vary the scenarios each time so you are not just rehearsing the same script - the point is to find weaknesses, not to pass a test.

What is the difference between an event and an incident?

An event is any observable security-related occurrence - a failed login, a firewall alert, an antivirus detection. Most events are routine. An event becomes an incident when it has an actual or potential negative impact: a successful breach, confirmed data exposure, active malware infection. Your classification process should include clear criteria for when an event gets escalated to an incident, because you do not want your response team chasing every failed password attempt.

Track ISO 27001 compliance in one place

Work through the ISO 27001 assessment, record supporting evidence and review the gaps in your answers.

Start Free Assessment

Start without an account · Sign up only to save

Start my free ISO 27001 assessment