When security teams lack a formal process to separate genuine threats from routine noise, real incidents slip through. An attacker’s initial foothold — a single anomalous login, an unusual data transfer — gets buried under thousands of undifferentiated alerts, and by the time anyone notices, the damage is already done.
What 5.25 Requires
Your organization must establish a formal triage process that evaluates every reported information security event and determines whether it qualifies as an incident requiring activation of your response plan. This is a core requirement of ISO 27001 compliance. This is not about reacting to alerts as they arrive — it is about building a repeatable, documented mechanism for classification.
In practice, that means defining clear criteria for what separates an event (a failed login attempt, a firewall block, an antivirus alert) from an incident (a confirmed unauthorized access, data exfiltration, or service compromise). You need a designated decision-maker — someone with the authority and context to classify events against those criteria and trigger escalation when thresholds are met.
Every classification decision must be documented: who assessed the event, what criteria they applied, what conclusion they reached, and why. Without that trail, your triage process is invisible to auditors and impossible to improve. The assessment process must also connect directly to your incident response plan so that confirmed incidents immediately trigger the right procedures rather than sitting in a queue.
Why 5.25 Matters
Organizations that fail to implement this control often face a predictable pattern: their security operations center generates hundreds or thousands of alerts daily, every alert receives the same cursory review, and analysts develop alert fatigue. In that environment, a sophisticated attacker who gains initial access through a compromised credential or a vulnerability exploit blends into the noise. The initial indicators — a login from an unusual location, a privilege escalation request, lateral movement between systems — are each individually triaged as low-severity events because no classification framework exists to correlate them into a pattern.
The consequence is delayed detection. IBM’s Cost of a Data Breach Report found that the mean time to identify and contain a breach reached 241 days in 2025 — and organizations with longer detection windows consistently face higher costs. Without a structured triage process, your organization contributes to that statistic rather than beating it.
The regulatory implications compound the operational risk. Frameworks like GDPR impose 72-hour notification windows that start from the moment you become aware of an incident. If your triage process cannot distinguish incidents from events in a timely manner, you may not even recognize the clock has started until it is too late.
What Attackers Exploit
- Alert fatigue: An overwhelming volume of undifferentiated events masks real attacks, and analysts begin dismissing alerts without thorough evaluation.
- No escalation criteria: Initial compromise indicators — unusual authentication patterns, unexpected process execution — are treated as routine because no threshold exists to flag them.
- Inconsistent classification: Without standardized criteria, different analysts reach different conclusions on the same event, creating gaps attackers can exploit repeatedly.
- Undocumented decisions: No audit trail means the same misjudgment happens multiple times, because the organization cannot learn from past triage errors.
- Delayed triage: Events accumulate in a backlog while the attacker moves laterally through the network, escalating privileges and staging data for exfiltration.
- Missing integration with response plan: Even when someone correctly identifies a suspicious event, there is no defined trigger to activate the formal incident response process, so the response is ad hoc and slow.
The risk class here is operational detection failure — and its severity is high because every hour of delayed incident identification directly increases the scope and cost of the breach.
How to Implement 5.25
Implementing this control requires building both the process and the organizational muscle to sustain it. The triage mechanism needs to be fast enough to keep pace with your alert volume, precise enough to catch real threats, and documented enough to satisfy auditors.
For Your Organization (First-Party)
Step 1: Define event classification criteria. Start by establishing what constitutes an event versus an incident in your environment. Base your criteria on impact to the CIA triad (confidentiality, integrity, availability), the criticality of affected assets, and the nature of the observed behavior. A single failed login on a non-critical system is an event. Ten failed logins on a domain admin account followed by a successful authentication from a new IP is a potential incident.
Step 2: Build a categorization and prioritization scheme. Use an Impact × Urgency = Priority model. Impact measures the severity of potential consequences (data loss, service disruption, regulatory exposure). Urgency reflects how quickly the organization must act to prevent further damage. Map combinations to priority levels (critical, high, medium, low) with defined response timeframes for each.
Step 3: Designate a triage authority. Assign a specific role — SOC lead, incident manager, or on-call security analyst — with the authority to officially classify events and escalate incidents. Avoid single points of failure by cross-training multiple team members and establishing an on-call rotation.
Step 4: Establish documentation requirements. Every triage decision must be logged with the event details, the criteria applied, the classification outcome, the assessor’s identity, and a timestamp. Record the reasoning, not just the decision — this is what auditors will examine and what drives process improvement.
Step 5: Integrate with your incident response plan. Define explicit triggers that link classification outcomes to response procedures under control 5.24. Build this integration into your incident response plan. When an event is classified as a high-priority incident, the response plan activates automatically — no manual handoff, no email chain.
Step 6: Implement supporting tooling. Deploy SIEM platforms for event aggregation and correlation, ticketing systems for tracking triage decisions, and automated rules for initial event filtering. The tooling should reduce analyst workload on obvious false positives so human judgment can focus on ambiguous cases.
Step 7: Train and test. Run tabletop exercises that simulate event triage scenarios. Review classification accuracy quarterly — track false positive rates, missed escalations, and time-to-triage metrics. Adjust criteria and automation rules based on what you find.
Common mistakes:
- Treating every alert as an incident, which overwhelms your response team and dilutes focus on genuine threats
- Operating without written classification criteria, making every triage decision subjective and inconsistent
- Creating a single point of failure where only one person can authorize escalation
- Not reviewing false positive rates, allowing stale correlation rules to generate noise that desensitizes analysts
- Documenting the classification decision but not the reasoning behind it, which makes audits difficult and prevents organizational learning
For Your Vendors (Third-Party Assessment)
When assessing vendors against this control, your security questionnaire should probe for specifics rather than accepting generic assurances.
Key questions to ask:
- “Describe your process for triaging reported security events. What classification scheme do you use?”
- “Who has the authority to escalate an event to an incident? What is the defined escalation path?”
- “What is your average time from event detection to triage decision?”
- “How do you document triage decisions, and can you provide a sample (redacted) incident log?”
Evidence to request: Event classification policy, a sample incident register showing documented triage decisions, triage SLA metrics covering the past 12 months, and screenshots or exports from their SIEM dashboard showing alert categorization.
Red flags in vendor responses:
- No written triage criteria — “we handle it case by case”
- No designated escalation authority — triage decisions are informal
- Inability to produce incident logs or triage records
- Triage response times measured in days rather than hours
- No connection between event triage and a formal incident response plan
Verification beyond self-attestation: Request the vendor’s SOC 2 Type II report and review the incident management controls section. Use a vendor risk management platform to continuously monitor vendor security posture beyond point-in-time assessments. Ask for quantitative triage metrics — mean time to classify, event-to-incident conversion rates, and false positive rates. If a vendor cannot produce these, their triage process likely exists on paper but not in practice.
Audit Evidence for 5.25
| Evidence Type | Example Artifact |
|---|---|
| Policy documentation | Information Security Event Assessment and Classification Policy defining triage criteria, escalation thresholds, and decision authority roles |
| Classification scheme | Event Classification Matrix documenting severity levels (critical/high/medium/low), impact categories, and priority assignments with response timeframes |
| Incident log | Security event register showing logged events with classification decisions, timestamps, assessor identities, and decision rationale |
| Escalation records | Documented escalation decisions with rationale for why specific events were or were not categorized as incidents |
| Training records | Evidence of triage training for SOC and incident response personnel, including tabletop exercise results and attendance logs |
| Integration evidence | Documented linkage between event assessment process and formal Incident Response Plan (control 5.24), showing defined escalation triggers |
| Review and improvement records | Quarterly triage accuracy reviews showing false positive rates, classification consistency metrics, and resulting process adjustments |
Cross-Framework Mapping
| Framework | Equivalent Control(s) | Coverage |
|---|---|---|
| NIST 800-53 | AU-06 (Audit Record Review, Analysis, and Reporting) | Full |
| NIST 800-53 | IR-04 (Incident Handling) | Full |
| SOC 2 | CC7.3 (Evaluates security events to determine whether they could or have resulted in a failure to meet objectives) | Full |
| NIST CSF 2.0 | DE.AE-04 (The estimated impact and scope of adverse events are understood) | Full |
| NIST CSF 2.0 | RS.AN-03 (Analysis is performed to determine what has taken place during an incident) | Partial |
| CIS Controls v8.1 | Control 17.2 (Establish and Maintain Contact Information for Reporting Security Incidents) | Partial |
| DORA (EU) | Article 17 (ICT-related incident management process — classification and reporting) | Partial |
Related ISO 27001 Controls
| Control ID | Control Name | Relationship |
|---|---|---|
| 5.24 | Information security incident management planning and preparation | Direct prerequisite — defines the response plan that 5.25 triage decisions activate |
| 5.26 | Response to information security incidents | Direct successor — incidents classified by 5.25 trigger 5.26 response procedures |
| 5.27 | Learning from information security incidents | Downstream dependency — triage accuracy data and incident outcomes feed post-incident review |
| 5.28 | Collection of evidence | Triage decisions determine when forensic evidence collection must begin to preserve integrity |
| 6.8 | Information security event reporting | Upstream input — reported events from personnel and systems are what 5.25 assesses and classifies |
| 5.5 | Contact with authorities | Triage may identify incidents requiring mandatory notification to regulators or law enforcement |
| 5.2 | Information security roles and responsibilities | Defines who has the authority to make triage and escalation decisions |
| 8.15 | Logging | Technical foundation — log data from systems and applications provides the raw events that enter triage |
| 8.16 | Monitoring activities | Detection layer — continuous monitoring generates the security events that feed the 5.25 assessment process |
Frequently Asked Questions
What is ISO 27001 5.25?
ISO 27001 5.25 is the Annex A control that requires organizations to implement a formal triage process for assessing reported information security events and deciding whether they constitute incidents. It establishes the classification mechanism that sits between event detection and incident response, ensuring that genuine threats are identified and escalated while routine events are documented and closed.
What happens if 5.25 is not implemented?
Without this control, organizations lose the ability to distinguish real incidents from background noise. Security teams either treat every alert with the same urgency — exhausting response resources on false positives — or develop alert fatigue and miss genuine threats. The result is delayed incident detection, increased breach impact, and likely audit findings during ISO 27001 certification.
How do you audit 5.25?
Auditors examine the event classification policy for documented triage criteria, then review the incident log for evidence those criteria are applied consistently — selecting specific events and asking the organization to walk through the classification decision, including who made it, what criteria they used, and why the event was or was not escalated.
How UpGuard Helps
Detect and classify security events across your attack surface before they become incidents.
UpGuard Breach Risk continuously monitors your organization’s external attack surface for security events — exposed credentials, misconfigured services, vulnerability disclosures, and data leaks — giving your triage team the visibility they need to assess and classify threats as they emerge. Instead of waiting for events to surface through internal logging alone, you get early detection that feeds directly into your 5.25 assessment process. Learn more about UpGuard Breach Risk.