ISO 27001 Annex A 5.24 is a security control that mandates the formal planning and preparation for information security incident management. By establishing predefined response processes and roles, organizations ensure a rapid and consistent recovery from breaches, minimizing operational disruption and fulfilling mandatory data protection reporting requirements.
In this guide, I will show you exactly how to implement ISO 27001 Annex A 5.24 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.24 Incident Management Planning and Preparation
ISO 27001 Annex A 5.24 requires organizations to plan and prepare for managing information security incidents by defining, establishing, and communicating incident management processes, roles, and responsibilities. As the saying goes, “security is not 100%,” and incidents are inevitable. This corrective control ensures that when a breach occurs, your response is quick, effective, consistent, and orderly. Proper preparation minimizes damage, ensures legal compliance (e.g., GDPR reporting), and protects your organization’s reputation.
Core requirements for compliance include:
- Incident Management Process: You must have a documented process covering detection, prioritization, triage, analysis, communication, and coordination of incidents.
- Defined Roles & Responsibilities: You must establish an Incident Response Team (IRT) with clearly allocated roles. These roles must be communicated across the organization so everyone knows who to contact during a crisis.
- Reporting Procedures: There must be a common, well-communicated way for employees and third parties to report security events (e.g., a dedicated email address or ticketing system).
- Training & Competency: Personnel handling incidents must be competent and receive periodic training. The standard encourages identifying specific certifications or development paths for the IRT.
- Service Level Objectives: You should define priority levels (e.g., P1 to P4) with specific target response and resolution times agreed upon with management.
- Scenario Planning: Your incident management plan should consider various scenarios, such as data breaches, malware infections, or natural disasters.
Audit Focus: Auditors will look for “The Readiness Evidence”:
- Staff Awareness: An auditor will likely ask any random employee: “If you think your laptop has been hacked or you’ve lost a USB drive, how do you report it?”
- Process Verification: “Show me your Incident Management Plan. When was it last reviewed and approved by management?”
- Role Clarity: “Show me the list of members in your Incident Response Team. Do they have the necessary authority to shut down a service during a major breach?”
Table of contents
- What is ISO 27001 Annex A 5.24?
- Watch the ISO 27001 Annex A 5.24 Tutorial
- ISO 27001 Annex A 5.24 Podcast
- ISO 27001 Annex A 5.24 Implementation Guidance
- How to implement ISO 27001 Annex A 5.24
- IRT Roles Table
- How to comply
- How to Audit ISO 27001 Annex A 5.24
- How to pass an ISO 27001 Annex A 5.24 audit
- What an auditor will check
- Top 3 ISO 27001 Annex A 5.24 Mistakes People Make and How to Avoid Them
- Applicability of ISO 27001 Annex A 5.24 across different business models.
- Fast Track ISO 27001 Annex A 5.24 Compliance with the ISO 27001 Toolkit
- ISO 27001 Annex A 5.24 Applicable Laws and Related Standards
- ISO 27001 Annex A 5.24 FAQ
- Related ISO 27001 Controls and Further Reading
- ISO 27001 controls and attribute values
Stop Guessing. Start Passing.
AI-generated policies are generic and fail audits. Our Lead-Auditor templates have a 100% success rate. Don’t risk your certification on a prompt
What is ISO 27001 Annex A 5.24?
ISO 27001 Annex A 5.24 is about information security incident management planning and preparation which means you must have a process and people to handle and manage information security incidents.
ISO 27001 Annex A 5.24 Information security incident management planning and preparation is an ISO 27001 control that requires an organisation to plan and prepare for managing information security incidents.
ISO 27001 Annex A 5.24 Purpose
The purpose of ISO 27001 Annex A 5.24 is a corrective control that ensures quick, effective, consistent and orderly response to information security incidents, including communication on information security events.
ISO 27001 Annex A 5.24 Definition
The ISO 27001 standard defines ISO 27001 Annex A 5.24 as:
The organization should plan and prepare for managing information security incidents by defining, establishing and communicating information security incident management processes, roles and responsibilities.
ISO 27001:2022 Annex A 5.24 Information security incident management planning and preparation
Watch the ISO 27001 Annex A 5.24 Tutorial
In the video ISO 27001 Information Security Incident Management Planning and Preparation Explained I show you how to implement it and how to pass the audit.
ISO 27001 Annex A 5.24 Podcast
In this episode: Lead Auditor Stuart Barker and team do a deep dive into the ISO 27001 Annex A 5.24 Information Security Incident Management Planning and Preparation. The podcast explores what it is, why it is important and the path to compliance.
ISO 27001 Annex A 5.24 Implementation Guidance
Roles and Responsibilities
You are going to work out the roles and responsibilities for the incident management processes and procedures that you are going to write and implement. Those roles and responsibilities are going to be communicated.
Usually you communicate reasonably frequently, say once every 3 months, how to raise an incident and who is responsible for information security in the organisation. Depending how complex the team is and how complex the organisation is you may have to do some additional targeted communications.
Ideally we want a common way to report information security incidents and have a point of contact.
The process of incident management is well documented elsewhere but the process is going to be cover documentation, how we detect incidents, how we prioritise them, if relevant how we triage the incidents, how we analyse incidents, how and to whom we communicate them and how we co-ordinate interested parties.
The standard wants us, rightly, to provide the capability to assess, respond and learn from security incidents. We won’t get things right all the time. Incidents will happen. As long as we plan and are prepared and can respond effectively we will be fine.
When it comes to the who, we are going to make sure that only competent personnel handle issues. Usually this means that they are subject matter experts and or trained in their field. These people will be communicated to and provided the process and procedure documents and will be given periodic training in information security.
As an add in, the standard wants us to consider identifying the training, certification and ongoing development of the incident response assigned people. A great way to do this is via the competency matrix.
Incident Management Procedures
The incident management processes and procedures you write will have priorities and service level’s agreed with management based on agreed objectives for information security incident management. Consider implementing priority levels with definitions of what each priority means and the expected time to resolve an incident at that level.
The incident management plan will consider different scenarios.
If we were to set out the activities that require process and procedure we would include
- Evaluation: The evaluation of incidents and understanding which incidents are information security incidents.
- Monitoring: The human and automated ability to detect, classify, analyse and report events and incidents.
- Managing: The management of incidents that includes response and escalation and knowing when to invoke crisis management and business continuity.
- Coordinating: The coordination of internal and external interested parties and resources
- Logging: The logging of incidents and associated activity.
- Handling of evidence: The handling of evidence and the potential to get specialist help where that evidence may lead to legal action.
- Root Cause Analysis: The ability to get to the root, the core, of what happened and why it happened.
- Lessons Learned: The ability to learn lessons and make improvements to reduce or eliminate it from happening again.
Reporting Procedures
We need to ability to effectively report on incidents and consider the types of reports that we will create.
We include how to report an incident, the use of incident forms and the creating of incident reports.
External reporting requirements and time frames are considered. A good example is reporting data breaches that come under the GDPR to the supervisory body.
The standard that relates to information security management for further reading if required is ISO/IEC 27035
How to implement ISO 27001 Annex A 5.24
Implementing Annex A 5.24 requires a structured approach to ensure that your organisation is not just reactive, but prepared to handle security events with precision and speed. Use the following ten steps to formalise your incident management planning and preparation.
1. Formalise the Incident Management Policy
- Define the scope, objectives, and importance of incident management across the entire organisation.
- Ensure the policy is approved by senior management and aligned with the overarching Information Security Management System (ISMS).
- Document the specific triggers that escalate a security event into a formal incident.
2. Appoint and Train the Incident Response Team (IRT)
- Identify internal stakeholders from IT, Legal, HR, and Communications to form a cross-functional response unit.
- Assign clear roles and responsibilities, including a designated Incident Commander to lead all response efforts.
- Provision specialised training for team members on technical forensics, evidence handling, and crisis communication.
3. Establish Incident Classification and Severity Levels
- Create a severity matrix (e.g., Low, Medium, High, Critical) based on the impact on business continuity and data confidentiality.
- Define specific criteria for each level, such as the volume of compromised records or the downtime of critical services.
- Map these levels to required response times to ensure high-priority incidents receive immediate attention.
4. Deploy Centralised Reporting Channels
- Establish clear, accessible reporting mechanisms, such as a dedicated email address, internal portal, or automated SIEM alerts.
- Encourage a culture of “see something, say something” by providing anonymous reporting options where appropriate.
- Ensure all employees and contractors know how to report a suspected incident immediately.
5. Integrate Monitoring and Detection Tools
- Configure Security Information and Event Management (SIEM) systems to aggregate logs from firewalls, servers, and cloud environments.
- Enable automated alerting for suspicious activities, such as brute-force attacks or unauthorised access to PII.
- Maintain an accurate Asset Register to ensure that monitoring covers all hardware and software within the scope of the ISMS.
6. Secure Response Tools with MFA and IAM
- Restrict access to incident management platforms and forensic tools using the principle of least privilege.
- Enforce Multi-Factor Authentication (MFA) for all administrative accounts associated with the Incident Response Team.
- Audit Identity and Access Management (IAM) roles quarterly to revoke access for staff who have changed roles or left the company.
7. Document Forensic Readiness and Evidence Handling
- Establish a formal Chain of Custody process to ensure digital evidence remains admissible in legal proceedings.
- Create “Rules of Engagement” (ROE) documents that outline how and when to perform data imaging or volatile memory captures.
- Provide secure, encrypted storage for all logs and evidence collected during an investigation.
8. Formalise Internal and External Communication Plans
- Identify external parties that may require notification, including regulatory bodies, law enforcement, and affected customers.
- Draft communication templates to ensure consistent messaging and to avoid the accidental disclosure of sensitive details.
- Define the specific timelines for regulatory reporting, such as the 72-hour window required by GDPR where applicable.
9. Deliver Organisation-Wide Awareness Training
- Conduct regular security awareness sessions to help staff recognise social engineering, phishing, and physical security threats.
- Update training materials to reflect the latest threat landscape and specific organisational risks.
- Verify training completion through quizzes or simulation tests to ensure the reporting procedure is understood.
10. Schedule and Execute Simulation Exercises
- Perform annual “tabletop” exercises where the IRT walks through a hypothetical breach scenario to test the plan.
- Conduct technical red-teaming or simulated phishing drills to validate the effectiveness of detection controls.
- Document “Lessons Learned” from every exercise to update the incident plan and improve future response capabilities.
IRT Roles Table
| Role | Responsibility | Who (Example) | ISO 27001:2022 Control |
|---|---|---|---|
| Incident Manager | Leads the response; makes the “shutdown” call. | CISO / IT Director. | Annex A 5.24 |
| Lead Investigator | Technical forensics; log analysis. | Senior SysAdmin. | Annex A 5.24 / 5.28 |
| Scribe | Documents every action taken (for legal evidence). | Junior Admin / Ops. | Annex A 5.24 / 5.28 |
| Communications | Talks to customers, press, and regulators (GDPR). | Marketing / Legal. | Annex A 5.24 / 5.3 |
| HR Rep | Handles internal disciplinary issues (if insider threat). | HR Manager. | Annex A 5.24 / 6.4 |
I’ve sat in the Auditor’s chair for 20 years. These are the exact tools I use to guarantee a pass.
How to comply
To comply with ISO 27001 Annex A 5.24 you are going to implement the ‘how’ to the ‘what’ the control is expecting. In short measure you are going to:
- Define and allocate roles and responsibilities
- Write and implement your incident management processes and procedures
- Communicate incident management to interested parties
How to Audit ISO 27001 Annex A 5.24
As an ISO 27001 Lead Auditor, I perform a deep dive into Annex A 5.24 to ensure the organisation is not merely documenting a process, but is technically and operationally prepared to respond to threats. The objective is to verify that the planning phase facilitates a rapid, coordinated, and effective response to security incidents. Follow these ten audit steps to validate your incident management readiness against the international standard.
1. Verify the Incident Management Policy Documentation
- Inspect the formal Information Security Incident Management Policy to ensure it has been reviewed and approved by senior management within the last 12 months.
- Confirm that the policy clearly defines what constitutes an incident versus a security event, providing a clear mandate for the response team.
- Check for alignment between this policy and the broader ISMS objectives to ensure consistency in risk appetite.
2. Evaluate Incident Response Team (IRT) Roles and IAM Permissions
- Review the list of nominated Incident Response Team members and their specific technical responsibilities.
- Audit the Identity and Access Management (IAM) roles assigned to IRT members to ensure they have the “Break Glass” or elevated permissions required to perform containment actions.
- Validate that roles are assigned based on the principle of least privilege, ensuring no single user has excessive control outside of an active incident.
3. Audit the Integration of the Asset Register
- Cross-reference the incident management plan with the organisational Asset Register to ensure all critical systems are covered.
- Confirm that asset owners are identified and that their contact details are readily available to the IRT during an escalation.
- Verify that the criticality of assets is used to determine incident priority levels.
4. Test Incident Reporting and Escalation Channels
- Perform a walkthrough of the internal reporting mechanisms, such as dedicated email aliases, service desks, or automated alerting systems.
- Validate that the escalation path is clearly documented, ensuring that high-severity incidents reach the correct decision-makers without delay.
- Confirm that reporting channels are accessible to all employees, contractors, and relevant third parties.
5. Inspect SIEM Configuration and Technical Alerting
- Review the configuration of the Security Information and Event Management (SIEM) tool to ensure it captures logs from all in-scope technical assets.
- Audit the alerting logic to verify that it triggers for high-intent threats, such as multiple failed MFA attempts or unauthorised data egress.
- Confirm that logs are protected against unauthorised modification or deletion to maintain audit trail integrity.
6. Review Multi-Factor Authentication (MFA) for Security Tools
- Verify that Multi-Factor Authentication is strictly enforced for all accounts with access to incident management platforms and forensic software.
- Check for the use of hardware tokens or phishing-resistant MFA for the most sensitive IRT administrative accounts.
- Audit recent access logs to ensure no MFA bypasses have been authorised without a formal, risk-assessed exception.
7. Validate Forensic Readiness and Rules of Engagement (ROE)
- Examine the “Rules of Engagement” (ROE) documents to ensure they provide clear instructions on when to perform live memory captures or disk imaging.
- Confirm that the organisation has access to the necessary forensic tools to preserve digital evidence in a legally defensible manner.
- Verify that a chain of custody procedure is documented and understood by the technical response staff.
8. Analyse External Communication and Regulatory Templates
- Review the pre-drafted communication templates for notifying regulators, law enforcement, and affected data subjects.
- Confirm that the contact list for external stakeholders, such as the ICO or relevant CERTs, is accurate and up to date.
- Verify that the plan includes specific timelines for notification to ensure compliance with legal requirements like GDPR or NIS2.
9. Audit Security Awareness and Incident Reporting Training
- Review employee training records to confirm that all staff have received instruction on how to recognise and report a security incident.
- Inspect the content of the training to ensure it covers common vectors, such as social engineering and physical security breaches.
- Validate that the training is repeated at regular intervals or following significant changes to the threat landscape.
10. Assess Simulation Records and Lessons Learned Outputs
- Examine the reports from the most recent tabletop exercises or simulated red-team attacks to verify that the incident plan was tested.
- Confirm that a “Lessons Learned” session was conducted following each simulation or actual incident.
- Verify that identified weaknesses have been converted into an action plan and tracked through to completion within the ISMS.
How to pass an ISO 27001 Annex A 5.24 audit
To pass an audit of ISO 27001 Annex A 5.24 Information security incident management planning and preparation you are going to make sure that you have followed the steps above in how to comply.
What an auditor 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 management 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.
The Tools We Use.
100% Audit Success. Zero AI Guesswork.
Top 3 ISO 27001 Annex A 5.24 Mistakes People Make and How to Avoid Them
The top 3 Mistakes People Make For ISO 27001 Annex A 5.24 are
1. You didn’t learn your lesson
Not learning and improving is a big mistake. Having your documentation to evidence that you made a corrective action or continual improvement will be key.
2. You didn’t tell people how to raise and incident
The auditor will likely ask everyone they meet, not just you, how to raise an incident. This is bread and butter stuff for them. Everyone being audited as a minimum should know how to raise an incident.
3. Your document and version control is wrong
Keeping your document version control up to date, making sure that version numbers match where used, having a review evidenced in the last 12 months, having documents that have no comments in are all good practices.
Applicability of ISO 27001 Annex A 5.24 across different business models.
| Business Type | Applicability | Examples of Control Implementation |
|---|---|---|
| Small Businesses | Highly applicable for ensuring the business can survive a major breach. The focus is on a simple “who-to-call” list and basic reporting procedures so staff know exactly how to escalate a lost laptop or suspicious email without delay. |
|
| Tech Startups | Critical for managing cloud-based risks and maintaining customer trust. Compliance involves formalizing the Incident Response Team (IRT) and establishing technical “Playbooks” for high-likelihood scenarios like ransomware or API leaks. |
|
| AI Companies | Vital for protecting specialized AI assets and research data. Focus is on planning for adversarial attacks and ensuring “Forensic Readiness” for high-performance computing (HPC) environments. |
|
Fast Track ISO 27001 Annex A 5.24 Compliance with the ISO 27001 Toolkit
For ISO 27001 Annex A 5.24 (Information security incident management planning and preparation), the requirement is to plan and prepare for managing incidents by defining, establishing, and communicating processes, roles, and responsibilities. This ensures a quick, effective, and orderly response when security events inevitably occur.
| Compliance Factor | SaaS Compliance Platforms | High Table ISO 27001 Toolkit | Audit Evidence Example |
|---|---|---|---|
| Strategy Ownership | Rents access to your emergency response strategy; if you cancel the subscription, your documented roles and plans vanish. | Permanent Assets: Fully editable Word/Excel Incident Management Policies and IRT Tables that you own forever. | A localized “Incident Management Policy” defining the criteria for a “Major Incident” vs. a standard security event. |
| Operational Readiness | Attempts to “automate” crisis leadership via dashboards that cannot make critical “shutdown” calls or lead a response team. | Governance-First: Formalizes your existing technical workflows and communication channels into an auditor-ready framework. | A completed “Incident Response Team (IRT) Roles Table” identifying key decision-makers across IT, Legal, and HR. |
| Cost Efficiency | Charges an “Incident Volume Tax” based on the number of breach logs or responders, creating perpetual overhead. | One-Off Fee: A single payment covers your planning governance whether you manage 2 incidents or 2,000. | Allocating budget to cyber-insurance or resilient backup systems rather than monthly “orchestration” dashboard fees. |
| Strategic Freedom | Mandates rigid reporting structures that may not align with your agile business model or unique technical environment. | 100% Agnostic: Procedures adapt to any environment—dedicated SOCs, lean IT teams, or specialized third-party labs. | The ability to evolve your crisis strategy and call-tree procedures without reconfiguring a rigid SaaS compliance module. |
Summary: For Annex A 5.24, the auditor wants to see that you have a formal incident management plan and proof that people know their roles and how to raise an incident. 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.24 Applicable Laws and Related Standards
The following table maps ISO 27001:2022 Annex A 5.24 to global legislative and regulatory frameworks. This mapping ensures that your incident management preparation satisfies multiple jurisdictional requirements simultaneously.
| Framework / Law | Relevant Section / Control | Mapping Context & Implementation Requirement |
|---|---|---|
| NIST CSF 2.0 | PR.IP, RS.RP | Aligns with the “Prepare” and “Respond” functions, necessitating formalised response plans and communication paths. |
| UK Data (Use and Access) Act 2025 | Security & Reporting | The UK’s evolution of GDPR. Requires technical and organisational measures to prepare for and report breaches involving personal data with reduced administrative overhead. |
| Cyber Security and Resilience Bill (UK) | Mandatory Reporting | The UK’s response to NIS2. Mandates documented incident planning and rapid reporting for Managed Service Providers (MSPs) and critical supply chains. |
| EU NIS2 Directive | Article 21 | Mandates incident management as a core risk management measure, including business continuity and crisis management preparation. |
| DORA (Digital Operational Resilience Act) | Articles 17-23 | Specific to the financial sector. Requires high-level preparation for ICT-related incidents, including detailed classification and reporting templates. |
| SOC2 (Trust Services Criteria) | CC7.2, CC7.3 | Focuses on Detection and Response criteria. Preparation must involve active monitoring and documented procedures for managing events. |
| EU AI Act | Article 15 | Requires high-risk AI systems to be resilient against adversarial attacks. Incident plans must cover model poisoning and data exfiltration. |
| ISO/IEC 42001 (AI Management) | Control A.7.4 | Requires incident management planning tailored to unique AI failure modes and security risks across the lifecycle. |
| CIRCIA (USA) | 72-hour Reporting | Mandates that critical infrastructure entities identify and report substantial cyber incidents within a 72-hour window. |
| EU Product Liability Directive (PLD) | Liability for Flaws | Extends liability to software providers. Incident preparation serves as a legal defence to prove state-of-the-art security was maintained. |
| ECCF (European Cybersecurity Cert.) | Substantial/High Levels | Organisations must prove incident planning meets harmonised technical standards to achieve EU-wide security labels. |
| HIPAA (USA) | §164.308(a)(6) | Requires specific incident procedures for identifying, responding to, and documenting breaches involving PHI. |
| CCPA / CPRA (California) | Section 1798.100 | Focuses on the duty to implement reasonable security. Preparation is the primary benchmark for avoiding statutory damages in data breaches. |
| GDPR (EU) | Article 32, Article 33 | Vital for meeting the 72-hour notification requirement for breaches impacting the rights and freedoms of individuals. |
Technical Incident Response Playbooks
While the ISO 27001:2022 standard asks for “Scenario Planning,” a skyscraper-level guide must provide the actual technical playbooks. A playbook is a step-by-step technical instruction for a specific threat vector. In 2026, you cannot rely on a generic plan. You need granular playbooks for Ransomware, Account Takeover, and SQL Injection. These documents provide your technical staff with the exact commands to run and the specific systems to isolate. As a Lead Auditor, I look for these because they prove you are not making it up as you go along during a high-pressure crisis. Without playbooks, your “preparation” is just a collection of good intentions.
Out-of-Band (OOB) Communication Protocols
What happens if your primary email server is encrypted or your Slack instance is compromised? If your incident response plan relies on the very systems being attacked, your response will fail. This is the “Out-of-Band” communication protocol gap. You must have a pre-verified, secure way to communicate outside of your corporate network, such as a hardened Signal group or a secondary, air-gapped communication platform. This simple addition separates the professional organisations from the amateurs during a Stage 2 audit. If the network goes dark, your team still needs to be able to talk.
Cyber Insurance Integration and Notification
Your incident management preparation must involve your cyber insurance provider. Most modern insurance policies have strict “Duty to Notify” clauses and “Approved Vendor” lists. If you hire a private forensic firm without checking your policy, you might find your claim is denied and you are left with a six-figure bill. Your Annex A 5.24 preparation should include a “First Call” list that features your insurance broker and a copy of your policy number kept in a physical or offline location. Don’t let a technical win become a financial loss because you ignored the small print.
Supply Chain and Third-Party Breach Preparation
In 2026, the biggest threat to your data isn’t your own network; it is a breach at a critical supplier. You are likely missing the preparation steps for third-party incidents. This requires having direct emergency contact details for your vendors’ security teams on file. You should also establish “Joint Playbooks” for your most critical SaaS or IaaS providers so you know exactly how data will be shared if their environment is the source of the leak. Managing the supply chain is a core part of 5.24 that many people overlook until it is too late.
Differentiating Crisis Management from Incident Response
A technical incident is a server being down; a crisis is your brand being destroyed on the evening news. To be audit-ready, you must explain the “Handover” point. Incident Management handles the tactical technical fix. Crisis Management handles the board, the regulators, and public relations. You need to define the exact trigger point where the Incident Response Team hands over the keys to the Crisis Management Team. If the CEO is trying to fix a database while the Lead Engineer is talking to the press, you have failed the “Roles and Responsibilities” requirement of the standard.
AI and Adversarial Attack Preparation
It is 2026, so you must prepare for AI-specific security incidents. This includes “Prompt Injection” attacks, “Model Poisoning,” or “Inference Data Leaks.” Your preparation phase must include training your Incident Response Team to recognize these new types of non-traditional threats. It is no longer just about malware and phishing. It is about protecting the integrity of your Large Language Models and knowing how to “Roll Back” an AI model to a known good state if it starts hallucinating or leaking proprietary data to unauthorized users.
The Virtual and Physical War Room
When an incident is declared, where does everyone go? You need a “War Room” protocol. This is a pre-established physical or virtual space that is ready to go at a moment’s notice. It should contain the latest hard copies of your network diagrams, asset registers, and incident logs. If it is a virtual room, it must be locked down and only accessible to the Incident Response Team via phishing-resistant Multi-Factor Authentication. If your team is hunting for a Zoom link while a hacker is exfiltrating data, you have already lost the battle.
Automation and SOAR Implementation
Manual response is simply too slow for the threats we face in 2026. You are likely missing the role of Security Orchestration, Automation, and Response (SOAR). To pass a high-maturity audit, you should explain how you “Prepare” your automation. This means pre-authorizing specific automated containment actions, such as automatically disabling a user account or isolating a workstation if it shows signs of a credential leak. Proving to an auditor that you have pre-approved automated guardrails is the gold standard for Annex A 5.24 compliance.
Forensic Preservation and Evidence Training
Most internal IT teams accidentally destroy digital evidence by trying to “Fix” the problem too quickly. You need specific “Forensic Readiness” training for your SysAdmins. They must know how to capture a memory dump or image a drive without breaking the chain of custody. Preparation means having the forensic tools licensed, installed, and ready to use before the breach happens. As an auditor, I want to see that you have the capability to preserve evidence for legal action, not just that you can reboot a server.
Financial Impact and BIA Integration
An incident’s priority should not be a guess; it should be linked to your Business Impact Analysis (BIA). You are missing the connection between your incident severity levels and the financial cost of downtime. If a system costs the business 50,000 pounds per hour in lost revenue, that is a P1 incident by default. Linking your incident preparation to these financial realities makes your ISMS much more valuable to the board and significantly more impressive to an external auditor. It proves you are managing business risk, not just IT tickets.
The Human Element: Psychological Preparation and Burnout Management
In thirty years of auditing, I’ve seen the best incident plans fail because the people behind them collapsed. Major incidents in 2026 aren’t over in an hour; they can last weeks. Your preparation is missing “People Sustainability.” You need to document a rotation schedule for your Incident Response Team to prevent burnout and “Decision Fatigue.” If your Lead Engineer has been awake for 36 hours, they are a security risk, not an asset. An auditor looking for high maturity will want to see that you have planned for “Surge Support”—either through a third-party retainer or internal cross-training—to ensure your response remains sharp during a prolonged crisis.
Legal Privilege and “Discovery” Preparation
If you don’t involve your legal team in the planning phase, your incident logs could become a liability in a future lawsuit. You are missing the “Legal Privilege” protocol. This means preparing your team to understand when an investigation should be conducted “at the direction of counsel” to protect sensitive findings under legal professional privilege. Your 5.24 preparation should include a briefing for the technical team on what they should—and more importantly, should not—write in internal chat logs during a live breach. “We are totally compromised” is a gift to a plaintiff’s lawyer; “Investigating unauthorized access” is a professional observation.
Forensic Readiness for IoT and OT Environments
If your business involves physical hardware, smart sensors, or manufacturing lines, your incident planning is likely missing the “OT/IoT Gap.” You cannot use standard Windows forensic tools on a smart thermostat or a PLC on a factory floor. Preparation for Annex A 5.24 requires you to identify these non-traditional assets and determine how you will capture “Point-in-Time” data from them before they are reset. If your “plan” only covers laptops and servers, but your business relies on a fleet of connected devices, an auditor will find a significant hole in your incident management scope.
Reputation Management: The “Dark Site” Preparation
In the digital age, silence is perceived as guilt. You are missing the “Communication Infrastructure” prep. This means having a “Dark Site”—a pre-designed, offline webpage that can be published in minutes if your main website is defaced or taken down. It should contain placeholder text for “Service Interruption” and “Security Update” so you can communicate with customers immediately without waiting for a designer to wake up. Proving you have these templates ready to go shows an auditor that you have mastered the “Orderly Communication” requirement of the standard.
Financial “War Chest” and Cost Tracking
An incident is a financial black hole. You are missing the “Financial Tracking” procedure. During a major breach, you will be spending money on emergency hardware, forensic consultants, and legal fees. Your preparation should include a pre-authorized “Emergency Spend” limit for the CISO and a specific accounting code to track all incident-related expenses. Why? Because when you get to Annex A 5.27 (Learning from Incidents), you need to be able to tell the board exactly how much the breach cost. If you can’t quantify the damage, you can’t justify the budget for future improvements.
The Multi-Jurisdictional Notification Matrix
If you operate in more than one country, “72 hours for GDPR” is not enough. You are missing the “Global Notification Matrix.” Different regions have different triggers and different clocks. In 2026, some US states require notification in as little as 24 hours, while certain Asian markets have no fixed timeline but expect “immediate” updates. Your 5.24 preparation should feature a matrix that lists every jurisdiction you operate in, the specific legal trigger for notification, and the contact details for that local regulator. An auditor will check if your plan accounts for the “worst-case” deadline, not just the easiest one.
Insider Threat Preparation: The “Enemy Within”
Most incident plans assume the attacker is a hooded figure in a remote basement, but as a Lead Auditor, I know the most damaging incidents often come from within. You are missing the Insider Threat Protocol. This requires a specific preparation path that involves HR and Legal from the start. You must define how you will investigate a privileged user—like a Senior Admin—without alerting them that they are being monitored. This includes “Shadow Logging,” where logs are sent to a secondary, secure location that the admin cannot access or delete. Preparation for 5.24 means having a “Neutral” investigation team ready that doesn’t include the person being investigated.
Social Engineering and Business Email Compromise (BEC)
We’ve covered malware, but you are missing the preparation for Social Engineering. In 2026, deepfake audio and video are standard tools for fraudsters. Your incident preparation should include “Verification Playbooks” for financial transactions and sensitive data requests. If the CEO “calls” the Finance Director asking for an urgent transfer, your incident plan should have a pre-agreed “Challenge-Response” code or a secondary out-of-band verification step. Proving to an auditor that you have prepared for the “Human Hack” is a key marker of a sophisticated ISMS.
Physical Security and Incident Convergence
In the digital world, we often forget that a server room fire or a stolen backup drive is an information security incident. You are missing Physical-Digital Convergence. Annex A 5.24 preparation must link your digital incident team with your physical security or facilities team. If a data center’s biometric lock is bypassed, that should automatically trigger an information security event. An auditor will look for evidence that your physical security logs are integrated into your incident detection workflow, ensuring that a “break-in” is handled with the same forensic rigour as a “hack-in.”
The “Cold Standby” Forensic Workstation
You cannot perform a clean investigation on a compromised laptop. You are missing the Hardened Forensic Workstation requirement. To be truly prepared, you should have a “Cold Standby” machine that is air-gapped from your production network and pre-loaded with licensed forensic tools. This machine is only turned on during an incident to analyse malware or disk images in a “Sandbox” environment. Showing an auditor this physical or virtual “Clean Room” is powerful evidence that you take evidence preservation and malware containment seriously.
Pre-Vetted Third-Party Forensic Retainers
When a major breach happens, the last thing you want to be doing is negotiating a contract with a forensic firm. You are missing the Retainer Evidence. For Annex A 5.24, I want to see that you have a “Pre-Vetted” agreement with a cyber-incident response firm. This includes having their Master Services Agreement (MSA) signed and their “Emergency Number” in your call tree. If you can show that you have an SLA where a specialist will be on-site or logged in within 4 hours of an incident, you have effectively outsourced a portion of your risk, which is a very smart move for any business.
Evidence Standardization and Trusted Timestamping
If your logs aren’t synchronized, they are useless in court. You are missing Time Synchronization (NTP) Governance. For incident preparation, you must evidence that all servers, firewalls, and cloud logs are synced to a single, trusted NTP (Network Time Protocol) source. If an auditor sees that your firewall says the attack happened at 10:00 and your server says it happened at 10:05, your entire “Analysis” phase (5.24) falls apart. Trusted timestamping is the “invisible” glue that holds an incident investigation together.
AI Model and LLM Specific Incident Playbooks
If you are using AI in 2026, your standard malware playbooks won’t save you. You are missing specific technical procedures for AI-centric threats like Prompt Injection, Model Inversion, and Prompt Leaking. For Annex A 5.24, I want to see a playbook that tells your team exactly what to do when a user bypasses your safety filters to exfiltrate system instructions or training data. This includes having a “Kill Switch” protocol for the model and a way to purge specific “poisoned” data from the inference cache without taking down your entire infrastructure. If you can’t show me how you stop a rogue LLM, you haven’t prepared for the reality of modern risk.
Shadow AI Discovery and API Monitoring
Your incident detection preparation is likely missing Shadow AI. In 2026, employees aren’t just using approved tools; they are pasting sensitive code and customer data into unvetted, free-tier AI browser extensions. To comply with 5.24, your monitoring stack must include Data Loss Prevention (DLP) specifically tuned for AI “Paste” events and API traffic to known AI domains. You need to prove to an auditor that you can detect an unauthorized AI interaction in real-time. If your “Detection” phase is blind to AI traffic, your “Preparation” is incomplete.
AI Forensic Readiness and Inference Logging
Traditional server logs don’t capture the nuance of an AI attack. You are missing Inference Log Integrity. For proper forensic readiness, you must prepare your environment to log the “Prompt,” the “System Instruction,” and the “Model Output” in a timestamped, immutable audit trail. In 2026, an auditor will ask: “How do you prove exactly what the AI said to the user during this breach?” If you aren’t capturing and securing these high-volume inference logs now, you will have zero evidence to analyze when the incident occurs.
Adversarial AI Red Teaming and Simulations
Tabletop exercises are great, but they usually focus on “Server Down” scenarios. You are missing Adversarial AI Simulations. As part of your 5.24 preparation, you should conduct “Red Teaming” specifically targeted at your AI models—simulating data poisoning or model evasion attacks. Showing an auditor the “Lessons Learned” from an AI red-teaming exercise is the absolute gold standard in 2026. It proves you aren’t just prepared for “old world” IT failures, but for the sophisticated AI exploits that define the current threat landscape.
AI Vendor Transparency and Incident SLAs
Most AI providers operate as “Black Boxes,” which is a nightmare for incident management. You are missing the AI-Specific Vendor “Handshake.” Your preparation must include verified SLAs with your AI API providers regarding “Model Transparency.” If an incident occurs on their side—like a model hallucination that leads to a privacy breach—how quickly will they provide the underlying technical logs to your IRT? If you don’t have these notification windows documented in your 5.24 preparation, you’ll be waiting in a generic support queue while your data is leaking.
Automated AI Containment and Guardrails
In 2026, an AI attack happens at machine speed; you cannot wait for a human to review the logs. You are missing Automated AI Guardrails. To be fully prepared, you should have “Circuit Breaker” automation that triggers if your model outputs a certain volume of PII or sensitive keywords. This is the ultimate “Corrective” preparation—stopping the incident before it scales. Proving to an auditor that your AI stack has an automated “Safety-Shutoff” based on pre-defined security thresholds is how you pass a 5.24 audit with flying colours.
ISO 27001 Annex A 5.24 FAQ
As a Lead Auditor, I’ve seen many organisations fail their Stage 2 assessment because their incident planning was purely theoretical. To satisfy Annex A 5.24, you need more than just a document; you need a tested, resourced, and forensically sound framework. The following FAQs address the technical and operational nuances required for true audit readiness.
What is ISO 27001 Annex A 5.24?
ISO 27001 Annex A 5.24 is a foundational security control that requires organisations to plan and prepare for managing information security incidents by establishing policies, roles, and procedures before an event occurs. It establishes the governance framework for incident handling, defines the specific roles and responsibilities of the response team, mandates the creation of reporting channels and escalation paths, and ensures the organisation is “forensically ready” for an audit.
Is an Incident Management Policy mandatory for ISO 27001?
Yes, a documented Information Security Incident Management Policy is a mandatory requirement to satisfy Annex A 5.24 and ensure a consistent organisational response to threats. It serves as the “Primary Directive” for all incident-related activities, provides auditors with proof of a formalised, repeatable process, defines what constitutes an incident versus a standard security event, and aligns the organisation with legal and regulatory notification requirements.
How does Annex A 5.24 differ from Annex A 5.26?
The primary difference is that Annex A 5.24 focuses on the proactive planning and preparation phase, whereas Annex A 5.26 focuses on the active response to an identified incident. 5.24: Strategic planning, policy writing, and team training. 5.26: Operational execution, containment, and restoration. 5.24 is the “Manual” while 5.26 is the “Action.”
Who should be part of the Incident Management Team?
A competent Incident Management Team (IMT) should be a multi-disciplinary group comprising internal stakeholders and, where necessary, external specialists to cover technical and legal impacts. Technical Leads: Responsible for forensic analysis and containment. Legal and Compliance: Manages regulatory notifications and data privacy. Senior Management: Authorises emergency budgets and business pivots. HR and Communications: Manages staff impact and external reputation.
How often should you test your incident management plan?
Organisations should test their incident management plan at least annually or whenever significant changes occur to the infrastructure or threat landscape to ensure operational readiness. Conduct tabletop exercises to simulate high-impact scenarios. Perform functional tests on backup restoration and failover systems. Review and update the plan based on “Lessons Learned” from tests. Ensure contact lists and escalation paths are still accurate.
How do you report an information security incident?
Incident reporting should be conducted through a single, clearly defined channel that is accessible to all employees, contractors, and relevant third parties. Utilise a centralised helpdesk or a dedicated security email address. Establish anonymous whistleblowing lines for sensitive internal issues. Ensure automated alerts from SIEM or SOC tools feed into the register. Define clear timeframes for reporting to meet statutory obligations.
What tools are required for Annex A 5.24 preparation?
While Annex A 5.24 is process-heavy, specific tools are required to facilitate communication, logging, and evidence preservation during the preparation phase. Secure Incident Register: To log and track every event through closure. Out-of-band Communication: Tools like Signal or physical “War Rooms.” ISO 27001 Toolkit: Pre-written policy templates and reporting logs. Forensic Toolkits: For safe acquisition of digital evidence.
Related ISO 27001 Controls and Further Reading
ISO 27001 Clause 7.5.1 Documented Information
ISO 27001 Clause 7.4 Communication
Business Continuity Incident Action Log Template
ISO 27001 controls and attribute values
| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains |
|---|---|---|---|---|
| Corrective | Confidentiality | Respond | Governance | Defence |
| Integrity | Recover | Information Security Event Management | ||
| Availability |
About the author
