Control Definition
Every information security event must be assessed against the organization's agreed criteria and a decision recorded on whether it qualifies as an information security incident — so the events-to-incidents call is made consistently, by designated people, using a scheme defined in advance rather than improvised under pressure.
Control Objective
To triage security events consistently and quickly, so genuine incidents are recognized, classified, and escalated while noise is filtered out — with both outcomes documented.
What This Really Means
This is emergency-room triage for your security program. Everything that walks in — a monitoring alert, a user-reported phishing email, a supplier notification, a lost laptop — gets assessed by the same criteria, by someone authorized to decide; a few cases go straight to the resuscitation bay, most go home with a note in the file, and every single one gets the note. The control rests on a distinction the whole incident cluster depends on: an event is an observation, something happened that might matter; an incident is a determination, an assessed event judged to compromise — or be likely to compromise — the confidentiality, integrity, or availability of information. Events are plentiful and mostly benign; incidents are rare and expensive. A.5.25 is the gate between them.
What the control asks for in practice is small but disciplined. Criteria written in advance — inside the A.5.24 incident plan — that say what promotes an event to an incident, with worked examples on both sides of the line. A severity classification scheme (most teams run SEV1–SEV4 or P1–P4) with concrete thresholds: what data classification is touched, how many systems, is it spreading, is there regulatory or customer exposure. A named triage role with deputies — typically the on-call security analyst or incident manager — holding explicit authority to declare an incident, assign severity, or close an event as benign, plus a written when-in-doubt-escalate rule. And a single intake: events from monitoring (A.8.16), user reports (A.6.8), the help desk, and suppliers all land in one queue with a decision SLA, not in five inboxes with none.
The discipline that separates mature programs from improvised ones is logging the negative calls. Most events are not incidents — the reported phishing email that the gateway already blocked and nobody clicked; a failed-login burst that traces to an expired password in a script; an unattended-screen report where the machine turns out to have locked itself. Closing these silently feels efficient and destroys the control: the decision log, including "assessed, not an incident, because…", is simultaneously your audit evidence, your tuning data, and your legal defense if a dismissed event later turns out to have been the breach's first signal.
Auditors test exactly that. They will sample recent alerts and user reports and trace each to a logged decision — criteria applied, decider named, timestamps from receipt to verdict — and the killer question is "show me something you decided was not an incident, and why." A program that can only produce its declared incidents has no evidence that assessment happens at all; zero recorded events and zero recorded incidents over a year reads as a process that does not operate, not as a year of safety.
Why It Matters
Triage fails in two directions, and both are expensive. Under-triage is the breach-maker: post-incident reviews of major intrusions routinely find that the first alert fired weeks or months before containment and was dismissed by someone using gut feel instead of criteria — the dwell time that turns a contained intrusion into a headline is usually purchased at the triage desk. Over-triage is the slow-motion version: declare everything an incident and you exhaust your responders, inflate severity until it means nothing, and teach the business to ignore declarations — so the real SEV1, when it comes, gets a shrug.
The decision is also where regulatory clocks start. Breach notification windows — hours in some regimes — run from when the organization recognizes an incident, which makes the speed and quality of the event-to-incident call a compliance control, not just an operational one. A triage queue nobody owns quietly converts a six-hour reporting duty into a violation before response has even begun.
Where event assessment is improvised, organizations face:
- •Real incidents dismissed as noise – the intrusion's first alert is closed on instinct, and the attacker gets weeks of dwell time that criteria would have denied them
- •Regulatory clocks burned in the queue – the notification window is consumed before anyone with authority has even looked at the event
- •Alert fatigue and severity inflation – everything declared urgent means nothing is, and responder capacity drains into noise
- •Inconsistent, indefensible decisions – the same event gets opposite outcomes on different shifts, and no rationale exists when a regulator or customer asks why you did not act
- •Unprovable diligence – with no record of negative decisions, you cannot demonstrate events were ever assessed — to an auditor or to a court
Regional Compliance Context
India compresses this control's timeline hard: CERT-In's 6-hour reporting window for specified incident categories runs from noticing the incident, so triage criteria should explicitly map to the CERT-In reportable categories — making "is this reportable?" a lookup performed during assessment, not a research project after it. The DPDP Act 2023 adds a personal-data lens: breach duties to data principals and the Data Protection Board attach to personal data breaches broadly, so the triage checklist needs a "personal data involved?" flag that routes the event to the DPO and starts the notification assessment immediately — a reflex worth building before full obligations land on 13 May 2027. RBI-regulated entities and SEBI CSCRF intermediaries carry parallel sector clocks measured in hours.
Implementation Guidance
Define Event and Incident in Writing, with Examples
In the incident response plan (A.5.24), define an event as any observed occurrence with potential security relevance and an incident as an assessed event that compromises or credibly threatens confidentiality, integrity, or availability — then add five worked examples of each from your own environment. The examples do more calibration work than the definitions; they are what makes Tuesday's decision match Friday's.
Build the Severity Classification Scheme
Adopt a small tier set — SEV1–SEV4 is the common shape — with objective criteria per tier: classification of data involved, number and criticality of affected systems, whether it is spreading, regulatory or customer exposure, and required response time per tier. Include explicit flags that force routing: personal data involved, CERT-In or other reportable category, customer-facing impact.
Name the Deciders and Their Deputies
Give triage authority to a named role — on-call security analyst, SOC shift lead, or incident manager depending on size — with deputies for leave and after-hours, and write down what they may do: declare an incident, assign or change severity, close an event as benign, escalate when unsure. The when-in-doubt-escalate rule belongs in the procedure verbatim, so a junior analyst at 2 a.m. is never gambling alone.
Consolidate Intake into One Queue with an SLA
Route every event source — SIEM and monitoring alerts (A.8.16), user reports (A.6.8), help desk escalations, supplier notifications, threat intel — into a single ticketed queue. Set a triage SLA scaled to source urgency (for example, initial assessment within 30–60 minutes for high-fidelity alerts and user-reported phishing, same business day for low-urgency sources) and measure queue age as a standing KPI.
Log Every Decision, Both Ways
Each event ticket records source, receipt time, assessor, criteria applied, the decision, severity if declared, rationale, and decision time. Make non-incident closures cheap but real: a reason code plus one rationale sentence, written in under a minute. The negative log is the control's core evidence — it proves assessment happens and gives post-incident reviews the data to find mis-triage.
Calibrate the Deciders and Tune the Sources
Train everyone who triages on the criteria and examples, then run periodic calibration: re-review a sample of closed non-incidents quarterly to catch under-triage drift, and discuss disagreements against the written criteria. Feed chronic false-positive sources back to monitoring tuning (A.8.16) so noise gets fixed at origin instead of absorbed at the desk.
Review the Criteria After Incidents and Exercises
In every post-incident review (A.5.27) and tabletop, ask whether the event was triaged correctly at first contact: right call, right severity, right speed. Update the criteria, examples, and severity thresholds when the answer is no, and re-brief the triage roster. Triage criteria are living calibration instruments — a scheme untouched for three years is almost certainly mis-calibrated.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.5.25:
Documentation
- Documented event-vs-incident criteria and severity classification scheme, with worked examples, inside the incident response plan or triage procedure
- Triage log or ticket export showing events from multiple sources with assessor, criteria applied, decision, and timestamps
- Closed non-incident records with reason codes and rationale — the negative decisions, not just the declared incidents
- On-call roster and escalation path showing named triage authority and deputies across shifts and time zones
- Calibration or QA records: sampled closure re-reviews, criteria updates after incidents or exercises, triage training for the roster
Interviews
- The on-call analyst or triage owner on how they decide a borderline event, and what they do when unsure
- The incident manager on declaration authority, severity assignment, downgrades, and who can overrule a triage call
- Help desk or SOC staff on where user-reported events go and how fast assessment follows
Observations
- A sample of recent monitoring alerts and A.6.8 user reports traced through to logged triage decisions
- Live walkthrough of the event queue and ticket workflow, including a non-incident closure with its rationale
- Timestamps from event receipt to decision compared against the stated triage SLA
Practitioner Insights
My first request in this control is always the same: show me something you decided was not an incident. Mature programs pull up a ticket in seconds — criteria, rationale, decider, timestamp. Everywhere else I hear "we only log the real ones", which tells me assessment is undocumented and the control exists only in someone's head. The related red flag is the empty year: no recorded incidents and no recorded events either. That is not evidence the organization is safe; it is evidence nothing is being assessed, and I write it up accordingly.
In smaller teams, triage happens in a chat thread: someone posts a screenshot, four people speculate, the thread scrolls away, and there is no decision anywhere. The fix costs almost nothing — one intake form or alias that opens a ticket, a one-page criteria sheet with five examples on each side of the line, and a team rule that every thread ends in a ticket with a decision on it. The criteria sheet matters more than any tooling, because it is what makes the decision the same regardless of who is on call. Write it before your next event, not after.
Common Challenges & Solutions
Challenge
Only declared incidents get logged; routine events are closed silently with no record they were ever assessed.
Solution
Make the negative decision a first-class record with a near-zero cost: a reason-code dropdown plus one rationale sentence, completable in under a minute inside the existing ticket. Frame it to the team as evidence generation, not bureaucracy — the non-incident log is what proves diligence at audit and what lets post-incident reviews find the alert that was wrongly dismissed.
Challenge
Triage is gut feel, so the same event gets different outcomes depending on who is on shift.
Solution
Write the criteria down with worked examples from your own history, and calibrate quarterly: the triage roster re-reviews a sample of recent closures together and argues disagreements against the written scheme, updating it where it is ambiguous. Consistency comes from shared examples and rehearsal, not from hiring identical analysts.
Challenge
Alert volume swamps the queue, and real incidents hide behind a wall of stale tickets.
Solution
Attack volume at the source rather than the desk: tune or retire chronically false-positive rules through A.8.16, deduplicate and aggregate related alerts, and rank sources by fidelity so high-trust channels get the tight SLA. Track queue age as a KPI with an escalation threshold — a triage backlog measured in days is an incident-detection outage in disguise.
Challenge
Nobody is clearly authorized to declare or downgrade an incident, so borderline events stall in committee while clocks run.
Solution
Vest declaration authority in the on-call triage role explicitly, with a provisional-declaration rule: the analyst can declare and mobilize immediately, and the incident manager ratifies or downgrades at the first review point. Pair it with the written when-in-doubt-escalate instruction. A wrong-but-fast provisional call costs an hour of response time; a stalled one can cost the regulatory window.
Challenge
Events involving personal data or reportable categories get triaged like ordinary IT noise until it is far too late.
Solution
Build forcing flags into the triage checklist — personal data involved, CERT-In or sector reportable category, customer-facing impact — that mandatorily route the event to the DPO or legal and start the notification assessment in parallel with technical analysis. The triage criteria should embed the regulatory map so the 2 a.m. decider does not need to know the law, only to follow the checklist.
