In this guide you will learn how to implement ISO 27001 Annex A 5.25 Assessment and decision on information security events and pass your audit from ISO 27001 Lead Auditor Stuart Barker – author of the ultimate ISO 27001 Toolkit.
ISO 27001 Annex A 5.25 is an ISO 27001 control that requires an organisation to assess information security events to categorise and prioritise them.
Table of contents
- Purpose & Definition
- FREE ISO 27001 Annex A 5.25 Training Video
- Implementation Guide
- How to implement ISO 27001 Annex A 5.25
- How to comply
- How to Audit ISO 27001 Annex A 5.25
- How to pass the audit
- What the auditor will check
- Top 3 Mistakes People Make and How to Avoid Them
- ISO 27001 Annex A 5.25 FAQ
- Related ISO 27001 Controls and Further Reading
- ISO 27001 controls and attribute values
Purpose & Definition
The purpose of ISO 27001 Annex A 5.25 is a detective control that ensures effective categorisation and prioritisation of information security events.
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
ISO 27001 Starter Kit – ($97)
Instant download of the mandatory ISO 27001 ISMS and Polices. Auditor verifed and certification body aprroved, downloaded 5.000+ times globablly to achieve ISO 27001 certification first time.
FREE ISO 27001 Annex A 5.25 Training Video
In this free training video you will learn How to implement ISO 27001 Assessment and Decision on Information Security Events (Annex A 5.25).
Implementation Guide
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
Check Your Work?
You buit it yourself. Maybe with AI. But will it pass the audit?
Don’t gamble – let a trained ISO 27001 auditor check your work.
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.
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:
- Identify information security incidents.
- Assess the impact of information security incidents.
- Prioritise information security incidents.
- Respond to information security incidents.
- 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.”
How to pass the 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.
- Have a documented information security incident management plan.
- Implement the information security incident management plan.
- Monitor the effectiveness of the information security incident management plan.
- 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 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.
ISO 27001 Annex A 5.25 FAQ
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.
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.
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.
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).
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.
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.
Related ISO 27001 Controls and Further Reading
- ISO 27001 Annex A 6.8 Information Security Event Reporting
- ISO 27001 Annex A 8.15 Logging
- ISO 27001 Annex A 5.26 Response To Information Security Incidents
- The complete guide to ISO/IEC 27002:2022
- ISO 27001 Logging and Monitoring Policy Explained
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
