6 dingen die elk incidentresponsplan nodig heeft

Het was een dinsdagochtend in maart toen een logistiek bedrijf in Rotterdam ontdekte dat hun bestandssystemen waren versleuteld. Tegen het middaguur zaten twaalf medewerkers werkloos thuis. De volgende ochtend waren drie belangrijke klantzendingen vertraagd. Drie weken later hadden ze een recoverybedrijf € 80.000 betaald om gedeeltelijk toegang tot hun data te krijgen – en ze moesten de inbreuk nog steeds uitleggen aan een belangrijke klant die de samenwerking heroverwoog.

Het bedrijf had op geen enkel moment een tekort aan bekwame mensen. Wat ze misten, was een plan.

Dit verhaal komt vaker voor dan de meeste Nederlandse ondernemers zouden denken. In 2025 werden meer dan 2.100 Nederlandse organisaties getroffen door ransomware – een stijging van 31% ten opzichte van het jaar ervoor (Searchlab Cybersecurity Statistics Netherlands, 2026). De gemiddelde downtime na zo’n aanval is 23 dagen. En toch blijkt uit onderzoek consistent dat een aanzienlijk deel van de Nederlandse MKB-bedrijven geen gedocumenteerd incidentresponsplan heeft – of er een heeft dat nog nooit is getest.

Dit veranderde aanzienlijk op 15 april 2026, toen het Nederlandse parlement de Cyberbeveiligingswet goedkeurde – de Nederlandse implementatie van de EU NIS2-richtlijn. De wet introduceert verplichte incidentmeldingen binnen 24 uur, eisen voor cybersecurityrisicobeheer en verantwoordelijkheid op directieniveau voor security governance. Voor organisaties die onder de wet vallen, is een incidentresponsplan niet langer optioneel. Voor organisaties die niet direct onder de wet vallen, maken vragenlijsten van grotere klanten het hoe dan ook een praktische vereiste.

Hieronder staan ​​de zes elementen die elk incidentresponsplan nodig heeft – geschreven voor IT-managers en ondernemers die een document willen dat daadwerkelijk werkt onder druk, en niet zomaar een document dat stof verzamelt in een map.

Wanneer er een verstoring optreedt, is het eerste dat meestal misgaat niet de technische reactie, maar de menselijke. Bij gebrek aan duidelijk gedefinieerde rollen dupliceren bekwame mensen taken op sommige gebieden en missen ze cruciale taken op andere. Tijd die besteed zou moeten worden aan het indammen van de verstoring, gaat verloren aan het uitzoeken wie wat moet doen.

Uw incidentresponsplan moet drie vragen beantwoorden vóórdat een incident plaatsvindt, niet tijdens:

• Wie heeft de beslissingsbevoegdheid tijdens een beveiligingsincident?
• Wie beheert de interne communicatie en aan wie rapporteert elk teamlid?
• Wie is het aangewezen aanspreekpunt voor externe partijen: uw IT-leverancier, juridisch adviseur, cyberverzekeraar en – onder NIS2 – het NCSC?

Een goed gestructureerd plan benoemt specifieke personen, niet alleen functietitels. Het benoemt ook back-ups, omdat incidenten zelden plaatsvinden wanneer de primaire contactpersoon direct beschikbaar is. Elke genoemde persoon moet een geprinte of offline kopie van zijn of haar verantwoordelijkheden hebben, omdat incidenten vaak de systemen beïnvloeden die je anders zou gebruiken om die informatie op te zoeken.

Midden in een actief incident is het laatste wat uw team zou moeten doen, e-mailconversaties doorzoeken naar een telefoonnummer van een leverancier of proberen te achterhalen onder welke account de cyberverzekering is geregistreerd. Kleine vertragingen kunnen snel oplopen. Elke minuut die wordt besteed aan het opsporen van een contactpersoon is een minuut die niet kan worden besteed aan het beheersen van het incident.

Uw incidentresponsplan moet op één centrale locatie, die niet afhankelijk is van de beschikbaarheid van uw primaire systemen, het volgende bevatten:

• Intern leiderschap – personen met mobiele nummers, geen kantoorextensies
• Uw IT-dienstverlener of interne IT-manager – met een contactpersoon voor buiten kantooruren
• Belangrijke software- en infrastructuurleveranciers – met name cloudproviders, ERP- en back-upsystemen
• Cyberverzekeraar – polisnummer, contactpersoon voor claims en of zij een incidentmelding binnen een specifiek tijdsbestek vereisen
• Juridisch adviseur met ervaring in datalekken
• De NCSC Cybersecurity Incident Notification (als u een essentiële entiteit bent volgens de Cyberbeveiligingswet)
• Belangrijke zakelijke partners of klanten die mogelijk op de hoogte moeten worden gesteld

Bewaar een fysieke, geprinte versie van deze contactlijst – op een veilige plek buiten het bedrijf of bij een vertrouwde persoon buiten de organisatie. Een ransomware-aanval die uw bestandssystemen versleutelt, versleutelt ook alle contactlijsten die erop zijn opgeslagen. Veel Nederlandse bedrijven hebben dit op de harde manier ondervonden.

Een veelvoorkomende aanname bij incidentplanning is dat communicatiemiddelen beschikbaar blijven. Dat is vaak niet het geval. E-mail is mogelijk niet beschikbaar als uw Exchange- of Microsoft 365-omgeving is getroffen. Interne berichtentools zijn mogelijk niet beschikbaar. Uw VoIP-systeem is mogelijk onbereikbaar.

Uw plan moet communicatiekanalen definiëren die onafhankelijk functioneren van de systemen die mogelijk gecompromitteerd zijn, en verwachtingen scheppen over wat er gecommuniceerd wordt, met wie en wanneer.

• Definieer een back-upkanaal: een gedeelde WhatsApp-groep voor belangrijke medewerkers, een vooraf afgesproken telefoonketen of een aangewezen ontmoetingspunt voor het kernteam.
• Definieer wie medewerkers op de hoogte stelt en wat er gezegd wordt. Onduidelijke interne communicatie tijdens een incident creëert geruchten en onrust, waardoor de situatie moeilijker te beheersen is.

• Communicatie met klanten: wanneer worden klanten op de hoogte gesteld en wat wordt hen verteld? Een snel verstuurde tussenwerpsel is vrijwel altijd beter dan stilte.

• Communicatie met toezichthouders: volgens de AVG (Algemene Verordening Gegevensbescherming) moet een datalek binnen 72 uur na ontdekking worden gemeld aan de Autoriteit Persoonsgegevens. Volgens de Cyberbeveiligingswet moeten essentiële entiteiten het NCSC binnen 24 uur op de hoogte stellen van significante incidenten. Beide termijnen gaan onmiddellijk in.
• Media- en publiekscommunicatie: in de meeste gevallen is het raadzaam om publiekelijk niets te zeggen totdat de juridische afdeling en het management het eens zijn over de boodschap. Definieer wie bevoegd is om extern te spreken.

Niet alle systemen zijn even belangrijk. Een storing in de interne HR-software is een ongemak. Een storing in uw betalingsverwerking, klantportaal of operationele database heeft echter direct financiële en reputatiegevolgen.

Uw incidentresponsplan moet een gedocumenteerd overzicht bevatten van:

• Welke systemen essentieel zijn voor uw kernactiviteiten
• Wat de acceptabele downtime is voor elk systeem (uw Recovery Time Objective, of RTO)
• Welk dataverlies acceptabel is — hoe ver terug kunt u gegevens herstellen en wat zijn de kosten van herstel versus het verlies van die gegevens (uw Recovery Point Objective, of RPO)
• De prioriteitsvolgorde voor herstel als meerdere systemen tegelijkertijd getroffen zijn

Dit is het onderdeel van de meeste incidentresponsplannen dat ofwel volledig ontbreekt, ofwel zo technisch gedetailleerd is beschreven dat slechts één persoon binnen de organisatie het kan volgen. Beide versies falen onder druk.

Herstelprocedures moeten specifiek genoeg zijn om uitvoerbaar te zijn en duidelijk genoeg om te worden gevolgd door iemand die onder stress staat, onder tijdsdruk werkt en mogelijk niet de gebruikelijke persoon is voor deze rol.

• Eerste stappen voor het inperken van de situatie: hoe de getroffen systemen te isoleren zonder bewijsmateriaal te vernietigen dat nodig is voor het onderzoek
• Wie moet in elke fase van de respons worden geïnformeerd en in welke volgorde
• Stappen voor het activeren van back-ups: inclusief waar de back-upgegevens worden opgeslagen en hoe het herstel wordt geverifieerd
• Een duidelijk escalatiepad: wat gebeurt er als de eerste reactie het incident niet binnen een vastgestelde termijn inperkt
• Documentatievereisten: wat moet er gedurende het incident worden vastgelegd en waarom (bewijsmateriaal bewaren voor juridische en verzekeringsdoeleinden)

Zowel onder de AVG als de Cyberbeveiligingswet moeten organisaties mogelijk aantonen wat er is gebeurd, wanneer en hoe ze hebben gereageerd. Het vastleggen van incidenten in realtime is niet intuïtief; mensen zijn gefocust op het oplossen van het probleem, niet op het documenteren ervan. Wijs daarom één persoon aan die specifiek verantwoordelijk is voor het bijhouden van een incidentlogboek, zelfs als het slechts gaat om aantekeningen met tijdstempels in een fysiek notitieboekje.

Een incidentresponsplan dat nooit is getest, is een document, geen plan. Het verschil tussen beide wordt pas op het slechtst denkbare moment duidelijk.
Testen dient twee doelen. Ten eerste onthult het tekortkomingen die op papier niet opvallen – een verouderd telefoonnummer, een back-upherstelproces dat drie keer langer duurt dan verwacht, een functiebeschrijving waarvan twee mensen dachten dat ze die allebei hadden. Ten tweede bouwt het een soort routine op waardoor mensen snel en kalm kunnen reageren wanneer zich een echt incident voordoet, in plaats van het plan voor het eerst onder druk te moeten lezen.

• Een simulatieoefening minstens één keer per jaar: een gestructureerde doorloop van een gesimuleerd incidentscenario met de belangrijkste personen die in uw plan worden genoemd. Er hoeven geen systemen te worden aangepast – alleen het gesprek over “wat zouden we in de praktijk doen als dit zou gebeuren?”.
• Een test voor het herstellen van een back-up minstens twee keer per jaar: kunt u daadwerkelijk herstellen vanuit uw meest recente back-up en hoe lang duurt dat?
• Een controle van de contactlijst elke zes maanden: is er iemand van functie veranderd, heeft iemand het bedrijf verlaten of is iemands mobiele nummer gewijzigd?
• Een evaluatie na elk incident, hoe klein ook: wat werkte, wat niet en wat moet er in het plan worden aangepast?

Volgens de Cyberbeveiligingswet wordt van essentiële entiteiten verwacht dat zij kunnen aantonen dat cybersecuritymaatregelen – inclusief incidentrespons – zijn geïmplementeerd en getest. Dit betekent dat er documentatie moet worden bijgehouden van tests, simulaties en evaluaties van het plan. Een plan met een revisiegeschiedenis en een testlogboek is aanzienlijk beter te verdedigen dan een plan dat drie jaar geleden is opgesteld en geen bewijs van updates bevat.

Een goed incidentresponsplan voorkomt geen incidenten. Wat het wel doet, is de tijd tussen detectie en beheersing verkorten, de herstelkosten verlagen en uw team houvast bieden wanneer de situatie te stressvol is voor helder denken.

Voor Nederlandse bedrijven is de urgentie toegenomen. De Cyberbeveiligingswet is nu wettelijk verplicht. De NIS2-incidentmeldingsplicht is van kracht. Leveranciersvragenlijsten van grotere klanten vragen rechtstreeks of u gedocumenteerde en geteste incidentresponsprocedures hebt. De vraag is niet langer of u een plan moet hebben, maar of uw plan de zes zaken dekt die er echt toe doen wanneer er iets misgaat.

De meeste bedrijven met een incidentresponsplan ontdekken tekortkomingen al bij de eerste test. De bedrijven die deze tekortkomingen pas tijdens een echt incident ontdekken, betalen aanzienlijk meer om ze te verhelpen.

Geen technisch jargon. Geen verplichtingen. Gewoon een helder beeld van de huidige stand van uw plan en wat er eventueel verbeterd moet worden.