Handling information security incidents (ISO 27001 A.5.24 to A.5.28)
An information security incident is an event that harms, or could harm, the confidentiality, integrity or availability of your information. Examples include a phishing email that someone clicked on, a lost laptop or ransomware. ISO/IEC 27001:2022 covers handling incidents in five controls from Annex A: A.5.24 to A.5.28.
Together, these controls describe a fixed cycle: prepare, assess, respond, learn and keep evidence. If personal data is involved, the data breach notification duty to the Dutch Data Protection Authority (Autoriteit Persoonsgegevens) also applies. If you fall under NIS2, you also report significant incidents to the CSIRT (Dutch national computer security incident response team).
Short answer: for ISO 27001 you need an incident procedure (A.5.24), a way to assess reports (A.5.25), agreements on the response (A.5.26), an evaluation after each incident (A.5.27) and rules for keeping evidence (A.5.28). The most important piece of evidence is a maintained incident register.
The five incident controls in ISO 27001 Annex A
The controls follow the life cycle of an incident. Employees report events under A.6.8 “Information security event reporting”. After that, these five controls take over.
| Control | Title (ISO/IEC 27001:2022) | In plain language |
|---|---|---|
| A.5.24 | Information security incident management planning and preparation | Have the procedure, roles and contact details ready before anything happens |
| A.5.25 | Assessment and decision on information security events | Decide whether a report is an incident and how serious it is |
| A.5.26 | Response to information security incidents | Contain, resolve, communicate and report |
| A.5.27 | Learning from information security incidents | Find the cause and prevent repetition |
| A.5.28 | Collection of evidence | Secure logs and other traces so they remain usable |
The difference between an event and an incident matters. A blocked phishing email is an event. An employee who entered their password on a fake website is an incident.
Incident procedure in five steps
A workable procedure fits on two pages. Everyone needs to know where to report. A small group needs to know what happens next.
Report
Employees report anything suspicious to one fixed reporting point, for example security@ or the service desk. Ten false alarms are better than one missed incident. See awareness and training for how to teach this.
Assess and classify
The incident coordinator assesses within a fixed period, for example 4 working hours, whether it is an incident. They assign a severity: low, medium, high or critical.
Contain and resolve
Stop the damage first: block the account, wipe the laptop remotely, take the system off the network. Then recover, if needed using your backup.
Notify external parties
Within 24 hours, check whether a reporting duty applies: a data breach to the AP within 72 hours, the CSIRT under the Cybersecurity Act, and customers according to contract.
Evaluate and record
Close every incident by recording the cause, the measures taken and what you will improve. For high or critical incidents, hold a short evaluation with those involved.
Example incident register for ISO 27001
The incident register is your most important evidence. A spreadsheet is enough, as long as every field is completed. This is a fictional example of a consultancy with 40 employees.
| No. | Reported | Description | Severity | Personal data? | Reported to | Measure | Cause | Closed |
|---|---|---|---|---|---|---|---|---|
| 2026-07 | 3 March 2026, 09:12 | Employee enters password on a fake login page | High | Possibly (mailbox) | AP not needed after analysis, reasoning recorded | Password reset, sessions revoked, mail rules checked | Phishing; MFA missing on old account | 4 March 2026 |
| 2026-08 | 17 March 2026, 16:40 | Laptop left on a train | Medium | Yes | AP not needed: disk encrypted | Laptop wiped remotely | Human error | 18 March 2026 |
| 2026-09 | 2 April 2026, 11:05 | Quote with client details sent to the wrong recipient | Medium | Yes | AP notified 3 April 2026 | Recipient asked to delete, confirmation received | Autocomplete in email | 10 April 2026 |
For every data breach, also record why you did or did not report it. The AP requires you to register all data breaches, including those you do not report, and provides a sample data breach register . You can combine the data breach register and the incident register, as long as the mandatory GDPR fields are included.
Which reporting deadlines apply to an information security incident?
ISO 27001 itself sets no reporting deadlines. These come from legislation and contracts. Include them in your procedure so that nobody has to look them up during an incident.
| When | To whom | Deadline | Source |
|---|---|---|---|
| Data breach with a risk to individuals | Autoriteit Persoonsgegevens (Dutch Data Protection Authority) | Within 72 hours of discovery | GDPR (AVG) |
| Data breach with a high risk to individuals | The individuals themselves | Without undue delay | GDPR (AVG) |
| Significant incident at an NIS2 entity | CSIRT | Early warning within 24 hours, notification within 72 hours, final report within one month | Cybersecurity Act (Cyberbeveiligingswet) |
| Incident affecting a client | Client | According to contract or data processing agreement | Contract |
The Cybersecurity Act (Cyberbeveiligingswet), the Dutch implementation of NIS2, came into force on 15 August 2026. Read the NIS2 page to find out whether it applies to you. For a step-by-step guide to reporting a data breach, see the page reporting a data breach.
Securing evidence (A.5.28)
For a serious incident, you want to be able to reconstruct later what happened. Sometimes this is also needed for a criminal report or for your insurer. That is why you should decide in advance who collects evidence and how.
In practice, this means: do not immediately reinstall an infected laptop. First keep a copy of the disk. Export relevant logs before they are overwritten automatically. Note who did what and when. Good logging is the basis for this.
What does the auditor ask for as evidence for A.5.24 to A.5.28?
During the ISO 27001 audit, the auditor usually asks for:
- The approved incident procedure, with roles and contact details.
- The incident register for the period under review.
- Two or three handled incidents in detail, from report to evaluation.
- An example of an improvement measure that resulted from an incident.
- How employees know where to report.
An empty incident register is suspicious. Every organisation receives phishing emails, loses phones and sends emails to the wrong recipient. Zero incidents usually means that nothing is being reported.
Common mistakes in incident management
Only registering major incidents. Small incidents reveal patterns. Ten wrongly sent emails point to a structural problem.
No exercises. A procedure that has never been practised fails on a Saturday night. Run through one scenario a year, for example ransomware.
Skipping the cause analysis. “Human error” is rarely the real cause. Ask further: why was that mistake possible? A root cause analysis helps.
Not assessing the reporting duty. Even if you do not report, you must be able to explain why not.
More information
- Annex A: all 93 controls, including A.5.24 to A.5.28
- Logging and monitoring: detecting and reconstructing incidents
- NIS2 and ISO 27001: reporting duty under the Cybersecurity Act
- GDPR and ISO 27001: data breaches and the accountability obligation
- Mandatory documents: the incident register in the documentation set
- NCSC: the value of login information