Incident response plan voor het mkb onder NIS2: de 24-72-30 in de praktijk

Sinds NIS2 komt op elke mkb-directie de vraag: “Hebben wij een incident response plan?” Meestal is het antwoord “zoiets ligt bij IT” en bedoelt IT daarmee een PDF uit 2019. Een werkbaar incident response plan mkb NIS2 begint met accepteren dat je 24 uur hebt vanaf het moment van bewustwording, niet vanaf de eerste alert. Belangrijk vooraf: dit is een technische en operationele leidraad, geen juridisch advies. Voor de juridische inrichting rond gegevensverwerking, scope-bepaling en meldingsplicht raad ik expliciet aan een privacy-advocaat te betrekken. Lypii is een webdev-partij, geen NIS2-compliance-consultant.

Dit artikel legt de meldingsketen uit (24u / 72u / 30d), wat er in een werkbaar IRP hoort, en een compact skelet dat je vandaag kunt vullen.

Wat NIS2 in de kern van je mkb vraagt

NIS2 is in Nederland geïmplementeerd via de Cyberbeveiligingswet, in werking getreden per 15 augustus 2026. De essentie: essential- en important-entities moeten een incident response plan hebben, cyberincidenten melden bij NCSC-NL of de sectorale CSIRT, en managementverantwoordelijkheid vastleggen. Bestuurders zijn persoonlijk aansprakelijk voor het naleven van de zorgplicht. Zie voor de normatieve bron: de Cyberbeveiligingswet-toelichting op rijksoverheid.nl.

Ben je “essential” of “important” entity?

Twee categorieën, beide met verplichtingen.

• Essential entities: onder andere energie, drinkwater, digitale infrastructuur (datacenter-providers, TLD-registries, DNS-resolvers), gezondheidszorg met beperkte uitzonderingen, transport.
• Important entities: onder andere postdiensten, afvalbeheer, chemie, food, providers van bepaalde digitale diensten (online marketplaces, zoekmachines, social platforms), MSP’s en managed security service providers.

Voor beide gelden de meldingsplicht en de zorgplicht. Voor essential entities ligt de toezicht-druk hoger (ex ante, dus toezicht kan proactief langskomen); voor important entities werkt toezicht meer reactief.

Als je twijfelt of je onder scope valt: gebruik de scope-tool bij de Rijksoverheid of het Digital Trust Center (DTC), en betrek een privacy-advocaat of gespecialiseerde compliance-consultant. Zelf-inschatting op “ik denk dat we buiten scope vallen” is risicovol bij een wet met bestuurdersaansprakelijkheid.

De 24-72-30 meldingsketen uitgelegd

24 uur: early warning

Klok start bij “redelijke zekerheid” dat er een significant incident is. Dat is dus niet bij de eerste alert (een spike in 5xx errors is nog geen incident), maar na initiële triage waarin je bevestigt dat het inderdaad een significant incident betreft.

Inhoud van de early warning: het feit dat een incident heeft plaatsgevonden, of het vermoedelijk kwaadaardig is, of er grensoverschrijdende effecten zijn, en of je hulp nodig hebt. Minimaal 4 tot 5 velden. Meer dan het essentiële hoef je in 24 uur nog niet te weten.

72 uur: incident notification

De volledige beschrijving. Aard van het incident, initiële impact, initiële maatregelen die je hebt genomen, cross-border effecten, indicatie van de oorzaak. Dit is het serieuze document dat toezichthouder en CSIRT in detail lezen.

Laat een tweede paar ogen meelezen voordat je verzendt. Bij voorkeur een privacy-advocaat als er persoonsgegevens betrokken zijn, geldt ook de AVG-meldplicht (72 uur naar de AP), apart van NIS2. Twee meldingen, één moment, andere geadresseerden.

1 maand: final report

Grondige oorzaakanalyse, definitieve impact, mitigatie, lessons learned. Dit is het document dat toezicht gebruikt om te beoordelen of je zorgplicht hebt nageleefd. Investeer hier de tijd; een half-af final report leidt vaker tot follow-up vragen dan één die grondig maar rustig verantwoord is.

Wat er in een werkbaar incident response plan hoort

Een incident response plan mkb NIS2 hoeft geen 80 pagina’s te zijn. Het moet werken op het moment dat het uit de la komt. Zes onderdelen zijn onmisbaar.

Rollen en verantwoordelijkheden

• Incident manager: vaak de IT-verantwoordelijke of de webmaster. Coördineert triage en respons.
• Executive sponsor: een directeur of bestuurder. Onder NIS2 is management-verantwoordelijkheid verplicht; deze rol is niet delegeerbaar.
• Communicator: marcom-lead of iemand die zowel intern als extern kan schrijven zonder paniek te veroorzaken.
• Legal: een privacy-advocaat als externe partij op standby. Niet in vaste dienst nodig, wel: nummer paraat, tarief bekend, tekstueel ready om te bellen.

Detectie en escalatietrap

Hoe komt een alert binnen (monitoring, klant-melding, medewerker-observatie, tip van derde), wie triageert, wanneer wordt het formeel een “incident” (severity-schaal P1-P4), en wanneer wordt het een “significant incident” dat de 24-uursklok triggert. Documenteer de drempels; onduidelijke escalatie is de meest voorkomende faalmodus in het uur nul.

Communicatie (intern, extern, toezicht, klanten)

Een communicatie-matrix per doelgroep en per fase.

• Intern: management, board, medewerkers.
• Extern: klanten, media (voorbereide statement-templates), partners.
• Toezicht: NCSC-NL en sectorale CSIRT.
• Persoonsgegevens: AP als AVG van toepassing.

Voorbereide templates schelen in acute situaties uren. Zorg dat ze aanpasbaar zijn per incident-type.

Log en bewijsvoering

Logboek met tijdstippen, beslissingen, wie wat wanneer wist. Cruciaal voor het final report én voor eventuele juridische nasleep. Bewaar het logboek op een aparte plek dan je hoofd-infrastructuur; als je hoofd-infra gecompromitteerd is, wil je niet dat je logboek dat ook is.

Herstel en post-mortem

Hersteldraaiboek per systeem (webshop, corporate site, back-office), met per systeem: prioriteit, hersteltijd, back-up-locatie. Post-mortem binnen 14 dagen na afronding, blameless (gericht op systeem, niet op individu).

Incident response plan mkb NIS2: het skelet dat je vandaag kunt vullen

Een compact template van 10 bulletpoints. Vul deze in een gedeeld document (bijvoorbeeld in je bedrijfs-wiki of als PDF in versiebeheer) en bespreek jaarlijks.

1. Doel en scope. Welke systemen dekt dit IRP? (websites, kantoornetwerk, klantensystemen, etc.)
2. Rollen en contactgegevens. Namen, functies, telefoon, mail. Up-to-date houden bij elke personele wijziging.
3. Ernst-classificatie. P1 (kritiek, downtime kernproces) tot P4 (verwaarloosbaar). Wat is “significant” onder NIS2?
4. Detectie-bronnen. Monitoring-tools, WAF-alerts, klant-meldingen, medewerker-observaties.
5. Meldingsketen. 24u/72u/30d NIS2 timeline, plus 72u AVG waar van toepassing. Contactadressen per instantie.
6. Communicatie-matrix. Per doelgroep, per fase, met voorbereide templates.
7. Logboek-template. Structuur (tijd, gebeurtenis, beslissing, uitvoerder), opslag-locatie.
8. Herstelvolgorde. Welk systeem eerst, welke back-up, welke persoon.
9. Post-mortem template. Blameless format: wat gebeurde, waarom, wat verbeteren.
10. Onderhouds-cyclus. Jaarlijkse test met een tabletop-oefening. Update na elke oefening.

Wat je zelf doet en wanneer je een privacy-advocaat inschakelt

Voor de juridische kant van je IRP is een privacy-advocaat geen “als je tijd hebt”-advies. NIS2 kent bestuurdersaansprakelijkheid, en in acute situaties is exact de juridische formulering (van je 72u-notification, van je AVG-melding, van je klantcommunicatie) wat het verschil maakt tussen “adequaat gereageerd” en “verdere handhaving”.

Waar je een privacy-advocaat expliciet voor inschakelt:

• Scope-bepaling (essential vs important, of buiten scope).
• Wettelijke notificatie-formulering van 72u-notification en final report.
• Samenloop AVG-meldplicht (72u naar de AP) versus NIS2-meldplicht (naar NCSC / sectorale CSIRT).
• Klantcommunicatie bij datalekken, om aansprakelijkheidsclaims te voorkomen.
• Bestuurdersaansprakelijkheid, met name als bestuurder besluiten heeft genomen die de zorgplicht kunnen raken.

In mijn ervaring is een IRP dat is opgesteld zonder juridische controle in de meest kritieke momenten (media, toezicht, klantcommunicatie) een risico. Techniek zonder juridische ruggengraat werkt niet in een acute setting.

De technische kant: wat Lypii voor je opzet

Ik regel de webtechnische kant van je incident response plan mkb NIS2. Concreet:

• Monitoring en alerting op je websites: uptime, error-spikes, WAF-hits, disk-usage, database-fouten. Tools als Uptime Kuma, Better Stack, of Sentry op je eigen infra.
• Incident-log op een aparte plek dan je hoofd-infra. Belangrijk: als je hoofd-infra weg is, wil je je logboek nog kunnen lezen.
• Recovery-tests van je back-ups. Elke drie maanden: back-up echt terugzetten in een staging-omgeving en controleren of het werkt. Onbeproefde back-ups zijn geen back-ups.
• Technische documentatie in het IRP-format zodat je hersteldraaiboeken bruikbaar zijn voor iemand anders dan jij.

Voor de meldloket-info en actuele NIS2-updates: de meldloket-pagina van NCSC-NL is de bron waar je in acute situaties je 24u-early-warning indient.

Tarieven: setup web-monitoring, back-up-restore-test en technisch IRP-hoofdstuk kost 6 tot 10 uur. Aan €95 per uur is dat €570 tot €950. Spoedopvolging tijdens een lopend incident: €105 per uur (in overleg, ik werk niet ’s nachts standaard, wel bij afgesproken spoed).

Dit is technische ondersteuning náást een privacy-advocaat en/of NIS2-consultant, niet in plaats van. Als aanvulling zie ook security.txt volgens RFC 9116 voor je disclosure-kanaal en back-up strategie voor mkb-websites voor de herstelkant.

Verbeteren boven herbouwen: je bestaande infra hoeft niet opnieuw. Monitoring toevoegen, back-ups testen, IRP-format documenteren.

Multi-stack opmerking: een IRP is organisatorisch, niet stack-specifiek. Het technische deel dat Lypii oplevert werkt op WordPress, Laravel, Shopify en custom PHP identiek: monitoring op de site, alerting op events, back-ups die getest zijn.