Information security incident management planning and preparation

What the control asks

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.

Purpose in the standard’s terms, in our words: Makes incident handling fast, effective, consistent and orderly, including how events are communicated.

Attribute values in one line: Corrective; Confidentiality, Integrity, Availability; Respond, Recover; Governance, Information security event management; Defence.

The five attribute values

These are the published values for this control, from ISO/IEC 27002:2022 clause 4.2 and Annex A Table A.1. Where your own value differs, record the difference and the reason in the same row rather than replacing the published value.

Evidence an auditor asks for

The attribute is a claim about how the control behaves. The evidence is what proves it operates. Keep both, and keep them together.

• An approved incident management plan and procedures covering evaluation, detection, classification, escalation, recovery, communication, evidence handling and post-incident review
• Incident management objectives and priorities agreed with management, including resolution time frames by severity
• A roles and responsibilities document for the incident team and its communication to internal and external parties
• Training, certification and exercise records for incident responders
• Incident reporting forms, the point of contact details and records of feedback given to reporters
• A register of external notification obligations and deadlines, such as regulator breach notification

Where audits commonly find gaps

• The plan exists but has never been exercised against realistic scenarios
• Regulatory notification deadlines are not built into the procedures
• People reporting events never hear the outcome, discouraging future reporting
• Responders lack training or the procedures they are expected to follow

What ISO/IEC 27028 changes for this control

It carries a single control type, corrective, which sets what the evidence has to prove. It contributes no detect function, so a control set built from this row alone would not show detection. It crosses 2 operational capabilities, so two teams share the work and the owner column matters. Its earlier numbering (16.1.1) is kept in the register so an older audit file can still be traced.

The guidance expands how the five values are used; it does not change the control or add a requirement. A register that carries the values and the evidence can answer the attribute question for this control without a new document. A register that does not can add the columns at the next SoA version, with an owner and a review date.

Controls that share its values

• 5.26 Response to information security incidents
• 5.5 Contact with authorities
• 5.6 Contact with special interest groups

Read the five attributes All 93 controls