Information security event is an identified technical occurrence indicating a potential breach of security policy or failure of safeguards within an ISMS. The Primary Implementation Requirement involves provisioning centralised logging and classification schemes under Annex A 5.24, delivering the Business Benefit of £1.1 million in average detection-cost savings and hardened digital resilience.
What is an Information security event?
An information security event is an event that can affect the confidentiality, integrity, or availability of information. It’s like something unusual happening with your data that might be a security problem. This can be anything from a small error to a big security threat. The word “event” means something that happens, and “information security” means protecting your data.
Examples
- A login failure: Someone tries to log in with the wrong password too many times.
- Malware detected: Your computer finds a virus or other malicious software.
- Unusual network activity: There’s a lot of data being sent from a computer at an odd time.
- A lost or stolen laptop: A device with important data is missing.
Context
When a security event happens, an organisation needs to figure out if it’s a security incident. A security incident is an event that harms or threatens the security of an organisation’s data. Not all security events become incidents, but they all need to be looked at to be safe. For example, one login failure might just be a typo, but 100 login failures in a row could be a hacking attempt.
How to implement Information security event
1. Provision a Centralised Logging Architecture
- Provision a technical solution for capturing 100 per cent of system, application, and network logs: Aggregate data into a secure repository, resulting in a single source of truth for event analysis and forensic investigation.
2. Formalise Event Classification Schemes
- Formalise a tiered classification matrix to distinguish between normal, suspicious, and malicious events: Define specific technical thresholds, resulting in a consistent identification process that prevents “alert fatigue” for security personnel.
3. Document Technical Rules of Engagement (ROE)
- Document the technical Rules of Engagement for event monitoring: Establish granular protocols for log review frequencies and escalation triggers, resulting in authorised technical conduct and predictable response paths.
4. Provision Granular IAM Roles for Log Access
- Provision specific Identity and Access Management roles for the security operations team: Map user permissions based on the principle of least privilege, resulting in the technical prevention of unauthorised log modification or deletion.
5. Enforce Multi-Factor Authentication (MFA) for Security Portals
- Enforce MFA for 100 per cent of access to logging and monitoring systems: Mandate strong authentication at the system boundary, resulting in a robust technical barrier against attackers attempting to mask their events.
6. Formalise Real-Time Alerting Triggers
- Formalise automated alerting for high-risk events such as failed MFA attempts or privilege escalations: Configure technical thresholds within your monitoring tools, resulting in the immediate notification of potential security breaches.
7. Audit Log Integrity and Synchronisation
- Audit the use of Network Time Protocol (NTP) across 100 per cent of systems: Synchronise timestamps across the environment, resulting in accurate technical sequencing of events during a post-event root cause analysis.
8. Provision an Information Asset Register for Event Mapping
- Provision a link between system events and the Information Asset Register: Map 100 per cent of critical assets to their respective logs, resulting in rapid impact assessment when an event occurs on a high-value system.
9. Revoke Legacy Logging Configurations
- Revoke outdated or redundant logging rules that create technical noise: Execute a formal sunsetting process for legacy event triggers, resulting in a streamlined monitoring environment that increases detection accuracy.
10. Audit the Event Management Lifecycle
- Audit the effectiveness of event detection through independent internal assessments: Execute regular spot checks on log coverage and alert responsiveness, resulting in a documented corrective action plan that satisfies ISO 27001 Clause 10.
Information security event FAQ
What is an information security event in ISO 27001?
An information security event is an identified occurrence of a system, service, or network state indicating a possible breach of information security policy or failure of controls. Under ISO 27001 Annex A 5.24, an event is a neutral observation that requires technical evaluation to determine if it will escalate into a security incident.
What is the difference between an information security event and an incident?
The difference lies in the impact: an event is any observable change in system behaviour, whereas an incident is one or more events that result in actual harm to business operations. Statistics show that while a typical enterprise logs over 100,000 events daily, fewer than 0.1% are classified as confirmed security incidents requiring full response activation.
What are some common examples of technical security events?
Common technical security events that indicate potential threats include:
- Access Anomalies: Multiple failed login attempts for 100% of privileged IAM roles within a 5-minute window.
- Configuration Changes: Unauthorised modification of firewall rules or system kernel parameters.
- Resource Spikes: Sudden 90% CPU utilisation indicating a potential DDoS event or malware execution.
- Data Egress: Large file transfers to unrecognised external IP addresses.
What is the financial risk of failing to monitor security events?
Failing to monitor security events increases the “dwell time” of attackers, which averages 277 days for undetected breaches. The financial impact of this delay is significant, as organisations that identify events within 200 days save an average of £1.1 million compared to those with slower technical detection capabilities.
How does a Lead Auditor verify information security event management?
A Lead Auditor verifies event management by sampling 100% of log aggregation records and technical escalation playbooks. They seek objective evidence that events are classified according to risk and that monitoring tools, such as SIEM solutions, are configured to alert technical staff of anomalies that bypass standard security perimeters.
Relevant ISO 27001 Controls
| Related ISO 27001 Control | Relationship Description |
|---|---|
| ISO 27001 Annex A 5.24: Incident Management Planning | Pre-emptive Step: Provides the framework for identifying and preparing for events that could potentially escalate into security incidents. |
| ISO 27001 Annex A 5.25: Assessment of Events | Core Process: The specific control that mandates assessing “Events” to determine if they should be classified as “Incidents.” |
| ISO 27001 Annex A 5.26: Response to Incidents | Escalation Path: If a security event is assessed and found to have a negative impact or pose a threat, it is managed through this incident response control. |
| ISO 27001 Annex A 8.15: Logging | Detection Tool: System logs are the primary technical source for discovering security events, such as failed logins or unusual network activity. |
| ISO 27001 Annex A 8.16: Monitoring Activities | Visibility: Active monitoring is required to identify “Events” in real-time before they can cause damage or become major incidents. |
| Glossary: Incident | Related Concept: An event is the occurrence of a state; it only becomes an “Incident” when it is confirmed to harm or threaten data security. |
| Glossary: CIA Triad | Security Impact: An event is categorized by its potential to affect the Confidentiality, Integrity, or Availability of information. |
| ISO 27001 Glossary of Terms (Main Index) | Parent Directory: The central index where Information Security Event is categorized as a fundamental incident management term. |
The Tools We Use.
100% Audit Success. Zero AI Guesswork.
About the author
