Assessment and decision on information security events

Plain-language summary

Looking at each reported security event, deciding whether it is an incident, and giving it a category and priority against agreed criteria, so that a phishing email someone deleted and a confirmed data leak are not handled the same way.

What the clause is really asking

Not every alert or report is an incident, and treating everything as one burns out the team while treating nothing as one lets real breaches run. This control asks you to assess information security events and decide whether they should be categorised as incidents, using an agreed scheme. That means defining what counts as an event and what makes it an incident; a classification and prioritisation scheme based on impact (on confidentiality, integrity, availability, personal information and operations) and extent; who makes the call, and how quickly; and recording the assessment and decision so it can be reviewed later. The common misunderstanding is that assessment is informal judgement by whoever picks up the ticket; auditors expect consistent criteria applied by competent people. In South Africa the assessment should always include one question: are there reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person? If yes, POPIA section 22 notification is in play, and the duty runs from discovery, not from the end of the investigation.

What auditors look for

Auditors ask for the classification scheme and then sample the event and incident log. For each entry they check there is a recorded assessment: who made the decision, when, which category and priority, and why. They look for events closed as non-incidents and ask whether that was right, especially anything involving personal information or a lost device. They compare the time from report to assessment against your own target. They interview the person who triages and ask them to classify a scenario on the spot. The hard question: show me an event you decided was not an incident, and the reasoning that supports that decision.

Typical evidence

Event and incident definitions; classification and prioritisation scheme with criteria and examples; triage checklist or flowchart; event log or ticket records showing assessment, category, priority, decision-maker and time; POPIA section 22 assessment records for events involving personal information; escalation records; periodic reviews of classification decisions and resulting changes to criteria.

How to comply — recommendations

Write a one-page classification table: three or four priority levels, each defined by impact on operations, data and personal information, with a response time and who must be told. Add a short triage checklist that asks, among other things, whether personal information is involved, so POPIA section 22 is considered every time. Name who may declare an incident and who may downgrade one. Log every reported event, including the ones that turn out to be nothing, with the decision and the reason. Review a sample of closed events each quarter to check that decisions were consistent, and refine the criteria from what you find.

Common nonconformities

No defined criteria for when an event becomes an incident; events closed without a recorded assessment or reason; priority assigned inconsistently for similar events; personal information involvement not considered, so POPIA section 22 obligations missed; triage decisions made by untrained staff; no record of events judged not to be incidents; assessment times far beyond the organisation's own targets.

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.