The organization is to prepare for handling information security incidents by defining, setting up and communicating how incidents are managed and who does what. Purpose: respond to incidents fast, well, in a consistent and orderly way, including how security events are communicated. Guidance on roles: establish the processes and make roles and responsibilities known to relevant internal and external parties, considering a common way to report events with a point of contact (6.8); an incident management process that covers running and documenting incidents, detecting, triaging, prioritizing and analysing them, and communicating and coordinating with interested parties; an incident response process to assess incidents, act on them and learn from them; letting only competent people handle incidents, with documented procedures and regular training; and a process to identify training, certification and ongoing development for responders. Procedures: management agrees incident management objectives, and those responsible understand priorities including resolution times by consequence and severity. Management ensures an incident management plan covering varied scenarios, with procedures for evaluating events against incident criteria; monitoring, detecting, classifying, analysing and reporting events and incidents by people or tools (8.15, 8.16, 5.25, 6.8); managing incidents to closure with response and escalation (5.26) by incident type, possible crisis management and continuity activation, controlled recovery and communication; coordination with authorities, interest groups, suppliers and clients (5.5, 5.6); logging of incident handling; evidence handling (5.28); root cause or post-mortem analysis; and capturing lessons and needed improvements. Reporting procedures cover what to do when an event occurs (note details such as malfunctions and on-screen messages at once, report immediately to the contact point, act only in a coordinated way), incident forms, feedback to reporters on outcomes where possible, and incident reports; external reporting deadlines such as regulatory breach notification must be built in. Other information: incidents can cross organizational and national borders, so coordinating and sharing with outside organizations helps; detailed guidance is in ISO/IEC 27035.
This control maps to 188 controls across 47 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
ISO 27002:2022 5.24 is one control. If you already hold one of the frameworks below, a reviewed crosswalk already says how much of ISO 27002:2022 your existing evidence covers. Hold NIST SP 800-53 Rev 5 and 79 of 93 ISO 27002:2022 controls already carry evidence.
Each report names every control your existing framework evidences, every one it does not, the reasoning behind each claim, and the claims that were argued against and rejected. 180 were rejected on the NIST SP 800-53 Rev 5 pair alone.
The graph holds this control, the 188 it maps to, and the evidence behind each claim, over MCP and REST.