What is ISO 27001 Annex A 5.25 – Assessment and Decision on Information Security Events?
ISO 27001 Annex A 5.25 focuses on the assessment of information security events and deciding whether those events should be classified and managed as information security incidents.
Organizations generate security-related events every day.
For example:
- Failed login attempts
- Phishing emails
- Malware alerts
- Unusual login locations
- Antivirus detections
- Cloud security alerts
- Vulnerability alerts
- Lost devices
- Unexpected system changes
- Suspicious network activity
Not every event is a security incident.
The organization needs a consistent method to determine:
Is this simply a security event, or does it need to be treated as an information security incident?
Simple Explanation
A.5.24 prepares the organization to handle incidents. A.5.25 helps determine whether something that happened is actually an incident and how seriously it should be treated.
Event vs. Incident
This distinction is one of the most important concepts in A.5.25.
Information Security Event
An event is an observed occurrence that may be relevant to information security.
Examples:
- Five failed login attempts
- An employee reports a suspicious email
- Antivirus detects a potentially malicious file
- A cloud provider reports unusual activity
- A vulnerability scanner identifies a critical vulnerability
An event does not automatically mean that a security incident has occurred.
Information Security Incident
An incident is an event or series of events that has been assessed as compromising, or potentially compromising, information security or requiring a security response.
Examples:
- Confirmed unauthorized access
- Confirmed malware infection
- Customer data exposure
- Compromised administrator account
- Ransomware
- Unauthorized disclosure of confidential information
Simple Principle
Every incident is a security event, but not every security event is an incident.
Why is ISO 27001 Annex A 5.25 Important?
Without a defined assessment process, organizations can make two opposite mistakes.
Mistake 1: Underreaction
A serious incident is treated as a normal event.
Example:
“It was just a strange login.”
Later, the organization discovers that an attacker had accessed a privileged account.
Mistake 2: Overreaction
Every alert is treated as a major incident.
This can cause:
- Alert fatigue
- Unnecessary escalation
- Wasted resources
- Business disruption
- Incident-team fatigue
A.5.25 helps establish a consistent and risk-based decision process.
What Does A.5.25 Require?
The organization should establish a process for:
- Receiving security events
- Recording them
- Assessing their significance
- Determining whether they constitute incidents
- Classifying the incident where applicable
- Escalating according to defined criteria
- Initiating the appropriate response
The assessment should consider the organization’s:
- Security requirements
- Risk criteria
- Business impact
- Information sensitivity
- Legal and regulatory obligations
- Customer commitments
- Threat context
Relationship Between A.5.24 and A.5.25
These controls work together.
A.5.24
Planning and Preparation
“Are we prepared to handle security incidents?”
A.5.25
Assessment and Decision
“Has this security event become an incident, and what should we do about it?”
A.5.26
Response
“Now that we have identified an incident, how do we respond?”
A simplified lifecycle is:
Prepare → Detect → Assess → Decide → Respond → Recover → Learn
1. Establish a Security Event Reporting Process
Security events need to reach the appropriate people.
Events may come from:
- Employees
- IT helpdesk
- Security tools
- Cloud providers
- Customers
- Suppliers
- Vulnerability researchers
- Managed security providers
- Monitoring systems
Examples:
Employee reports phishing email
→ Security team receives report
AWS generates suspicious-login alert
→ Security team receives alert
Customer reports unauthorized activity
→ Support escalates to security
The organization should define how these events enter the assessment process.
2. Record Security Events
Important security events should be recorded sufficiently to support assessment.
An event record may include:
| Field | Example |
|---|---|
| Event ID | EVT-2026-015 |
| Date/time | 15 March 2026, 10:15 UTC |
| Source | AWS alert |
| Description | Unusual administrator login |
| Affected system | AWS production |
| Initial severity | Medium |
| Assessor | Security Lead |
| Decision | Incident |
| Incident ID | INC-2026-004 |
| Action | Account disabled |
Not every low-value event needs extensive documentation.
The level of recording should be proportionate to the organization’s environment.
3. Define Assessment Criteria
The organization should establish criteria for determining whether an event is significant.
Questions may include:
Confidentiality
Could unauthorized people access information?
Integrity
Could information or systems have been changed without authorization?
Availability
Could systems or information become unavailable?
Authenticity
Could someone be impersonating a legitimate user or system?
Business Impact
Could the event affect:
- Customers?
- Revenue?
- Operations?
- Reputation?
- Critical services?
Regulatory Impact
Could the event trigger:
- Data-breach assessment?
- Regulatory requirements?
- Contractual notification?
- Customer notification?
4. Assess the Credibility of the Event
Not every alert is genuine.
For example:
A security tool reports:
“Possible malicious login.”
The security team may investigate:
- Was the login actually successful?
- Was MFA completed?
- Was the IP address suspicious?
- Was the user traveling?
- Was a VPN involved?
- Did the user initiate the activity?
- Were any privileged actions performed?
The objective is to distinguish:
False positive → Suspicious event → Confirmed incident
5. Determine Whether the Event Is an Incident
A defined decision process should be used.
For example:
Event
Employee receives phishing email.
↓
Assessment
No link clicked.
No credentials entered.
No malware executed.
↓
Decision
Security event — not an incident.
Another example:
Event
Employee enters credentials into phishing site.
↓
Assessment
Credentials potentially compromised.
↓
Decision
Information security incident.
↓
Response
Reset credentials → Revoke sessions → Investigate → Monitor.
6. Classify the Incident
If the event is determined to be an incident, classify it.
For example:
| Level | Description | Example |
|---|---|---|
| Low | Limited impact | Single compromised low-risk account |
| Medium | Noticeable security impact | Malware on employee endpoint |
| High | Significant impact | Unauthorized access to confidential data |
| Critical | Major business/security impact | Ransomware affecting production |
The exact classification criteria should be defined by the organization.
7. Consider the Full Context
An event that looks small in isolation may become significant when combined with other events.
For example:
Event 1
Unusual login.
↓
Event 2
New MFA device registered.
↓
Event 3
Administrative privilege granted.
↓
Event 4
Large database query.
Individually, each event may appear manageable.
Together, they could indicate account compromise.
Therefore, assessment should consider patterns and relationships between events, not just individual alerts.
8. Establish Escalation Criteria
Certain events should automatically trigger escalation.
Examples include:
- Suspected customer-data breach
- Compromised privileged account
- Ransomware
- Major production outage
- Significant unauthorized access
- Large-scale malware infection
- Critical supplier security incident
- Suspected insider misuse
- Potential regulatory breach
The escalation path might be:
Security Analyst
↓
Incident Manager
↓
Management
↓
Legal / Privacy
↓
Customer / Regulatory notification assessment
Where appropriate.
9. Define Decision Authority
Someone should have authority to make the decision that an event is an incident.
For example:
| Decision | Responsible |
|---|---|
| Initial assessment | Security Analyst |
| Incident classification | Incident Manager |
| Major incident declaration | Incident Manager / Management |
| Legal notification assessment | Legal/Privacy |
| Customer communication | Authorized Management |
| Regulatory notification decision | Appropriate Legal/Privacy authority |
For a small startup, several responsibilities may belong to one person.
The important point is clear accountability.
10. Consider Threat Intelligence
Threat intelligence can provide useful context.
For example, a login from a particular IP address may initially look suspicious.
Threat intelligence could indicate that the IP is associated with:
- Known malicious infrastructure
- Credential attacks
- Botnets
- Malware campaigns
This information can help the organization assess the event.
This connects A.5.25 with A.5.7 – Threat Intelligence.
11. Consider Business and Customer Impact
Technical severity is not the only consideration.
For example:
A minor technical issue affecting an internal test system may have little business impact.
The same issue affecting a production customer database may be highly significant.
Assessment should therefore consider:
- Number of users affected
- Customers affected
- Data involved
- System criticality
- Business interruption
- Financial impact
- Contractual obligations
- Regulatory implications
Startup Example
Consider a SaaS company using:
- AWS
- GitHub
- Google Workspace
- Cloudflare
- PostgreSQL
- Customer-facing application
The security monitoring system reports:
Successful login to an administrator account from an unusual country.
Step 1 – Record
Security team creates:
EVT-2026-024
Step 2 – Validate
The team checks:
- Login time
- Source IP
- MFA
- User location
- VPN usage
- Recent password changes
- Administrative activity
Step 3 – Investigate
The team discovers:
- Login was successful
- MFA was bypassed through a stolen session
- New API credentials were created
- Production database was accessed
Step 4 – Decision
The event is classified as:
Information Security Incident – High Severity
Step 5 – Escalate
Incident Manager is activated.
Step 6 – Respond
Actions may include:
- Revoke sessions
- Disable account
- Revoke API credentials
- Preserve logs
- Investigate database access
- Determine affected information
- Assess customer/regulatory obligations
This is A.5.25 in practice.
Startup-Focused Quick Summary
A startup can implement A.5.25 through a simple decision process:
1. Receive
Capture security events from employees and security systems.
2. Record
Create an event record.
3. Validate
Determine whether the alert or report is genuine.
4. Assess
Evaluate security and business impact.
5. Decide
Determine whether it is an incident.
6. Classify
Assign severity.
7. Escalate
Notify the appropriate people.
8. Respond
Activate the incident-response process.
Example Security Event Assessment Matrix
| Assessment Question | Yes | No |
|---|---|---|
| Was unauthorized access confirmed? | Escalate | Continue assessment |
| Was confidential information exposed? | Escalate | Continue |
| Was a privileged account involved? | Escalate | Continue |
| Was production affected? | Escalate | Continue |
| Is there customer impact? | Escalate | Continue |
| Is there potential regulatory impact? | Legal/Privacy review | Continue |
| Is the event a confirmed threat? | Escalate | Monitor/close |
This should be adapted to the organization’s own risk criteria.
Event vs. Incident Decision Table
| Scenario | Likely Classification | Action |
|---|---|---|
| Failed login attempt | Security event | Monitor |
| Multiple failed logins | Security event / suspicious event | Investigate |
| Successful login from unusual location | Security event | Assess |
| Confirmed compromised account | Incident | Respond |
| Phishing email received but ignored | Security event | Record/monitor |
| Employee entered credentials into phishing site | Incident | Respond |
| Malware detected and automatically blocked | Security event | Assess |
| Confirmed malware execution | Incident | Respond |
| Public vulnerability announcement | Security event | Assess exposure |
| Confirmed exploitation of vulnerability | Incident | Respond |
| Cloud provider security notification | Security event | Assess impact |
| Confirmed customer data exposure | Incident | Escalate |
Audit Evidence for Annex A 5.25
An auditor may expect evidence showing that security events are being assessed consistently.
Procedures
- Security Event Assessment Procedure
- Incident Classification Procedure
- Incident Escalation Procedure
Records
- Security event tickets
- Incident register
- Security alerts
- Investigation records
- Classification decisions
- Escalation records
Tools
- SIEM
- EDR
- Cloud security monitoring
- Identity monitoring
- Vulnerability management tools
- Helpdesk/ticketing system
Decision Evidence
Examples:
- Event assessed as false positive
- Event classified as security event
- Event escalated to incident
- Incident severity assigned
- Management notified
Audit Checklist
Event Management
- Are security events identified?
- Can employees report suspicious activity?
- Are relevant alerts recorded?
- Are events assessed consistently?
Assessment
- Are assessment criteria defined?
- Is the credibility of alerts evaluated?
- Is confidentiality considered?
- Is integrity considered?
- Is availability considered?
- Is business impact considered?
- Is regulatory impact considered?
Decision
- Is there a defined incident decision process?
- Are incident classification criteria documented?
- Are decision authorities defined?
- Are significant events escalated?
Response
- Are confirmed incidents transferred into the incident-response process?
- Are incident records linked to the original event?
- Are decisions documented?
Improvement
- Are false positives reviewed?
- Are recurring events analyzed?
- Are assessment criteria improved when necessary?
Common Mistakes
1. Treating Every Alert as an Incident
A large number of security alerts can create unnecessary workload.
Assessment should distinguish genuine incidents from routine events and false positives.
2. Treating Every Event as a False Positive
The opposite problem can be even more dangerous.
Suspicious activity should be investigated before being dismissed.
3. No Defined Decision Criteria
If every analyst uses different judgment, similar events may receive completely different treatment.
4. No Documentation
An organization may have performed an assessment but have no evidence showing:
What happened → Who assessed it → What was decided → Why
5. Ignoring Business Impact
Technical teams may focus only on technical severity.
A relatively small technical event can have significant customer or regulatory consequences.
6. Looking at Events in Isolation
Attackers often perform multiple activities over time.
A series of individually minor events may represent a serious attack when viewed together.
7. No Clear Escalation Authority
People may hesitate during a serious incident because they do not know who can formally declare it an incident.
8. No Link Between Event and Incident Records
When an event becomes an incident, the original evidence and assessment should remain traceable.
Practical Startup Implementation Model
A simple model for A.5.25 is:
Capture → Validate → Assess → Decide → Classify → Escalate → Respond
Capture
Record the security event.
Validate
Determine whether the event is genuine.
Assess
Evaluate security, business, customer, and regulatory impact.
Decide
Determine whether the event constitutes an incident.
Classify
Assign severity.
Escalate
Notify the appropriate people.
Respond
Activate the incident-management process.
Policy vs. Process vs. Evidence
| Area | Policy | Process | Evidence |
|---|---|---|---|
| Event management | Incident Management Policy | Event Assessment Process | Event record |
| Classification | Incident Classification Policy | Severity Assessment | Classification record |
| Escalation | Incident Escalation Policy | Escalation Process | Escalation record |
| Investigation | Incident Investigation Policy | Investigation Procedure | Investigation report |
| Monitoring | Security Monitoring Policy | Alert Review Process | Security alerts |
| Decision-making | Incident Management Policy | Event-to-Incident Decision Process | Decision record |
Relationship with Other ISO 27001 Controls
A.5.7 – Threat Intelligence
Provides threat information that can help assess suspicious events.
A.5.24 – Incident Management Planning and Preparation
Establishes the organization’s readiness to manage incidents.
A.5.25 – Assessment and Decision on Information Security Events
Determines whether a security event should become an incident and how it should be classified.
A.5.26 – Response to Information Security Incidents
Provides the response after an event has been determined to be an incident.
A.5.27 – Learning from Information Security Incidents
Uses incidents to improve information security.
A.5.28 – Collection of Evidence
Supports investigation and evidence handling.
Together:
Prepare → Detect → Assess → Decide → Respond → Learn → Preserve Evidence
Useful Documents for A.5.25
A startup may create:
- Information Security Event Assessment Procedure
[Insert Draft Document Link] - Security Event Classification Matrix
[Insert Draft Document Link] - Incident Severity Matrix
[Insert Draft Document Link] - Security Event Reporting Form
[Insert Draft Document Link] - Security Event Register
[Insert Draft Document Link] - Incident Escalation Matrix
[Insert Draft Document Link] - Security Alert Investigation Checklist
[Insert Draft Document Link] - Event-to-Incident Decision Checklist
[Insert Draft Document Link]
Questions an Auditor May Ask
An auditor may ask:
How do you determine whether a security event is an incident?
What criteria do you use for incident classification?
Who makes the decision?
How do you handle false positives?
How do you assess the impact of an event?
How do you determine whether customer or personal information is affected?
How do you escalate a significant security event?
Can you show an example of a security event that was assessed and closed without becoming an incident?
Can you show an example where an event was escalated into an incident?
How do you ensure similar events are assessed consistently?
Startup-Focused Final Takeaway
ISO 27001 Annex A 5.25 is about making consistent, evidence-based decisions about security events.
The goal is not to turn every alert into an emergency.
The goal is also not to dismiss alerts too quickly.
The organization needs a practical process to determine:
What happened?
↓
Is it genuine?
↓
What is the impact?
↓
Does it constitute an incident?
↓
How serious is it?
↓
Who needs to know?
↓
What response is required?
Key Principle
Good incident management starts with good decisions: identify the event, assess the facts and impact, classify it consistently, and escalate when necessary.
Simple Sequence
Capture → Validate → Assess → Decide → Classify → Escalate → Respond
That is the practical purpose of ISO 27001 Annex A 5.25 – Assessment and Decision on Information Security Events.