ISO 27001 Annex A 5.24: incident management planning and preparation

The client's security questionnaire asks who leads an incident at 2am on a Saturday, and who deputises. The honest answer is whoever picks up. ISO 27001 Annex A 5.24 replaces that answer with a procedure, named roles and a rehearsed routine that exist before anything goes wrong.

This guide is for security leads, CTOs and COOs at 25–250-person firms heading for ISO 27001:2022 certification. It covers what the control requires, how to build a lean plan and team, severity tiers, reporting, rehearsal, what auditors sample, and how to automate readiness.

What does ISO 27001 Annex A 5.24 information security incident management planning and preparation require?

Annex A 5.24 requires an organisation to prepare for security incidents before one happens. That means an agreed process covering detection, triage, escalation, response, communication, evidence and learning; named, trained people; one known reporting route; management-agreed priorities; and awareness of external reporting clocks. It is the 'before' control of the incident family.

You will see the control written as ISO 27001 A.5.24, or in full as ISO 27001:2022 Annex A 5.24 information security incident management planning and preparation. Either way, it owns the capability that exists before an incident, not the handling of one. Four neighbouring controls pick up from there:

• ISO 27001 Annex A 5.25 triages events and decides which of them become incidents.
• A.5.26 runs the response itself. Auditors read the plan under A.5.24 and the incident log under A.5.26.
• A.5.28 governs how evidence is collected and handled.
• A.6.8 carries the staff duty to report events, which the reporting channel built under A.5.24 serves.

Read the control proportionately. It does not ask for a security operations centre. It asks that a 50-person firm can show who does what when something goes wrong, and that the answer is written down, agreed and tested.

The control is corrective in character. It exists to limit and repair damage once something has gone wrong, and preparation is what makes that correction fast rather than improvised. It defends confidentiality, integrity and availability alike, because incidents arrive as breaches, tampering and outages.

Why does incident readiness matter under the UK GDPR 72-hour clock?

Incident response is where several clocks converge. UK GDPR requires notifiable personal data breaches to be reported to the ICO without undue delay and within 72 hours of becoming aware, and client contracts may add tighter promises. Firms that improvise miss those windows, and the mishandling usually costs more than the incident.

The ICO personal data breach reporting guidance frames the threshold. Only breaches that meet it go to the ICO, but the 72 hours run from when you discover the breach, not when it happened. Deciding quickly whether a breach qualifies is therefore a preparation task, not a response-day improvisation.

The NCSC incident management overview makes the point about outcomes: whatever the threat, good preparation is the one thing that helps you deal well with an incident. Technical skill works inside the structure you built beforehand.

Other clocks run alongside the ICO's:

• Client contracts increasingly carry their own notification promises.
• DORA and NIS2 obligations flow down from regulated clients into their suppliers' contracts.
• Cyber insurers now ask about response readiness on proposal forms.

A contained technical event becomes a regulatory and commercial one when updates contradict each other and notifications arrive late. Readiness is what lets you tell the client what happened, what you have done and what happens next, in that order.

How do you build a lean ISO 27001 incident response plan and team?

Write one procedure of about ten pages, not forty, that a stressed person can follow at 2am. Name the team by role: incident lead, technical investigator, note-taker, and reach-ins for legal, HR and communications. Give every role a deputy, and use a virtual team drawn from existing staff rather than a dedicated one.

An incident response plan for ISO 27001 should read as instructions, not policy prose. It walks the full arc in the order a stressed reader needs it:

1. Reporting: how an event reaches the team.
2. Assessment: who decides whether it is an incident.
3. Severity: how the tier is set.
4. Response: who does what.
5. Communication: who talks to whom, inside and outside the firm.
6. Evidence: what to preserve before anyone starts rebuilding.
7. Lessons: how the review is captured.

Name roles, not departments:

• Incident lead: whoever owns security. At this size that is often the founder, COO or a fractional CISO.
• Technical investigator: the person who can actually look at the systems.
• Note-taker: keeps the timeline and decisions as they happen.
• Reach-ins: legal, HR and communications contacts identified in advance.

Put one person's name against each role. A steering group can advise, but the incident needs a single decision-maker at 2am.

Ownership by committee is no ownership.

The contact list matters as much as the roster. Keep it somewhere that still works when the phone system or corporate chat is down. Include personal mobile numbers for the lead, the investigator and their deputies.

The NCSC guidance on building a CSIRT says a virtual team, pulled together when needed from people with other day jobs, is more cost-effective than a dedicated one. For a firm of 25 to 250 people, that is the realistic model.

Keep training records for the response roles. Procedure documents and periodic training are what an auditor reads as competent personnel.

The design avoids two failures. One is a roster that rots because the named lead left last year. The other is an enterprise SOC playbook suite of twenty runbooks that no 40-person firm will maintain. One living procedure beats a shelf of dead ones.

How do you set severity tiers and response targets?

Severity tiers P1 to P4, each with plain criteria and a target response time agreed by management, make the priority call carry authority. Tie the criteria to what is critical in your asset register, and map which severities start which regulatory clocks, so the notify-or-not decision is defensible at speed.

Write each tier as a test a stressed person can apply without asking permission. Example criteria:

• P1: confirmed loss of client data, or an outage of a system your asset register marks as critical.
• P2: suspected data exposure, or degraded service on a critical system.
• P3: a contained event on a non-critical asset, such as one malware alert on a managed laptop.
• P4: a near-miss or false alarm, logged for the record.

Management signs off the tiers and their target response times. That signature turns the priority call into an authorised one, so the incident lead never waits for approval before paging the team.

Then pre-map the clocks. For each tier, record whether it starts an ICO assessment, a client notification or a staff briefing, and keep a template ready for each. Drafting a regulator notification in hour three of a ransomware event is how windows get missed.

The mapping closes off the usual failure of regulatory duties discovered mid-crisis. Without it, nobody asks whether the ICO needs to know until the 72-hour window is half spent.

Sequence matters, because severity needs something to be relative to. Build the tiers once the asset register and risk assessment exist. From there, the procedure, roles and templates take one to two weeks.

What does a single front door for incident reporting look like?

A single front door means one obvious, low-friction route (a Slack channel, a monitored address or a ticket form) that any member of staff can name without thinking. Feedback keeps that route alive: reporters should hear what happened, or they stop reporting, and events then surface days late through corridor conversation.

Pick the route staff already open every day. Publish it in onboarding, the handbook and the procedure, and it also serves the staff reporting duty in A.6.8. Friction kills reporting, so ask only for what, where and when, and let the incident lead collect the rest.

Feedback is the maintenance. A two-line acknowledgement and a short outcome note tell the reporter the report mattered. A false alarm that earns a thank-you produces the next real report.

Test the door with a new starter: ask where they would report a phishing email. If they hesitate, it is not yet one door.

How often should you rehearse the incident plan?

Rehearse at least annually, and after major changes to systems or people. A half-day tabletop against a realistic scenario counts, provided findings are logged, actions are closed, and the procedure is updated. Ransomware combined with a data-breach clock is the highest-yield pairing. The first run always finds the dead phone number.

Choose a scenario that forces both halves of the plan. A ransomware event where client personal data was also copied out starts the technical response and the notification clock together. Allow a half-day plus preparation, with the lead, investigator, note-taker and a reach-in from legal or communications in the room. Expect to find an ambiguous handoff between lead and investigator, and a template nobody can locate.

A plan nobody has rehearsed is a hypothesis, not a capability.

Make the exercise count by logging and closing it:

1. Record the scenario, attendees and findings.
2. Assign each finding an owner and a date.
3. Close the action and keep the evidence.
4. Update the procedure and its version date.

Re-run the exercise after major change, such as a new identity provider, a new incident lead or an acquisition. Every real incident gets the same loop: a root-cause discussion, procedure updates and a trail showing the improvements landed.

This inverts two common pitfalls. A plan written for the certificate meets its first test in a real incident, the most expensive tabletop there is. A firefighting culture, where incidents are fixed but never reviewed, sees the same root cause return every quarter.

What do auditors look for, and when is a gap major or minor?

Auditors trace one or two incident-log entries end to end against the procedure and check the contact list is current. They also ask a random interviewee how they would report something suspicious. No procedure, no designated responders, or a real incident handled off-process grades major; overdue exercises or stale rosters grade minor, adding up to major as a pattern.

Expect questions like these in the room:

• "Talk me through what happens from the moment someone suspects an incident."
• "Who is your incident lead, who deputises, and when were they last exercised?"
• "When did you last rehearse, what broke, and what did you change?"
• "A laptop with client data goes missing on a Friday evening. Which notification obligations start, and how do you meet them over a weekend?"

The Friday laptop is the sharpest of them. A good answer names the severity tier, the personal-data assessment, the ICO clock and any client promise, then says who does each over the weekend. The answer comes from the plan, not from memory.

Auditors check the procedure's review date before its content. Exercise records get the same scrutiny, because findings without closed actions are a finding in themselves.

Assemble the evidence pack before the audit:

• Procedure: approved, dated and version-controlled.
• Roster: roles, deputies, current contact details and training records.
• Severity matrix: response targets with the management sign-off behind it.
• Exercise artefacts: scenario, attendees, findings and closure dates.
• Templates: notification drafts and the regulatory mapping.
• Post-incident reviews: improvements traced into the procedure.
• Incident log: near-misses and false alarms recorded alongside real events.

An empty incident log doesn't prove a quiet year. To an auditor, it reads as a dead process.

Grading follows a simple logic. An isolated minor is fixable, but the same minor repeated across contact lists, exercises and records is a pattern, and a pattern grades major. The classic example is staff broadly unaware of the reporting route.

With the pack assembled, the audit is a walk-through, not an interrogation.

How do you engineer incident readiness so it runs itself?

Wire readiness into tools people already use. A Slack workflow or portal form opens a structured ticket, severity drives paging, the timeline is captured as the incident runs, and attestations and exercise reminders fire on a schedule. The log self-assembles, and the response tooling keeps a break-glass route for when the identity provider is down.

The reporting workflow comes first. The ticket is timestamped, categorised and acknowledged, which makes the front door frictionless. Severity then drives routing: the tier decides who is paged and when, so response targets are enforced by the system rather than remembered under stress.

The record becomes a by-product. Decisions and communications are captured in the ticket and the incident channel as the response runs. The post-incident review and the auditor's end-to-end trace fall out of the tooling instead of being reconstructed from memory.

Readiness runs on a schedule. Contact-list attestation, template reviews and exercise reminders fire automatically, and overdue tasks surface on the compliance dashboard instead of in the audit. That retires stale-roster rot without anyone remembering to check.

Protect the response tooling itself, so it works when the corporate stack is what is compromised:

• Ticketing: tight access, with the incident queue limited to the response team.
• Communications bridge: a backup channel that does not depend on corporate chat.
• Admin credentials: a break-glass account held offline, with every use logged and reviewed.

Our Fractional CISO service designs the capability, takes the incident-lead seat and runs the annual exercise. Our GRC Engineering service builds the workflows, escalation rules and scheduled checks. None of it needs a SOAR suite. The table compares the four automations by what each catches, how often it runs and the evidence it leaves.

Frequently asked questions