ISO 27001 Annex A 5.25 Audit Checklist

The ultimate audit guide to ISO 27001 Annex A 5.25 Assessment and decision on information security events 

1. Security Event Assessment Methodology Formalisation Verified

Verification Criteria: A documented methodology exists that defines the objective criteria for assessing whether a security event should be classified as a security incident.

Required Evidence: Approved Incident Management Procedure containing a “Decision Tree” or “Assessment Matrix” for event-to-incident conversion.

Pass/Fail Test: If the organisation relies on the subjective “gut feeling” of IT staff rather than a documented classification rubric, mark as Non-Compliant.

2. Point of Contact (PoC) for Event Reporting Confirmed

Verification Criteria: A specific, singular point of contact or function (e.g., SOC, Helpdesk) is designated and available to receive and log all security events.

Required Evidence: Service Desk configuration or “Contact Us” security portal documentation showing a central intake for all events.

Pass/Fail Test: If security events are sent to multiple uncoordinated personal mailboxes without a central tracking ID, mark as Non-Compliant.

3. Event Logging Integrity and Completeness Validated

Verification Criteria: Every reported security event is recorded with a unique ID, timestamp, reporter details, and a description of the observed anomaly.

Required Evidence: Sample of 10 “Low” or “Informational” events from the ITSM tool or SIEM (Security Information and Event Management) system.

Pass/Fail Test: If an event was reported but no record of its initial assessment exists in the ticketing system, mark as Non-Compliant.

4. Triage and Decision-Making Timelines Verified

Verification Criteria: Assessment of events occurs within a predefined timeframe (SLA) to minimise the window of potential impact before a formal incident is declared.

Required Evidence: Audit logs showing the delta between “Event Created” and “Assessment Completed” timestamps.

Pass/Fail Test: If high-priority events consistently exceed the documented assessment window without justification, mark as Non-Compliant.

5. Technical Assessment Competence Alignment Confirmed

Verification Criteria: Personnel responsible for the initial assessment of security events possess the technical training or experience required to differentiate between false positives and real threats.

Required Evidence: Training records for Tier 1 Analysts or Helpdesk staff specifically covering “Security Event Triage.”

Pass/Fail Test: If the staff performing initial triage have not received specific security awareness or technical triage training, mark as Non-Compliant.

6. False Positive Documentation and Justification Verified

Verification Criteria: Events assessed as “Non-Incidents” or “False Positives” include a brief technical justification for the decision to close the event.

Required Evidence: Closed event tickets showing comments such as “Benign activity: verified as authorized vulnerability scan” or similar technical detail.

Pass/Fail Test: If tickets are closed with generic “No action required” notes without a technical explanation, mark as Non-Compliant.

7. Escalation Trigger Points and Thresholds Validated

Verification Criteria: Specific triggers (e.g., failed login threshold, malware detection on critical asset) are documented that mandate immediate escalation to the Incident Response Team.

Required Evidence: SIEM correlation rule definitions or the “Escalation” section of the Incident Management Plan.

Pass/Fail Test: If the escalation path is purely manual and lacks automated thresholds for critical security events, mark as Non-Compliant.

8. Incident Declaration Records and Handover Confirmed

Verification Criteria: When an event is classified as an incident, a formal “Declaration” occurs, and the record is transitioned to the Incident Response workflow.

Required Evidence: Audit trail in the ticketing tool showing a change in record type from “Event/Alert” to “Incident” with a corresponding severity assignment.

Pass/Fail Test: If incidents are managed within the standard “Service Request” queue without a distinct security incident status, mark as Non-Compliant.

9. Multi-Source Event Correlation Evidence Identified

Verification Criteria: The assessment process considers multiple data points (e.g., logs, user reports, threat intel) to determine the legitimacy of an event.

Required Evidence: Security Analyst work-notes showing the cross-referencing of a user report against firewall or endpoint logs.

Pass/Fail Test: If assessments are performed solely on the basis of a user’s description without verifying technical log data, mark as Non-Compliant.

10. Periodic Review of Assessment Accuracy Verified

Verification Criteria: Management or a Senior Analyst periodically reviews closed “Events” to ensure that incidents were not incorrectly dismissed as benign.

Required Evidence: Quality Assurance (QA) logs or meeting minutes from SOC “Shift Handover” or weekly security reviews.

Pass/Fail Test: If there is no evidence of a “Second Look” or QA process for events closed at the first line, mark as Non-Compliant.

About the author