Response to information security incidents

What the control asks

Incidents are to be handled following the documented response procedures. Purpose: respond to information security incidents efficiently and effectively. Guidance: set and communicate response procedures to relevant parties, and have a designated, competent team respond (5.24). Response includes: containing affected systems where consequences could spread; collecting evidence as early as possible (5.28); escalating as needed, including crisis management and possibly business continuity plans (5.29, 5.30); logging all response activity for later analysis; informing relevant internal and external parties of the incident or relevant details on a need-to-know basis; working with authorities, specialist groups, suppliers and clients to respond better and limit harm to others; formally closing and recording the incident once resolved; carrying out forensic analysis where required (5.28); analysing afterwards to find the root cause and documenting and communicating it as defined (5.27); and identifying and managing vulnerabilities and weaknesses, including control weaknesses that caused, contributed to or failed to stop the incident. More on incident handling is in ISO/IEC 27035.

Purpose in the standard’s terms, in our words: Ensures incidents are responded to efficiently and effectively.

Attribute values in one line: Corrective; Confidentiality, Integrity, Availability; Respond, Recover; 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.

• Documented incident response procedures or playbooks communicated to relevant parties
• Incident records showing containment, evidence collection, escalation, communication and formal closure
• Response activity logs or ticket histories kept for later analysis
• Communication records to internal and external parties following need-to-know
• Root cause analysis reports and the resulting vulnerability or control weakness remediation actions
• Records of coordination with authorities, suppliers or clients during significant incidents

Where audits commonly find gaps

• Containment is delayed while approval is sought, letting the incident spread
• Incidents are closed without root cause analysis
• Response actions are not logged, so later analysis and evidence are weak
• Control weaknesses revealed by the incident are never tracked to remediation

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. Its earlier numbering (16.1.5) 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.24 Information security incident management planning and preparation
• 5.28 Collection of evidence
• 5.37 Documented operating procedures

Read the five attributes All 93 controls