Skip to content
AuditFront
A.5.24 ISO 27001

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

What This Control Requires

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

In Plain Language

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. 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 Your Auditor Will Request

  • 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 CC7.3 Related
SOC 2 CC7.4 Related
GDPR Art.33 Related
GDPR Art.34 Related
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

AuditFront helps you manage every ISO 27001 control, collect evidence, and stay audit-ready.

Start Free Assessment