A disorganized incident response turns a containable security event into an extended crisis. When teams lack documented procedures, containment stretches from hours to days, regulators receive late notifications, and attackers exploit the chaos to deepen their access. Control 5.26 exists to prevent exactly this outcome.
What 5.26 Requires
ISO 27001 Control 5.26 is a corrective control that requires organizations to execute documented and tested response procedures when an information security incident is confirmed. The objective is prompt containment, eradication, and recovery while minimizing business impact.
This control activates after 5.24 (planning and preparation) and 5.25 (assessment and triage) have done their work. Once an event is classified as an incident, 5.26 governs what happens next.
Specifically, the control requires organizations to:
- Execute documented response procedures tied to the incident category — not improvise under pressure.
- Assign defined authority to response teams so they can act decisively — isolating systems, disconnecting networks, revoking access — without waiting for approval chains.
- Preserve evidence throughout the response process, maintaining chain of custody for potential legal, regulatory, or forensic needs.
- Coordinate communications with internal stakeholders, regulators, and affected parties according to pre-established templates and timelines.
- Formally close incidents only after recovery is verified, root causes are documented, and lessons learned are recorded.
The distinction matters: 5.26 is not about having a plan (that is 5.24) or deciding whether something is an incident (that is 5.25). It is about executing the response itself — the actions your team takes from the moment an incident is confirmed until it is formally closed. For a broader view of the ISO 27001 certification process, see our compliance overview.
Why 5.26 Matters
Consider a scenario: an organization detects ransomware on a file server. The security team knows something is wrong, but there are no documented response procedures. One engineer starts reimaging the affected machine. Another begins disconnecting network segments, but is not sure which ones. No one has authority to shut down the email gateway the attacker used to gain initial access. Meanwhile, the attacker moves laterally through the network, exfiltrating data from a database server that no one thought to isolate.
Three days later, containment is finally achieved. The organization then discovers it must notify regulators — GDPR requires notification within 72 hours of becoming aware of a personal data breach. That window closed on day two.
This is not a theoretical exercise. According to the IBM Cost of a Data Breach Report 2025, the mean time to identify and contain a breach is 241 days, and the average cost reaches $4.44 million. Organizations with formal, tested incident response procedures consistently contain incidents faster and at lower cost.
Without 5.26, incidents escalate from manageable events into full-blown crises. The damage compounds: operational disruption extends, regulatory exposure multiplies, and reputational harm deepens when stakeholders learn the response was improvised.
What attackers exploit
Every gap in your incident response process is an advantage for an attacker. These are the specific failure modes 5.26 is designed to close:
- No documented response playbooks — teams improvise under pressure, making inconsistent and sometimes counterproductive decisions.
- No pre-authorized containment actions — responders wait for management approval while the threat spreads to additional systems.
- Untested communication plans — notifications to regulators and affected parties are late, incomplete, or sent to the wrong contacts.
- No evidence preservation procedures — forensic data is overwritten during hasty recovery efforts, eliminating the ability to determine root cause or scope of compromise.
- Undefined escalation criteria — minor incidents are not escalated until they become major ones, losing the window for early containment.
- No formal incident closure process — root causes go unaddressed, and the same attack vector is exploited again weeks later.
How to Implement 5.26
For your organization (first-party)
Implementing 5.26 means building response procedures that your team can actually execute under pressure — not compliance documents that sit in a SharePoint folder.
1. Document response procedures for each incident category. Create separate playbooks for ransomware, data breach, insider threat, DDoS, and lost or stolen devices. Each playbook should specify step-by-step containment, eradication, and recovery actions. Generic “respond to the incident” instructions fail in practice because a ransomware response looks nothing like a DDoS response.
2. Define roles and assign authority. Name the individuals who can isolate systems, disconnect networks, revoke credentials, and communicate externally. Response teams need pre-authorized decision-making power. If your incident commander must escalate to a VP before disconnecting a compromised server, you have already lost time.
3. Establish evidence collection and chain-of-custody procedures. Define how forensic images are captured, where logs are preserved, and who maintains the chain of custody. This is not optional — you will need this evidence for root cause analysis, regulatory inquiries, and potentially legal proceedings.
4. Build escalation matrices. Link severity levels to specific escalation paths. A severity 1 incident (active data exfiltration) should trigger crisis management and potentially business continuity activation. A severity 3 (phishing email contained by email gateway) should not. Define these thresholds before an incident forces you to decide in real time.
5. Prepare communication templates. Draft templates for regulator notifications, customer communications, and internal stakeholder updates. Under GDPR, you have 72 hours to notify your supervisory authority. Under sector-specific regulations, timelines may be shorter. Templates prevent delays caused by drafting and approving language during an active incident.
6. Define formal closure criteria. An incident is not closed when systems are restored. It is closed when recovery is verified, the root cause is documented, lessons learned are recorded, and any process improvements are assigned to owners with deadlines.
7. Test procedures through exercises. Run tabletop exercises and simulated incidents at least annually. The UK Cyber Security Breaches Survey 2025 found that only 22% of businesses have a formal incident response plan — and among those that do, many have never tested it. Untested procedures are unreliable procedures.
8. Deploy supporting tooling. Incident response is supported by SIEM platforms for detection and correlation, SOAR tools for automated response actions, incident ticketing systems for tracking and documentation, and forensic imaging tools for evidence preservation. The tooling does not replace procedures, but it makes execution faster and more consistent.
Common implementation mistakes:
- Writing procedures that exist only as documents — never tested through tabletop exercises or simulations.
- Conflating incident response with business continuity. They overlap during major incidents, but serve different purposes and require different procedures.
- Assigning response roles to people who lack the technical skills or organizational authority to act.
- Treating all incidents identically instead of creating severity-based playbooks.
- Prioritizing service restoration over evidence preservation — destroying forensic data in the rush to get systems back online.
For your vendors (third-party assessment)
When conducting a vendor risk assessment against 5.26, self-attestation is not sufficient. Ask specific questions and request concrete evidence. An ISO 27001 vendor questionnaire can help structure this process.
Questions to ask:
- Describe your incident response procedure for a confirmed data breach affecting customer data.
- When was your incident response procedure last tested? Provide the tabletop exercise report.
- What is your breach notification timeline to affected customers?
- Who is your incident response lead, and what is their authority level?
Evidence to request:
- Incident response policy document
- Tabletop exercise reports from the past 12 months
- Sample incident closure report (redacted)
- Breach notification templates
Red flags:
- The vendor cannot name their incident response lead.
- No evidence of testing — procedures exist on paper but have never been exercised.
- Notification timeline is vague (“as soon as practical” rather than a specific hour target).
- No formal closure process — incidents are resolved but never formally closed with root cause documentation.
Beyond self-attestation: Review the third-party risk requirements under ISO 27001 and request the vendor’s SOC 2 Type II report, reviewing the incident management criteria. Ask for penetration test remediation timelines to assess how quickly they act on identified vulnerabilities. If the vendor has experienced a publicly reported breach, evaluate how their actual response compared to their documented procedures.
Audit Evidence for 5.26
Auditors assessing 5.26 need to verify that response procedures exist, have been tested, and were followed during real incidents. The following table outlines the specific evidence types and example artifacts they will request.
| Evidence Type | Example Artifact |
|---|---|
| Incident Response Policy | Policy document defining response phases, roles, authority levels, and escalation criteria |
| Incident Response Playbooks | Category-specific runbooks (e.g., ransomware playbook with step-by-step containment and eradication actions) |
| Incident Log / Register | Chronological record of all incidents with timestamps, severity classification, actions taken, and closure status |
| Tabletop Exercise Reports | Documentation from annual response exercises including scenario, participants, findings, and corrective actions |
| Communication Records | Evidence of regulator notifications, stakeholder updates, and internal escalation communications during real incidents |
| Evidence Collection Procedures | Chain-of-custody forms, forensic imaging logs, and preserved log files from past incidents |
| Post-Incident Review Reports | Root cause analysis documents with identified improvements and implementation status |
| Incident Metrics Dashboard | Metrics tracking mean time to detect, contain, and recover across incident categories |
The strongest evidence combines documented procedures with proof of execution. An auditor who sees both a ransomware playbook and an incident closure report showing that playbook was followed during an actual ransomware event has high confidence in the control’s effectiveness.
Cross-Framework Mapping
Control 5.26 maps to incident response requirements across major compliance frameworks. If your organization operates under multiple standards, this mapping shows where 5.26 requirements overlap with or satisfy controls in other frameworks.
| Framework | Equivalent Control(s) | Coverage |
|---|---|---|
| NIST 800-53 | IR-04 (Incident Handling) | Full |
| NIST CSF 2.0 | RS.MA (Incident Management), RS.AN (Incident Analysis) | Partial |
| SOC 2 Trust Services Criteria | CC7.4 (Response to Identified Security Incidents), CC7.5 (Recovery from Identified Security Incidents) | Full |
| CIS Controls v8.1 | Control 17 (Incident Response Management) | Full |
| DORA (EU) | Article 17 (ICT-related incident management process) | Partial |
| CPS 230 (APRA) | Operational risk management — incident response requirements | Partial |
The NIST 800-53 IR-04 mapping is drawn from the official OLIR (Online Informative References) crosswalk between ISO 27001 and NIST 800-53. The partial mappings indicate frameworks where 5.26 covers the core incident response execution requirement but additional framework-specific obligations (such as DORA’s ICT incident classification scheme) extend beyond 5.26’s scope.
Related ISO 27001 Controls
Control 5.26 does not operate in isolation. It sits within a chain of incident management controls and depends on several supporting controls across the standard.
| Control ID | Control Name | Relationship |
|---|---|---|
| 5.24 | Information Security Incident Management Planning and Preparation | Prerequisite — defines the plans that 5.26 executes |
| 5.25 | Assessment and Decision on Information Security Events | Upstream — triages events into incidents that trigger 5.26 |
| 5.27 | Learning from Information Security Incidents | Downstream — post-incident analysis feeds back into improving 5.26 procedures |
| 5.28 | Collection of Evidence | Supporting — defines forensic evidence standards used during 5.26 response |
| 5.29 | Information Security During Disruption | Adjacent — ensures security controls persist when business continuity is activated during response |
| 5.30 | ICT Readiness for Business Continuity | Adjacent — ensures infrastructure can support recovery actions triggered by 5.26 |
| 5.5 | Contact with Authorities | Supporting — defines communication channels used for regulatory notifications during response |
| 5.6 | Contact with Special Interest Groups | Supporting — enables information sharing with CERTs and ISACs during incident response |
Frequently Asked Questions
What is ISO 27001 5.26?
ISO 27001 5.26 is a corrective control requiring organizations to respond to confirmed information security incidents using documented and tested procedures. It covers the full response lifecycle — containment to stop the threat from spreading, eradication to remove the threat from affected systems, recovery to restore normal operations, and evidence preservation for forensic and regulatory purposes.
What happens if 5.26 is not implemented?
Without documented incident response procedures, organizations face prolonged containment times, regulatory penalties for missed notification deadlines, and uncontrolled business impact. Incidents that could be contained in hours stretch into days. Evidence is destroyed during ad hoc recovery efforts, eliminating the ability to determine root cause. The same attack vectors are reused because formal closure and lessons learned processes do not exist.
How do you audit 5.26?
Auditors verify that documented response procedures exist, have been tested through tabletop exercises or simulations, and were followed during real incidents. They request specific evidence including incident response policies, category-specific playbooks, incident logs with timestamps and actions, exercise reports, and post-incident review documents. The strongest audit position combines documented procedures with evidence of their execution during actual incidents.
How UpGuard Helps
Your incident response readiness depends not just on your own procedures, but on your vendors’ ability to respond when they are compromised. UpGuard’s Breach Risk product monitors for indicators of compromised vendor environments, giving you early warning when a third party’s incident response may affect your organization. This visibility directly supports the vendor assessment requirements in 5.26.