Informatiebeveiligingsincidenten afhandelen (ISO 27001 A.5.24–A.5.28)
Een informatiebeveiligingsincident is een gebeurtenis die de vertrouwelijkheid, integriteit of beschikbaarheid van je informatie schaadt of kan schaden. Denk aan een phishingmail waarop iemand klikte, een kwijtgeraakte laptop of ransomware. ISO/IEC 27001:2022 regelt het afhandelen van incidenten in vijf maatregelen uit Annex A: A.5.24 tot en met A.5.28.
Samen beschrijven die maatregelen een vaste cyclus: voorbereiden, beoordelen, reageren, leren en bewijs bewaren. Gaat het om persoonsgegevens, dan geldt daarnaast de meldplicht datalekken bij de Autoriteit Persoonsgegevens . Val je onder NIS2, dan meld je significante incidenten ook bij het CSIRT.
Kort antwoord: voor ISO 27001 heb je een incidentprocedure nodig (A.5.24), een manier om meldingen te beoordelen (A.5.25), afspraken over de reactie (A.5.26), een evaluatie na elk incident (A.5.27) en regels voor het bewaren van bewijs (A.5.28). Het belangrijkste bewijsstuk is een bijgehouden incidentregister.
De vijf incidentmaatregelen in ISO 27001 Annex A
De maatregelen volgen de levensloop van een incident. Medewerkers melden gebeurtenissen via A.6.8 “Information security event reporting”; daarna nemen deze vijf maatregelen het over.
| Maatregel | Titel (ISO/IEC 27001:2022) | In gewone taal |
|---|---|---|
| A.5.24 | Information security incident management planning and preparation | Procedure, rollen en contactgegevens klaar hebben vóór er iets gebeurt |
| A.5.25 | Assessment and decision on information security events | Bepalen of een melding een incident is en hoe ernstig |
| A.5.26 | Response to information security incidents | Inperken, oplossen, communiceren en melden |
| A.5.27 | Learning from information security incidents | Oorzaak achterhalen en herhaling voorkomen |
| A.5.28 | Collection of evidence | Logs en andere sporen veiligstellen zodat ze bruikbaar blijven |
Het verschil tussen een gebeurtenis en een incident is belangrijk. Een geblokkeerde phishingmail is een gebeurtenis. Een medewerker die zijn wachtwoord invulde op een nepsite is een incident.
Incidentprocedure in vijf stappen
Een werkbare procedure past op twee pagina’s. Iedereen moet weten waar hij meldt; een kleine groep moet weten wat er daarna gebeurt.
Melden
Medewerkers melden alles wat verdacht is bij één vast meldpunt, bijvoorbeeld security@ of de servicedesk. Liever tien onterechte meldingen dan één gemiste. Zie bewustwording en training voor hoe je dat aanleert.
Beoordelen en classificeren
De incidentcoördinator beoordeelt binnen een vaste termijn, bijvoorbeeld 4 werkuren, of het een incident is. Hij kent een ernst toe: laag, midden, hoog of kritiek.
Inperken en oplossen
Stop de schade eerst: account blokkeren, laptop op afstand wissen, systeem van het netwerk halen. Daarna herstel je, eventueel met je back-up.
Melden aan externen
Check binnen 24 uur of er een meldplicht geldt: datalek bij de AP binnen 72 uur, CSIRT onder de Cyberbeveiligingswet, klanten volgens contract.
Evalueren en vastleggen
Sluit elk incident af met de oorzaak, de genomen maatregelen en wat je verbetert. Bij hoge of kritieke incidenten houd je een korte evaluatie met de betrokkenen.
Voorbeeld incidentregister ISO 27001
Het incidentregister is je belangrijkste bewijs. Een spreadsheet volstaat, zolang alle velden worden ingevuld. Dit is een fictief voorbeeld van een adviesbureau met 40 medewerkers.
| Nr. | Gemeld | Omschrijving | Ernst | Persoonsgegevens? | Gemeld aan | Maatregel | Oorzaak | Gesloten |
|---|---|---|---|---|---|---|---|---|
| 2026-07 | 03-03-2026 09:12 | Medewerker vult wachtwoord in op nep-inlogpagina | Hoog | Mogelijk (mailbox) | AP niet nodig na analyse, onderbouwing vastgelegd | Wachtwoord gereset, sessies ingetrokken, mailregels gecontroleerd | Phishing; MFA ontbrak op oud account | 04-03-2026 |
| 2026-08 | 17-03-2026 16:40 | Laptop laten liggen in trein | Midden | Ja | AP niet nodig: schijf versleuteld | Laptop op afstand gewist | Menselijke fout | 18-03-2026 |
| 2026-09 | 02-04-2026 11:05 | Offerte met klantgegevens naar verkeerde ontvanger | Midden | Ja | AP gemeld 03-04-2026 | Ontvanger gevraagd te verwijderen, bevestiging ontvangen | Autocomplete in e-mail | 10-04-2026 |
Leg bij elk datalek ook vast waarom je wel of niet hebt gemeld. De AP eist dat je alle datalekken registreert, ook die je niet meldt, en biedt daarvoor een voorbeeld-datalekregister . Je kunt het datalekregister en het incidentregister combineren, zolang de verplichte AVG-velden erin staan.
Welke meldtermijnen gelden bij een informatiebeveiligingsincident?
ISO 27001 zelf kent geen meldtermijnen. Die komen uit wetgeving en contracten. Neem ze op in je procedure, zodat niemand ze tijdens een incident hoeft op te zoeken.
| Wanneer | Bij wie | Termijn | Bron |
|---|---|---|---|
| Datalek met risico voor betrokkenen | Autoriteit Persoonsgegevens | Binnen 72 uur na ontdekking | AVG |
| Datalek met hoog risico voor betrokkenen | De betrokkenen zelf | Zonder onredelijke vertraging | AVG |
| Significant incident bij een NIS2-entiteit | CSIRT | Vroegtijdige waarschuwing binnen 24 uur, melding binnen 72 uur, eindverslag binnen een maand | Cyberbeveiligingswet |
| Incident dat een klant raakt | Klant | Volgens contract of verwerkersovereenkomst | Contract |
De Cyberbeveiligingswet, de Nederlandse uitwerking van NIS2, is op 15 augustus 2026 in werking getreden. Lees op de NIS2-pagina of je eronder valt. Hoe je een datalek stap voor stap meldt, staat op de pagina datalek melden.
Bewijs veiligstellen (A.5.28)
Bij een ernstig incident wil je later kunnen reconstrueren wat er gebeurde. Soms is dat ook nodig voor aangifte of je verzekeraar. Leg daarom vooraf vast wie bewijs verzamelt en hoe.
Praktisch betekent dat: zet een geïnfecteerde laptop niet direct opnieuw op, maar bewaar eerst een kopie van de schijf. Exporteer relevante logs voordat ze automatisch worden overschreven. Noteer wie wat wanneer heeft gedaan. Goede logging is hier de basis.
Wat vraagt de auditor als bewijs voor A.5.24 tot en met A.5.28?
Tijdens de ISO 27001-audit vraagt de auditor meestal naar:
- De vastgestelde incidentprocedure met rollen en contactgegevens.
- Het incidentregister van de afgelopen periode.
- Twee of drie afgehandelde incidenten in detail, van melding tot evaluatie.
- Een voorbeeld van een verbetermaatregel die uit een incident voortkwam.
- Hoe medewerkers weten waar ze moeten melden.
Een leeg incidentregister is verdacht. Elke organisatie heeft phishingmails, verloren telefoons en verkeerd verstuurde mails. Nul incidenten betekent voor de auditor meestal dat er niet gemeld wordt.
Veelgemaakte fouten bij incidentmanagement
Alleen grote incidenten registreren. Kleine incidenten laten patronen zien. Tien keer een verkeerd verstuurde mail wijst op een structureel probleem.
Geen oefening. Een procedure die nooit is geoefend, faalt op zaterdagnacht. Speel één keer per jaar een scenario door, bijvoorbeeld ransomware.
Oorzaakanalyse overslaan. “Menselijke fout” is zelden de echte oorzaak. Vraag door: waarom kon die fout gebeuren? Een root cause analyse helpt.
Meldplicht niet beoordelen. Ook als je niet meldt, moet je kunnen uitleggen waarom niet.
Meer informatie
- Annex A: alle 93 beheersmaatregelen, inclusief A.5.24 tot en met A.5.28
- Logging en monitoring: incidenten ontdekken en reconstrueren
- NIS2 en ISO 27001: meldplicht onder de Cyberbeveiligingswet
- AVG en ISO 27001: datalekken en de verantwoordingsplicht
- Verplichte documenten: het incidentregister in de documentatieset
- NCSC: de waarde van loginformatie