Annex A Controls

A.5.25 through A.5.28 — Incident Management That Actually Works

Alex Fuerst

19 Sep 2025 — 6 min read

The Incident Management Reality Check

Most organizations I audit have incident management processes that look immaculate on paper and crumble spectacularly when something actually goes wrong. I've watched security teams fumble through their first real breach while frantically searching SharePoint for a procedure document nobody has read since it was written three years ago. The gap between documented incident management and effective incident response is often a chasm, and Controls 5.25 through 5.28 are precisely where that gap becomes painfully visible.

These four controls form the backbone of ISO 27001's incident management requirements, and they're structured to work together as a cohesive system. Treat them as individual checkboxes, and you'll fail when it matters most. Treat them as an integrated capability, and you might actually contain that ransomware attack before it encrypts your backup servers.

Understanding the Incident Management Control Cluster

Let's break down what we're working with here. Control 5.25 covers assessment and decision-making on information security events—the critical triage function. Control 5.26 addresses response to security incidents once you've determined something requires action. Control 5.27 focuses on learning from incidents to prevent recurrence. Control 5.28 deals with evidence collection and preservation. Notice how they flow logically from "is this an incident?" to "respond appropriately" to "learn and improve" while maintaining forensic integrity throughout. This isn't accidental.

Where organizations typically go wrong is treating these as separate activities rather than phases of a continuous cycle. Your assessment criteria (Control 5.25) should drive appropriate response actions (Control 5.26). Your lessons learned (Control 5.27) should inform future assessment decisions. Your evidence collection procedures (Control 5.28) should support both response activities and post-incident analysis.

Control 5.25 — Assessment and Decision: The Critical Triage Function

The standard requires you to assess information security events and decide if they are to be categorized as information security incidents. This sounds straightforward until you're staring at an alert at 2 AM trying to determine if that unusual database query pattern constitutes an incident worth waking the CISO.

I audited a healthcare provider that had implemented a sophisticated SIEM system generating thousands of events daily. Their incident management process required the on-call analyst to "use professional judgment" to determine incident classification. During our audit interviews, I discovered that three different analysts had classified identical events as low, medium, and high severity respectively over the previous month. Without clear categorization criteria, your assessment process becomes a dice roll.

Effective assessment requires:

Documented categorization schemes that map event types to incident classifications
Clear escalation thresholds that don't require interpretation
Defined roles for who makes assessment decisions at different severity levels
Time-bound assessment requirements (e.g., initial assessment within 30 minutes)
Documented decision rationale for audit trail purposes

The ISO/IEC 27035 series provides detailed guidance on incident management processes, but I've seen organizations get lost in its complexity. For practical implementation, focus on three severity levels: informational (log and monitor), incident (investigate and contain), and crisis (activate full response team). Each level should have clear triggers and response procedures.

Building Effective Categorization Schemes

Your categorization scheme needs to consider multiple factors simultaneously. I recommend a matrix approach that evaluates:

Scope: Single user, department, or organization-wide impact
Data sensitivity: Public, internal, confidential, or restricted information
System criticality: Based on your business impact analysis
Regulatory implications: Potential notification requirements

A multinational manufacturer I worked with created decision trees that their Level 1 analysts could follow without requiring deep security expertise. The key was making the criteria objective and measurable rather than subjective.

Control 5.26 — Response to Information Security Incidents

Once you've categorized an event as an incident, Control 5.26 requires you to respond according to documented procedures. This is where preparation meets reality, and where most organizations discover their procedures were written by people who've never actually responded to an incident.

The control specifies requirements for managing information security incidents in accordance with documented procedures. The critical word here is "managed"—incidents need orchestration, not just technical response. I've seen brilliant technical teams successfully contain malware infections while completely failing to manage stakeholder communications, resulting in regulatory penalties despite effective technical response.

Your incident response procedures must address:

Immediate containment actions to prevent incident escalation
Communication protocols for internal stakeholders and external parties
Evidence preservation requirements during response activities
Recovery procedures to restore normal operations
External notification requirements including regulators and law enforcement

Cross-reference with Control 5.29 (Information security during disruption) ensures your incident response procedures account for degraded operating conditions. When your primary email system is compromised, how do you activate your incident response team?

The Communications Challenge

I've audited organizations that executed perfect technical responses but failed spectacularly on communications. A professional services firm I worked with contained a data breach within hours but waited three days to notify affected clients while "gathering more information." The technical team had done everything right, but the communications failure resulted in significant client losses.

Effective incident communications require pre-drafted templates for different scenarios, designated spokespersons with decision-making authority, and clear escalation triggers for when legal counsel or senior management must be involved.

Control 5.27 — Learning from Information Security Incidents

This control requires you to use knowledge gained from analyzing and resolving information security incidents to reduce the likelihood or impact of future incidents. Yet I consistently find organizations that treat post-incident reviews as blame assignment sessions rather than learning opportunities.

I audited a technology company that had experienced three similar phishing incidents over six months. Each incident was resolved quickly, but the post-incident reports focused on user behavior rather than systematic improvements. They hadn't implemented technical controls to prevent similar attacks or enhanced their security awareness training based on the attack patterns they were seeing.

Effective post-incident analysis includes:

Root cause analysis that examines both technical and process failures
Timeline reconstruction to identify detection and response gaps
Control effectiveness evaluation based on actual incident data
Specific corrective actions with ownership and deadlines
Updates to procedures based on lessons learned

The key is treating incidents as valuable data sources for continuous improvement. Link your findings back to your risk assessment under Clause 6.1.2 and update your risk treatment plans accordingly.

Control 5.28 — Collection of Evidence

Evidence collection is where technical precision meets legal requirements. The control requires procedures for identification, collection, acquisition, and preservation of evidence related to information security events. Get this wrong, and your incident response might solve the immediate problem while rendering the evidence inadmissible for disciplinary action or prosecution.

ISO/IEC 27037 provides detailed guidance on digital evidence handling, but I've seen organizations implement complex forensic procedures that their teams can't execute under pressure. A financial institution I audited had adopted enterprise-grade forensic tools but discovered during an incident that none of their analysts were trained to use them properly.

Practical evidence collection requires:

Chain of custody procedures that maintain legal admissibility
Technical capabilities for imaging and preserving digital evidence
Documentation standards that capture collection methodology
Secure storage for evidence that might be needed months later
Legal review processes for evidence retention and disclosure

For organizations subject to regulations like GDPR, consider how ISO/IEC 27018 requirements for PII processing apply to evidence collection activities. Evidence containing personal data requires additional protection measures.

The Timing Dilemma

Evidence collection creates a fundamental tension between rapid response and forensic preservation. I worked with a healthcare provider that spent so much time preserving evidence that the incident continued to spread while they imaged affected systems. The solution was implementing live forensics capabilities that could collect evidence without interrupting containment activities.

Integration with Business Continuity

These incident management controls don't operate in isolation. Your incident response procedures must integrate with business continuity planning under Control 5.30 (ICT readiness for business continuity). When incident response requires taking critical systems offline, you need predetermined procedures for maintaining essential business operations.

Consider how your incident management capabilities support the broader cybersecurity framework referenced in ISO/IEC 27032. Your incident response team should understand how their actions contribute to overall cyber-resilience, not just immediate problem resolution.

What the Auditor Looks For

During incident management audits, I examine evidence across multiple dimensions:

For Control 5.25 (Assessment and Decision):

Categorization schemes with measurable criteria
Assessment decision logs showing consistent application
Evidence that assessments drive appropriate response escalation
Time stamps demonstrating assessment timeliness

For Control 5.26 (Response):

Incident response procedures that teams can actually execute
Evidence of coordination between technical and business teams
Documentation showing communications were managed effectively
Proof that external notification requirements were met

For Control 5.27 (Learning):

Post-incident reports that identify systematic improvements
Updates to procedures based on actual incident experience
Changes to controls or processes driven by lessons learned
Integration of incident data into risk management processes

For Control 5.28 (Evidence Collection):

Procedures that maintain chain of custody requirements
Evidence that collection activities don't impede response
Secure storage and handling of collected evidence
Documentation supporting legal admissibility

Common Implementation Failures

The most common failure I see is organizations that implement these controls in sequence rather than as an integrated system. They create separate procedures for assessment, response, learning, and evidence collection without considering how these activities interact during actual incidents.

Another frequent issue is over-engineering the documentation while under-engineering the capabilities. Complex playbooks that nobody can follow under pressure are worse than simple procedures that teams can execute effectively.

Finally, many organizations fail to test their incident management capabilities until they face a real incident. Regular tabletop exercises and technical drills reveal gaps that documentation reviews never catch.

Ready to strengthen your incident management capabilities? Join our ISO 27001 community at the IX ISO 27001 Info Hub for practical implementation guidance and peer discussions.

Need personalized guidance? Reach our team at ix@isegrim-x.com.