Hoe stel ik een incidentresponsplan op voor mijn bedrijf?

Patrick de Veer · 26 jul 2026

Een incidentresponsplan stel je op door zes onderdelen vast te leggen: de minimale inhoud van het plan, de rollen en verantwoordelijkheden, de stappen bij een incident, de relevante incidenttypen voor jouw bedrijf, een test- en actualisatiecyclus, en de meest gemaakte fouten. Voor MKB-bedrijven geldt dat een werkbaar plan beter is dan een perfect plan dat in een la blijft liggen. Dit artikel loopt alle onderdelen stap voor stap met je door.

Wat staat er minimaal in een incidentresponsplan?

Een incidentresponsplan bevat minimaal vijf onderdelen: een beschrijving van wat een incident is voor jouw bedrijf, een lijst van rollen en contactpersonen, de stappen die je neemt bij een incident, een communicatieprotocol en een evaluatieprocedure achteraf. Zonder deze vijf bouwstenen heb je geen plan, maar een losse checklist.

Begin met een heldere definitie van wat jij als incident beschouwt. Dat klinkt vanzelfsprekend, maar in de praktijk is het een van de meest overgeslagen stappen. Is een medewerker die zijn laptop vergeet in de trein een incident? Wat als diezelfde laptop niet versleuteld is? Door vooraf grenzen te trekken, weet iedereen wanneer het plan in werking treedt.

Vervolgens leg je vast wie wat doet, hoe je intern en extern communiceert, en hoe je achteraf leert van wat er is misgegaan. Dat laatste onderdeel, de evaluatie, wordt regelmatig weggelaten. Zonde, want juist daarin zit de meeste verbetering.

Voor bedrijven die onder de NIS2-richtlijn vallen, is een gedocumenteerd incidentresponsplan geen optie maar een verplichting. Maar ook als je daar (nog) niet onder valt, is een werkend plan een concrete stap richting betere digitale weerbaarheid. De NIS2 mkb checklist die veel brancheorganisaties verspreiden, verwijst dan ook vrijwel altijd naar dit document als startpunt.

Welke rollen en verantwoordelijkheden horen erin?

In een incidentresponsplan horen minimaal drie rollen thuis: een incidentcoördinator die het proces leidt, een technisch aanspreekpunt dat de oorzaak onderzoekt en maatregelen neemt, en een communicatieverantwoordelijke die intern en extern de juiste mensen informeert. In grotere organisaties zijn dit drie aparte personen; in een klein MKB-bedrijf kan één persoon meerdere rollen vervullen.

Schrijf bij elke rol ook een vervanger op. Incidenten gebeuren zelden op een doordeweekse dinsdag om elf uur. Ze gebeuren op vrijdagmiddag, in de zomervakantie of wanneer de eigenaar toevallig op reis is. Een plan zonder vervangers werkt niet.

Naast interne rollen horen ook externe contacten in het plan. Denk aan je IT-leverancier, je juridisch adviseur en, als je persoonsgegevens verwerkt, de contactgegevens van de Autoriteit Persoonsgegevens. Bij een datalek heb je in Nederland 72 uur om melding te doen. Als je dan nog op zoek bent naar het telefoonnummer, ben je al te laat.

Hoe beschrijf je de stappen bij een cyberincident?

De stappen bij een cyberincident beschrijf je in vijf fasen: detectie, insluiting, onderzoek, herstel en evaluatie. Elke fase heeft een duidelijke beginconditie, een verantwoordelijke en een concrete actie. Door het zo te structureren weet iedereen wat er van hem of haar wordt verwacht, ook onder druk.

Houd de beschrijving per fase kort en concreet. Geen lappen tekst, maar lijstjes met acties. In een stressvolle situatie leest niemand een alinea van tien regels.

Detectie: Wie signaleert het incident en hoe wordt het gemeld? Via welk kanaal?
Insluiting: Welke systemen worden losgekoppeld of geblokkeerd om verdere schade te voorkomen?
Onderzoek: Wie analyseert wat er is gebeurd en welke data of systemen zijn geraakt?
Herstel: Hoe en wanneer worden systemen weer opgestart? Wat zijn de criteria om te besluiten dat het veilig is?
Evaluatie: Wat is er misgegaan, wat werkte goed, en wat wordt er aangepast in het plan?

Let op: bij cloudgebaseerde diensten zoals Microsoft 365 of Google Workspace is insluiting lastiger, omdat je niet zomaar een server kunt uitzetten. Noteer in je plan wie de beheerdersrechten heeft en hoe je snel toegang kunt blokkeren of accounts kunt bevriezen. De digitale afhankelijkheid van MKB-bedrijven van dit soort platforms maakt dit onderdeel steeds relevanter.

Welke incidenten moet een MKB-bedrijf opnemen in het plan?

Een MKB-bedrijf neemt minimaal vier typen incidenten op in het plan: ransomware- of malware-aanvallen, datalekken (inclusief menselijke fouten), verlies of diefstal van apparatuur, en uitval van kritieke systemen of diensten. Dit zijn de incidenttypen die het meest voorkomen en de meeste schade veroorzaken.

Voeg daar voor jouw specifieke situatie relevante scenario’s aan toe. Werk je veel met clouddiensten van Amerikaanse aanbieders? Dan is het verstandig om ook een scenario op te nemen rondom CLOUD Act risico’s voor jouw bedrijf, waarbij een buitenlandse overheid toegang vraagt tot jouw data. Dit klinkt misschien vergezocht, maar voor bedrijven die gevoelige klant- of bedrijfsdata in de cloud opslaan, is het een reëel risico om op voorbereid te zijn.

Denk ook aan de menselijke kant: een medewerker die per ongeluk een phishingmail opent, een verkeerd verstuurde e-mail met persoonsgegevens, of een leverancier wiens systemen worden gehackt en die toegang heeft tot jouw netwerk. Incidenten komen vaker van binnenuit of via de keten dan via een directe aanval van buitenaf.

Hoe test en actualiseer je een incidentresponsplan?

Je test een incidentresponsplan door minimaal één keer per jaar een tabletop-oefening te doen: een bespreking waarbij je een fictief incident doorloopt zonder dat er iets echt misgaat. Je actualiseert het plan na elke test, na een echt incident, en bij grote veranderingen in je organisatie of systemen.

Een tabletop-oefening hoeft niet ingewikkeld te zijn. Kies een scenario, nodig de betrokken medewerkers uit en loop samen de stappen door. Stel vragen als: wie belt wie als dit om acht uur ’s avonds gebeurt? Hebben we de back-up ooit echt teruggezet? Waar staat het wachtwoord van het beheerdersaccount?

Actualiseer het plan ook wanneer je overstapt op nieuwe software of diensten. Overstappen van Microsoft 365 naar een ander platform, of juist de keuze voor een EU-alternatief voor Google Workspace, verandert wie toegang heeft tot welke systemen en hoe je bij een incident kunt ingrijpen. Zorg dat het plan die werkelijkheid weerspiegelt.

Wat zijn de meest gemaakte fouten bij een incidentresponsplan?

De meest gemaakte fouten bij een incidentresponsplan zijn: het plan nooit testen, verouderde contactgegevens, te veel jargon waardoor medewerkers niet weten wat ze moeten doen, en het ontbreken van een evaluatieprocedure. Een plan dat niet wordt onderhouden, werkt niet op het moment dat het er echt toe doet.

Een andere veelgemaakte fout is het plan alleen digitaal opslaan. Als je netwerk platligt door ransomware, kom je niet bij je eigen incidentresponsplan. Print een samenvatting van de belangrijkste stappen en contactgegevens uit en bewaar die fysiek op een vaste plek.

Tot slot: te veel bedrijven schrijven een plan voor de bühne, bedoeld om een auditor of klant tevreden te stellen, maar nooit echt doorgesproken met de mensen die het moeten uitvoeren. Een incidentresponsplan is pas nuttig als de mensen in je organisatie weten dat het bestaat, weten waar het staat en begrijpen wat er van hen wordt verwacht.

Bij GreenAumatic zien we dat veel MKB-bedrijven niet goed weten waar ze staan op het gebied van digitale weerbaarheid, inclusief de vraag of hun incidentresponsplan voldoende is. Benieuwd waar jouw bedrijf staat op het gebied van digitale weerbaarheid? Doe de gratis Digitale Weerbaarheid pre-scan en weet het in tien minuten. Geen registratie, direct resultaat.

Frequently Asked Questions

Hoe lang mag een incidentresponsplan zijn voor een klein MKB-bedrijf?

Een incidentresponsplan voor een klein MKB-bedrijf hoeft geen uitgebreid document te zijn. Twee tot vijf pagina's met de vijf kernonderdelen is voor de meeste kleine bedrijven meer dan voldoende. Het gaat erom dat het plan bruikbaar is onder druk, niet dat het indrukwekkend oogt op papier. Een beknopt, getest plan klopt altijd een uitgebreid, ongelezen document.

Moet ik een extern beveiligingsbedrijf inschakelen om een incidentresponsplan op te stellen?

Dat hoeft niet per se. Voor de meeste MKB-bedrijven is het goed haalbaar om zelf een werkbaar plan op te stellen aan de hand van een sjabloon of stappenplan, zoals beschreven in dit artikel. Een externe partij kan wel meerwaarde bieden bij het testen van het plan, het beoordelen van specifieke risico's, of als je onder NIS2 valt en aantoonbaar aan de eisen moet voldoen. Begin zelf, en schakel externe hulp in waar je vastloopt.

Wat doe ik als een incident buiten kantooruren plaatsvindt en ik de incidentcoördinator niet kan bereiken?

Dit is precies waarom het plan vervangers bij elke rol moet bevatten én een duidelijke escalatielijn. Leg in het plan vast: wie is de eerste vervanger, wie is de tweede, en via welk kanaal wordt er gecontacteerd (telefoon, sms, WhatsApp). Overweeg ook een vast alarmnummer of een gedeeld noodcontact dat altijd bereikbaar is. Test dit scenario expliciet tijdens je jaarlijkse tabletop-oefening, want buiten kantooruren is precies wanneer aanvallers toeslaan.

Hoe weet ik of mijn huidige back-up voldoende is om te herstellen na een ransomware-aanval?

De enige manier om dat zeker te weten, is door de back-up daadwerkelijk terug te zetten in een testomgeving. Veel bedrijven hebben een back-up maar hebben nooit gecontroleerd of het herstel ook echt werkt. Controleer daarbij ook of je back-up offline of off-site is opgeslagen, want ransomware versleutelt vaak ook gekoppelde back-upschijven en cloudmappen die continu gesynchroniseerd worden. Een goede vuistregel is de 3-2-1-methode: drie kopieën, op twee verschillende media, waarvan één offsite.

Wanneer ben ik verplicht een datalek te melden bij de Autoriteit Persoonsgegevens, en wat als ik de deadline mis?

Je bent verplicht te melden als het datalek waarschijnlijk een risico oplevert voor de rechten en vrijheden van betrokkenen, en dat moet binnen 72 uur na ontdekking. Denk aan gelekte klantgegevens, medische informatie of financiële data. Als je de deadline mist, riskeer je een boete van de AP, maar je kunt de melding alsnog doen met uitleg over de vertraging. Neem bij twijfel altijd contact op met je juridisch adviseur of meld preventief, want te laat melden weegt zwaarder dan onnodig melden.

Hoe betrek ik medewerkers bij het incidentresponsplan zonder ze te overweldigen met technische details?

Maak een beknopte 'medewerkerssamenvatting' van één pagina: wat is een incident, hoe meld je het, en bij wie. Geef medewerkers geen tachtig pagina's beleid, maar één concrete actie: bel direct dit nummer als je iets verdachts ziet. Bespreek het plan kort tijdens een teamoverleg en herhaal dit jaarlijks. Bewustzijn en een lage drempel om te melden zijn waardevoller dan technische kennis bij de gemiddelde medewerker.

Geldt een incidentresponsplan ook voor incidenten bij mijn leveranciers of softwarepartners?

Ja, en dit wordt door veel bedrijven onderschat. Als een leverancier toegang heeft tot jouw systemen of data beheert, kan een incident bij hen direct impact hebben op jouw bedrijf. Neem in je plan een scenario op voor ketenincidenten: wie informeert jou, wat doe jij in de tussentijd, en hoe beperk je de schade? Vraag ook actief aan kritieke leveranciers of zij zelf een incidentresponsplan hebben en hoe ze jou informeren bij een incident aan hun kant.