Information security incident management planning and preparation

Plain-language summary

Getting ready for incidents before they happen: a documented incident management process, defined roles and contacts, a way for anyone to report, competent people to respond, and the regulatory notification steps already worked out — so the first hour is spent responding, not organising.

What the clause is really asking

Every organisation will have incidents; this control is about whether you meet them prepared. It asks you to plan and prepare for incident management by defining, establishing and communicating the processes, roles and responsibilities involved. The usual output is an incident management procedure covering how events are reported and to whom; how they are assessed and classified; who leads the response and who has authority to take systems offline; contact lists for staff, suppliers, insurers, advisers and authorities; communication rules; evidence handling; and training and exercises so the plan is known. The common misunderstanding is that the IT helpdesk ticket process is the incident plan. It handles faults, not a ransomware attack at 2am. In South Africa, POPIA section 22 requires notification of security compromises to the Information Regulator and affected data subjects as soon as reasonably possible, so the decision route and template should be ready. Section 54 of the Cybercrimes Act (72-hour reporting to SAPS for communications providers and financial institutions) is still not in force as at October 2026; plan for it anyway.

What auditors look for

Auditors ask for the incident management procedure and the roles in it, then interview two or three people: someone on the response team, a line manager and an ordinary user. They ask the user how they would report a suspicious email or a lost laptop. They check that contact lists are current — some will ring a number. They ask for records of training or tabletop exercises and what changed afterwards. They look for the POPIA section 22 decision route: who decides whether a compromise must be notified, and who drafts the notice. The hard question: if ransomware hit tonight, who decides to disconnect the network, and is that written down?

Typical evidence

Incident management policy and procedure; incident response roles and authority matrix; current contact lists (internal, suppliers, insurer, legal advisers, Information Regulator, SAPS); event reporting channel and user guidance; incident classification scheme; POPIA section 22 notification procedure and templates; training records for the response team; tabletop or simulation exercise reports with actions; incident register.

How to comply — recommendations

Write an incident response procedure of five to eight pages: definitions, reporting route, classification, roles, escalation, communication, evidence handling and closure. Name an incident lead and a deputy, and give the lead written authority to isolate systems. Build a contact sheet with supplier, insurer, legal and regulator details, keep a printed copy offline, and check it every quarter. Publish one reporting route for staff (a mailbox or phone number) and repeat it in awareness training. Prepare the POPIA section 22 notification template and decide in advance who signs it. Run a tabletop exercise once a year on a realistic scenario and record the lessons.

Common nonconformities

No documented incident management procedure; roles and authority to act undefined; contact lists out of date or held only on systems that would be unavailable; staff unaware of how to report events; no plan for POPIA section 22 notification; response team never trained or exercised; incident plan not reviewed for years; helpdesk fault process presented as the incident plan.

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.