Incidents happen. The question ISO 27001 asks is not whether you have had a security incident — it is whether you have a structured process for handling them when they do. Annex A.5.24 through A.5.28 cover the full incident management lifecycle, from planning and reporting through to evidence collection and learning. Auditors in Stage 2 will always ask to see your incident log and at least one closed incident with evidence of how it was handled.
What Counts as a Security Incident?
ISO 27001 does not restrict "incident" to catastrophic breaches. An incident is any event that has — or could have — an adverse effect on the confidentiality, integrity, or availability of your information assets. That includes:
- A phishing email that a staff member clicked (even if no data was exfiltrated)
- Accidental sending of customer data to the wrong email recipient
- A laptop lost or stolen
- Unauthorised access to a system or file
- A prolonged system outage affecting data availability
- Discovery of malware on an endpoint
- A contractor accessing more data than their role required
A useful distinction: a security event is something that happens. A security incident is an event that you assess as having had (or potentially having had) an adverse impact. Not every event escalates to an incident, but you must have a process for making that assessment.
The 6-Step Incident Lifecycle
Detect
Identify that an event has occurred — through monitoring tools, staff reporting, or external notification. Your process must define how incidents can be reported (e.g., a dedicated email address or a ticket in your ITSM tool).
Report
All staff must know how and to whom to report a potential security incident. This is not optional — A.5.24 requires a formal reporting mechanism and staff must be aware of their responsibility to use it.
Assess
Classify the reported event: is it a security incident? If so, what is the severity? Who is affected? Is there a regulatory notification obligation (e.g., GDPR 72-hour breach notification)?
Respond
Contain the incident. Isolate affected systems, revoke compromised credentials, notify affected parties as required. Document all actions taken with timestamps.
Recover
Restore normal operations. Verify that the issue has been resolved and that the affected systems are secure. Only close the incident after a formal assessment confirms recovery.
Learn
Conduct a post-incident review. Identify root cause, contributing factors, and what should change to prevent recurrence. This is A.5.27 — lessons learned must feed back into your ISMS.
What Your Incident Log Must Capture
Every incident must be recorded. The incident log is one of the first documents an auditor requests in Stage 2. At minimum, each entry should contain:
| Field | Description |
|---|---|
| Incident ID | Unique reference number |
| Date/time detected | When the event was first identified |
| Reporter | Who reported it and via which channel |
| Description | What happened, what assets were affected |
| Severity | Low / Medium / High / Critical |
| Actions taken | Timestamped log of containment and recovery steps |
| Root cause | Identified after the incident is contained |
| Lessons learned / corrective action | What will be done differently; links to any nonconformity raised |
| Closure date | When the incident was formally closed and by whom |
The Most Common Incident Management Failures
No incidents recorded at all
An empty incident log tells an auditor one of two things: either no incidents have occurred (which is statistically unlikely for any active organisation), or incidents have occurred but were not logged. Both are problems. Even minor events — a phishing email, a lost phone — should be in the log.
No lessons learned section
Recording what happened without documenting what changes as a result fails A.5.27. Every closed incident should have a lessons learned entry, even if the conclusion is "no change required — existing controls were sufficient."
Staff do not know how to report incidents
A.5.24 requires that staff know their responsibilities. If you ask a random employee "how do you report a security incident?" and they do not know, that is an audit finding waiting to happen.
If you want help designing and testing your incident management process, our ISO 27001 consulting service covers incident response as part of a structured ISMS implementation.