ISO 27001 Annex A 5.24

Plan for incidents now - the response cannot be invented during the event.

ISO 27001 Annex A 5.24 - Information Security Incident Management Planning and Preparation

Incidents are not the moment to start writing the response procedure. The control requires the procedure to exist beforehand, with named roles, defined criteria and known communication routes. When something happens, the response runs on muscle memory rather than improvisation.

The plan needs to cover the practical steps - how an incident is detected and reported, who triages, who has authority to declare an incident, what the escalation routes are, how communication is handled internally and externally, how decisions are recorded and how the incident is formally closed. It should also cover post-incident learning, which is the bridge to Annex A 5.27.

Preparation includes more than the document. Staff need to know how to recognise and report a potential incident. The team responsible for response needs to be trained and equipped. Communication routes need to be tested. For higher-risk environments, exercises that simulate incidents help confirm the plan works in practice rather than just on paper.

The incident plan needs to be readable at three in the morning by a tired person under pressure. That means clear steps, names rather than role titles, and contact details that work out of hours. A polished plan that no one can use when they need it is worse than a plain one that people actually follow.

Practical Compliance Guidance

Incident management arrangements are described in the IMS1 manual at section 8.2 alongside the information security incident reporting process. The incident form is used to record incidents through to closure.

alphaZ document How to use it
ISO 27001 Toolkit The full alphaZ ISO 27001 toolkit covering manual, policies, procedures, registers and audit checklists.
F-Q109 Information Security Incident The form used to record an information security incident from initial report through investigation, response and closure. Each incident gets its own record.

Note - all the above files can be downloaded with an alphaZ subscription.

Frequently Asked Questions

Some form of testing is recommended. For lower-risk environments, a tabletop walk-through of a hypothetical scenario may be enough. For higher-risk environments, more realistic exercises that test communication, decision-making and technical response add value. Testing should happen at least annually and after significant changes to the plan.
At minimum someone with technical authority over the affected systems, the Information Security Lead or equivalent, and someone with management authority who can make decisions including external communication. Larger organisations may add legal, HR, communications and senior management roles depending on the incident.
Incident management addresses information security events specifically and the immediate response. Business continuity is about recovery from major disruption to the business. The two overlap where a security incident causes business disruption, but they have different focus and trigger thresholds. Both plans should cross-reference where the boundary sits.

Further Resources

payment logos