Response to information security incidents

Plain-language summary

Responding to incidents according to documented procedures — containing the damage, preserving evidence, escalating, communicating with the right people inside and outside, recovering, and closing each incident formally — so the response is controlled rather than improvised.

What the clause is really asking

Planning (5.24) and triage (5.25) are wasted if the response itself is improvised. This control asks that incidents are responded to in line with documented procedures, by competent people. The response normally covers containment of the systems and accounts involved; collection of evidence as early as possible; escalation and, where needed, activation of crisis management or business continuity; coordination with suppliers, insurers and authorities; communication to the people who need to know, at the right time; eradication and recovery; and formal closure with a record of what was done. The common misunderstanding is that the incident is over once systems work again. Closure needs a recorded cause, the notification decisions and the follow-up actions. In South Africa, if personal information was compromised, the POPIA section 22 notification to the Information Regulator and to data subjects is part of the response; it must be in writing and give data subjects enough information to protect themselves. If you are an operator, section 21 requires you to tell the responsible party immediately. Cybercrimes Act section 54 reporting is not yet in force.

What auditors look for

Auditors pick two or three incidents from the register, ideally including one involving personal information, and trace each end to end: the report, the assessment, containment actions with times, evidence collected, who was told and when, recovery and closure. They compare what happened with the procedure and ask about any differences. For personal information incidents they ask for the section 22 decision and, where notification was made, the notices to the Regulator and data subjects. They check that suppliers involved were brought in. The hard question: from detection to containment, how long did it take, and was that good enough?

Typical evidence

Incident register; incident records with timeline, containment, eradication and recovery actions; evidence logs; escalation and crisis management records; communication records with staff, customers, suppliers and insurers; POPIA section 22 notification decisions and copies of notices to the Information Regulator and data subjects; operator notifications sent or received; closure reports with cause and follow-up actions.

How to comply — recommendations

Build short playbooks for your four or five most likely incidents — phishing and account compromise, ransomware, lost or stolen device, misdirected email containing personal information, supplier breach — each a page of first actions, who to call and what to preserve. Keep an incident record template with a running timeline, and fill it in as you go, not afterwards. Decide the section 22 question on every incident involving personal information and record the decision even when you do not notify. Agree with your IT provider and cyber insurer, before you need them, how each will be engaged. Close every incident with a short report: cause, impact, actions taken, notifications made and follow-up actions.

Common nonconformities

Response not following the documented procedure, with no explanation; incident records without timelines or containment actions; evidence lost through reimaging before collection; POPIA section 22 notification not considered or delayed without reason; affected customers or suppliers not informed; incidents closed without cause or follow-up actions; operator breach not reported to the responsible party.

Resources for this clause

• ArticlePOPIA section 19 and ISO 27001: how the standard evidences the law — and why a certificate is not compliance
• ArticleISO/IEC 27001:2022 Annex A explained: the 93 controls in plain English, theme by theme, with the 114-to-93 map and the attribute tags
• ArticleThe Statement of Applicability, explained — what ISO/IEC 27001 clause 6.1.3 requires, the four ways an SoA fails Stage 1, and how to build one from the risk register
• ArticleISO/IEC 27001:2022 explained for people who already run ISO 9001: what is the same, what is new, and how to get certified
• Toolkit · $29Incident & Breach Response KitWhen something happens the questions arrive faster than the facts: is it an incident, how bad, is it a POPIA breach, who must be told and by when, what do we write, what do we keep. This kit answers them in order.
• Toolkit · $39Risk & SoA ToolkitScore your information security risks on a documented method, pick the Annex A controls that treat them, and the Statement of Applicability writes its own first draft — every justification citing the risks behind it.
• Toolkit · $29ISMS Metrics & Evidence TrackerThe three things an ISMS has to show after certification, in one workbook: measures with a live Green / Amber / Red status, management review minutes that cover every required input, and an evidence register that gives every control an owner, a rhythm and a due date.
• Free downloadAnnex A 93 Controls Quick ReferenceOne A3 page: all 93 Annex A controls in their four themes, the eleven new in 2022 flagged, and the ISO/IEC 27002:2022 attribute legend — the poster for the wall beside the Statement of Applicability.
• Free downloadISO 27001 Gap Analysis ChecklistWhere you stand against ISO/IEC 27001:2022 in one afternoon — the 30 management-system requirements and all 93 Annex A controls, scored, with owners, dates and a readiness figure that calculates itself.
• Free masterclass · ~27 minISO 27001 MasterclassYou already know four fifths of ISO 27001. Here is the other fifth — the risk method, the SoA, the 93 controls, the evidence rhythm, POPIA, and a 44-week path.
• Free appAudit ManagerPlan the programme, anchor each finding to its clause and drive the NC to closure.