Incidentresponsplan vs. Incidentmanagementsysteem: Wat NIS2 Werkelijk Vereist
Elk ISMS heeft een incidentresponsplan. NIS2 vereist een incidentmanagementsysteem. Het verschil is niet semantisch – het is operationeel. Wat een IMS concreet moet leveren, welke componenten het nodig heeft, en hoe u de overgang maakt van plan naar systeem.
Incidentresponsplan vs. Incidentmanagementsysteem: Wat NIS2 Werkelijk Vereist
De meeste organisaties hebben een incidentresponsplan. Ze hebben rollen gedefinieerd, escalatiepaden beschreven, contactlijsten gemaakt. Het probleem: een plan is een document. Een document werkt niet om 3 uur 's nachts wanneer de CISO op vakantie is, drie meldverplichtingen tegelijkertijd worden geactiveerd, en het bestuur een situatiebeoordeling nodig heeft.
NIS2 beoordeelt niet het plan. NIS2 beoordeelt de capaciteit. Dit artikel beschrijft wat een incidentmanagementsysteem concreet moet leveren – component voor component – en hoe u de overgang maakt van document naar operationeel systeem.
Ga naar:
- Plan vs. systeem: Het operationele verschil
- De zeven componenten van een NIS2-klaar IMS
- Het opbouwen in de praktijk
Waarom het Plan Niet Genoeg Is
Een incidentresponsplan (IRP) onder ISO 27001 is een onmisbaar governance-document. Het definieert hoe de organisatie moet reageren op beveiligingsincidenten: Wie is verantwoordelijk? Welke escalatieniveaus bestaan er? Welke stappen in welke volgorde?
Het probleem is niet het plan zelf. Het probleem is de aanname dat een goed plan een goede respons garandeert.
NIS2 heeft die aanname weerlegd – door concrete, deadline-gedreven eisen die niet met een document kunnen worden vervuld:
- Vroegtijdige waarschuwing binnen 24 uur aan de bevoegde autoriteit, met verplichte elementen en ingediend via een officieel portaal (Art. 23(4)(a))
- Melding binnen 72 uur met initiële beoordeling van ernst, impact en indicators of compromise (Art. 23(4)(b))
- Parallelle meldverplichtingen onder de AVG, contracten en mogelijk sectorspecifieke regelgeving
- Verifieerbare documentatie van de gehele incidentrespons – versiebeheerd, traceerbaar, op verzoek beschikbaar
- Kennisgeving aan dienstontvangers over significante incidenten die de dienstverlening kunnen beïnvloeden (Art. 23(1))
Dit alles moet gelijktijdig werken – onder tijdsdruk, met onvolledige informatie, over meerdere functies heen. Dit is geen proces dat u in een document kunt beschrijven en vervolgens "uitvoeren" tijdens een noodsituatie. Het is een besturingssysteem.
Plan vs. Systeem: Het Operationele Verschil
Dit onderscheid is geen woordspel. Het beschrijft twee fundamenteel verschillende volwassenheidsniveaus:
Een incidentresponsplan is reactief en statisch. Het wordt gemaakt, goedgekeurd, opgeborgen en geraadpleegd tijdens een noodsituatie. De kwaliteit hangt af van of de juiste mensen het hebben gelezen, of ze het onthouden, en of de realiteit overeenkomt met het plan.
Een incidentmanagementsysteem is proactief en dynamisch. Het zorgt ervoor dat de juiste workflows plaatsvinden – ongeacht of individuen het plan onthouden. Het coördineert, documenteert en escaleert automatisch. Het werkt ook wanneer de noodsituatie niet overeenkomt met het scenario in het plan.
| Eigenschap | Incidentresponsplan | Incidentmanagementsysteem |
|---|---|---|
| Formaat | Document (PDF, wiki, ISMS-tool) | Operationeel systeem met workflows |
| Activering | Handmatig – iemand moet het plan vinden en volgen | Systeemondersteund – workflows worden automatisch geactiveerd |
| Coördinatie | Beschreven maar niet afgedwongen | Gestructureerd en traceerbaar |
| Documentatie | Achteraf gereconstrueerd | Realtime logging |
| Meldverplichtingen | Verwezen als processtap | Geïntegreerd met deadlines, sjablonen, kanalen |
| Traceerbaarheid | Afhankelijk van discipline van individuen | Systemisch – elke actie wordt gelogd |
| Mensenafhankelijkheid | Hoog | Verminderd door rollen en plaatsvervangers |
| Testbaarheid | Tabletop-oefening tegen het plan | Tabletop-oefening tegen het systeem |
De volwassenheidssprong van plan naar systeem is de sprong die NIS2 afdwingt. Niet optioneel, niet "nice to have" – maar operationeel noodzakelijk om meldverplichtingen op tijd en met verifieerbaar bewijs te kunnen nakomen.
De Zeven Componenten van een NIS2-Klaar IMS
Een incidentmanagementsysteem hoeft niet monolithisch te zijn. Het moet zeven dingen leveren – en elke component kan met verschillende tools of processen worden geïmplementeerd. Wat telt is dat ze samenwerken.
1. Triage en Classificatie
Wat het moet leveren: Binnen minuten na het detecteren van een incident bepalen of het kwalificeert als een significant incident onder NIS2. De classificatie bepaalt welke meldverplichtingen van toepassing zijn en welke deadlines gaan lopen.
Concreet: Vooraf gedefinieerde criteria voor drempelbepaling: Welke incidenttypen zijn "significant"? Bij welk ernstniveau? Welke systemen/diensten zijn getroffen? Een beslisboom of checklist die onder stress kan worden toegepast – niet een beleidsdocument van drie pagina's dat eerst interpretatie vereist.
Veelgemaakte fout: Classificatie wordt meegetrokken in technische analyse en duurt uren in plaats van minuten. Maar de 24-uursdeadline loopt vanaf het moment van bewustwording – niet vanaf voltooiing van de analyse.
2. Rolactivering en Escalatie
Wat het moet leveren: De juiste mensen binnen minuten activeren – met duidelijke roltoewijzing en plaatsvervangerregelingen. Niet "Security is geïnformeerd" maar "Persoon X in rol Y is geactiveerd via kanaal Z; indien onbereikbaar neemt plaatsvervanger A over."
Concreet: Benoemde rollen voor elke fase: Incident Commander (algehele coördinatie), Technical Lead (technische analyse), Regulatory Lead (meldverplichtingen), Communications Lead (interne/externe communicatie), Executive Sponsor (bestuursniveau). Automatische escalatie als activering niet binnen een vastgestelde tijd wordt bevestigd.
Veelgemaakte fout: De escalatieketen bestaat op papier, maar niemand heeft het mobiele nummer van de plaatsvervanger. Of: het bestuur wordt te laat ingeschakeld omdat het beveiligingsteam eerst "meer feiten wil verzamelen."
3. Parallelle Meldverplichting-Management
Wat het moet leveren: Alle relevante meldverplichtingen identificeren en parallel beheren – met aparte deadlines, inhoudseisen en kanalen voor elk.
Concreet: Mapping van alle meldverplichtingen per incidenttype: NIS2 (24u/72u/1 maand aan autoriteit), AVG (72u aan gegevensbeschermingsautoriteit), contractuele verplichtingen (per contract), sectorspecifieke verplichtingen (per branche). Voor elke verplichting: sjabloon, deadline-tracking, verantwoordelijke persoon, indieningskanaal.
Veelgemaakte fout: Het NIS2-rapport wordt voorbereid terwijl de AVG-melding wordt vergeten – of andersom. Of: contractuele meldingsverplichtingen richting klanten worden pas ontdekt nadat de deadline al is verstreken.
4. Gestructureerde Situatierapportage
Wat het moet leveren: Een centraal, versiebeheerd situatierapport dat de huidige stand van kennis over het incident samenvat – en aangepast kan worden voor verschillende doelgroepen.
Concreet: Een levend document (geen statische PDF) dat continu wordt bijgewerkt: Wat weten we? Wat weten we niet? Wat is er veranderd sinds de vorige versie? Welke besluiten staan open? Het situatierapport moet bestaan in een versie voor technische analyse, een versie voor het bestuur, en een versie voor het rapport aan de toezichthouder.
Veelgemaakte fout: Er is geen centraal situatierapport. In plaats daarvan circuleren diverse e-mails, chatberichten en mondelinge updates met tegenstrijdige informatie. Het bestuur neemt besluiten op basis van verouderde informatie.
5. Versiebeheerde Realtime Documentatie
Wat het moet leveren: Elk besluit, elke actie, elke communicatie wordt gedocumenteerd – met tijdstempel, verantwoordelijke en context. Niet achteraf, maar tijdens de incidentrespons.
Concreet: Een centraal logboek dat automatisch vastlegt: Wie nam welk besluit wanneer? Op basis van welke informatie? Welke acties werden geïnitieerd? Welke communicatie vond plaats – intern en extern? Dit logboek moet audit-grade zijn – het is het bewijs dat de organisatie haar verplichtingen heeft nagekomen.
Veelgemaakte fout: Documentatie wordt "na het incident bijgewerkt" – gereconstrueerd uit e-mails, chatgeschiedenis en herinneringen. Onder NIS2 is dit niet bewijs-grade en creëert het problemen tijdens een beoordeling door de toezichthouder.
6. Externe Communicatie-Management
Wat het moet leveren: Gecoördineerde, goedgekeurde communicatie naar buiten – richting autoriteiten, klanten, partners en mogelijk het publiek. Afgestemd tussen Legal, Communicatie en het bestuur voordat het naar buiten gaat.
Concreet: Vooraf goedgekeurde communicatiesjablonen voor de meest voorkomende scenario's. Een goedkeuringsproces dat snel genoeg is om melddeadlines te halen maar grondig genoeg om juridische risico's te vermijden. Versiebeheerde documentatie van alle externe communicatie.
Veelgemaakte fout: De PR-afdeling communiceert voordat Legal heeft goedgekeurd. Of: Legal blokkeert alle communicatie totdat het incident volledig is geanalyseerd – waardoor de melddeadline wordt overschreden.
7. Post-Incident Review en Bewijsbewaring
Wat het moet leveren: Na het incident: root cause analyse, lessons learned, IMS-updates. Maar bovenal: bewaring van al het bewijs voor regulatoire documentatie – het eindrapport (1 maand na initiële melding) en opslag voor eventuele latere beoordelingen door de toezichthouder.
Concreet: Gestructureerde post-incident review met alle betrokkenen. Consolidatie van alle artefacten: situatierapporten, besluitlogs, regulatoire indieningen, communicatie, technische analyses. Archivering in een formaat dat traceerbaar en audit-grade is. Identificatie van verbetermaatregelen en hun opvolging.
Veelgemaakte fout: De post-incident review wordt uitgesteld en vervolgens vergeten. Of: artefacten zijn verspreid over verschillende systemen en kunnen niet worden samengesteld wanneer een toezichthouder ze later opvraagt.
Het Opbouwen in de Praktijk
Stap 1: Inventarisatie (Week 1)
Wat hebt u al? In de meeste organisaties bestaan delen van een IMS maar zijn ze niet verbonden: Een IRP in het ISMS. Een ticketingsysteem voor beveiligingsincidenten. Een e-maildistributielijst voor escalatie. Misschien een war room of crisisteamprocedure.
Breng deze elementen in kaart tegen de zeven componenten hierboven. Waar is dekking? Waar zitten de hiaten?
Stap 2: Hiaten Dichten – Snel (Week 2–4)
Begin met componenten die direct kunnen worden geïmplementeerd en de grootste impact hebben:
- Definieer triagecriteria: Wanneer is een incident "significant"? Beslisboom op één pagina. Afstemmen, goedkeuren, distribueren.
- Wijs rollen op naam toe: Incident Commander, Regulatory Lead, Communications Lead, Executive Sponsor – met plaatsvervangers en bereikbaarheid.
- Maak meldverplichting-mapping: Welke verplichtingen gelden voor welk incidenttype? Deadlines, inhoud, kanalen, verantwoordelijken.
- Bereid sjablonen voor: Sjablonen voor 24u vroegtijdige waarschuwing, 72u melding, eindrapport – vooraf gemaakt en vooraf goedgekeurd.
Stap 3: Systematiseren (Maand 1–3)
Verbind nu de componenten:
- Richt situatierapportage in: Centrale locatie voor het versiebeheerde situatierapport – toegankelijk voor alle rollen, met wijzigingsgeschiedenis.
- Automatiseer documentatie: Elk besluit, actie en communicatie wordt voorzien van tijdstempel en gelogd.
- Bereid externe communicatie voor: Sjablonen, goedkeuringsproces, kanaalbeheer voor autoriteiten, klanten, partners.
Stap 4: Testen (Maand 2–3)
Een tabletop-oefening tegen het systeem – niet tegen het plan. Realistisch scenario, echte tijdslimieten, alle rollen bezet:
- Kan triage binnen 30 minuten worden afgerond?
- Zijn de juiste rollen binnen één uur geactiveerd?
- Kan de 24u vroegtijdige waarschuwing op tijd worden geproduceerd en ingediend?
- Worden parallelle meldverplichtingen herkend en beheerd?
- Is documentatie compleet en traceerbaar?
Elke oefening onthult hiaten. Dat is het doel van de oefening.
Stap 5: Itereren (Doorlopend)
Een IMS is nooit af. Het verbetert door elke oefening, elk echt incident en elke feedbackcyclus. Minimaal twee tabletop-oefeningen per jaar – met wisselende scenario's en deelname van het bestuur.
De IMS Volwassenheidstoets
Vijf vragen om het huidige volwassenheidsniveau van uw incidentmanagement te beoordelen:
-
Kunt u binnen 30 minuten na detectie van een incident bepalen of er een NIS2-meldplicht geldt? Zo niet: triagecomponent ontbreekt of is te traag.
-
Weet u op dit moment – nu – wie uw Incident Commander is en hoe u deze om 3 uur 's nachts bereikt? Zo niet: rolactivering is niet geoperationaliseerd.
-
Hebt u sjablonen voor de 24u vroegtijdige waarschuwing en 72u melding die vooraf zijn goedgekeurd en getest? Zo niet: meldverplichting-management is niet voorbereid.
-
Kunt u na een incident exact aantonen wie wanneer welk besluit heeft genomen? Zo niet: realtime documentatie ontbreekt.
-
Hebt u in de afgelopen zes maanden een tabletop-oefening uitgevoerd tegen NIS2-melddeadlines? Zo niet: het systeem is ongetest – en een ongetest systeem is geen systeem.
Bronnen
- Richtlijn (EU) 2022/2555 (NIS2-richtlijn) – Volledige tekst – Artikel 21(2)(b) over incidentafhandeling, Artikel 23 over meldverplichtingen.
- OpenKRITIS - NIS2-Umsetzungsgesetz in Deutschland – § 32 BSIG over het drietraps-meldregime.
- ENISA – Implementing Guidance on NIS2 Security Measures – Implementatierichtlijnen voor incidentafhandeling en -melding.
- ISO/IEC 27001:2022 – Annex A, A.5.24-A.5.28 – ISO-controls voor incidentmanagement als vergelijkingsbasis.