A.5.24 — Incident Management Planning and Preparation

A ransomware attack hits at 3 a.m. on a Saturday. The on-call IT engineer knows the systems but has never handled a security incident. There is no documented escalation path, no pre-defined communication plan, no evidence preservation procedure. Every decision is improvised under pressure. A.5.24 prevents this by requiring organisations to plan and prepare for incident management before an incident occurs.

Purpose: To ensure quick, effective, consistent and orderly response to information security and privacy incidents, including communication on information security and privacy events.
Direction: Corrective
Protection goals: Confidentiality, Integrity, Availability
Theme: Organisational
BSI modules: DER.2.1, DER.1
KPI: % of incident response plans tested within the last 12 months

Responsible	Information Security Officer / (C)ISO
Accountable	Information Security Officer / (C)ISO
Consulted	Data Protection Officer, Department Head, HR Manager, Head of IT, Information Security Officer / (C)ISO, Legal Counsel, Risk Owner, Supply Chain Manager
Informed	All Employees, Department Head, Incident Response Team, Information Security Officer / (C)ISO, Legal Counsel, Top Management

What does the standard require?

Establish an incident management process. Define how security events are reported, assessed, escalated and handled across the organisation.
Define roles and responsibilities. Assign clear roles for incident detection, triage, response, communication and post-incident review. Establish an incident response team with defined authority.
Create incident response procedures. Develop detailed procedures for the most likely incident types: malware, data breach, denial of service, insider threat, physical security breach.
Plan communications. Define who communicates with whom during an incident — internal escalation, external parties (authorities, customers, media), and under what conditions.
Ensure competence. Train the incident response team regularly and test the procedures through exercises.

In practice

Define the reporting channel. Every employee must know how to report a security event. A simple, well-publicised mechanism — a dedicated email address, a phone number, or a button in the intranet — ensures that events are captured quickly.

Establish classification criteria. Define what distinguishes a minor event from a major incident. Typical criteria include the number of affected users, the classification of compromised data, business impact and regulatory implications. This classification drives the response level.

Prepare communication templates. Under the pressure of a real incident, drafting communications from scratch wastes critical time. Prepare templates for management briefings, authority notifications (A.5.5), customer notifications and press statements. Adapt them during the incident.

Test through exercises. Run at least one tabletop exercise per year. Walk through a realistic scenario with the incident response team, management and legal. Document lessons learned and update the plan accordingly.

Typical audit evidence

Auditors typically expect the following evidence for A.5.24:

Incident management policy — defining the overall framework for incident handling
Incident response procedures/runbooks — detailed step-by-step guides for specific scenarios
Role assignments — documented incident response team with contact details
Exercise reports — evidence that plans were tested, with documented lessons learned
Training records — showing that incident response personnel received appropriate training
Communication plan — defining internal and external communication during incidents

KPI

% of incident response plans tested within the last 12 months

This KPI tracks whether your plans have been validated through exercises. Target: 100% of documented plans tested within their review cycle. A plan that has never been tested provides false confidence.

Supplementary KPIs:

Average time from event report to initial triage (target: under 1 hour for critical events)
Percentage of employees who know how to report a security event
Number of tabletop exercises conducted per year
Time since last plan update

BSI IT-Grundschutz

A.5.24 maps to the following BSI requirements:

DER.2.1 (Security incident management) — the comprehensive BSI module for planning, detecting and responding to security incidents.
DER.1 (Detection of security-relevant events) — covers the detection capabilities that feed into incident management.

A.5.24 is the planning phase for the entire incident lifecycle:

A.5.25 — Assessment of security events: The triage process that classifies events as incidents.
A.5.26 — Response to incidents: The operational response that the plan enables.
A.5.27 — Learning from incidents: Post-incident reviews feed back into plan improvements.
A.5.5 — Contact with authorities: Authority notification is a key element of the communication plan.

Sources

ISO/IEC 27001:2022 Annex A, Control A.5.24 — Incident management planning and preparation
ISO/IEC 27002:2022 Section 5.24 — Implementation guidance
BSI IT-Grundschutz, DER.2.1 — Security incident management

Frequently asked questions

What is the difference between a security event and a security incident?

A security event is any observable occurrence relevant to information security -- a failed login attempt, an antivirus alert, an unusual network connection. A security incident is a security event (or series of events) that has a significant probability of compromising business operations or threatening information security. The incident management process starts with events and escalates confirmed incidents.

What must an incident response plan contain?

At minimum: roles and responsibilities, classification criteria for events and incidents, escalation procedures, communication plans (internal and external), containment and eradication steps, evidence preservation procedures, recovery steps and post-incident review requirements.

How often should incident response plans be tested?

At least annually through tabletop exercises or simulations. After any significant incident, the plan should be reviewed and updated based on lessons learned. Organisations in regulated sectors often face more frequent testing requirements.