Auditing ISO 27001 Annex A 5.24 Information Security Incident Management Planning involves rigorous verification of an organization’s preparedness to detect, report, and respond to security events. This process validates the Primary Implementation Requirement of establishing defined roles, reporting channels, and tested response procedures. The Business Benefit ensures a rapid, coordinated response that minimizes impact and preserves evidence during security crises.
This technical verification tool is designed to ensure that the organisation possesses a robust structural framework for detecting, reporting, and managing security events. Use this checklist to validate compliance with ISO 27001 Annex A 5.24 (Information security incident management planning and preparation).
1. Information Security Incident Management Policy Formalisation Verified
Verification Criteria: A documented policy exists, is approved by senior management, and defines the organisation’s overarching approach to incident management.
Required Evidence: Approved Information Security Incident Management Policy with a current version history and evidence of board-level sign-off.
Pass/Fail Test: If the policy is in “draft” status or lacks formal authorisation from the current leadership team, mark as Non-Compliant.
2. Incident Management Roles and Responsibilities Defined
Verification Criteria: Specific individuals or teams (e.g., CSIRT) are formally appointed with clearly defined accountabilities for incident response and escalation.
Required Evidence: A Responsibility Assignment Matrix (RACI) or specific Job Descriptions (JDs) for incident response leads and deputies.
Pass/Fail Test: If incident response duties are assigned to a generic “IT Team” without naming specific accountable leads, mark as Non-Compliant.
3. Internal and External Incident Reporting Channels Established
Verification Criteria: Clear, accessible pathways exist for employees and external parties to report suspected security events without delay.
Required Evidence: Dedicated reporting email addresses, intranet links, or telephone hotlines; evidence of communication of these channels to all staff.
Pass/Fail Test: If a sample of five random employees cannot identify how to report a lost laptop or suspicious email, mark as Non-Compliant.
4. Incident Classification and Categorisation Criteria Documented
Verification Criteria: A formalised system is present to categorise incidents by type (e.g., malware, data breach) and prioritise them by severity/impact levels.
Required Evidence: Incident Classification Matrix or Impact Assessment Triage guide integrated into the response workflow.
Pass/Fail Test: If the triage process relies on “discretionary judgment” without a documented severity matrix, mark as Non-Compliant.
5. Information Security Incident Management Plan (ISIMP) Present
Verification Criteria: A comprehensive response plan exists, containing step-by-step procedures for different incident scenarios (e.g., ransomware, DDoS, lost media).
Required Evidence: The Information Security Incident Management Plan (ISIMP) or specific “Response Playbooks” for high-likelihood threats.
Pass/Fail Test: If the plan describes “What” to do but lacks specific “How-to” technical playbooks for the organisation’s primary risks, mark as Non-Compliant.
6. Specialist External Contact Lists Maintained
Verification Criteria: A current directory of external specialists, authorities, and law enforcement agencies is maintained to facilitate rapid escalation.
Required Evidence: Verified contact list including the Information Commissioner’s Office (ICO), National Cyber Security Centre (NCSC), external legal counsel, and forensics partners.
Pass/Fail Test: If the contact list contains only general switchboard numbers or has not been verified/dial-tested in the last 12 months, mark as Non-Compliant.
7. Evidence Handling and Forensic Readiness Procedures Validated
Verification Criteria: Procedures are in place to ensure that evidence is collected and preserved in a manner that maintains its integrity for potential legal proceedings.
Required Evidence: Evidence Handling Policy and a sample Chain of Custody form; evidence of technical controls for log preservation.
Pass/Fail Test: If the organisation lacks a defined “Chain of Custody” process for physical or digital evidence, mark as Non-Compliant.
8. Incident Response Testing and Exercise Records Present
Verification Criteria: The organisation regularly tests its incident management plans through drills, simulations, or tabletop exercises.
Required Evidence: Records of the most recent tabletop exercise, including the scenario used, participants list, and an After-Action Report (AAR).
Pass/Fail Test: If no formal incident response exercise has been conducted and documented within the last 12 months, mark as Non-Compliant.
9. Post-Incident Review (PIR) and Improvement Mechanism Verified
Verification Criteria: A process exists to review incidents after closure to identify root causes and implement corrective actions to prevent recurrence.
Required Evidence: Completed Post-Incident Review (PIR) reports from the current audit cycle showing tracked improvement actions.
Pass/Fail Test: If incident tickets are “Closed” without a corresponding root cause analysis or recorded lesson learned, mark as Non-Compliant.
10. Staff Incident Awareness and Training Completion Confirmed
Verification Criteria: Personnel are trained to recognise security events and understand their role within the organisation’s incident response framework.
Required Evidence: Training logs showing that incident reporting and response awareness has been completed by >95% of current staff.
Pass/Fail Test: If training records show that new joiners have not received incident reporting instructions within their first week, mark as Non-Compliant.
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Response Planning | Uploading a generic “Incident Response Template” found online. | Verify that the plan includes specific IP addresses, local server names, and authorised vendor contact names. |
| Role Definition | Listing “The IT Manager” as the sole person responsible for everything. | Verify a formalised deputy system. Does the plan work if the IT Manager is on annual leave or is the target of the incident? |
| Classification | Ticking “High” on every ticket to ensure it gets seen. | Inspect the ticket backlog; verify that “Medium” and “Low” events are actually being categorised according to the documented matrix. |
| Contact Lists | Storing a link to the ICO website and calling it an “escalation path”. | Demand the direct phone numbers for the organisation’s insurance breach coach and cyber-legal counsel. |
| Testing/Exercises | Claiming a “real incident” counts as the annual test. | Verify a controlled exercise where specific *failures* were simulated. Real incidents don’t allow for the “what if” stress-testing required by Annex A. |
| Forensic Readiness | Assuming IT staff can “just copy the files” if needed. | Verify whether the staff have forensic write-blockers or access to a third-party retainer for bit-for-bit imaging. |
| Improvement | Closing tickets with the resolution “User told to be more careful”. | Verify systemic changes (e.g., firewall policy updates or MFA enforcement) resulting from incident post-mortems. |
About the author
