Information security event reporting

Plain-language summary

Giving everyone a simple, known route to report anything that looks wrong — a suspicious email, a lost laptop, a door left open, a weakness they spotted — quickly and without fear, so the organisation hears about problems while they are still small.

What the clause is really asking

Most incidents are first noticed by an ordinary person, not a tool, and this control asks you to make sure that person reports it, promptly and through the right channel. You need a reporting route that everyone knows and that is easy to use, covering events (something has happened) and weaknesses (something could happen). People should be told what to report — phishing, malware, lost or stolen equipment, unauthorised access, mistakes, policy breaches, odd system behaviour — and told not to test a suspected weakness themselves. The misunderstanding is that a procedure in the ISMS manual is enough; what matters is the habit, and the habit depends on a no-blame culture where people who report their own mistakes are thanked, not punished. The best single measure is the phishing report rate: what share of staff report a simulated or real phish, and how quickly the first report arrives. In South Africa, POPIA section 22 requires you to notify the Information Regulator and affected people as soon as reasonably possible after a compromise, and that clock depends on someone reporting.

What auditors look for

Auditors ask how a staff member reports a security event, then put the same question to several people in interviews and compare the answers with the procedure. They test the channel: a report-phish button, a service desk category, a number for after hours. They pull the event log and look at volume, sources (people versus tools), the time between occurrence and report, and whether each report was triaged. They look for reports from the shop floor and contractors, not only IT. They check simulation data for report rates. The hard question: the last time someone reported their own mistake, what happened to them?

Typical evidence

Event reporting procedure and its communication to staff; reporting channels (report-phish button, service desk category, after-hours number); event and weakness log with dates of occurrence, report and triage; phishing simulation report rates and time to first report; awareness material on what to report; records of feedback given to reporters; no-blame statement endorsed by top management.

How to comply — recommendations

Set up one easy route and advertise it everywhere: a report-phish button in the mail client, a security category on the service desk, and a phone number for after hours and the shop floor. Write a half-page guide on what to report, with examples. Have top management say, in writing and in person, that reports are welcome and that mistakes reported promptly in good faith are not punished. Acknowledge every report and tell the reporter what happened. Track phishing report rate, time to first report and reports by department every month, and take them to management review. Recognise good reporters publicly.

Common nonconformities

Staff unable to say how to report an incident; no channel for after hours, the shop floor or contract staff; reports go to one person's mailbox with no cover; weaknesses not reportable, or staff test them themselves; no record of reports or triage; reporters never get feedback; phishing report rate never measured; staff afraid to report their own mistakes.

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.