How to Implement ISO 27001 Annex A 5.25

Implementing ISO 27001 Annex A 5.25 is the governance process of evaluating potential security incidents through manual log analysis. The primary implementation requirement centers on human-led triage and classification matrices, providing the business benefit of accurate threat detection and high-integrity evidence for audit trails.

ISO 27001 Annex A 5.25 Assessment and Decision on Information Security Events Implementation Checklist

Use this implementation checklist to achieve compliance with ISO 27001 Annex A 5.25. Real-world security is verified through the manual interrogation of raw system logs and human decision-making, not by relying on the ‘auto-remediation’ promises of a GRC dashboard.

1. Define the Manual Event Logging Baseline

Control Requirement: Establish a clear baseline of what constitutes an information security event across all organisational assets.

Required Implementation Step: Log into your primary domain controller and firewall. Manually document the specific Event IDs (e.g., Windows Event ID 4625 for failed logins) that must be captured, ensuring you aren’t just trusting a default ‘collect all’ setting that creates noise.

Minimum Requirement: A documented list of high-priority Event IDs and log sources specific to your local infrastructure.

2. Assign a Human ‘Triage Lead’

Control Requirement: Appoint a competent individual or team to assess events and determine if they should be classified as incidents.

Required Implementation Step: Designate a lead engineer as the primary ‘Triage Lead’. Update their physical job description to include the manual review of daily event summaries, ensuring accountability lies with a person, not an algorithm.

Minimum Requirement: A signed appointment letter or updated roles-and-responsibilities matrix for the Triage Lead.

3. Implement a Manual Event-to-Incident Classification Matrix

Control Requirement: Develop a criteria-based assessment process to decide if an event is a security incident.

Required Implementation Step: Create a physical or local spreadsheet matrix. Define specific thresholds—such as “5 failed login attempts from a foreign IP within 10 minutes”—that mandate an escalation from ‘Event’ to ‘Incident’.

Minimum Requirement: A 1-page decision matrix used by IT staff to categorise events during the triage process.

4. Configure Out-of-Band Event Alerts

Control Requirement: Ensure security events are reported through appropriate management channels in a timely manner.

Required Implementation Step: Set up direct SMTP or SMS alerts from your core network hardware to the Triage Lead. Do not route these through a third-party GRC platform; they must go directly from the hardware to the human to ensure zero-latency reporting.

Minimum Requirement: Evidence of active, direct alerts for critical system failures or unauthorised access attempts.

5. Establish a Physical Evidence Log of Assessments

Control Requirement: Maintain records of the assessment and decision-making process for security events.

Required Implementation Step: Keep a ‘Triage Diary’ or local database where every significant event assessment is logged. Record the time the event was identified, who assessed it, and the specific reason it was (or was not) escalated to an incident.

Minimum Requirement: A 12-month archive of event assessment decisions, including those deemed ‘False Positives’.

6. Perform Manual Log Correlation Dry Runs

Control Requirement: Assess events using knowledge of the context of the event and the organisational environment.

Required Implementation Step: Once a month, manually compare your firewall logs against your physical office entry logs. Verify if a ‘remote login event’ corresponds with an employee’s known physical location; this manual correlation is something automated tools frequently miss.

Minimum Requirement: A monthly signed-off report confirming that log correlation has been performed manually across disparate systems.

7. Define ‘False Positive’ Thresholds

Control Requirement: Ensure that security events are not ignored and that false positives are documented to improve future assessments.

Required Implementation Step: When an event is dismissed as a ‘False Positive’, manually record the technical justification. Update your firewall or server config files to suppress the specific trigger while ensuring you aren’t blinding the system to genuine threats.

Minimum Requirement: A ‘False Positive Registry’ detailing the technical reason for every suppressed alert.

8. Implement a ‘Second Opinion’ Protocol for High-Impact Events

Control Requirement: Establish a process for escalating complex or high-impact events for senior management decision-making.

Required Implementation Step: Document a procedure where any event involving ‘Admin’ credentials or ‘Financial’ systems requires a second engineer to sign off on the triage decision before the case is closed.

Minimum Requirement: A documented policy requiring ‘Two-Person Integrity’ for the assessment of critical infrastructure events.

9. Conduct Technical Peer Review of Automated Filters

Control Requirement: Periodically review the rules and filters used to identify and report security events.

Required Implementation Step: Open your SIEM or log-management configuration files. Manually review the regex and filtering rules with the security team to ensure that a simple configuration change hasn’t accidentally silenced critical event reporting.

Minimum Requirement: A quarterly review log of all active event-filtering rules, signed by the CISO.

10. Store Triage Evidence Offline

Control Requirement: Ensure the availability and integrity of information security event assessment records.

Required Implementation Step: Every month, export your event assessment logs to an encrypted physical drive. Store this drive in a fireproof safe; relying on a GRC SaaS means you lose your evidence if the vendor goes offline or your internet connection is severed.

Minimum Requirement: Physical possession of the last 6 months of assessment records in an offline, secure format.

ISO 27001 Annex A 5.25 SaaS / GRC Platform Implementation Failure Checklist

Control Requirement	The ‘Checkbox Compliance’ Trap	The Reality Check
Event Identification	SaaS tool pulls in ‘high-level’ alerts via API.	APIs often filter out the ‘low-level’ raw logs where true lateral movement is first detected.
Human Assessment	The platform uses ‘AI’ to automatically close alerts.	ISO 27001 requires a ‘competent’ decision; AI cannot understand the specific context of your physical office.
Triage Accuracy	Shows a green tick because ‘Alerts were processed’.	An auditor wants to see ‘why’ an event wasn’t an incident; GRC tools rarely capture the human ‘logic’ behind a dismissal.
Log Context	Links to a dashboard of ‘Threat Intelligence’.	Threat Intel is generic; it doesn’t know that Bob from Accounting is on holiday, making his login a critical event.
Evidence Integrity	Records are kept in the GRC vendor’s database.	If you cancel your subscription or the vendor is breached, your evidence of compliance disappears.
Alert Latency	Dashboard refreshes every 15-60 minutes.	Security events happen in milliseconds; relying on a slow GRC sync means you’re already too late.
Rule Review	Uses ‘Standard’ industry rules for event detection.	Standard rules don’t cover your legacy on-premise hardware; only manual rule-tuning does.
Peer Review	One person clicks ‘Resolve’ in the app.	Does not enforce ‘Two-Person’ sign-off for critical events, failing the higher-standard governance test.

About the author