The SIEM generates 500 alerts per day. The security team investigates the ones they notice and ignores the rest. A genuine data exfiltration hides among the noise, undetected for weeks. A.5.25 addresses this problem by requiring a systematic process for assessing security events and deciding which ones warrant incident-level response.
What does the standard require?
- Define classification criteria. Establish a clear scheme for categorising events by type (malware, unauthorised access, data loss, etc.) and severity (low, medium, high, critical).
- Designate a decision point. Appoint a person or team responsible for assessing events and deciding whether each one constitutes an incident.
- Prioritise based on impact. Events with greater potential impact on business operations, data confidentiality or regulatory compliance must receive priority treatment.
- Document every assessment. Record the event details, the assessment rationale and the decision taken — whether or not the event is escalated.
In practice
Automate initial triage where possible. SIEM correlation rules, automated alert scoring and playbook-driven workflows can handle the bulk of low-severity events, freeing human analysts to focus on ambiguous or high-severity cases.
Define response time targets per severity. Critical events should be triaged within 30 minutes; high within 2 hours; medium within 8 hours; low within 24 hours. These targets create accountability and are measurable.
Establish an escalation path. Define what happens when an event exceeds the analyst’s authority or expertise. Escalation should be seamless — predefined contacts, clear criteria, no ambiguity about when to escalate.
Review false positive rates. If the majority of events turn out to be non-incidents, the detection rules need tuning. A high false positive rate erodes analyst attention and increases the risk that real incidents are missed.
Typical audit evidence
Auditors typically expect the following evidence for A.5.25:
- Event classification scheme — documented criteria for categorisation and severity levels
- Event log/register — showing that events were recorded and assessed
- Triage records — documenting the assessment rationale and decision for each event
- Response time metrics — evidence that events were classified within defined timeframes
- Escalation records — showing that high-severity events were escalated appropriately
KPI
Average time to classify and escalate IS events (in hours)
This KPI measures the speed of the triage process. Faster classification means faster response. Track the metric by severity level — critical events should have significantly shorter triage times than low-severity events.
Supplementary KPIs:
- Percentage of events triaged within defined response time targets
- False positive rate (percentage of escalated events that turn out to be non-incidents)
- Number of events per month (trend analysis for detection capability)
- Percentage of events with complete documentation
BSI IT-Grundschutz
A.5.25 maps to the following BSI requirements:
- DER.1 (Detection of security-relevant events) — covers the detection, collection and initial assessment of security events.
- DER.2.1 (Security incident management) — includes the classification and escalation criteria for events that become incidents.
Related controls
A.5.25 is the decision point in the incident lifecycle:
- A.5.24 — Incident management planning: The plan defines the criteria that A.5.25 applies.
- A.5.26 — Response to incidents: Events classified as incidents trigger the response process.
- A.5.7 — Threat intelligence: Threat context improves the accuracy of event assessment.
Sources
- ISO/IEC 27001:2022 Annex A, Control A.5.25 — Assessment and decision on information security events
- ISO/IEC 27002:2022 Section 5.25 — Implementation guidance
- BSI IT-Grundschutz, DER.1 — Detection of security-relevant events