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

In this guide you will learn how to implement ISO 27001 Annex A 5.24 Information security incident management planning and preparation and pass your audit from ISO 27001 Lead Auditor Stuart Barker – author of the ultimate ISO 27001 Toolkit.

ISO 27001 Annex A 5.24 is an ISO 27001 control that requires an organisation to plan and prepare for managing information security incidents.

Purpose & Definition

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.

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

FREE ISO 27001 Annex A 5.24 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.

Implementation Guide

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.

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.

ISO 27001 Annex A 5.24 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