ISO 27001 Annex A 5.26 Audit Checklist

Auditing ISO 27001 Annex A 5.26 Response to Information Security Incidents verifies the effectiveness of tactical actions taken during a cyber crisis. This process validates the Primary Implementation Requirement of executing tested response procedures to contain and eradicate threats. The Business Benefit minimizes operational downtime and reputational damage by ensuring rapid, coordinated recovery from security breaches.

This professional audit tool is designed to verify the effectiveness of tactical response actions following the declaration of a security incident. Use this checklist to validate compliance with ISO 27001 Annex A 5.26 (Response to information security incidents).

1. Incident Response Procedure Formalisation Verified

Verification Criteria: Documented playbooks exist for specific incident categories (e.g. ransomware, unauthorised access, data exfiltration) defining binary response actions.

Required Evidence: Approved Incident Response Plan (IRP) or a technical playbook library with version control and management sign-off.

Pass/Fail Test: If response actions rely on the “best effort” of staff without documented, scenario-specific playbooks, mark as Non-Compliant.

2. Response Team Activation Protocols Confirmed

Verification Criteria: Technical triggers for activating the Cyber Security Incident Response Team (CSIRT) are established and functional.

Required Evidence: On-call rotas, CSIRT contact directories, and timestamped activation logs from a recent incident or simulation.

Pass/Fail Test: If the organisation cannot demonstrate a formal “Point of Contact” available 24/7 for incident escalation, mark as Non-Compliant.

3. Containment and Eradication Evidence Validated

Verification Criteria: Technical measures are implemented to isolate affected assets and neutralise the threat prior to recovery efforts.

Required Evidence: Firewall logs showing VLAN isolation, EDR (Endpoint Detection and Response) action history, or account suspension logs.

Pass/Fail Test: If evidence shows recovery actions (e.g. restoring backups) were initiated before the threat was confirmed as contained, mark as Non-Compliant.

4. Out-of-Band Communication Integrity Verified

Verification Criteria: Secure communication channels are designated for use during incidents where primary channels (e.g. corporate email) may be compromised.

Required Evidence: Provisioning records for encrypted messaging platforms or designated “emergency bridge” conference details outside the standard tenant.

Pass/Fail Test: If the IRP mandates the use of potentially compromised internal systems for sensitive incident coordination, mark as Non-Compliant.

5. Statutory and Regulatory Reporting Compliance Confirmed

Verification Criteria: Procedures and records demonstrate that notifications to authorities (e.g. ICO) occur within mandatory timeframes (e.g. 72 hours).

Required Evidence: Submission receipts from regulatory portals or communication logs with legal counsel regarding reporting thresholds.

Pass/Fail Test: If a reportable incident exceeded statutory notification windows without a documented legal justification, mark as Non-Compliant.

6. Evidence Preservation and Forensic Readiness Validated

Verification Criteria: Digital and physical evidence is collected and preserved using methods that maintain integrity for potential legal proceedings.

Required Evidence: Signed Chain of Custody forms, bit-for-bit disk images, or immutable log exports (WORM storage).

Pass/Fail Test: If technical staff “live-modified” compromised systems (e.g. browsing files) without first securing a forensic image, mark as Non-Compliant.

7. Response Action Logging Integrity Verified

Verification Criteria: A chronological record of all actions taken during the response phase is maintained in real-time.

Required Evidence: Centralised incident log, master ticket audit trail, or timestamped scribe notes from the incident room.

Pass/Fail Test: If the incident log was reconstructed from memory 24+ hours after the event rather than recorded during the response, mark as Non-Compliant.

8. Recovery Verification and Integrity Checks Confirmed

Verification Criteria: Restored systems are subjected to technical verification (e.g. vulnerability scans, integrity checks) before returning to production.

Required Evidence: Post-recovery scan reports or signed-off verification checklists from the system owner.

Pass/Fail Test: If systems were returned to a live state without a recorded security verification to ensure the threat was fully eradicated, mark as Non-Compliant.

9. Stakeholder and Third-Party Escalation Records Present

Verification Criteria: External stakeholders (e.g. insurers, forensic partners, affected clients) are notified in accordance with contractual obligations.

Required Evidence: Escalation logs or email headers confirming notification to cyber insurance providers or partner organisations.

Pass/Fail Test: If a contractual notification requirement to a third party was missed during an active incident, mark as Non-Compliant.

10. Responder Access Authority and Tooling Validated

Verification Criteria: Designated incident responders possess pre-authorised administrative access to the forensic and recovery tools required for their role.

Required Evidence: Access Control Lists (ACLs) for security tooling or “Break Glass” account logs showing responder access.

Pass/Fail Test: If response efforts were delayed because the CSIRT lacked the necessary privileges to isolate systems, mark as Non-Compliant.

About the author