ISO 27001 Annex A 5.24 Information Security Incident Management Planning and Preparation Explained

ISO 27001 Information Security Incident Management Planning and Preparation

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.

It 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.

Key Takeaways

ISO 27001 Annex A 5.24 requires organisations 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 minimises damage, ensures legal compliance (e.g., GDPR reporting), and protects your organisation’s reputation.

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.

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

Explanation

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, organizstions ensure a rapid and consistent recovery from breaches, minimising operational disruption and fulfilling mandatory data protection reporting requirements.

Requirement

• 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

1. 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?”
2. Process Verification: “Show me your Incident Management Plan. When was it last reviewed and approved by management?”
3. 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?”

FREE Training Video

In this free training video you will learn How to implement ISO 27001 Incident Management Planning & Preparation (Annex A 5.24) & Pass Audit.

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

Continual Improvement Policy Template

Incident management is part of continual improvement and we ensure at the planning stage they are aligned.

Incident and Corrective Action Log Template

The incident and corrective log is a corner stone of the incident management process and continual improvement as a result of incidents process.

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

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.

ISO 27001 Templates

How to pass the 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.

Top 3 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 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.	Setting up a dedicated email address (e.g., alert@company.com) for all staff to report suspected security events. Documenting a basic “Incident Response Call Tree” that lists the business owner, the IT contractor, and the insurance provider. Holding a 30-minute annual briefing to ensure all employees know the difference between a “technical glitch” and a “security event.”
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.	Defining an IRT that includes the CTO (Incident Manager), Lead Developer (Technical Investigator), and Legal Counsel. Establishing an “Out-of-Band” communication channel (e.g., a private Signal group) to coordinate the response if primary email or Slack is compromised. Conducting an annual “Tabletop Simulation” of a production database breach to identify gaps in the response process.
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.	Creating specialized response playbooks for “Model Exfiltration” or “Training Data Poisoning” incidents. Provisioning “Break-Glass” admin accounts with elevated privileges that are only used by the IRT during a confirmed critical incident. Integrating automated alerts from model monitoring tools directly into a secure, timestamped Incident Register.

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.

FAQ

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