ISO 27001:2022 Annex A 5.26 Response to Information Security Incidents Explained

ISO 27001 Annex A 5.26 Response to information security incidents logo

ISO 27001 Annex A 5.26 is an ISO 27001 control that requires an organisation to respond to information security incidents based on documented procedures.

In this guide you will learn how to implement ISO 27001 Annex A 5.26 Response to information security incidents and pass your audit from ISO 27001 Lead Auditor Stuart Barker – author of the ultimate ISO 27001 Toolkit.

Purpose & Definition

The purpose of ISO 2701 Annex A 5.26 is a corrective control that ensures efficient and effective response to information security incidents.

The ISO 27001 standard defines Annex A 5.26 as:

ISO 27001 Annex A 5.26 Response to information security incidents guide

Information security incidents should be responded to in accordance with the documented procedures.

ISO/IEC 27001:2022 Annex A 5.26 – Response To Information Security Incidents
Fay-Barker-High-Table

ISO 2701 Annex A 5.26 Training Video

In this free training video you will learn

Implementation Guide

This guide provides a framework for responding to an information security incident. The guide should be used in conjunction with your information security incident management plan.

The standard that relates to information security management for further reading if required is ISO/IEC 27035

To implement ISO 27001 Annex A 5.26 is straightforward. You are going to document processes and procedures for information security incident response and then communicate to those people that need to know about it.

The team that does the response is going to be designated which means you know and have recorded who they are and they are going to have the required competence to do the job.

What the incident response process should include

The information security incident response process is going to include

  • Containment: stopping the incident from spreading or getting worse
  • Evidence Collection: collecting evidence of what happened
  • Escalation: considering and acting on escalation as required which may mean invoking business continuity
  • Logging: recording the response activities and what you did so you can analyse it later
  • Communicating: telling people about the processes so they know what is expected and what to do
  • Sharing: sharing knowledge with people that would be interested to improve responsiveness and reduce wider impact
  • Closing: once the incident ends formally closing the incident and recording it
  • Root cause: identifying why it happened and acting on that root cause conclusion.

The 3 steps of Information Security Incident Response

The 3 steps in information security incident response are:

  1. Identification: identifying the information security incident
  2. Assessment: assessing and prioritising the information security incident
  3. Response: responding to the information security incident incident

How to implement ISO 27001 Annex A 5.26

Implementing a robust incident response capability is not merely a compliance checkbox: it is the difference between a minor disruption and a catastrophic business failure. Following these ten steps will ensure your organisation meets the rigorous requirements of ISO 27001 Annex A 5.26 while protecting your digital assets and reputation.

1. Formalise the Incident Management Plan and Policy

Define the governance framework and specific procedures for handling security breaches. Result: Provides a structured, legally defensible roadmap for the IRT to follow during high-pressure events.

  • Document clear definitions for events versus incidents based on your Asset Register.
  • Specify legal and regulatory reporting triggers for GDPR, NIS2, and DORA.
  • Ensure the policy is signed off by senior leadership to guarantee resource availability.

2. Provision the Incident Response Team and IAM Roles

Identify internal stakeholders and external specialists required to execute the plan. Result: Ensures that the right people have the necessary authorities and technical access before an incident occurs.

  • Define clear IAM roles and “Break Glass” accounts for emergency system access.
  • Establish Rules of Engagement (ROE) documents for third-party digital forensics providers.
  • Mandate MFA for all accounts with administrative or incident response privileges.

3. Establish Internal and External Reporting Channels

Create dedicated pathways for employees and automated systems to flag suspicious activity. Result: Reduces the “Mean Time to Detect” (MTTD) and ensures compliance with 72-hour notification windows.

  • Configure SIEM alerts to trigger notifications to the SOC and IRT immediately.
  • Set up an anonymous reporting line or internal portal for staff to report anomalies.
  • Maintain an offline contact list for regulators, law enforcement, and key clients.

4. Classify Incidents Using a Severity Matrix

Develop a technical criteria for triaging events based on impact and urgency. Result: Enables the organisation to prioritise resources effectively and avoid “alert fatigue” on low-risk events.

  • Map incident severity to the criticality of assets defined in your Asset Register.
  • Define escalation triggers that move an incident from “Technical” to “Crisis Management.”
  • Include quantitative metrics: such as volume of data compromised or duration of downtime.

5. Execute Technical Containment Playbooks

Develop step-by-step technical guides for specific incident types like ransomware or DDoS. Result: Stops the lateral movement of threats and prevents further data exfiltration.

  • Draft network isolation procedures to quarantine infected segments or VLANs.
  • Identify specific “Kill Switches” for high-risk cloud services or API integrations.
  • Test these playbooks quarterly via tabletop exercises to ensure they remain current.

6. Capture and Preserve Forensic Evidence

Standardise the collection of logs, disk images, and memory dumps. Result: Maintains the integrity of evidence for legal proceedings, insurance claims, and root cause analysis.

  • Utilise write-blockers and hash-sum verification for all captured digital evidence.
  • Maintain a strict Chain of Custody (CoC) log for all physical and digital media.
  • Ensure logs are stored in a central, tamper-proof repository.

7. Restore Systems via Eradication and Recovery Steps

Remove the root cause of the incident and return services to a “Known Good” state. Result: Minimises business downtime while ensuring that the threat does not immediately recur.

  • Restore data only from verified, immutable backups to avoid reinfection.
  • Perform vulnerability scans on all restored systems before they are reconnected to the network.
  • Revoke and reissue compromised credentials, certificates, and API keys.

8. Orchestrate Stakeholder and Regulatory Communications

Manage the flow of information to employees, customers, and authorities. Result: Protects the organisation’s brand equity and ensures adherence to global data protection laws.

  • Prepare pre-approved communication templates for various incident scenarios.
  • Utilise out-of-band communication channels if primary email or Slack is compromised.
  • Designate a single spokesperson to prevent conflicting messages.

9. Conduct a Formal Post-Incident Review (PIR)

Analyse the timeline and effectiveness of the response after the threat is neutralised. Result: Identifies specific control gaps and drives continuous improvement in your security posture.

  • Document “Lessons Learnt” and identify why the initial security controls failed.
  • Assess the performance of the IRT against established Key Performance Indicators (KPIs).
  • Quantify the total financial and operational cost of the incident.

10. Update the Risk Register and Statement of Applicability

Integrate the findings from the PIR back into the organisational risk management cycle. Result: Closes the compliance loop by ensuring future risk assessments are based on real-world data.

  • Adjust risk likelihood and impact scores based on the actual incident data.
  • Update Annex A controls and technical configurations to mitigate the discovered root cause.
  • Verify that the updated controls are audited in the next internal audit cycle.

Check Your Work?

You built it yourself. Maybe with AI. But will it pass the audit?

Don’t gamble – let an ISO 27001 Lead Auditor check your work.

Stuart Barker - High Table - ISO27001 Director

ISO 27001 Templates

ISO 27001 Templates - ISO 27001 Annex A 5.26 Response to Information Security Incidents Templates
ISO 27001 Templates

How to comply

To comply with ISO 27001 Annex A 5.26 you are going to implement the ‘how’ to the ‘what’ the control is expecting. In short measure you are going to:

  1. Document your information security incident response process
  2. Assign and document the roles and responsibilities involved in the information response process
  3. Communicate the incident response processes that those that need to know about it
  4. Implement appropriate controls to mitigate, monitor and report on information security incidents
  5. Monitor and review the information security incident response effectiveness

How to pass the audit

To pass an audit of ISO 27001 Annex A 5.26 Information security incidents should be responded to in accordance with the documented procedures you are going to make sure that you have followed the steps above in how to comply.

  1. Have a documented information security incident management plan.
  2. Implement the information security incident management plan.
  3. Monitor the effectiveness of the information security incident management plan.
  4. Review and update the information security incident management plan as needed.

What the audit will check

The audit is going to check a number of areas. Lets go through the main ones

1. That you have documented your roles, responsibilities and process

The audit will check the documentation, that you have reviewed it and signed and it off and that it represents what you actually do not what you think they want to hear.

2. That you can demonstrate the process working

They are going to ask you for evidence to the incident response process and take one example. For this example you are going to show them and walk them through the process and prove that you followed it and that the process worked.

3. That you can learn your lesson

Documenting your lessons learnt and following this through to continual improvements or incident and corrective actions will be checked. They want to see that not only did you respond but that you learnt from it and did something to improve that reduced or eliminated the possibility of it happening again.

Top 3 Mistakes People Make and How to Avoid Them

The top 3 Mistakes People Make For ISO 27001 Annex A 5.26 are

1. Not having a documented information security incident response plan.

This is the most common mistake made by organisations. A documented information security incident response plan is essential for effective incident response. It should include the following:

  • A process for identifying information security incidents.
  • A process for assessing the impact of information security incidents.
  • A process for prioritising information security incidents.
  • A process for responding to information security incidents.
  • A process for recording information security incidents.

2. Not implementing the information security incident response plan.

Even if you have a documented information security incident response plan, it is not enough to simply have the plan. The plan must be implemented in order to be effective. This means assigning responsibility for implementing the plan, providing training on the plan, and testing the plan.

3. Not monitoring the effectiveness of the information security incident response plan.

Once the information security incident response plan is implemented, it is important to monitor its effectiveness. This means reviewing reports of information security incidents, conducting audits of the plan, and taking corrective action as needed.

By avoiding these mistakes, you can ensure that you have an effective information security incident management plan in place.

ISO 2701 Annex A 5.26 FAQ

What are the core requirements of an incident response procedure?

To comply with Annex A 5.26, your response procedure must be structured, repeatable, and capable of addressing various threat vectors. The procedure must define specific criteria for what constitutes an incident versus an event, containment steps to stop threats, eradication of root causes, and safe restoration of systems to normal operations.

What are the mandatory reporting timelines for Annex A 5.26?

Reporting timelines vary by regulation but typically range from 24 to 72 hours. Under GDPR and the UK Data (Use and Access) Act 2025, you must notify the ICO within 72 hours of becoming aware of a breach. DORA requires same-day initial reporting for major ICT incidents, while NIS2 mandates a 24-hour early warning for essential entities.

Does every security incident require a formalised response?

Yes, every identified information security incident must be responded to according to your documented procedures, though the scale of the response should be proportional to the risk. You should triage for severity immediately, prioritise critical assets, and maintain consistent logging and closure processes even for minor security events to ensure forensic integrity.

Who should be included in the incident response team (IRT)?

An effective incident response team (IRT) should be a multi-disciplinary group capable of addressing technical, legal, and operational impacts. This must include an IT/Security Lead for technical containment, Legal/Compliance for regulatory notifications, Management for high-impact decision authority, and Communications/PR to manage the organisation’s reputation and external messaging.

What is the difference between Annex A 5.26 and 5.24?

Annex A 5.24 focuses on the “planning and preparation” of incident management (strategy and roles), whereas Annex A 5.26 focuses on the actual “execution and response” when an incident occurs. Annex A 5.26 is the operational implementation of the plans created in 5.24, focusing on active triage, containment, and system restoration activities.

How does the EU AI Act impact Annex A 5.26?

The EU AI Act introduces a strict 15-day reporting window for “serious incidents” involving high-risk AI systems. For Annex A 5.26 compliance, your playbooks must specifically address AI-related malfunctions, model poisoning, or prompt injection attacks that could lead to widespread rights breaches or physical harm, as these are now legally classified as critical incidents.

What technical tools are essential for compliance?

Effective response requires a combination of SIEM, SOAR, and forensic preservation tools to achieve a 40% reduction in containment time. Essential tools include SIEM for real-time telemetry, immutable backups for 100% data recovery, Privileged Access Management (PAM) for “Break Glass” accounts, and encrypted out-of-band communication channels for the Incident Response Team.

Should organisations utilise external experts for response?

Yes, if your internal team lacks specialist skills or capacity for a major breach, Annex A 5.26 suggests having pre-vetted external forensic and legal specialists on retainer. External experts provide specialist forensics, 24/7 availability, and independent verification of your recovery efforts, which is often a requirement for cyber insurance and the EU Product Liability Directive.

ISO 27001 controls and attribute values

Control typeInformation security propertiesCybersecurity conceptsOperational capabilitiesSecurity domains
CorrectiveConfidentialityRespondInformation Security Event ManagementDefence
IntegrityRecover
Availability

Stuart Barker

ISO 27001 Ninja

Stuart Barker is a veteran practitioner with over 30 years of experience in systems security and risk management. Holding an MSc in Software and Systems Security, he combines academic rigour with extensive operational experience, including a decade leading Data Governance for General Electric (GE).

As a qualified ISO 27001 Lead Auditor, Stuart possesses distinct insight into the specific evidence standards required by certification bodies. His toolkits represent an auditor-verified methodology designed to minimise operational friction while guaranteeing compliance.

Stuart Barker - High Table - ISO27001 Director
  • MSc Security
  • ISO 27001 Lead Auditor
  • 30+ Years Exp
  • Ex-GE Leader
Shopping Basket
Scroll to Top