Information security incident management for ISO 27001: a practical guide

An information security incident is an event that has, or could have, harmed the confidentiality, integrity or availability of your information: a phishing email someone clicked, a lost laptop, a supplier breach, an outage, data sent to the wrong person. Incident management is how you spot them, deal with them, and learn from them.

You don't need a security operations centre. You need a clear way to report, a person who takes charge, and a record of what happened.

Why it matters

Incident management is covered by Annex A controls 5.24 to 5.28 of ISO/IEC 27001:2022. In summary, they ask you to:

• Plan and prepare (5.24): define how incidents are handled, and who does what.
• Assess and decide (5.25): judge whether an event is an incident, and how serious.
• Respond (5.26) using your documented procedures.
• Learn (5.27): use what you learn to strengthen controls.
• Collect evidence (5.28) in a way that would stand up if needed.

Control 6.8 asks that staff can report events quickly through a known channel.

If personal data is involved, UK GDPR may require you to report the breach to the ICO within 72 hours of becoming aware of it, and sometimes to tell the people affected.

What an auditor looks for

• A known way to report. Staff can say how they'd report a suspected incident.
• Incidents are actually logged, including small ones. A year with no incidents at all usually means nobody is reporting.
• Each record shows triage, actions, owner and closure, with dates.
• Lessons learned are acted on, often through a nonconformity or improvement.
• Personal data breaches were assessed for ICO reporting, with the decision recorded.

Common reasons it fails: no records; records with no outcome; serious incidents with no post-incident review; or breaches where nobody considered the 72-hour rule.

A simple response flow

1. Report: anyone who sees something reports it straight away.
2. Triage: the incident lead decides: is it an incident? How serious? Is personal data involved?
3. Contain: stop the harm spreading (reset the password, isolate the device, revoke access).
4. Fix and recover: remove the cause and restore normal service.
5. Notify: customers, the ICO or others if required, within the deadlines.
6. Review: what happened, why, and what changes. Record actions with owners.

Common mistakes, and how to keep it manageable

• Reporting only big things. Encourage reporting near misses; they show where to improve before something worse happens.
• Evidence scattered across inboxes. Keep emails, screenshots and notes with the incident record.
• No owner. Every incident needs one person in charge until it's closed.
• Skipping the review. A short review after every significant incident is where the value is.

How to do it in ClearIMS

1. Open Incidents and log the incident: what happened, when, who's leading, and how serious it is.
2. Use the incident's own email address. Each incident can have its own randomly generated email address. Forward or copy emails there, including from suppliers, and they're filed against the incident.
3. Let the AI do the admin. It summarises what comes in, suggests tasks and updates the incident's timeline. People still make the decisions.
4. Track actions with owners and due dates. ClearIMS emails owners when they're due.
5. Close with a review. Record what you learned, and raise a nonconformity or improvement where something needs to change.

Related pages

• Nonconformities: where lessons become corrective actions.
• Business continuity: for incidents that disrupt operations.
• Tabletop exercises: practising your response.
• UK GDPR overview: when an incident is a personal data breach.