ISO 27001 Annex A 5.26 Response to Information Security Incidents is a security control that mandates the operational execution of documented response procedures. Implementing this ensures that organisations can efficiently contain threats and recover services, thereby maintaining legal compliance and protecting reputation during a critical cybersecurity breach.
In this guide, I will show you exactly how to implement ISO 27001 Annex A 5.26 and ensure you pass your audit. You will get a complete walkthrough of the control, practical implementation examples, and access to the ISO 27001 templates and toolkit that make compliance easy.
I am Stuart Barker, an ISO 27001 Lead Auditor with over 30 years of experience conducting hundreds of audits. I will cut through the jargon to show you exactly what changed in the 2022 update and provide you with plain-English advice to get you certified.
Key Takeaways: ISO 27001 Annex A 5.26 Response to Information Security Incidents
ISO 27001 Annex A 5.26 requires organizations to respond to information security incidents in accordance with documented procedures. While previous controls (A.5.24 and A.5.25) cover the planning and assessment, this control is about the operational execution of your response. It is a corrective control designed to ensure that once an incident is confirmed, your team acts efficiently to contain the threat, recover services, and meet legal obligations (such as the 72-hour GDPR notification rule).
Core requirements for compliance include:
- Documented Response Procedures: You must have clear, step-by-step instructions (often called Playbooks) for different types of incidents, such as ransomware, lost devices, or unauthorized data access.
- Team Competency: The designated response team must have the technical skills and authority to act. This includes the power to take systems offline or disconnect networks during a crisis.
- Containment & Eradication: The immediate goal of the response is to stop the incident from spreading (Containment) and then remove the root cause, such as malware or an exploited vulnerability (Eradication).
- Evidence Collection: During the response, you must collect and preserve evidence (logs, memory dumps, or physical hardware). This is critical if the incident leads to legal action or insurance claims.
- Legal & Regulatory Communication: You must have a process for notifying external parties. For data breaches involving personal data, this often requires notifying a regulator (like the ICO) within a strict legal timeframe.
- Formal Closure: Every incident must be officially “Closed” only after the recovery is complete and a summary report has been created.
Audit Focus: Auditors will look for “The Execution Evidence”:
- Response Timestamps: “Show me the logs for your last major incident. How much time passed between the ‘Decision’ to categorize it (A.5.25) and the start of ‘Containment’?”
- Playbook Accuracy: “Show me your ransomware playbook. Can you prove that the team followed these specific steps during your last malware event?”
- Communication Logs: “If you had a data breach last year, show me the record of your notification to the regulator. Did you meet the mandatory deadline?”
Response Lifecycle Table (Audit Prep):
| Phase | Core Action Required | Primary Goal | ISO 27001:2022 Control |
|---|---|---|---|
| 1. Containment | Isolate infected systems (disconnect). | “Stop the bleeding.” | Annex A 5.26 |
| 2. Eradication | Remove malware / Patch the flaw. | “Clean the wound.” | Annex A 5.26 / 8.8 |
| 3. Recovery | Restore from backup / Restart services. | Get back to work. | Annex A 5.26 / 8.13 |
| 4. Communication | Notify Subjects / Regulators. | Legal Compliance. | Annex A 5.26 / 5.18 |
Table of contents
- What is ISO 27001 Annex A 5.26?
- Watch the ISO 27001 Annex A 5.26 Tutorial
- ISO 27001 Annex A 5.26 Podcast
- ISO 27001 Annex A 5.26 Implementation Guidance
- How to implement ISO 27001 Annex A 5.26
- Response Lifecycle Table
- How to comply
- How to audit ISO 27001 Annex A 5.26
- How to pass an ISO 27001 Annex A 5.26 audit
- What the audit will check
- Top 3 ISO 27001 Annex A 5.26 Mistakes People Make and How to Avoid Them
- Why is ISO 27001 Response to Information Security Incidents Important?
- Applicability of ISO 27001 Annex A 5.26 across different business models.
- Fast Track ISO 27001 Annex A 5.26 Compliance with the ISO 27001 Toolkit
- ISO 27001 Annex A 5.26 Applicable Laws and Related Standards
- ISO 27001 Annex A 5.26 FAQ
- Related ISO 27001 Controls
- Further Reading
- ISO 27001 controls and attribute values
DO IT YOURSELF ISO 27001
All the templates, tools, support and knowledge you need to do it yourself.
What is ISO 27001 Annex A 5.26?
ISO 27001 Annex 5.26 is about your response to information security incidents which means you need a documented process for what you will do.
ISO 27001 Annex A 5.26 Response to information security incidents is an ISO 27001 control that requires an organisation to respond to information security incidents based on documented procedures.
ISO 27001 Annex A 5.26 Purpose
The purpose of ISO 2701 Annex A 5.26 is a corrective control that ensures efficient and effective response to information security incidents.
ISO 27001 Annex A 5.26 Definition
ISO 27001 defines Annex A 5.26 as:
Information security incidents should be responded to in accordance with the documented procedures.
ISO 27001:2022 Annex A 5.26 Response to information security incidents
Watch the ISO 27001 Annex A 5.26 Tutorial
In this tutorial video I show you how to implement ISO 27001 Annex A 5.26 and how to pass the audit.
ISO 27001 Annex A 5.26 Podcast
In this episode: Lead Auditor Stuart Barker and team do a deep dive into the ISO 27001 Annex A 5.26 Response To Information Security Incidents. The podcast explores what it is, why it is important and the path to compliance.
ISO 27001 Annex A 5.26 Implementation Guidance
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 should the incident response process 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:
- Identification: identifying the information security incident
- Assessment: assessing and prioritising the information security incident
- 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.
I’ve sat in the Auditor’s chair for 30 years. Use the exact system and tools I use to guarantee a pass.
Response Lifecycle Table
| Phase | Action | Goal |
| 1. Containment | Isolate infected server (disconnect network). | Stop the bleeding. |
| 2. Eradication | Remove malware / Close vulnerability. | Clean the wound. |
| 3. Recovery | Restore from backup / Restart services. | Get back to work. |
| 4. Communication | Notify Data Subject / Regulator (72h rule). | Legal compliance. |
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:
- Document your information security incident response process
- Assign and document the roles and responsibilities involved in the information response process
- Communicate the incident response processes that those that need to know about it
- Implement appropriate controls to mitigate, monitor and report on information security incidents
- Monitor and review the information security incident response effectiveness
The Tools We Use.
100% Audit Success. Zero AI Guesswork.
How to audit ISO 27001 Annex A 5.26
Auditing your incident response capability is a critical safeguard for business continuity: it ensures that when a breach occurs, your team acts with precision rather than panic. This guide provides a technical roadmap for Lead Auditors to verify that Annex A 5.26 is fully operational within the organisation.
1. Formalise the Information Security Incident Management Policy
Review the overarching policy to ensure it defines what constitutes an incident versus an event. Result: Establishes a clear legal and operational baseline for all security activities.
- Verify the document version control and senior management approval.
- Check for alignment with the internal Risk Management Framework.
- Ensure the policy is accessible to all employees via the company intranet.
2. Provision Incident Management Roles and IAM Permissions
Audit the Incident Response Team (IRT) structure and verify that specific IAM roles are pre-configured for emergency access. Result: Enables immediate action without administrative delays during a crisis.
- Inspect the “Rules of Engagement” (ROE) documents for third-party responders.
- Confirm that MFA is mandated for all privileged incident response accounts.
- Review the skills matrix to ensure technical staff are trained in forensic preservation.
3. Deploy Automated Detection and Reporting Channels
Examine the technical integration between your SIEM, SOC, and internal reporting tools. Result: Reduces the “Mean Time to Detect” (MTTD) by automating the initial alert phase.
- Test the “Report Phishing” or “Report Incident” buttons within the mail client.
- Audit log aggregation settings to ensure critical assets are sending telemetry.
- Verify that out-of-band communication channels (e.g., encrypted messaging) are established.
4. Classify Incident Severity and Triage Procedures
Evaluate the criteria used to categorise incidents by impact and urgency. Result: Ensures resources are allocated proportionally to the level of risk.
- Review the “Incident Classification Matrix” for consistency across different departments.
- Check that “High” severity triggers an automatic escalation to the CISO.
- Verify that the triage process accounts for data sensitivity as defined in the Asset Register.
5. Execute Technical Containment Playbooks
Sample recent incident logs to verify that containment steps were followed according to pre-defined playbooks. Result: Prevents the lateral movement of threats and limits data exfiltration.
- Inspect playbooks for specific scenarios: Ransomware, DDoS, and Model Poisoning for AI.
- Verify that network isolation procedures (VLAN tagging or port shutdown) are tested.
- Confirm that “Forensic Integrity” is maintained before systems are wiped or restored.
6. Trigger Mandatory Regulatory and Legal Notifications
Audit the workflow for notifying authorities such as the ICO (UK) or relevant EU regulators within 72 hours. Result: Maintains legal compliance and avoids heavy statutory fines.
- Check the reporting templates for GDPR, NIS2, and DORA requirements.
- Verify that “CIRCIA” timelines are understood if operating in US critical sectors.
- Ensure the Legal and PR departments are integrated into the escalation path.
7. Conduct Eradication and Forensic System Recovery
Verify that systems are only returned to production after a confirmed “clean” state is achieved. Result: Eliminates the risk of reinfection from dormant backdoors.
- Audit the backup restoration logs to ensure “Immutable Backups” were utilised.
- Confirm that vulnerability scans are performed on recovered assets before they go live.
- Check that local admin passwords and service account keys were rotated post-incident.
8. Review Post-Incident Lessons Learnt and Root Causes
Inspect the “Post-Incident Report” (PIR) for the most recent major incident to identify systemic failures. Result: Drives continuous improvement and prevents incident recurrence.
- Ensure the “Root Cause Analysis” (RCA) led to a specific change in technical controls.
- Verify that the PIR was shared with relevant stakeholders within 30 days.
- Check for a “No-Blame” culture that encourages honest reporting of human error.
9. Synchronise the Asset Register and Risk Assessment
Ensure that incident data is used to update the organisational risk profile and asset criticality. Result: Provides an accurate, data-driven view of the current threat landscape.
- Cross-reference the incident log with the Asset Register to see if new “Shadow IT” was discovered.
- Verify that risk scores for compromised assets were recalculated.
- Check that technical debt identified during the response is added to the remediation backlog.
10. Audit Response Effectiveness via Simulation and Testing
Verify the frequency and quality of “Tabletop Exercises” or “Red Team” simulations. Result: Confirms that response procedures work in practice, not just on paper.
- Review the results of the most recent annual “Simulated Breach” exercise.
- Verify that third-party vendors (MSPs) participated in the joint response testing.
- Check that the “Incident Management Plan” was updated based on simulation findings.
How to pass an ISO 27001 Annex A 5.26 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.
- Have a documented information security incident management plan.
- Implement the information security incident management plan.
- Monitor the effectiveness of the information security incident management plan.
- 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 ISO 27001 Annex A 5.26 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.
Why is ISO 27001 Response to Information Security Incidents Important?
As the saying goes, shit happens. It is facts of life. No system or security is 100% We cannot be on the back foot when the inevitable happens and effective incident management can eliminate or reduce the impact of information security incidents.
ISO 27001 Annex A 5.26 Response to information security incidents is important because it provides guidance on how to manage information security incidents. Information security incidents can have a significant impact on an organisation, so it is important to have a plan in place for how to respond to them. The guidance in ISO 27001 Annex A 5.26 can help you to develop and implement an effective information security incident response plan.
The following are some of the benefits of having an effective information security incident response plan:
- It can help to reduce the impact of information security incidents.
- It can help to protect the organisations reputation.
- It can help to comply with legal and regulatory requirements.
- It can help to improve the organisations overall information security posture.
Applicability of ISO 27001 Annex A 5.26 across different business models.
| Business Type | Applicability | Examples of Control Implementation |
|---|---|---|
| Small Businesses | Highly applicable for ensuring that the team acts effectively during a crisis. The focus is on clear, simple instructions that guide the small staff through containment and recovery without needing a dedicated security department. |
|
| Tech Startups | Critical for startups with complex cloud infrastructures and strict customer SLAs. Compliance involves technical playbooks that automate containment and ensure that “Eradication” doesn’t destroy forensic evidence. |
|
| AI Companies | Vital for protecting unique AI assets and proprietary research data. Focus is on specialized response protocols for adversarial attacks on models or unauthorized exfiltration of large training datasets. |
|
Fast Track ISO 27001 Annex A 5.26 Compliance with the ISO 27001 Toolkit
For ISO 27001 Annex A 5.26 (Response to information security incidents), the requirement is to respond to incidents according to documented procedures. This is a corrective control that ensures your response is efficient and effective, minimising damage through containment, eradication, and recovery.
| Compliance Factor | SaaS Compliance Platforms | High Table ISO 27001 Toolkit | Audit Evidence Example |
|---|---|---|---|
| Strategy Ownership | Rents access to your emergency plans; if you cancel the subscription, your documented response standards and history vanish. | Permanent Assets: Fully editable Word/Excel Incident Response Plans and Lifecycle Tables that you own forever. | A localized “Incident Response Plan” stored on your secure server defining containment steps for a malware outbreak. |
| Response Governance | Attempts to “automate” crisis management via dashboards that cannot physically isolate servers or verify legal reporting windows. | Governance-First: Formalizes your existing technical workflows (Restore, Patch, Notify) into an auditor-ready framework. | A completed “Incident Response Lifecycle Table” proving that containment and recovery were achieved within target timeframes. |
| Cost Efficiency | Charges an “Incident Volume Tax” based on the number of breach logs or active responders, creating perpetual overhead. | One-Off Fee: A single payment covers your response governance for 2 incidents a year or 200. | Allocating budget to advanced forensics tools or SOC services rather than monthly “response” dashboard fees. |
| Crisis Strategy Freedom | Mandates rigid reporting formats that may conflict with your unique technical stack or 72-hour regulatory reporting windows. | 100% Agnostic: Procedures adapt to any environment—dedicated SOCs, lean IT teams, or specialized legal counsel. | The ability to evolve your crisis strategy and notification procedures without reconfiguring a rigid SaaS compliance module. |
Summary: For Annex A 5.26, the auditor wants to see that you have a formal process for responding to incidents and proof that you follow it (e.g., incident logs and evidence of containment). The High Table ISO 27001 Toolkit provides the governance framework to satisfy this requirement immediately. It is the most direct, cost-effective way to achieve compliance using permanent documentation that you own and control.
ISO 27001 Annex A 5.26 Applicable Laws and Related Standards
| Standard / Law | Relevant Control / Article | Mapping & Requirements |
|---|---|---|
| NIST CSF v2.0 | PR.IR-P1, PR.IR-P2, RS.MA-01 | Focuses on the creation and execution of incident response playbooks and maintaining response integrity. |
| NIST SP 800-61 | Incident Response Life Cycle | Provides the operational framework for detection, containment, and eradication required by ISO 5.26. |
| SOC 2 (Trust Services Criteria) | CC7.3, CC7.4, CC7.5 | Requires procedures to identify and respond to incidents, including technical containment and system recovery. |
| EU GDPR | Articles 33 & 34 | ISO 5.26 triggers the 72-hour regulatory notification and communication to affected data subjects. |
| UK Data (Use and Access) Act 2025 | Complaints & Emergency Interest | Maintains 72h rule; adds 30-day mandatory response to security complaints and allows processing for “emergency interest.” |
| NIS2 Directive (EU) | Articles 21 & 23 | Mandates incident handling for essential/important entities with a 24-hour “Early Warning” requirement. |
| UK Cyber Security and Resilience Bill | MSPs & 24h Reporting | Extends reporting duties to Managed Service Providers (MSPs) with a 24-hour initial notification window. |
| DORA (Digital Operational Resilience Act) | Articles 17, 18, 19 | Specific to finance; requires same-day initial reporting for “Major ICT-related incidents.” |
| CIRCIA (USA) | 72h / 24h Reporting | Mandatory 72-hour reporting for critical infrastructure; 24-hour reporting if a ransom is paid. |
| EU AI Act | Article 62 | Requires immediate reporting (max 15 days) of “serious incidents” caused by high-risk AI systems. |
| ISO/IEC 42001 (AI Management) | Annex A.10.3 | Maps incident response to AI-specific risks like model poisoning and prompt injection. |
| HIPAA (USA) | 164.308(a)(6) | Requires documented procedures to identify, respond to, and mitigate security incidents involving ePHI. |
| CCPA / CPRA (California) | 1798.82 & 1798.150 | Incident response effectiveness is used as evidence of “reasonable security” to mitigate statutory damages. |
| EU Product Liability Directive (PLD) | Article 4 | Classifies software as a product; failure to effectively respond to known flaws establishes “strict liability.” |
| ECCF (European Cybersecurity Cert) | Assurance Levels | Compliance with ISO 5.26 is a prerequisite for “Substantial” and “High” security labels for ICT products. |
AI Incident Response: The New Frontier for Annex A 5.26
In 2026, if your incident response plan only covers malware and lost laptops, you are going to get a major non-conformity. AI is now a core component of the modern tech stack: and it brings unique incident profiles that require specific, documented response procedures. As a Lead Auditor, I expect to see your organisation addressing the following AI-specific scenarios in your playbooks.
| AI Incident Type | Annex A 5.26 Response Action | Primary Recovery Goal |
|---|---|---|
| Prompt Injection | Immediate suspension of the LLM API and sanitisation of input filters. | Prevent unauthorised data exfiltration via chat interfaces. |
| Model Poisoning | Isolation of the affected model and rollback to the last known “clean” training set. | Maintain the integrity of automated decision-making. |
| Sensitive Data Leakage | Identification of PII in training logs and purging of the model weights. | Compliance with GDPR and the UK Data (Use and Access) Act. |
| AI Hallucination Impact | Formal assessment of output accuracy and notification to affected stakeholders. | Mitigate operational risk and prevent misinformation spread. |
The 2026 Regulatory Landscape: Compliance Deadlines
The rules of the game have changed. Annex A 5.26 is no longer just about ISO 27001: it is the vehicle for meeting strict legal reporting windows. If you miss these, you are not just failing an audit; you are inviting a regulatory fine.
- EU AI Act (2026): Requires “serious incidents” involving high-risk AI systems to be reported within 15 days of becoming aware.
- NIS2 Directive: Mandates an “early warning” notification within 24 hours for essential and important entities.
- UK Data (Use and Access) Act: Continues the 72-hour window but adds specific requirements for reporting “high-risk” processing breaches.
- DORA: Financial organisations must provide an initial report on major ICT-related incidents within the same business day.
Operational KPIs: Measuring Response Effectiveness
Auditors love data. If you cannot measure your response, you cannot improve it. To satisfy the “improvement” requirement of ISO 27001, you should track these four key metrics for every incident.
| Metric | Definition | Lead Auditor’s Target |
|---|---|---|
| MTTD | Mean Time to Detect (from occurrence to identification). | Reduction year-on-year via improved logging (Annex A 8.15). |
| MTTR | Mean Time to Respond (from identification to containment). | Minutes for high-severity; hours for medium-severity. |
| FDR | False Discovery Rate (percentage of events that were not incidents). | Below 15 percent to avoid “alert fatigue” in the team. |
| PIR Completion | Time taken to complete the Post-Incident Review. | 100 percent completion within 5 business days of closure. |
The Human Factor: No-Blame Culture in 5.26
As an auditor, I look at the culture of your Incident Response Team. If your team is afraid of making a mistake, they will hide incidents. This is a massive risk. A compliant Annex A 5.26 process must foster a “No-Blame” culture. This means focusing on the “Why” and the “How” of the system failure, rather than the “Who” of the human error.
- Psychological Safety: Encourage staff to flag “near misses” without fear of disciplinary action.
- Constructive PIRs: Ensure Post-Incident Reviews focus on control gaps and technical improvements.
- Competency Training: Move beyond basic awareness: run regular tabletop exercises that include “stress tests” for the responders.
Technical Tooling for 2026: Automation and AI
Manual response is too slow for 2026. To be truly “Skyscraper” compliant, you should be leveraging automation. This is what we call “fighting AI with AI.” Your Annex A 5.26 procedures should document how these tools are integrated into your workflow.
- SOAR (Security Orchestration, Automation, and Response): Use scripts to automatically isolate infected servers or revoke compromised API keys.
- XDR (Extended Detection and Response): Provide a unified view of threats across email, cloud, and network to reduce detection time.
- Immutable Backups: Ensure that your “Recovery” phase (Annex A 8.13) is protected against ransomware that targets backup files.
Lead Auditor Final Checklist for Annex A 5.26
Before you call in the auditors, run through this list. If you cannot tick these boxes, you are not ready.
- Do you have a specific playbook for AI-related data leaks or model poisoning?
- Can you show evidence of a “near miss” being reported and assessed?
- Is your notification process aligned with the 24-hour window for NIS2 (if applicable)?
- Do your PIR reports lead to actual changes in your Risk Register?
- Has the Incident Response Team been tested with a live simulation in the last 6 months?
Forensic Integrity: Preserving the Chain of Custody
If an incident leads to legal action or a massive insurance claim, your “response” is worthless if you have tainted the evidence. Most IT teams instinctively fix the problem but destroy the proof in the process. For ISO 27001 Annex A 5.26, you must document how you preserve digital evidence.
| Forensic Step | The “Wrong” Way (Audit Fail) | The “Barker” Way (Audit Pass) |
|---|---|---|
| System Access | Logging in with a standard admin account to “check things out.” | Using a “Write-Blocker” or forensic image tool to capture the state without alteration. |
| Data Capture | Copying and pasting suspicious files to a USB stick. | Generating MD5 or SHA-256 hashes for every captured file to prove integrity. |
| Volatile Memory | Rebooting the server to “clear the glitch.” | Performing a RAM dump before power-cycling to capture active malware in memory. |
| Documentation | Notes scribbled on a notepad or kept in a Slack thread. | A formal “Chain of Custody” log detailing who handled the evidence and when. |
The Supply Chain Nightmare: Third-Party Incident Integration
In 2026, your biggest risk is likely a SaaS provider or an AI vendor being compromised. Your Annex A 5.26 procedures must explicitly state how you handle incidents that occur outside your perimeter but impact your data.
- SLA Alignment: Do your vendor contracts mandate they notify you within 4, 12, or 24 hours? Your response is bottlenecked by their transparency.
- Joint Exercises: I want to see that you have run at least one tabletop exercise that includes your primary Managed Service Provider (MSP) or Cloud provider.
- Data Portability: If a vendor is breached and goes offline, does your 5.26 recovery plan include moving to a secondary provider or “Air-Gapped” backup?
Crisis Communication Matrix: Beyond the Regulator
You have 72 hours for the ICO, but you have 72 seconds for Twitter and LinkedIn. A failed communication strategy can destroy more value than the breach itself. Your response procedure must include a pre-approved communication matrix.
| Stakeholder Group | Communication Channel | Owner | Timeline |
|---|---|---|---|
| Employees | Internal All-Hands / Intranet | CEO / HR | Within 4 hours of confirmation. |
| Key Clients | Direct Phone Calls / Account Manager | Head of Sales | Before any public statement. |
| General Public | Company Website / Social Media | PR / Marketing | Post-containment phase. |
| Insurance Providers | Dedicated Claims Portal | Legal / Finance | Immediate (to trigger forensic support). |
Budgeting and Resource Allocation for Incident Response
Auditors check Clause 7.1 (Resources) alongside Annex A 5.26. If you have a plan but no budget for forensic tools or a retainer for a Cyber Incident Response Team (CIRT), your plan is a “Paper Tiger.” You must demonstrate that the board has allocated the necessary funds to make the response effective.
- Forensic Retainers: Having a “pre-vetted” expert on a 4 hour SLA.
- Cyber Insurance: Ensuring your policy covers the specific costs of ransomware negotiation and data restoration.
- Technical Debt: Allocating budget to fix the “Root Cause” identified in your Post-Incident Reviews.
Testing the Untestable: AI Red Teaming for IR
Traditional “fire drills” are too simple for 2026. To be truly exhaustive, your testing regime must include “Adversarial AI” simulations. This means testing how your SOC and IRT respond to AI-generated phishing, automated credential stuffing, or model-based attacks.
- Deepfake Simulations: Testing your “Response to Financial Fraud” when a voice or video call appears to be from the CEO.
- Automated Triage Testing: Deliberately flooding your SIEM with AI-generated noise to see if your triage process (5.25/5.26) can find the real “needle in the haystack.”
The Auditor’s Shopping List: Evidence for Annex A 5.26
When I turn up for your Stage 2 audit, I am going to ask for these five things. Have them ready in a folder named “Annex A 5.26 Evidence.”
- The Master Incident Register: A list of every event, including “Near Misses” and “False Positives.”
- The Triage Decision Log: Evidence of how you moved from 5.25 (Assessment) to 5.26 (Response).
- A Sample PIR (Post-Incident Review): I want to see a report that shows you found a flaw and fixed it.
- Forensic Chain of Custody Forms: Even if they are blank, I want to see the template you would use to preserve evidence.
- Tabletop Exercise Minutes: A summary of your last simulation, including the “Lessons Learnt” and the attendance list.
People Also Asked: ISO 27001 Incident Response
How long should I keep incident logs for ISO 27001?
I recommend keeping detailed incident logs for at least 3 years. This aligns with most legal limitation periods and allows you to track long-term trends for the Management Review (Clause 9.3).
Do we need to report an incident if no data was lost?
ISO 27001 requires you to respond to all security incidents. If it impacted Confidentiality, Integrity, or Availability, it is an incident. You might not have to report it to the ICO, but you must record it internally to satisfy the auditor.
What is the most common reason for failing an Annex A 5.26 audit?
Lack of evidence. Companies have great conversations during a crisis but forget to log the timestamps and decisions. If it isn’t written down, it didn’t happen.
ISO 27001 Annex A 5.26 FAQ
Understanding the operational execution of ISO 27001 Annex A 5.26 is paramount for maintaining cyber resilience. This FAQ section provides a technical deep dive into the mandatory requirements, regulatory timelines, and audit expectations for incident response.
What is ISO 27001 Annex A 5.26?
ISO 27001 Annex A 5.26 is a reactive security control that mandates organisations establish and implement a formalised procedure for responding to information security incidents. It requires a documented Incident Response Plan (IRP), rapid containment, and clear communication paths to ensure 100% of detected breaches are investigated and remediated to minimise disruption.
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.
How do you evidence Annex A 5.26 for an ISO 27001 audit?
Auditors verify compliance by reviewing documented incident response plans and examining “post-mortem” reports from actual or simulated incidents. Evidence includes detailed incident logs, proof of technical actions taken such as server isolation or firewall changes, and communication records for notifications sent to regulators, law enforcement, or affected data subjects.
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.
Related ISO 27001 Controls
ISO 27001 Clause 8.1 Operational Planning and Control
ISO 27001 Annex A 5.25 Assessment And Decision On Information Security Events
ISO 27001 Annex A 5.24 Information Security Incident Management Planning and Preparation
Further Reading
The complete guide to ISO/IEC 27002:2022
The Top 5 Ways AI is Changing ISO 27001
ISO 27001 controls and attribute values
| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains |
| Corrective | Confidentiality | Respond | Information Security Event Management | Defence |
| Integrity | Recover | |||
| Availability |
About the author
