A.5.24 Incident management planning: requirements and evidence

What A.5.24 incident management planning requires before an incident happens

A compliance lead or CISO preparing for an audit or a customer questionnaire needs to show that incident response was designed before anything went wrong. A.5.24 asks the organization to plan and prepare for managing information security incidents by defining, establishing and communicating an incident management process, with roles and responsibilities that people know about before they are needed. The control does not ask for a response in the moment. It asks for the decisions, owners, routes and rehearsals that make the response possible when a real event arrives. Without that preparation, the first hours of an incident are spent deciding who is in charge, who may shut down a system, who calls the regulator and which lawyer to contact. Those decisions made under pressure tend to be inconsistent and poorly recorded, which weakens the evidence an auditor will later ask for. A.5.24 is the foundation for the controls that follow it: A.5.25 needs triage criteria to decide whether an event is an incident, A.5.26 needs documented procedures to respond against, A.5.27 needs a review step to learn from the result, and A.5.28 needs collection rules so evidence stays usable. A.6.8 depends on the same groundwork, because staff can only report events if they know the channel and the form to use.

The usual failure points are predictable. Roles exist on an org chart but nobody has accepted them, so the named incident manager is on leave when an alert fires. Contact lists hold people who left a year ago or omit the out-of-hours number for the cloud provider. Reporting routes differ between the help desk, the security mailbox and the on-call tool. Plans are written once and never exercised, so their gaps only surface during a real event. To check readiness, confirm that each role has a named person with a deputy, that contact details were verified within a set review period you define, and that the last tabletop exercise produced recorded actions. The requirement has roots in ISO/IEC 27001:2013, where the closest predecessor was control A.16.1.1, Responsibilities and procedures. NIST's crosswalk from SP 800-53 Rev. 5 to ISO/IEC 27001:2022 relates A.5.24 to IR-8 Incident Response Plan, which gives a useful cross-check if your organization already maintains a NIST-aligned plan. Confirm the mapping against the current NIST workbook before citing it to an assessor, since mappings are interpretive and do not transfer compliance automatically.

Which systems, teams and third parties the incident process must cover

The incident process under A.5.24 is only as wide as the ISMS scope and the Statement of Applicability that defines it. The cards below cover the decisions that set that width: the assets, the internal teams, and the external parties whose contact details and reporting routes must be written down before an event occurs.

Information assets inside the ISMS scope

Start with the scope statement and the asset inventory it points to. Every system, dataset and service that falls inside the boundary needs a documented route into the incident process, including the owner who can make decisions about it. Systems that sit outside the boundary may still matter if they connect to in-scope data, so confirm how those connections are treated. Check that the inventory and the scope agree, because an auditor will sample one against the other.

Security and IT operations roles

The security team and IT operations usually hold the core roles. Security leads triage, coordinate and record decisions, while operations staff contain, isolate and restore systems. Name a primary and a deputy for each function, including out-of-hours cover. Confirm that operations staff know when to hand over to security, because the handover is where delays and lost evidence usually occur.

Legal, communications and management roles

Legal counsel decides how privilege, contractual notice and regulatory duties apply to an event. Communications prepares internal and external statements, and management holds the authority to approve containment choices that affect customers or revenue. Write down who can declare an incident, who can approve external messages, and who must be told within the first hours. Test these roles with a tabletop exercise so that the names and routes are known before they are needed.

HR and people involved in investigations

HR is needed when an incident involves an employee, a contractor or a disciplinary matter. The process should define when HR is informed, how employment records are handled, and how personnel who are subjects of an investigation are separated from the response team. Confirm that HR contacts are on the same list as the other roles, and that HR knows its part in preserving evidence.

Suppliers and cloud providers in reporting routes

Every supplier that hosts, processes or administers in-scope information must appear in the reporting routes. For cloud services, record the provider's security contact, the escalation path, and the channel the provider uses to notify customers. Check what the contract requires the provider to notify and within what period, because your own internal clock may depend on it. Review these entries whenever a supplier or service changes.

Contact lists and proportionate coverage

The contact list is the working record of the process, so keep it current and accessible when the usual systems are down. The depth of the process should match the scope and the Statement of Applicability: a narrow scope needs fewer roles and routes than a scope covering many sites, sectors or outsourced services. Confirm with your certification body how it expects the scope and contact records to be evidenced.

How an assessor tests incident management planning

This table sets out what an assessor does for each part of A.5.24, the evidence they ask to see and the findings that most often come up. Read each row as a question the assessor will put to your records, and use the common findings column to check your own plan before the audit starts.

Test area	What the assessor checks and requests	Common findings
Documented process and approval	Reviews the incident management process document, confirms it covers planning and preparation, and checks the version, approver and approval date.	Plan not approved or approved by someone without authority; process exists only as draft or informal practice.
Roles and responsibilities	Checks that each incident role (incident manager, technical lead, communications, legal, decision maker) is assigned to a named person or function, with deputies where roles depend on one person.	Roles unassigned, assigned to people who have left, or described in the plan but never agreed by those named.
Contact lists and reporting routes	Compares contact lists and reporting paths against current staff, suppliers and authorities, and asks when each entry was last verified.	Contacts out of date, missing out-of-hours routes, or reporting routes that differ from what the process describes.
Communication and awareness	Samples evidence that the process was communicated to people who have incident roles, such as acknowledgements, briefing records or announcements.	No evidence of communication or awareness; staff with incident roles cannot show they received the plan.
Training and exercises	Requests training records and exercise reports for incident roles, and checks whether lessons from exercises were recorded.	Training planned but not delivered; exercises run without records of attendance or outcomes.
Links to A.5.25 to A.5.27	Traces a sample event through the triage criteria in A.5.25, the response steps in A.5.26 and the lessons process in A.5.27 to confirm the planning matches the operating records.	Triage criteria in the plan do not match the criteria used in practice; no lessons-learned records feed back into the process.
Evidence of review	Checks that the process and contact lists were reviewed at planned intervals and after significant changes, with the review recorded.	No review record since the last organizational change, or reviews that repeat without updating content.

How to build the incident management plan step by step

This sequence turns A.5.24 from a policy statement into a working plan: defined categories, documented phases, named people, verified contacts, reporting routes, approval and trained responders. Each step ends with an artifact an assessor can sample.

Define incident categories and severity criteria
Start by agreeing which events count as information security incidents and how serious each type is. Set categories (for example, malware, unauthorized access, data disclosure, service disruption, supplier breach) and severity levels with written criteria tied to impact on confidentiality, integrity, availability and regulatory or contractual exposure. Security leadership, legal and the business owners of key services should sign off. The output is a categories and severity matrix that the triage step and A.5.25 decisions can apply consistently. You know it is done when two people reading the same scenario reach the same severity.
Document the process and its phases
Write the incident management procedure as a sequence of phases: preparation, detection and reporting, assessment, containment and response, recovery, communication and closure, and lessons learned. For each phase, state the trigger, the owner, the inputs, the actions and the record that proves the action happened. Keep the procedure short enough to use under pressure and link it to the detailed response steps under A.5.26 and the learning steps under A.5.27. The output is an approved process document with a version number and a stored location that responders can reach when the normal systems are unavailable.
Assign roles, responsibilities and deputies
Name the incident manager, technical leads, communications lead, legal and privacy contact, executive decision maker and the people who can authorize external notifications. For each role, write what it decides and what it must not decide alone. Assign a deputy for every role so that absence does not stop the process, and check that no single person can both declare an incident and sign off its closure without oversight. The output is a responsibilities table in the plan. You know it is done when each named person has confirmed the role in writing and the deputies have been briefed.
Build and verify the contact and escalation list
Compile the internal and external contact list: on-call rotations, business owners, key suppliers and their security contacts, cloud and hosting providers, forensic and legal support, insurers and any authority contacts the organization has established. Record the escalation path with the time-sensitive triggers that move an event up the chain. Store a copy outside the systems that an incident might take down, such as a printed or offline version. Then test the list by calling or messaging each contact. The output is a verified contact list with a date of last verification and a named owner who updates it. Auditors often sample this list against the people who actually answer.
Define internal and external reporting routes
Map how an event reaches the incident team (employee reporting channel, monitoring alerts, supplier notifications, customer complaints) and how the organization reports outward. List the external duties that apply to your organization, such as contractual notification clauses with customers, regulator and supervisory notification duties under sector or national rules, data protection breach notification where personal data is involved, and law enforcement contact. Confirm each duty with legal counsel and record the notifying role, the recipient and the information required. Cross-check against A.5.5 and A.6.8. The output is a reporting matrix with each route and duty, reviewed by legal and compliance.
Approve, communicate and store the plan
Obtain formal approval of the plan from the people accountable for information security and the business, and record the approval with date and version. Communicate the plan to everyone with a role in it, and make the relevant sections available to all personnel who can report events. Set the plan in a controlled repository with version history so changes and approvals can be shown to an assessor. The output is an approved, versioned plan and a distribution record showing who received it and acknowledged their role. You know it is done when each responder can state their first action without rereading the document.
Schedule training and exercises
Plan awareness for general staff on how to recognize and report events, role-specific training for responders, and exercises that walk the team through realistic scenarios such as ransomware on a production system or a compromised supplier account. After each exercise, record what worked, what failed and which actions were assigned, and feed those into the plan. Confirm with the business how often exercises will run and who attends. The output is a training and exercise schedule, attendance records, and exercise reports with follow-up actions tracked to closure. Assessors commonly ask for evidence that the plan has been tested, not only written.

How the plan connects to assessment, response and lessons learned

The incident management plan built under A.5.24 is the foundation that three later controls quietly depend on. A.5.25 asks the organization to assess reported events and decide which ones are incidents, and that decision only works if the triage criteria, categories and priority levels were defined in advance and the people who apply them know where to record their decisions. A.5.26 then asks for responses that follow documented procedures, so containment, escalation, communication and recovery have to exist as written steps with named owners before the first alert arrives. A.5.27 (learning from incidents) and A.5.28 (collection of evidence) rest on the same groundwork: a post-incident review needs a defined owner and a template, and evidence can only be preserved in a usable state if the planning layer told responders what to capture, how to hash it and who holds the chain of custody.

When the planning layer is weak, the failures surface at the next layer. Assessment becomes inconsistent, so two analysts close similar events differently and the decision records cannot be compared. Response stalls while people search for the on-call contact or the regulator's reporting route, which is exactly what a current contact list and reporting matrix prevent. Lessons learned never happen because nobody was assigned to run the review, and evidence is contested in a legal or disciplinary matter because nobody agreed on handling rules. Reviewers testing these links will typically ask for a sample of recent events and trace each one from triage record to response record to review and evidence. Confirm that your own sample can be traced end to end before the audit, not during it.

ISO/IEC 27035-1:2023 gives concepts and process guidance that cover this full sequence, from preparation through detection, reporting, assessment, response and lessons learned, and it is a useful reference for how the phases hand off to one another. Read it as a description of how the pieces connect, then confirm the specific criteria, roles and timelines against your own risk appetite and your contractual and regulatory notification duties. Those duties, not the standard alone, determine how fast a decision must be made and who must be told.

Evidence that passes an A.5.24 audit and how to keep it current

An auditor testing A.5.24 looks for planning documents that exist, name real people and routes, and show a history of review. The six artifacts below are the ones assessors most often sample, and each needs a trigger for review so it stays accurate between audit cycles.

Approved incident management process

The documented process covers how incidents are defined, classified, escalated, and closed, and it must be approved by someone with authority over the ISMS. Check that the approval date, the approver, and the scope match the current organization. Review it after any significant change to systems, suppliers, or reporting obligations, and after any incident where the process did not work as written.

Role descriptions and RACI

A RACI matrix shows who is responsible, accountable, consulted, and informed for each incident step, and each named role needs a written description. Auditors compare these names against the org chart and staff records. Refresh the matrix at every reorganization, leaver, or new system owner, and confirm that deputies exist for every critical role.

Contact and escalation register

The register lists internal responders, executives, legal, the regulator, key suppliers, and external incident response providers, with 24-hour routes for each. A stale phone number is a common finding, so record a last-verified date for every entry. Test a sample of contacts at each review and after staff or supplier changes.

Reporting route diagram

A diagram shows how a staff member, customer, or supplier reports a suspected event, where that report lands, and who triages it. It should match the reporting control A.6.8 and the ticketing or alert tools actually in use. Re-check the diagram whenever a channel is added or retired, and walk a sample report through the route to confirm it arrives.

Training and exercise records

Attendance records for awareness sessions and tabletop exercises show that responders know the plan and have practiced it. Keep the scenario, participants, observed gaps, and the corrective actions raised. Schedule exercises after material changes, and use the outcome of each exercise to decide whether the plan, the contacts, or the roles need an update.

Version history of the plan

An auditor expects to see how the plan changed over time, who changed it, and why. A wiki with page version control records each edit, lets reviewers compare any two versions, and allows rollback if an edit is wrong. For example, a team using XWiki can compare the approved version against the current draft before each review. Confirm the approval step is recorded, not just the edit.

What meeting A.5.24 costs in money and effort

An in-house build puts the cost mainly in staff time. The organization's own people define the incident management process, assign roles, build the contact lists and reporting routes, and agree the approvals. Most of this is one-time effort, but it draws on people who already have day jobs, so the real cost is the time they spend away from other work. Tooling is usually a smaller line item, especially where the team already runs a wiki, ticketing or case management system.

Role definition and approval: Security, IT, legal, communications and senior management each review the roles and the escalation path, and each review takes meeting time and rework.
Contact lists and reporting routes: Someone must find, verify and keep current the internal and external contacts, including the reporting route for regulators where the organization has one.
Exercise design and facilitation: Tabletop exercises need a scenario, a facilitator and a written record of what was learned. Staff must set this up themselves.
Tooling and licenses: Commercial licenses recur annually, while open-source tools carry hosting and maintenance effort instead of license fees.
Auditor sampling: Records of roles, training and exercises must be retained so an auditor can sample them later.

Ask the internal owner to estimate hours by role for each step and to state which costs recur each year. Confirm who will maintain the contact lists when staff change.

Where incident planning usually falls short and how to close each gap

Most incident plans exist on paper but fail when an event starts. The gaps below cluster around people, contacts, reporting duties, testing, the links to assessment and response, and where evidence ends up. Each card names the check an assessor is likely to make and the closing action that makes the control hold up under test.

Roles named but not accepted

The plan lists an incident manager, a technical lead and a communications owner, but the named people may never have agreed to the role or know what it requires at 2 a.m. For A.5.24, the assignment has to be defined, communicated and accepted. Check that each role holder has signed a role description, has a deputy, and can state their first three actions without looking at the document.

Contact lists with departed staff

Incident contact lists go stale when people leave, change teams or change phone numbers, and the list is often the first thing tested in a real event. Assign an owner to the list, review it on a fixed schedule and tie updates to joiner, mover and leaver steps. Confirm that every listed contact can be reached through a second channel that does not depend on corporate email or the affected network.

Reporting routes missing key recipients

A plan may cover internal escalation but omit the external parties the organization must notify, such as regulators, key customers, cloud providers and law enforcement contacts. Map each category of incident to its required recipients and the deadline that applies to each. Check the map against your contracts and applicable regulation, since the obligations come from those sources, not from the standard itself.

No exercise evidence

An auditor who asks when the plan was last exercised will expect a dated record, not an assurance that the team knows what to do. Run tabletop exercises on the scenarios most likely for your environment, record attendance, decisions and gaps, and track each gap to closure. Keep the exercise record in the same place as the plan so the two can be sampled together.

Plan not linked to A.5.25 to A.5.27

A.5.24 prepares the process, but the assessment of events (A.5.25), the response (A.5.26) and the lessons learned (A.5.27) must use it. If triage criteria, severity levels and post-incident review steps are written separately, responders improvise and the records do not show the planned process being followed. Cross-reference each step of the plan to the control that governs it, and sample a closed incident to confirm the path was followed.

Evidence scattered across tools

Alert data sits in the monitoring platform, decisions in chat, tasks in a tracker and approvals in email, so reconstructing who decided what takes days. Pick one system of record for each incident and define which tools feed it. Open-source case management such as DFIR-IRIS can hold the case timeline, assets, tasks and evidence in one audit trail, and a versioned wiki can hold the plan itself. Confirm that the tools you choose meet your own retention and access requirements.

Questions buyers ask about A.5.24 cost, effort and outsourcing

How much effort does a small team need to meet A.5.24?

The effort depends mostly on how many systems, suppliers and customer commitments the incident process has to cover, not on the control text itself. A small team usually needs to define one incident process, name the people who act in it, write a contact list and reporting route, and run at least one exercise. The work is front-loaded: drafting and agreeing the plan takes the most time, and the recurring load is keeping contacts current and running the exercises. Ask any provider to break the effort into drafting, review, tooling, training and exercises, and to state which parts your staff must attend.

Can our own team write the incident management plan without a consultant?

Yes. A.5.24 asks the organization to define, establish and communicate its incident management processes, roles and responsibilities, and the organization owns that content. A team with security, operations and legal input can write it, provided someone with authority approves it and the roles match real people. Outside help is most useful for reviewing gaps against ISO/IEC 27035-1:2023, checking that the plan links to A.5.25 through A.5.28, and building the tooling that records cases. Confirm with your certification body how it expects the plan to be evidenced before you choose the level of help.

What must an implementation partner not do for A.5.24?

A partner must not own the incident management process, approve its own work or act as the incident commander for your organization. It also cannot decide whether an event is an incident on your behalf, because those decisions sit with your staff under A.5.25. An implementation partner prepares the plan, contacts, tooling and evidence, and documents what it did. Only an independent auditor or certification body issues a report or certificate. If a provider offers to certify you or guarantees a result, treat that as a warning sign.

How often should the incident management plan be reviewed?

ISO/IEC 27001 expects the ISMS to be reviewed and improved, but it does not set a fixed review interval for the A.5.24 plan in the supplied facts, so confirm the cadence with your auditor and your own policy. Common triggers for an unscheduled review are a significant incident, a change in suppliers or cloud providers, a new regulatory reporting duty, and staff changes in named roles. Contacts deserve more frequent checks than the process itself because people move roles often. Record each review, its outcome and any changes in your document system so the history is visible.

Are tabletop exercises required to meet A.5.24?

The control requires preparation and communication, and training is part of that, but the supplied facts do not state that a specific exercise format is mandatory. In practice, auditors look for evidence that people know their roles and that the plan works when used. A tabletop exercise is a common way to show this, and it can feed the lessons-learned process in A.5.27. Confirm with your certification body what evidence it expects. Plan exercises against your own scenarios, such as a compromised supplier account, and keep the attendance records, injects and follow-up actions.

How does A.5.24 relate to other frameworks and incident requirements?

A.5.24 is the planning control that other incident controls depend on. In ISO/IEC 27001:2022 it sits beside A.5.25 (assessment and decision), A.5.26 (response), A.5.27 (learning), A.5.28 (evidence collection) and A.6.8 (event reporting). NIST's crosswalk from SP 800-53 Rev. 5 relates A.5.24 to IR-8 Incident Response Plan, which is a useful starting point if you also map to NIST. For regulated sectors, incident reporting duties under frameworks such as DORA or NIS2 are separate obligations, so confirm with counsel which reporting timelines apply and make sure your contact list covers those authorities.

What should we ask for in a fixed-scope quote for A.5.24 work?

Ask for a written scope that names each deliverable, such as the incident process document, role descriptions, contact and reporting routes, training materials, tooling configuration and an exercise plan. Ask which items your staff must review or approve, and how many review rounds are included. The quote should state what is one-time (drafting, setup, first exercise) and what recurs (contact upkeep, retainer support, repeat exercises). It should also list assumptions about your systems and the dates when inputs are due from your side. Ask for the exclusions in writing, including anything the certification body charges separately.

Official sources for A.5.24

Start with the primary texts before you plan any incident process. The control itself is defined in ISO/IEC 27001:2022, which you can review on the ISO/IEC 27001:2022 standard page. Read the Annex A entry for A.5.24 alongside the clause 4 to 10 requirements, because the auditor will test whether the incident process you define is tied to your documented scope, risk assessment and improvement cycle. Buy the standard from ISO and keep the version your team uses on file, since the assessor will ask which edition your ISMS was built against.

For the practical detail behind the control, read ISO/IEC 27035-1:2023 on the ISO/IEC 27035-1:2023 standard page. It sets out the concepts and process for preparing for, detecting, reporting, assessing and responding to incidents, and it is the most direct reference for the planning work covered on this page. Confirm the edition and the availability of any companion parts with ISO before you cite them in your procedures, because later parts may have been published or revised since this page was written.

The implementation guidance for A.5.24 sits in ISO/IEC 27002:2022, which you can find on the ISO/IEC 27002:2022 standard page. Note that ISO states 27002 cannot itself be certified to, so use it as guidance for designing your process rather than as a set of requirements an assessor will check line by line. Before the certification audit, confirm with your certification body which edition and guidance documents it expects you to reference.

How DeployOpen scopes and prepares A.5.24 evidence

DeployOpen plans, builds and documents the incident management planning and preparation arrangements behind A.5.24 inside the client's own infrastructure, using self-hosted open-source platforms. The organization keeps ownership of its processes, roles and decisions, while DeployOpen prepares the systems and written evidence that an independent auditor or certification body will sample.

How we scope

Engagements are fixed-scope, with the A.5.24 boundary, systems and deliverables agreed in writing before work starts.
We confirm which business units, sites and cloud accounts the incident management process must cover.
Scope records who owns each role, contact list and reporting route, and which of those the client will maintain itself.

How we build

We set up a self-hosted case management platform so each incident has one record with tasks, assets and evidence.
We configure a wiki with version history so the incident process, contact lists and roles stay current and attributable.
We test the reporting routes and escalation contacts with the client and record the results as preparation evidence.

How we hand over

Handover includes written process documentation, role descriptions, contact lists and training records for the incident team.
We provide an evidence index mapping each artifact to A.5.24 and to the related A.5.25 to A.5.28 controls it supports.
The client receives configuration documentation and access to the platforms, so its own staff can run and update them.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
Retainers can cover periodic review of contact lists, role changes and tabletop exercise records for the planning controls.
Before any assessment, we confirm with the client which evidence the independent auditor has requested and what is still missing.