ISO/IEC 27001:2022 · derived mapping target
A.5.24Information security incident management planning and preparation
Plan and prepare for security incidents before they happen by defining processes, roles and responsibilities. Being ready turns chaos into a controlled response.
Mapping at a glance
A.5.24Information security incident management planning and preparationISO/IEC 27001:2022
A.5.24 is covered by 15 Sekit CSF controls. +10 more in the table below. Open in the full graph →
Mapped from the Sekit CSF
The Sekit controls that cover this requirement, lens by lens.
RCF-0034Issues management · PolicysupportsA written rule that every security issue is logged in one place gives the incident plan a feeder system, so findings from audits or scans surface before they turn into incidents.RCF-0259IR plan · PolicyequivalentThe formal written incident response plan is the same deliverable ISO asks for here: a documented process defining detection, handling and reporting before an incident occurs.RCF-0260IR plan · ProcesssupportsFollowing the response plan and logging decisions as incidents unfold turns the written plan into a practice auditors can verify was used.RCF-0262Roles & communications · PolicysupportsDocumenting who decides, who deputises and who contacts external parties gives the incident plan the named roles this control requires as part of preparation.RCF-0263Roles & communications · ProcesssupportsConfirming that incident roles activate when needed, not only existing on paper, is the operational proof that the planning in this control works.RCF-0265Playbooks · PolicysupportsShort, approved playbooks for scenarios like ransomware or phishing account takeover are the concrete preparation artifact this control asks companies to have ready.RCF-0266Playbooks · ProcesssupportsUpdating playbooks with lessons learned after each activation keeps the preparation work in this control current instead of a one-time document.RCF-0268Forensics readiness · PolicyrelatedA written approach to preserving evidence touches the same incident lifecycle but serves evidence collection rather than the detection and response planning this control covers.RCF-0271Notification & escalation · PolicysupportsDefining in writing who must be notified and within what deadlines is part of the preparation this control requires, covering regulators, clients and leadership.RCF-0274Tabletop exercises · PolicysupportsA written commitment to run simulated incident exercises at a set frequency is how a company proves its plan was built to be tested, not filed away.RCF-0275Tabletop exercises · ProcesssupportsRunning the scheduled exercises and feeding findings back into the plan is the evidence that preparation is maintained rather than static.RCF-0276Tabletop exercises · TechnicalenablesTooling such as phishing simulation platforms or an isolated test environment makes the tabletop exercises this control expects realistic instead of a discussion only.RCF-0277Post-incident review (lessons learned) · PolicyrelatedA documented post-incident review requirement belongs mainly to learning from incidents, but it also defines the criteria for reviews this preparation control assumes exist.RCF-0427IR for ICS · PolicysupportsExtending the incident plan with production-specific procedures, covering who may touch operating machinery and when to isolate, is preparation for the OT-heavy incidents this control anticipates.RCF-0428IR for ICS · ProcesssupportsPracticing the OT-specific response procedures so production, maintenance and IT each know their part is the tested readiness this control requires for operational technology incidents.
NIST CSF 2.0 counterparts
Reached through the Sekit CSF controls both map to — a mapping, not a formal equivalence.
ISO/IEC 42001:2023 — Annex A counterparts
Evidence that proves this control
What an auditor, or Sekit's evidence engine, asks for.
Incident response plan
The plan defining how the company acts when a security incident occurs: who does what, who is notified, and within what timeframes.
Incident playbooks, exercises and forensics readiness
The step-by-step guides for the most likely incidents, the tabletop exercises, the post-incident review reports, and how evidence is preserved so an incident can be investigated.
From the Sekit evidence catalog
In practice
Most companies write an incident response plan once, during onboarding or a client questionnaire, and then never touch it again. Auditors check whether the plan names real people, not only titles, and whether contact details still work. The plan should assign who decides to activate it, who talks to clients and regulators, and who handles technical containment. Playbooks for scenarios like ransomware or a phishing account takeover turn a first hour of panic into a checklist. Tabletop exercises are where gaps surface: a plan that reads well on paper often falls apart when someone tries to reach the named deputy, only to learn that person left the company and the plan was never updated to name a replacement.
Common gaps
The incident response plan lists contact details for people who no longer work at the company, and nobody has tested reaching the named backups.
Playbooks exist for generic categories like malware but not for the scenarios most likely to hit the business, such as vendor account takeover.
No tabletop exercise has run in over a year, so the plan has never been tested against a realistic scenario.
Questions your auditor will ask
Who has the authority to declare a security incident?
The incident response plan names a decision-maker and deputy, with title and contact method, not only a role description.
How does the team communicate if email and chat are compromised?
The plan defines an out-of-band channel, such as a phone tree or a separate messaging app, so responders can coordinate even if primary systems are down.
When was the incident response plan last tested?
Point to the most recent tabletop exercise report, including the scenario used and the gaps it found in the plan.
Are there playbooks for the incidents most likely to affect this business?
Playbooks cover the scenarios named in the plan, such as ransomware, phishing account takeover and accidental data exposure, each with concrete first steps for responders to follow.
Where regulation demands it
NIS2 3.1 requires a documented incident handling policy before an incident occurs, covering detection, response and reporting.
ENS org.3 requires formal security procedures, which is exactly what a written incident response plan provides for handling security events.
Related controls
Via the shared Sekit CSF topic, not the framework's own index.
Ask Sekura: “What evidence proves A.5.24?”
Also via MCP, free with account