ISO/IEC 27001:2022 · derived mapping target
A.5.26Response to information security incidents
Respond to confirmed incidents according to your documented procedures, containing the damage and restoring normal operations. A practiced response limits impact and recovery time.
Mapping at a glance
A.5.26Response to information security incidentsISO/IEC 27001:2022
A.5.26 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-0011Risk treatment · ProcessrelatedTracking agreed risk actions to completion is a general governance discipline that also applies to the corrective actions a response generates, though its main scope is risk treatment, not incident response.RCF-0035Issues management · ProcesssupportsAssigning owners and due dates to logged issues is the mechanism that keeps incident-driven corrective actions from stalling once the response is over.RCF-0260IR plan · ProcessequivalentFollowing the response plan and documenting decisions and timings as an incident unfolds is exactly the response activity this control requires.RCF-0261IR plan · TechnicalsupportsDetection tooling that supports rapid containment on endpoints and accounts gives responders the technical means to act during an incident, not only a plan.RCF-0263Roles & communications · ProcesssupportsTeam members activating their assigned roles when an incident occurs is the operational proof that the response, not only the planning, works.RCF-0264Roles & communications · TechnicalsupportsAn out-of-band channel and direct alerting give the response team a way to coordinate even when the systems under attack are the ones normally used to communicate.RCF-0266Playbooks · ProcesssupportsFollowing the playbooks during real incidents is one operational piece of this control's response behavior, which also spans containment, escalation and notification beyond playbook execution alone.RCF-0267Playbooks · TechnicalenablesEmbedding playbook steps into ticketing templates, EDR response actions or chat-based runbooks is what lets a response execute the documented procedure under pressure.RCF-0272Notification & escalation · ProcesssupportsSending incident notifications to regulators, clients and leadership within required timeframes and logging each one supports the response this control requires, though notification alone does not contain damage or restore operations.RCF-0273Notification & escalation · TechnicalenablesOn-call alerting and SLA timers give the response team an automated way to meet notification deadlines instead of relying on someone remembering to make a call.RCF-0278Post-incident review (lessons learned) · ProcesssupportsTurning post-incident findings into tracked corrective actions closes the loop that a response is not complete until the same incident cannot recur.RCF-0287Crisis management · ProcesssupportsActivating crisis procedures and following the defined escalation path during major incidents is the response this control expects when an incident becomes a business-wide crisis.RCF-0427IR for ICS · PolicysupportsWritten procedures for who may touch operating machinery during an incident set the boundaries a production-system response must respect.RCF-0428IR for ICS · ProcesssupportsFollowing the OT-specific response procedures whenever an incident touches production systems contributes directly to this control's response requirement, but on its own only covers operational technology, not the organization-wide response this control asks for.RCF-0429IR for ICS · TechnicalsupportsTooling that can observe and contain incidents on the production network without disrupting operations gives responders a way to act on OT incidents safely.
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
Responding well depends less on the plan itself than on whether the team can reach each other when primary systems are compromised. A common gap is a response plan that assumes email and the normal chat tool still work, with no fallback when the attacker is inside those systems. Playbooks embedded into ticketing templates or EDR response actions turn a written procedure into something a junior analyst can follow at two in the morning. Notifications to clients, insurers and the data protection authority need a record of when each went out, since a phone call nobody logged is not evidence during a later audit.
Common gaps
The incident response plan assumes the team can still use email and Slack, with no documented backup channel if those systems are the ones compromised.
Notification records are informal phone calls with no log of who was told and when, making it impossible to prove regulatory deadlines were met.
Playbook steps live in a document nobody opens during an active incident, so responders improvise instead of following the documented procedure.
Questions your auditor will ask
How does the team coordinate if primary communication systems are down?
An out-of-band channel, such as a separate messaging app or phone tree, is documented in the plan and tested during exercises.
Can you prove notification deadlines to regulators and clients were met?
Notification records log the time, recipient and content of each communication, checked against the plan's stated timeframes.
Are playbook steps built into the tools responders use during an incident?
Ticketing templates and EDR response actions embed the playbook steps directly, so responders follow a guided process rather than a static document.
What happens to open corrective actions after an incident closes?
Post-incident findings become tracked corrective actions with owners and dates, verified closed before the incident is considered fully resolved.
Where regulation demands it
NIS2 3.5 requires an incident response capability that contains and resolves confirmed incidents, not only a written plan.
ENS org.3 requires documented security procedures, which cover the response steps a team follows once an incident is confirmed.
Related controls
Via the shared Sekit CSF topic, not the framework's own index.
Ask Sekura: “What evidence proves A.5.26?”
Also via MCP, free with account