Incidentresponsplan opstellen: zo pak je het aan als mkb
Een incidentresponsplan is je draaiboek voor het moment dat er iets misgaat met je IT: een ransomware-aanval, een datalek of een gehackt mailaccount. Er staat in wie wat doet, wie je belt, welke systemen je eerst afsluit en wanneer je moet melden bij de Autoriteit Persoonsgegevens. In dit artikel lees je wat er in zo’n plan hoort, hoe je het in een paar middagen opstelt, hoe je het aanvult met playbooks voor specifieke aanvallen en hoe je het levend houdt. We schrijven het voor ondernemers en bedrijfsleiders in het mkb, dus zonder dikke rapporten die niemand leest.
Kort samengevat
- 📋 Een incidentresponsplan legt vast hoe je een beveiligingsincident ontdekt, erop reageert en de schade herstelt, met vaste rollen, een bellijst en een meldpunt.
- 🧭 Het plan is de algemene aanpak. Een playbook is een stappenlijst per scenario, zoals ransomware, phishing of een datalek.
- ⏱️ Een meldplichtig datalek meld je binnen 72 uur bij de Autoriteit Persoonsgegevens. Valt je organisatie onder de Cyberbeveiligingswet, dan geldt ook een vroegtijdige melding binnen 24 uur.
- 🔁 Een plan werkt alleen als je het oefent. Plan minstens een tabletop-oefening per jaar en evalueer elk echt incident.
- 🤝 Houd de kern kort: een paar pagina’s met namen, nummers en beslisregels. De details zet je in bijlagen en playbooks.
Inhoudsopgave
- Wat is een incidentresponsplan?
- Plan, playbook en runbook: wat is het verschil?
- Het verschil met een continuïteitsplan en disaster recovery
- Wat hoort er in een incidentresponsplan?
- Zo stel je het plan op in 7 stappen
- De vier fasen tijdens een incident
- Melden: welke termijnen gelden?
- Communicatie: wat zeg je en tegen wie?
- Testen en bijwerken
- Veelgemaakte fouten in het mkb
- Onze kijk: een plan werkt alleen met een vast aanspreekpunt
- Incidentrespons uitbesteden aan ASTIA
- Veelgestelde vragen
- Bronnen
Wat is een incidentresponsplan?
Het Nationaal Cyber Security Centrum omschrijft een incidentresponsplan als een set instructies die medewerkers helpt om beveiligingsincidenten te detecteren, erop te reageren en mogelijke schade te herstellen. Denk aan een verstoring, een datalek of een digitale aanval.
Het verschil met “we zien het wel als het gebeurt” is groot. Zonder plan gaat de eerste uren op aan vragen als: wie mag de server uitzetten? Wie belt de IT-partner? Moeten we klanten inlichten? Met een plan liggen die antwoorden al klaar. Je team hoeft dan niet te improviseren, maar kan direct handelen.
Welke incidenten dekt het plan?
Een goed plan is breed genoeg voor elk incident, maar je werkt de meest waarschijnlijke scenario’s apart uit. Het NCSC noemt in zijn draaiboek voor cyberincidenten onder meer deze voorbeelden waarvoor een specifiek playbook nuttig is:
- Ransomware: bestanden worden versleuteld en criminelen vragen losgeld.
- Datalek: persoonsgegevens komen bij onbevoegden terecht, bijvoorbeeld door een verkeerd verstuurde mail of een gestolen laptop.
- DDoS-aanval: je website of verbinding wordt platgelegd door een stroom nepverkeer.
- Phishing: een medewerker klikt op een valse link en geeft zijn wachtwoord af.
- Malware-uitbraak: schadelijke software verspreidt zich over je netwerk.
Voor de meeste mkb-bedrijven zijn phishing, een overgenomen Microsoft 365-account en ransomware de scenario’s om mee te beginnen. Wil je weten waar je medewerkers op moeten letten, lees dan onze uitleg over phishing herkennen.
Plan, playbook en runbook: wat is het verschil?
Deze drie woorden lopen vaak door elkaar. Zo houd je ze uit elkaar:
| Document | Wat staat erin | Voorbeeld |
|---|---|---|
| Incidentresponsplan | De algemene aanpak: rollen, bellijst, beslisregels, meldplichten en de fasen van een incident | “De directeur beslist of we systemen offline halen” |
| Playbook | De stappen per type incident, van eerste signaal tot afsluiting | “Ransomware: ontkoppel het netwerk, bel de IT-partner, raak de back-ups niet aan” |
| Runbook | De technische uitvoering van één handeling | “Zo blokkeer je een gebruiker in Microsoft 365 en trek je alle sessies in” |
Het plan is dus de strategie, het playbook de tactiek en het runbook de handleiding voor de techniek. Als mkb-ondernemer schrijf je zelf vooral het plan en de playbooks. Het runbook ligt meestal bij je IT-partner, omdat die de handelingen ook uitvoert.
Het verschil met een continuïteitsplan en disaster recovery
Ook hier gaat het vaak mis. Een incidentresponsplan gaat over de eerste reactie: het incident herkennen, inperken en oplossen. Een bedrijfscontinuïteitsplan gaat over de vraag hoe je bedrijf blijft draaien terwijl dat gebeurt. Kun je nog factureren? Kunnen je monteurs nog bij hun planning? Neem je de telefoon nog op?
Disaster recovery is weer een stap verder: hoe zet je systemen en data terug na een grote storing. De drie documenten vullen elkaar aan en verwijzen naar elkaar. Schrijf ze niet als één groot document, want dan vindt niemand in een crisis de juiste pagina. Hoe je dat herstelgedeelte aanpakt, lees je in ons artikel over een praktisch disaster recoveryplan.
Wat hoort er in een incidentresponsplan?
Volgens het NCSC beschrijft een plan in elk geval de rollen en verantwoordelijkheden, de scenario’s, de te nemen stappen en welke mensen en partijen je betrekt of informeert. Ook een meldpunt en een bellijst voor noodsituaties horen erbij. Vertaald naar een mkb-bedrijf ziet dat er zo uit:
| Onderdeel | Wat je vastlegt | Tip uit de praktijk |
|---|---|---|
| Doel en reikwijdte | Voor welke systemen en locaties het plan geldt | Noem ook cloudomgevingen zoals Microsoft 365 |
| Rollen | Wie leidt, wie beslist, wie communiceert, wie regelt de techniek | Zet bij elke rol een vervanger |
| Bellijst | Namen en mobiele nummers van intern team, IT-partner, verzekeraar, advocaat | Bewaar hem ook op papier, want bij ransomware is je netwerk niet bereikbaar |
| Meldpunt | Waar medewerkers een vermoedelijk incident melden | Eén telefoonnummer werkt beter dan een mailadres |
| Classificatie | Wanneer is iets een klein incident en wanneer een crisis | Gebruik drie niveaus: laag, middel, hoog |
| Beslisregels | Wie mag systemen uitzetten, wie schakelt de verzekeraar in | Leg vast wat je doet als die persoon onbereikbaar is |
| Meldplichten | Welke meldingen, bij wie, binnen welke termijn | Zet het meldformulier van de AP al klaar |
| Communicatie | Wat je zegt tegen medewerkers, klanten en pers | Maak conceptteksten vooraf |
| Playbooks | Stappen per scenario | Begin met twee of drie scenario’s |
| Logboek | Wat er wanneer gebeurde en wie wat besloot | Nodig voor je melding en je verzekeraar |
Houd de kern kort. Een paar pagina’s met rollen, nummers, beslisregels en meldtermijnen is genoeg. Alles wat langer is, zet je in een bijlage.
De rol van de directie
Cybersecurity is geen klusje voor alleen de IT-partner. De Cyberbeveiligingswet legt de verantwoordelijkheid voor de weerbaarheid bij het bestuur, dat besluit over netwerk- en informatiebeveiliging en daar genoeg kennis voor moet hebben. Ook als jouw bedrijf niet onder die wet valt, is dit een goede lijn: de directie is eigenaar van het plan en neemt de grote beslissingen tijdens een incident.
Zo stel je het plan op in 7 stappen
Je hoeft niet te beginnen met een leeg vel. Het NCSC biedt een uitgebreid sjabloon voor een Cyber Incident Response Plan dat je kunt inkorten voor jouw situatie. Deze stappen helpen je op weg:
- Breng je kroonjuwelen in kaart. Welke systemen en gegevens heb je echt nodig om te werken? Denk aan je mail, je boekhouding, je planningssoftware, je klantgegevens en je telefonie.
- Doe een korte risicoanalyse. Wat kan er misgaan en wat is de impact? Een overgenomen mailaccount bij de financiële afdeling weegt zwaarder dan een kapotte printer.
- Verdeel de rollen. Wijs een incidentleider aan, een beslisser (vaak de directeur), iemand voor communicatie en een technisch aanspreekpunt. In een klein bedrijf kan één persoon twee rollen hebben, zolang er een vervanger is.
- Maak de bellijst en het meldpunt. Verzamel de nummers van je IT-partner, je cyberverzekeraar, je internetprovider en eventueel een jurist. Zet ook de meldkanalen van de AP en, als het voor jou geldt, je CSIRT erin.
- Schrijf je eerste playbooks. Kies de twee of drie scenario’s die het meest waarschijnlijk zijn en beschrijf per scenario de eerste tien acties.
- Informeer je medewerkers. Het NCSC noemt dit expliciet als onderdeel van de voorbereiding. Iedereen moet weten waar je een verdacht incident meldt en dat melden altijd goed is, ook bij twijfel.
- Oefen en stel bij. Speel een scenario na met je team en pas het plan aan op wat je leert.
Heb je een cyberverzekering? Kijk dan ook welke eisen je verzekeraar stelt. Veel polissen vragen om een gedocumenteerd plan en een vast meldnummer. Lees er meer over in ons stuk over cyberverzekering en IT-eisen.
De vier fasen tijdens een incident
De aanpak van het NCSC is gebaseerd op internationale standaarden zoals ISO/IEC 27035 en NIST SP 800-61. Tijdens een incident doorloop je volgens het NCSC-sjabloon deze fasen:
1. Detectie en analyse 🔍
Je merkt dat er iets mis is: een melding van de monitoring, een medewerker die een vreemde mail heeft geopend of een klant die belt over een nepfactuur. Je stelt vast wat er aan de hand is, hoe groot het is en welk niveau het incident krijgt. Begin vanaf nu een logboek met tijden en besluiten.
2. Inperken (containment) 🧱
Je voorkomt dat het erger wordt. Je haalt een besmette laptop van het netwerk, blokkeert een gehackt account of zet een verbinding dicht. Belangrijk: zet een besmet apparaat niet zomaar uit en wis niets. Sporen zijn nodig voor onderzoek en voor je verzekeraar. Volg hier het advies van je IT-partner.
3. Oplossen en herstellen 🛠️
Je verwijdert de oorzaak, bijvoorbeeld malware of een lek in de software, en zet systemen terug. Bij ransomware gebeurt dat vanuit een schone back-up. Hoe dat in de praktijk werkt, lees je in ons ransomware herstelplan.
4. Na het incident 📝
Je evalueert wat er goed en fout ging en verwerkt de lessen in het plan. Deze stap wordt vaak overgeslagen, terwijl hij het meest oplevert.
Melden: welke termijnen gelden?
In je plan staat precies wanneer en waar je meldt. Dit zijn de twee belangrijkste meldplichten in Nederland:
| Regel | Wanneer | Bij wie | Termijn |
|---|---|---|---|
| AVG | Een meldplichtig datalek met persoonsgegevens | Autoriteit Persoonsgegevens | Binnen 72 uur na ontdekking |
| Cyberbeveiligingswet | Een significant incident bij een organisatie die onder de wet valt | Je CSIRT en je toezichthouder | Vroegtijdige melding binnen 24 uur, vervolgmelding binnen 72 uur, eindverslag uiterlijk 1 maand na de eerste melding |
Voor datalekken gebruik je het meldformulier van de AP. Volgens de Autoriteit Persoonsgegevens meld je ook binnen 72 uur als je nog niet alle details weet. De rest vul je aan met een vervolgmelding. Wacht dus niet tot het onderzoek klaar is. De AVG geldt in de hele EU, en elders werkt het net zo: ook in Zweden draait het om een datalek melden binnen 72 uur, met een eerste melding en later een aanvulling.
De stappen onder de Cyberbeveiligingswet gelden alleen voor organisaties die onder die wet vallen. Twijfel je of dat voor jouw bedrijf geldt, bijvoorbeeld omdat je levert aan een vitale sector? Laat dat dan uitzoeken door een jurist of adviseur die thuis is in de Cbw. Leg het antwoord vast in je plan, zodat je er tijdens een incident niet over hoeft na te denken.
💡 Tip: wijs vooraf aan wie de melding doet en zet de inloggegevens of het formulier klaar. Een termijn van 72 uur is in een weekend sneller om dan je denkt.
Communicatie: wat zeg je en tegen wie?
Tijdens een incident wil iedereen weten wat er aan de hand is. Medewerkers, klanten, leveranciers en soms de pers. Zonder afspraken gaan er verschillende verhalen rond. Leg daarom in je plan vast:
- Wie spreekt namens het bedrijf. Eén persoon, met een vervanger.
- Welk kanaal je gebruikt. Als je mail is gehackt, communiceer je via telefoon of een apart kanaal. Een WhatsApp-groep met je kernteam is een simpele back-up.
- Conceptteksten. Een kort bericht voor medewerkers, een voor klanten en een voor de pers. Vooraf schrijven scheelt fouten onder druk.
- Wanneer je betrokkenen informeert. Bij een datalek met een hoog risico moet je ook de mensen zelf inlichten. Overleg dit met je jurist of functionaris gegevensbescherming.
Een incident raakt ook je naam. Valse berichten of negatieve reviews na een lek kunnen veel schade doen. Een vast protocol tegen online reputatieaanvallen helpt je om ook dat deel van een incident rustig en snel op te pakken.
Testen en bijwerken
Een plan in een la helpt je niet. Het NCSC zegt het duidelijk: door te oefenen wordt incidentrespons een natuurlijke handeling en leer je van fouten en belemmeringen. Zo pak je dat aan:
- Tabletop-oefening: je zit met je kernteam aan tafel en speelt een scenario na. “Het is maandagochtend, alle bestanden op de server zijn versleuteld. Wat doe je?” Binnen een uur zie je waar het plan gaten heeft.
- Simulatie: je IT-partner bootst een incident na, bijvoorbeeld een phishingtest of het terugzetten van een back-up.
- Training: het NCSC noemt periodiek trainen van medewerkers als vast onderdeel, zodat iedereen zijn eigen taak kent. Een security awareness programma helpt daarbij.
- Evaluatie na elk incident: ook na een klein incident. Het NCSC-verbeterplan beschrijft hoe je lessen systematisch verwerkt.
Werk het plan ook bij als er iets verandert: een nieuwe medewerker in een sleutelrol, een nieuwe IT-partner, een overstap naar de cloud of een nieuw telefoonnummer. Een bellijst met een oud nummer is in een crisis waardeloos.
Veelgemaakte fouten in het mkb
Deze fouten zien we het vaakst:
- ❌ Het plan staat alleen op de server. Bij ransomware kun je er dan niet bij. Bewaar een papieren en een offline kopie.
- ❌ Eén persoon weet alles. Is die persoon op vakantie, dan staat alles stil. Zet bij elke rol een vervanger.
- ❌ Te lang en te algemeen. Dertig pagina’s leest niemand onder stress. Houd de kern op een paar pagina’s.
- ❌ Back-ups nooit getest. Een back-up die je niet kunt terugzetten, is geen back-up. Meer hierover lees je in onze kennisbank over back-up en disaster recovery.
- ❌ Geen afspraken met de IT-partner. Weet je wie je om zondagavond belt en wat die dan doet?
- ❌ Nooit geoefend. Dan merk je pas tijdens het echte incident wat er niet klopt.
Onze kijk: een plan werkt alleen met een vast aanspreekpunt
We zien bij veel mkb-bedrijven hetzelfde patroon. Het plan is netjes geschreven, maar op het moment zelf belt iemand een algemeen nummer, maakt een ticket aan en wacht. Of de verantwoordelijkheid ligt verspreid over een internetprovider, een telefonieleverancier en een losse IT’er, die elkaar naar elkaar doorverwijzen. Juist in de eerste uur telt elke minuut.
Daarom vinden we twee dingen belangrijk. Ten eerste: zorg dat er één partij is die verantwoordelijk is voor je hele IT-fundament, van werkplek en netwerk tot telefonie en cloud. Dan staat er in je bellijst één nummer, en hoeft niemand uit te zoeken waar het probleem zit. Ten tweede: voorkom zoveel mogelijk dat het zover komt. Met 24/7 monitoring zien we veel signalen voordat een medewerker iets merkt. Het incidentresponsplan blijft nodig, maar je gebruikt het minder vaak en met minder schade.
Onze tip: zet in je plan niet alleen wie je belt, maar ook wat je van die partij mag verwachten. Hoe snel nemen ze op? Wie beslist over het afsluiten van systemen? Wie meldt bij de verzekeraar? Als je dat vooraf afspreekt, is je plan meer dan een document.
— Mick
Incidentrespons uitbesteden aan ASTIA
Wil je een plan dat in de praktijk werkt, zonder dat je zelf een securityteam hoeft op te bouwen? Bij ASTIA nemen we het volledige IT-beheer van je bedrijf over: werkplekken, netwerk, telefonie, cloud en beveiliging. Je belt ons direct, zonder ticketsysteem, en je betaalt een vaste, transparante prijs per werkplek.
We bewaken je omgeving 24/7, regelen back-ups en pakken incidenten op als het toch misgaat. Zo staat in je incidentresponsplan één partner die het hele fundament kent. Bekijk hoe we incidentbeheer voor het mkb aanpakken, of lees meer over onze IT-beveiliging. We zitten in Vianen en werken voor bedrijven in onder meer Utrecht, Zuid-Holland, Noord-Brabant en Noord-Holland.
Veelgestelde vragen
Is een incidentresponsplan verplicht voor mijn bedrijf?
Niet voor elk bedrijf staat het letterlijk in de wet. Wel moet je onder de AVG een datalek binnen 72 uur kunnen melden, en dat lukt alleen als je weet wie wat doet. Organisaties die onder de Cyberbeveiligingswet vallen, hebben zwaardere plichten, en ook cyberverzekeraars vragen vaak om een plan.
Hoe lang moet een incidentresponsplan zijn?
Zo kort als het kan. Een kern van een paar pagina’s met rollen, bellijst, beslisregels en meldtermijnen werkt het best. Playbooks en technische details zet je in bijlagen.
Hoe vaak moet ik het plan testen?
Plan minstens een tabletop-oefening per jaar en evalueer elk echt incident. Werk het plan daarnaast bij zodra er iets verandert in je team, je leveranciers of je IT-omgeving.
Wat is het eerste wat ik doe bij een vermoedelijke hack?
Bel direct je IT-partner en de incidentleider uit je plan. Ontkoppel een verdacht apparaat van het netwerk, maar zet het niet uit en wis niets. Noteer vanaf het begin wat er gebeurt en wanneer.
Wat is het verschil tussen incidentbeheer en een incidentresponsplan?
Incidentbeheer is het dagelijkse proces van storingen en meldingen oplossen, van een vastgelopen laptop tot een netwerkstoring. Een incidentresponsplan is gericht op beveiligingsincidenten zoals ransomware of een datalek. Het plan bouwt voort op goed incidentbeheer.
Bronnen
- NCSC: Incidentresponsplan
- NCSC: Cyber Incident Response Plan, Deel A Context
- NCSC: Cyber Incident Response Plan, Deel B Draaiboek
- NCSC: Incident Response Verbeterplan
- NCSC: Basisprincipe 5, Bereid je voor op incidenten
- Autoriteit Persoonsgegevens: Zo meldt u een datalek
- Digitale Overheid: Verplichtingen onder de Cyberbeveiligingswet