---
title: "ISO 27001 Annex A 5.24: incident management planning and preparation"
canonical: https://www.grcmana.io/vault/iso-27001/annex-a-5-24-information-security-incident-management-planning-and-preparation
published: 2023-03-13
updated: 2026-10-07
author: "Harry West"
framework: "ISO 27001"
control: "A.5.24 Information security incident management planning and preparation"
journeyStage: implementation
---

# ISO 27001 Annex A 5.24: incident management planning and preparation

## Key takeaways

Annex A 5.24 is the standing incident capability you build before a crisis: a lean procedure, named roles with deputies, severity tiers and pre-mapped regulatory clocks. Rehearsal and a dated evidence trail are what auditors test. Tooling a 25–250-person firm already uses can keep the whole thing alive.

- **Scope** — Annex A 5.24 is the 'before' control of the incident family: the process, people, reporting route and priorities that must exist before any incident occurs.
- **Team model** — One living procedure, named roles with a deputy for each, and a virtual team drawn from existing staff give a small firm a plan it can keep current.
- **Regulatory clocks** — UK GDPR gives 72 hours to notify the ICO of a qualifying breach, so severity tiers should map in advance which incidents start which regulatory and client clocks.
- **Audit grading** — Auditors trace incident-log entries end to end, check the contact list is current and ask staff how they would report. Overdue exercises grade minor; absent procedures or responders grade major.

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](https://ico.org.uk/for-organisations/advice-for-small-organisations/personal-data-breaches/72-hours-how-to-respond-to-a-personal-data-breach/) 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](https://www.ncsc.gov.uk/collection/incident-management) 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](https://www.ncsc.gov.uk/collection/incident-management/creating-incident-response-team) 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.

| Automation | What it catches | Cadence | Evidence left |
| --- | --- | --- | --- |
| Reporting workflow | Events reported late, or not at all | Continuous | Timestamped, categorised ticket with acknowledgement |
| Severity-driven escalation | Slow or unauthorised priority calls | Every incident | Paging record against the response target |
| Self-assembling record | Gaps in timeline, decisions and communications | During each incident | Timeline for the post-incident review and the auditor's trace |
| Scheduled readiness checks | Stale contacts, outdated templates, overdue exercises | Quarterly attestation, annual exercise | Attestation records on the compliance dashboard |

## Frequently asked questions

### Do we need an incident management platform to meet A.5.24?

No. A ticket queue or a structured Slack channel plus a disciplined log satisfies the control at 25–250 people. SIEM and SOAR platforms are patterns you grow into when alert volume outgrows manual triage. Buy them for that reason, not for the audit.

### Who should own A.5.24 incident management in a firm without a CISO?

Name one senior owner, typically the COO, CTO or founder, who keeps the procedure in date and takes the severity tiers to management for sign-off. The owner need not lead incidents: a fractional CISO can hold the design and the incident-lead seat while the owner keeps the authority to speak for the firm.

### Does every incident under A.5.24 have to be reported to the ICO?

No. Only personal-data breaches that meet the ICO's reporting threshold go to the ICO. The ICO's guidance says to start a log even when you may not need to report. Record what happened and your reasoning, including any decision not to notify, so the call is defensible later.

### What should an A.5.24 procedure say about suppliers, external responders and crisis escalation?

Decide in advance what the internal team handles and where external help starts: forensics, specialist counsel and your insurer's response panel. Keep contact numbers that work out of hours in the plan. Add coordination arrangements with suppliers who would sit inside a real incident, and an escalation route into crisis or continuity plans for scenarios that outgrow IT.

### Does incident response readiness under A.5.24 affect cyber insurance?

In practice, yes. Response readiness is now a question on cyber insurance proposal forms. Your procedure, roster and last exercise date are answers you will be asked for. Agree with your insurer beforehand how its response panel fits into your escalation steps.