ISO 27001 Assessment and Decision on Information Security Events | Annex A 5.25 | The Lead Auditor’s Implementation and Audit Guide

/ By

ISO 27001 Annex A 5.25 is a security control that requires organizations to evaluate information security events and determine if they constitute incidents. The Primary Implementation Requirement involves establishing triage criteria to ensure a Business Benefit of prioritized response focus and consistent classification of technical anomalies.

In this guide, I will show you exactly how to implement ISO 27001 Annex A 5.25 and ensure you pass your audit. You will get a complete walkthrough of the control, practical implementation examples, and access to the ISO 27001 templates and toolkit that make compliance easy.

I am Stuart Barker, an ISO 27001 Lead Auditor with over 30 years of experience conducting hundreds of audits. I will cut through the jargon to show you exactly what changed in the 2022 update and provide you with plain-English advice to get you certified.

Key Takeaways: ISO 27001 Annex A 5.25 Assessment and Decision on Information Security Events

ISO 27001 Annex A 5.25 requires organizations to assess information security events and decide if they should be categorized as information security incidents. This is a critical detective control that acts as the “triage” stage of incident management. Not every technical glitch is a security incident. This control ensures you have a consistent process to filter out noise, identify true threats to Confidentiality, Integrity, and Availability, and prioritize them so your response team focuses on the highest risks first.

Core requirements for compliance include:

  • Establish Triage Criteria: You must define clear criteria to differentiate between a “security event” (e.g., a single failed login) and a “security incident” (e.g., a brute-force attack).
  • Prioritization Formula: The priority of an incident is typically determined by the formula: Impact x Urgency = Priority.
    • Impact: How severe are the consequences (e.g., data loss, downtime)?
    • Urgency: How quickly must we act to prevent further damage?
  • Designated Decision Maker: You must identify a specific point of contact (often the Incident Manager) who has the authority to officially categorize an event as an incident and set its priority level.
  • Recording Decisions: Every assessment and decision must be documented. This record is essential for Root Cause Analysis (RCA) and for proving to auditors that your process is operational.
  • Integration with IR Plan: This control must link directly to your Incident Management Plan (A.5.24) to ensure that once a decision is made, the correct response procedures are triggered.

Audit Focus: Auditors will look for “The Triage Logic”:

  1. Incident Logs: “Show me your incident log for the last year. Pick an event that was not categorized as an incident. How did you reach that decision?”
  2. SLA Compliance: “Show me a ‘High’ priority incident from last month. Did your team respond within the timeframe defined in your Event Classification Matrix?”
  3. Evidence of Analysis: “For your most recent major incident, show me the record of the initial assessment. Who made the decision on the priority level?”

Event Classification Matrix (Audit Prep):

Severity Definition Real-World Example Response Target ISO 27001:2022 Control
Low No service impact; single user. Blocked phishing email. 24 Hours. Annex A 5.25
Medium Limited impact; non-critical data. Malware on one workstation. 4 Hours. Annex A 5.25
High Critical service down; data risk. Ransomware on a file server. 1 Hour. Annex A 5.25 / 5.26
Critical Existential threat; massive leak. Database exposed to public. IMMEDIATE Annex A 5.25 / 5.26

Table of contents

Do it Yourself ISO 27001

Our Lead-Auditor verified templates with expert support have a 100% success rate.

Get the Auditor-Verified ISO 27001 Toolkit.
Fay Barker - High Table - ISO27001 Director

What is ISO 27001 Annex A 5.25?

ISO 27001 Annex A 5.25 is about the assessment and decisions on information security events which means you need a process for assessing incidents and then deciding if they are an information security incident and prioritising them for action.

ISO 27001 Annex A 5.25 Assessment and decision on information security events is an ISO 27001 control that requires an organisation to assess information security events to categorise and prioritise them.

ISO 27001 Annex A 5.25 Purpose

The purpose of ISO 27001 Annex A 5.25 is a detective control that ensures effective categorisation and prioritisation of information security events.

ISO 27001 Annex A 5.25 Definition

The ISO 27001 standard defines ISO 27001 Annex A 5.25 as:

The organisation should assess information security events and decide if they are to be categorised as information security incidents.

ISO 27001:2022 Annex A 5.25 Assessment and decision on information security events

Watch the ISO 27001 Annex A 5.25 Tutorial

In this tutorial video I show you how to implement ISO 27001 Annex A 5.25 and how to pass the audit.

ISO 27001 Annex A 5.25 Podcast

In this episode: Lead Auditor Stuart Barker and team do a deep dive into the ISO 27001 Annex A 5.25 Assessment And Decision On Information Security Events. The podcast explores what it is, why it is important and the path to compliance.

ISO 27001 Annex A 5.25 Implementation Guidance

An information security incident is an event that could potentially have a negative impact on the confidentiality, integrity, or availability of information. The consequences of an incident can vary depending on the nature of the incident, the systems and data affected, and the organisation’s response.

The priority of an incident is determined by its impact and urgency. Impact refers to how severe the consequences of the incident are, and urgency refers to how quickly action is needed to resolve the incident.

Criteria for Categorising Events as Information Security Incidents

In roles and responsible ISO 27001 Annex A 5.24 Information Security Incident Management Planning And Preparation we assigned the various roles including the contact who will assess each information security incident using the agreed criteria.

The following can be used to categorise events as information security incidents:

  • A virus
  • Unauthorised access to information systems or data
  • Ransomeware
  • A system outage
  • Social engineering attacks
  • Unauthorised disclosure of information
  • Unauthorised modification of information
  • Denial of service to information systems or users

Assessment of Information Security Events

We also set out in ISO 27001 Annex A 5.24 Information Security Incident Management Planning And Preparation who will co-ordinate and respond to the information security incident and it those people that will perform the assessment and make a decision on the events.

The point of contact should assess each information security event using the following as guidance:

  • Impact: The impact of the event should be assessed in terms of the severity of the consequences, such as loss of confidentiality, integrity, or availability of information.
  • Urgency: The urgency of the event should be assessed in terms of how quickly a resolution is needed
  • Priority: The priority of the event should be determined by its impact and urgency.

Information Security Assessment Formula

Impact x Urgency = Priority

Decision on Information Security Events

The point of contact should make a decision on each information security event based on the assessment. The decision should include the following:

  • Whether the event is an information security incident
  • The priority of the incident
  • The appropriate response to the incident

Recording of Results

The results of the assessment and decision should be recorded. This is for reference, verification, lessons learnt, root cause analysis and continual improvement. We would record the following information:

  • The date and time of the event
  • The nature of the event
  • The impact of the event
  • The urgency of the event
  • The priority of the event
  • The decision on the event
  • The response to the event

Implementation Conclusion

This guide provides a framework for identifying the impact, consequences and priority of an information security incident. The guide should be used in conjunction with your information security incident management plan.

The standard that relates to information security management for further reading if required is ISO/IEC 27035

I’ve sat in the Auditor’s chair for 20 years. These are the exact tools I use to guarantee a pass.

Get the Auditor-Proven Toolkit.
Stuart Barker - High Table - ISO27001 Director

How to implement ISO 27001 Annex A 5.25

Implementing Annex A 5.25 requires a structured approach to distinguish between routine events and genuine security incidents. As a Lead Auditor, I recommend following these ten steps to ensure your organisation responds with precision and consistency, maintaining the integrity of your Information Security Management System (ISMS).

1. Appoint and Define Assessment Roles

Provision clear accountability by identifying the specific individuals or teams responsible for evaluating information security events. This ensures that when an event occurs, there is no ambiguity regarding who makes the final decision.

  • Assign a Primary Incident Manager or Point of Contact.
  • Define IAM (Identity and Access Management) roles specifically for incident logging and assessment.
  • Document these responsibilities within your Information Security Policy.

2. Establish Formal Assessment Criteria

Formalise the logic used to determine if an event qualifies as an incident. This creates an objective framework that removes guesswork and ensures consistency across different shifts or departments.

  • Define “Event” versus “Incident” based on potential impact.
  • Categorise events by type: such as system malfunctions, human error, or malicious attacks.
  • Use a risk-based approach aligned with your organisational risk appetite.

3. Provision an Updated Asset Register

Integrate your Asset Register into the assessment workflow to provide critical context. Knowing the value and sensitivity of the affected asset allows for a more accurate assessment of the event’s severity.

  • Ensure all technical assets are mapped to owners.
  • Classify assets by criticality (e.g., High, Medium, Low).
  • Reference the Asset Register during the initial triage phase.

4. Deploy a Centralised Event Logging Mechanism

Implement a technical solution to capture all reported events in a single, secure location. Centralisation prevents data loss and allows for chronological analysis of security trends.

  • Utilise a SIEM (Security Information and Event Management) tool or a dedicated GRC platform.
  • Ensure logs are immutable and time-stamped.
  • Enable MFA (Multi-Factor Authentication) for all users accessing the log.

5. Implement a Triage Workflow

Create a step-by-step process for moving an event from “reported” to “assessed.” A formalised workflow ensures that high-priority events are prioritised over routine maintenance alerts.

  • Set internal SLAs (Service Level Agreements) for assessment times.
  • Use a ticketing system to track the status of each event.
  • Define escalation paths for events that appear complex or high-risk.

6. Formalise the Decision Logic and Matrix

Develop a decision matrix that combines impact and urgency to produce a definitive classification. This matrix serves as the primary tool for the assessor to decide the next course of action.

  • Map potential outcomes to Annex A 5.24 (Incident Management).
  • Include “false positive” as a valid assessment result.
  • Document the rationale for each decision within the event record.

7. Secure the Evidence Trail

Maintain a detailed record of the assessment process to satisfy audit requirements. This evidence proves that the control is operating effectively and that decisions are based on data rather than intuition.

  • Capture snapshots of system logs or error messages.
  • Record the identity of the assessor and the time the decision was reached.
  • Store evidence in accordance with your document retention policy.

8. Conduct Competency and Awareness Training

Train all relevant personnel on the assessment criteria and the use of reporting tools. A technical control is only as effective as the people operating it: human error is a significant risk in event misclassification.

  • Perform “Tabletop Exercises” to test the assessment logic.
  • Brief staff on identifying social engineering or sophisticated phishing events.
  • Include Annex A 5.25 requirements in new starter inductions.

9. Integrate with Incident Response Procedures

Ensure a seamless hand-off between event assessment and incident response. If an event is classified as an incident, the transition to the response phase must be immediate to minimize impact.

  • Link the event log directly to the incident report.
  • Notify the Incident Response Team automatically upon a “Positive” assessment.
  • Define “Rules of Engagement” (ROE) for technical investigators.

10. Audit and Refine the Assessment Process

Review the history of assessments regularly to identify patterns or flaws in the criteria. Continual improvement ensures the process evolves alongside new security threats and organisational changes.

  • Conduct a monthly review of “False Positives” to tune monitoring filters.
  • Audit the event log for completeness and accuracy.
  • Update the assessment matrix based on lessons learned from past incidents.

Event Classification Matrix

Severity Definition Example Response Time
Low No impact on services; single user affected. Phishing email (blocked). 24 Hours
Medium Limited impact; non-critical data. Malware on 1 laptop. 4 Hours
High Critical service down; sensitive data risk. Ransomware on server. 1 Hour
Critical Existential threat; massive data loss. Database public leak. IMMEDIATE

How to comply

To comply with ISO 27001 Annex A 5.25 you are going to implement the ‘how’ to the ‘what’ the control is expecting. In short measure you are going to:

  1. Identify information security incidents.
  2. Assess the impact of information security incidents.
  3. Prioritise information security incidents.
  4. Respond to information security incidents.
  5. Record information security incidents.

How to Audit ISO 27001 Annex A 5.25

Auditing the assessment and decision process for information security events is a critical step in ensuring your organisation does not miss a genuine threat or become overwhelmed by false positives. As a Lead Auditor, I look for evidence that decisions are objective, consistent, and recorded with technical integrity. Follow these ten steps to audit your Annex A 5.25 controls effectively.

1. Provision the Information Security Policy for Review

Examine the formal policy framework to ensure that the process for assessing security events is documented and approved. Without a defined policy, the assessment process lacks the authority and structure required for a successful ISO 27001 audit.

  • Confirm the existence of a documented event assessment procedure.
  • Verify that the policy has been reviewed and signed off by senior management within the last 12 months.
  • Ensure the policy explicitly defines the difference between a security event and a security incident.

2. Formalise the Audit of Roles and Responsibilities

Verify that specific IAM (Identity and Access Management) roles have been assigned to individuals responsible for event assessment. Accountability is non-negotiable, and you must see clear evidence that assessors know their specific duties.

  • Inspect the organisational chart or Asset Register to identify designated assessors.
  • Review IAM logs to ensure only authorised personnel have the permissions required to change event statuses.
  • Confirm that deputies are assigned to ensure continuous coverage for event triage.

3. Examine the Event Classification Criteria

Evaluate the logic used to categorise events to ensure it is objective and repeatable. Auditors look for a decision matrix or a formalised set of criteria that prevents subjective interpretation of security risks.

  • Request the event classification matrix or decision tree.
  • Check for technical parameters, such as system criticality or data sensitivity levels.
  • Validate that the criteria align with the organisation’s overall risk management framework.

4. Inspect the Centralised Event Log

Audit the technical repository where events are recorded to ensure completeness and availability. A fragmented logging system often leads to missed events and inconsistent decision-making during the assessment phase.

  • Verify that a centralised log or SIEM (Security Information and Event Management) tool is in use.
  • Ensure that all departments and technical assets are reporting into this central system.
  • Confirm that access to this log is protected by MFA (Multi-Factor Authentication) to prevent unauthorised tampering.

5. Sample Recent Security Event Decisions

Select a random sample of reported events and trace them through to the final decision. This “walkthrough” provides the primary evidence that the assessment process is functioning as intended in a live environment.

  • Select at least 5 to 10 events from the past quarter.
  • Check if the decision (incident or non-incident) was recorded for every event sampled.
  • Verify that the rationale for each decision was documented clearly in the event record.

6. Evaluate the Timeliness of Assessments

Analyse the time elapsed between an event being reported and a decision being reached. Delayed assessments increase the window of opportunity for attackers, so auditors look for evidence of prompt triage.

  • Review time stamps on event reports versus decision records.
  • Compare performance against internal SLAs (Service Level Agreements) for incident triage.
  • Investigate any significant delays to identify potential resource bottlenecks or process failures.

7. Cross-Reference Assessments with the Asset Register

Verify that the assessment process takes into account the value of the affected asset. Linking event assessment to the Asset Register ensures that high-value targets receive the appropriate level of scrutiny.

  • Check if the event log captures the unique asset ID or classification from the register.
  • Ensure that events involving “Critical” assets are prioritised for immediate decision.
  • Confirm that asset owners are notified as part of the formal decision-making workflow.

8. Audit the Integrity of Assessment Evidence

Inspect the evidence attached to event records to ensure it is sufficient for forensic or audit purposes. Technical density, such as system logs or error reports, is vital to prove why a specific decision was made.

  • Confirm that logs or screenshots are attached to the assessment record where applicable.
  • Check that evidence is stored in a way that prevents post-decision modification.
  • Verify that the retention period for this evidence matches the organisation’s data retention policy.

9. Review Rules of Engagement (ROE) and Training

Assess the competence of the personnel making the decisions by reviewing their training records and technical guidance. Auditors need to be confident that the staff have the technical knowledge to judge complex security events.

  • Examine the ROE (Rules of Engagement) documents provided to the security team.
  • Check training logs for evidence of specific ISO 27001 awareness or technical incident handling courses.
  • Interview a member of the assessment team to verify their understanding of the classification logic.

10. Validate Continuous Process Refinement

Search for evidence that the organisation learns from its assessment history. A mature ISMS will use data from “False Positives” to refine technical filters and improve the accuracy of future decisions.

  • Review minutes from security review meetings where event trends were discussed.
  • Look for evidence of technical adjustments made to logging tools to reduce noise.
  • Verify that the assessment criteria are updated following any major security incidents or “near misses.”

The Tools We Use.

100% Audit Success. Zero AI Guesswork.

Get the Auditor-Proven Toolkit.
Stuart and Fay High Table

How to pass an ISO 27001 Annex A 5.25 audit

To pass an audit of ISO 27001 Annex A 5.25 Assessment and decision on information security events you are going to make sure that you have followed the steps above in how to comply.

  1. Have a documented information security incident management plan.
  2. Implement the information security incident management plan.
  3. Monitor the effectiveness of the information security incident management plan.
  4. Review and update the information security incident management plan as needed.

What the 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 ISO 27001 Annex A 5.25 Mistakes People Make and How to Avoid Them

The top 3 Mistakes People Make For ISO 27001 Annex A 5.25 are

1. Not having a documented information security incident management plan.

This is the most common mistake made by organisations. A documented information security incident management plan is essential for effective incident response. It should include the following:

  • A process for identifying information security incidents.
  • A process for assessing the impact of information security incidents.
  • A process for prioritising information security incidents.
  • A process for responding to information security incidents.
  • A process for recording information security incidents.

2. Not implementing the information security incident management plan.

Even if you have a documented information security incident management plan, it is not enough to simply have the plan. The plan must be implemented in order to be effective. This means assigning responsibility for implementing the plan, providing training on the plan, and testing the plan.

3. Not monitoring the effectiveness of the information security incident management plan.

Once the information security incident management plan is implemented, it is important to monitor its effectiveness. This means reviewing reports of information security incidents, conducting audits of the plan, and taking corrective action as needed.

By avoiding these mistakes, you can ensure that you have an effective information security incident management plan in place.

Why is Assessment and Decision on Information Security Events Important?

As the saying goes, shit happens. It is facts of life. No system or security is 100% We cannot be on the back foot when the inevitable happens and effective incident management can eliminate or reduce the impact of information security incidents.

ISO 27001 Annex A 5.25 is important because it provides guidance on how to manage information security incidents. Information security incidents can have a significant impact on an organisation, so it is important to have a plan in place for how to respond to them. The guidance in ISO 27001 Annex A 5.25 can help you to develop and implement an effective information security incident management plan.

The following are some of the benefits of having an effective information security incident management plan:

  • It can help to reduce the impact of information security incidents.
  • It can help to protect the organisations reputation.
  • It can help to comply with legal and regulatory requirements.
  • It can help to improve the organisations overall information security posture.

Applicability of ISO 27001 Annex A 5.25 across different business models.

Business Type Applicability Examples of Control Implementation
Small Businesses Highly applicable for filtering out technical “noise” from true security threats. The focus is on a simple triage process that ensures the owner or office manager isn’t overwhelmed by every minor log entry while catching critical events.
  • Implementing a simple “Severity Formula” (Impact x Urgency) to decide if a blocked phishing email is just a “Low” event or part of a “High” priority targeted campaign.
  • Designating the Business Owner as the final “Decision Maker” to officially categorize a lost employee smartphone as a security incident.
  • Maintaining a manual log of assessed security events to prove to auditors that a consistent triage process is being followed.
Tech Startups Critical for managing high-volume alerts from cloud infrastructure and CI/CD pipelines. Compliance involves defining technical triage criteria that allow the DevOps team to focus on existential threats to the production environment.
  • Creating an Event Classification Matrix that defines a “Critical” incident as any unauthorized access to the production database.
  • Automating the initial triage of server alerts so that “Medium” priority events (like one-off login failures) don’t trigger the on-call engineer at 2 AM.
  • Recording the “Decision Logic” within the company’s ticketing system (e.g., Jira or Zendesk) for every event that is escalated to a formal security incident.
AI Companies Vital for protecting specialized AI model IP and sensitive training data. Focus is on assessing sophisticated anomalies in model behavior or dataset access patterns that could indicate a data poisoning or model theft attempt.
  • Establishing specialized criteria to assess “Inference Anomalies” and deciding if they are technical glitches or adversarial prompt-injection incidents.
  • Utilizing a “Record of Decision” for events involving unauthorized access to AI Model Weights, ensuring that any such event is automatically treated as a “Critical” incident.
  • Integrating the triage process with the company’s Adversarial Risk Framework to assess if unusual data download patterns represent a credible IP theft threat.

Fast Track ISO 27001 Annex A 5.25 Compliance with the ISO 27001 Toolkit

For ISO 27001 Annex A 5.25 (Assessment and decision on information security events), the requirement is to assess information security events and decide if they should be categorised as incidents. This ensures that every potential threat is triaged, prioritized, and met with an appropriate response, preventing minor events from escalating into major disasters.

Compliance Factor SaaS Compliance Platforms High Table ISO 27001 Toolkit Audit Evidence Example
Logic Ownership Rents access to assessment logic; if you cancel the subscription, your documented triage rules and decision history vanish. Permanent Assets: Fully editable Word/Excel Event Classification Matrices and formulas that you own forever. A localized “Event Assessment Formula” defining the specific impact/urgency thresholds for your business.
Decision Governance Attempts to “automate” triage via generic engines that cannot distinguish between a false positive and a nuanced breach. Governance-First: Formalizes your existing technical triage into an auditor-ready framework for informed decision-making. A recorded “Assessment Result” proving that a suspicious login alert was investigated and formally classified.
Cost Efficiency Charges an “Event Volume Tax” based on the number of logs or investigations, creating perpetual overhead as alerts grow. One-Off Fee: A single payment covers your assessment governance whether you triage 10 events or 10,000. Allocating budget to high-fidelity monitoring tools rather than monthly “dashboard” fees for logging triage notes.
Freedom of Strategy Mandates rigid scoring formats that may not align with your unique technical environment or specialized business impacts. 100% Agnostic: Procedures adapt to any stack—from lean IT teams to fully outsourced Security Operations Centers (SOC). The ability to evolve your event classification criteria without reconfiguring a rigid, third-party SaaS compliance module.

While SaaS compliance platforms often try to sell you “automated event triaging” or complex “risk scoring engines,” they cannot actually decide if a “suspicious login” from an employee on vacation is a false positive or a breach, those are human investigative and decision-making tasks. The High Table ISO 27001 Toolkit is the logical choice because it provides the assessment framework you need to categorize events effectively without a recurring subscription fee.

1. Ownership: You Own Your Assessment Rules Forever

SaaS platforms act as a middleman for your compliance evidence. If you define your event classification rules and store your decision logs inside their proprietary system, you are essentially renting your own investigative standards.

  • The Toolkit Advantage: You receive the Event Classification Matrix and Incident Assessment Formula in fully editable Word/Excel formats. These files are yours forever. You maintain permanent ownership of your standards (such as specific definitions for “High” vs. “Critical” severity), ensuring you are always ready for an audit without an ongoing “rental” fee.

2. Simplicity: Governance for Real-World Triage

Annex A 5.25 is about making decisions based on evidence. You don’t need a complex new software interface to manage what an existing security log or a simple triage checklist already does perfectly.

  • The Toolkit Advantage: Your IT team already looks at logs and alerts. What they need is the governance layer to prove to an auditor that these events are assessed consistently, using a formal impact/urgency formula. The Toolkit provides pre-written procedures and “Event Classification Matrices” that formalize your existing technical triage into an auditor-ready framework, without forcing your team to learn a new software platform just to log a decision.

3. Cost: A One-Off Fee vs. The “Event Volume” Tax

Many compliance SaaS platforms charge more based on the number of “logged events” or “investigations” you conduct. For a control that requires you to assess everything from blocked phishing to server outages, these monthly costs can scale aggressively.

  • The Toolkit Advantage: You pay a single, one-off fee for the entire toolkit. Whether you assess 10 events a year or 10,000, the cost of your Event Assessment Documentation remains the same. You save your budget for actual security monitoring tools rather than an expensive compliance dashboard.

4. Freedom: No Vendor Lock-In for Your Decision Strategy

SaaS tools often mandate specific ways to report on and categorize events. If their system doesn’t match your unique business impact definitions or specialized technical environment, the tool becomes a bottleneck to efficiency.

  • The Toolkit Advantage: The High Table Toolkit is 100% technology-agnostic. You can tailor the Assessment Procedures to match exactly how you operate, whether you use a dedicated SOC or a lean IT team. You maintain total freedom to evolve your triage strategy without being constrained by the technical limitations of a rented SaaS platform.

Summary: For Annex A 5.25, the auditor wants to see that you have a formal process for assessing events and proof that you are making informed decisions (e.g., recorded assessment results and prioritised incidents). The High Table ISO 27001 Toolkit provides the governance framework to satisfy this requirement immediately. It is the most direct, cost-effective way to achieve compliance using permanent documentation that you own and control.

Framework / Law Relevant Section / Control Mapping Context and Implementation Requirement
NIST CSF v2.0 RS.MA-01 (Incident Management) Requires establishing and maintaining an incident response plan that includes triage and assessment of events.
NIS2 Directive (EU) Article 21 (Risk Management) Mandates “incident handling” procedures. Annex A 5.25 is the specific gatekeeper for the Article 23 “Early Warning” reporting requirement.
DORA (EU) Article 17 (ICT Incident Management) ICT event detection and classification is mandatory. You must have a process to determine “Major” ICT-related incidents for reporting.
SOC2 (Trust Services) CC7.2 (Evaluation & Mitigation) Requires the organisation to evaluate security events to determine the necessity of a response and identify their impact.
UK GDPR / DPA 2018 Article 33 (Breach Notification) Assessment determines if a “personal data breach” has occurred, triggering the 72-hour notification window to the ICO.
UK Data (Use & Access) Act 2025 Section on Security Standards Maintains high security thresholds while streamlining the assessment records required for low-risk events to reduce “red tape.”
Cyber Security & Resilience Bill (UK) Mandatory Reporting Section Expands the scope of who must assess and report events, specifically targeting Managed Service Providers (MSPs).
CIRCIA (USA) 72-Hour Reporting Mandate Assessment of an event must be rapid enough to meet the strict 72-hour reporting deadline for critical infrastructure sectors.
EU AI Act Article 62 (Incident Reporting) Providers of high-risk AI systems must assess events to identify “serious incidents” that lead to health/safety breaches or fundamental rights violations.
ISO/IEC 42001 (AI) Annex A 10.4 (AI Incident Response) Specifically requires assessing if an AI system anomaly (event) constitutes a security or safety incident.
HIPAA (USA) 45 CFR § 164.308(a)(6)(i) The “Security Incident Procedures” standard requires the assessment of potential breaches of Protected Health Information (PHI).
CCPA / CPRA (California) Section 1798.150 Requires “reasonable security.” Failing to assess and decide on an event that leads to a breach creates statutory damage liability.
EU PLD (Product Liability) Article 6 (Defectiveness) Failing to assess an event that indicates a software vulnerability could be used as evidence of a “defective” product in liability claims.
ECCF (European Certification) High Assurance Level Requires certified products to have automated or formalised event assessment feeds for security label maintenance.
PCI DSS v4.0 Requirement 10.4.1 Requires immediate detection and assessment of failures of critical security control systems.

ISO 27001 Annex A 5.25 FAQ

What is ISO 27001 Annex A 5.25?

ISO 27001 Annex A 5.25 is a security control that requires organisations to assess information security events to determine whether they should be classified as information security incidents.

  • It provides a formalised process for filtering noise from genuine threats.
  • It ensures that incident response resources are only deployed when necessary.
  • It mandates the use of predefined criteria for consistent decision-making.

What is the difference between a security event and a security incident?

An information security event is an identified occurrence that indicates a possible breach, while a security incident is an event that has been confirmed to have an adverse effect on business operations.

  • Events: System log alerts, failed login attempts, or pintu-to-door visitors.
  • Incidents: Successful unauthorised access, data exfiltration, or service downtime.
  • Assessment: The process defined in 5.25 turns a “possible” event into a “confirmed” incident.

How do organisations assess information security events?

Organisations assess events by analysing the observed activity against a set of predefined impact thresholds and risk criteria established in the ISMS.

  • Technical Analysis: Reviewing system logs, traffic patterns, and user behaviour.
  • Impact Evaluation: Determining the potential effect on confidentiality, integrity, and availability.
  • Categorisation: Assigning a severity level based on the type of data or system affected.

Who is responsible for assessing security events under Annex A 5.25?

The responsibility typically lies with a designated individual or team with the appropriate technical knowledge, such as a Security Lead, SOC Analyst, or Incident Manager.

  • Authorisation: Only trained personnel should have the authority to classify an incident.
  • Escalation: The assessor must know exactly when to trigger the full Incident Response Plan.
  • Documentation: The assessor is responsible for recording the rationale behind the final decision.

What are the criteria for escalating an event to an incident?

Criteria for escalation usually include the breach of security policies, loss of data integrity, or any event that poses a significant risk to the organisation’s reputation.

  • Data Sensitivity: Any event involving Personal Identifiable Information (PII) or Intellectual Property.
  • Scale of Impact: Events affecting a large number of users or critical infrastructure.
  • Legal Obligations: Occurrences that trigger statutory reporting requirements (e.g., GDPR).

Should every security event be logged in a register?

Yes, organisations should maintain a log of all identified security events and the subsequent decisions made, as this forms a critical part of the audit trail.

  • Accountability: Proves that the organisation is actively monitoring and assessing threats.
  • Trend Analysis: Helps identify recurring “events” that may indicate a systemic weakness.
  • Compliance: Provides evidence for auditors that the 5.25 control is operating effectively.

How does Annex A 5.25 relate to Annex A 5.24?

Annex A 5.24 focuses on the planning and preparation for incident management, whereas Annex A 5.25 is the specific operational step of evaluating events as they happen.

  • Preparation (5.24): Writing the policy and defining the criteria.
  • Assessment (5.25): Applying the criteria to a live alert or observation.
  • Workflow: 5.25 is the “trigger” that puts the plans from 5.24 into active motion.

ISO 27001 controls and attribute values

Control type Information security properties Cybersecurity concepts Operational capabilities Security domains
Detective Confidentiality Respond Information Security Event Management Defence
Integrity Detect
Availability
, , , , , , ,

About the author

Stuart Barker
🎓 MSc Security 🛡️ Lead Auditor ⚡ 30+ Years Exp 🏢 Ex-GE Leader

Stuart Barker

ISO 27001 Ninja

Stuart Barker is a veteran practitioner with over 30 years of experience in systems security and risk management. Holding an MSc in Software and Systems Security, he combines academic rigor with extensive operational experience, including a decade leading Data Governance for General Electric (GE).

As a qualified ISO 27001 Lead Auditor, Stuart possesses distinct insight into the specific evidence standards required by certification bodies. His toolkits represent an auditor-verified methodology designed to minimise operational friction while guaranteeing compliance.

Shopping Basket
Scroll to Top