Een incident response plan opstellen doe je door een gestructureerd document te maken dat beschrijft hoe jouw organisatie reageert op beveiligingsincidenten: wie wat doet, in welke volgorde, en hoe je communiceert. Het plan vormt de ruggengraat van een doeltreffende beveiligingsincidentaanpak en voorkomt dat medewerkers in paniek improviseren op het moment dat het er echt toe doet. In dit artikel beantwoorden we de meest gestelde vragen over het opstellen en onderhouden van een werkbaar incident response plan.
Wat moet er minimaal in een incident response plan staan?
Een incident response plan bevat minimaal een definitie van wat een incident is, een classificatieschema, een lijst van verantwoordelijke personen met contactgegevens, een stappenplan voor afhandeling, communicatierichtlijnen en een evaluatieprocedure. Zonder deze bouwstenen is het plan onvolledig en niet bruikbaar onder druk.
In de praktijk zien veel organisaties een incident response plan als een lang beleidsdocument, maar de kern moet juist beknopt en operationeel zijn. Denk aan een document dat ook midden in de nacht snel raadpleegbaar is. De minimale inhoud bestaat uit:
- Scope en doelstelling: voor welke systemen, locaties en incidenttypen geldt het plan?
- Definities: wat verstaat de organisatie onder een beveiligingsincident, een datalek en een calamiteit?
- Classificatieschema: hoe worden incidenten ingedeeld op ernst?
- Rollen en contactpersonen: wie is bereikbaar, wie beslist, wie communiceert?
- Afhandelingsprocedure: de stappen van detectie tot en met herstel
- Communicatieprotocol: intern naar management en medewerkers, extern naar klanten, toezichthouders of de Autoriteit Persoonsgegevens
- Registratie en rapportage: hoe worden incidenten gedocumenteerd?
- Evaluatie: hoe wordt het incident naderhand geanalyseerd?
Een goed incident response plan sluit aan bij bestaande normen zoals ISO 27001, die informatiebeveiliging organisatiebreed verankert. De norm vereist dat organisaties een procedure hebben voor het melden, beoordelen en afhandelen van incidenten als onderdeel van het Information Security Management System.
Hoe classificeer je een beveiligingsincident?
Een beveiligingsincident classificeer je op basis van de impact op beschikbaarheid, integriteit en vertrouwelijkheid van informatie, gecombineerd met de urgentie van herstel. Een veelgebruikte indeling is drie niveaus: laag, middel en hoog, waarbij elk niveau een eigen responstijd en escalatiepad heeft.
Classificatie is het fundament van een effectieve incident response. Zonder heldere categorieën reageert de organisatie op elk incident met dezelfde intensiteit, wat leidt tot verspilling van capaciteit bij kleine incidenten en onderschatting bij grote. Gebruik bij de classificatie de volgende criteria:
- Laag (niveau 1): beperkte impact, geen persoonsgegevens betrokken, systemen nog functioneel. Voorbeeld: een medewerker klikt op een phishingmail maar voert geen gegevens in.
- Middel (niveau 2): merkbare verstoring, mogelijk persoonsgegevens betrokken, beperkt aantal gebruikers getroffen. Voorbeeld: een account is gecompromitteerd maar direct geblokkeerd.
- Hoog (niveau 3): grote impact op bedrijfscontinuïteit, aantoonbaar datalek, meerdere systemen of klanten betrokken. Voorbeeld: ransomware op een productieserver of een datalek met meldplicht bij de Autoriteit Persoonsgegevens.
Leg de classificatiecriteria zo concreet mogelijk vast in het plan, zodat de medewerker die als eerste een incident signaleert zelfstandig een eerste inschatting kan maken. Dat bespaart kostbare tijd in de beginfase van een informatiebeveiligingsincident.
Wie is verantwoordelijk tijdens een beveiligingsincident?
Tijdens een beveiligingsincident is doorgaans de Security Officer of CISO eindverantwoordelijk voor de coördinatie, maar de daadwerkelijke afhandeling vraagt om een duidelijk team met vaste rollen: een incidentcoördinator, technische specialisten, een communicatieverantwoordelijke en een beslisser op managementniveau.
Een veelgemaakte fout is dat verantwoordelijkheden pas tijdens een incident worden bepaald. Dan gaat kostbare tijd verloren aan discussie over wie wat mag beslissen. Leg in het plan minimaal de volgende rollen vast:
- Incidentcoördinator: bewaakt het proces, houdt het overzicht en zorgt dat stappen worden uitgevoerd en gedocumenteerd
- Technisch specialist: analyseert de oorzaak, isoleert systemen en voert herstelmaatregelen uit
- Communicatieverantwoordelijke: stelt berichten op voor interne en externe communicatie
- Beslisser (management): neemt besluiten over escalatie, uitschakeling van systemen of externe meldingen
- Functionaris Gegevensbescherming (FG): adviseert bij incidenten waarbij persoonsgegevens zijn betrokken en beoordeelt de meldplicht
Vermeld bij elke rol ook de vervanger, want incidenten houden geen rekening met vakanties of ziekteverzuim. Voeg telefoonnummers en alternatieve contactmethoden toe, zodat het team ook bereikbaar is als e-mail tijdelijk niet beschikbaar is.
Welke stappen volg je bij het afhandelen van een incident?
Bij het afhandelen van een beveiligingsincident volg je zes opeenvolgende stappen: detectie en melding, eerste beoordeling en classificatie, inperking, uitroeiing, herstel en tot slot evaluatie. Deze volgorde zorgt dat je niet direct naar herstel springt terwijl de oorzaak nog actief is.
De stappen in detail:
- Detectie en melding: een medewerker, systeem of externe partij signaleert een afwijking en meldt dit via het vastgelegde kanaal, zoals een intern ticketsysteem of een speciaal meldpunt.
- Eerste beoordeling en classificatie: de incidentcoördinator beoordeelt de melding, bepaalt het niveau en activeert het juiste responsteam.
- Inperking (containment): beperk de schade door besmette systemen te isoleren, accounts te blokkeren of netwerksegmenten af te sluiten. Onderscheid hierbij kortetermijnmaatregelen (direct stoppen van de verspreiding) van langetermijnmaatregelen (structurele aanpak).
- Uitroeiing (eradication): verwijder de oorzaak, zoals malware, een kwetsbare configuratie of een gecompromitteerd account.
- Herstel: herstel systemen en diensten stap voor stap, monitor nauwlettend op terugkeer van het probleem en valideer of alles correct functioneert.
- Evaluatie (lessons learned): analyseer wat er is gebeurd, hoe het is ontdekt, hoe effectief de respons was en welke verbeteringen nodig zijn in het plan of de technische omgeving.
Zorg dat elke stap wordt gedocumenteerd met tijdstempel, uitgevoerde actie en naam van de uitvoerder. Die registratie is niet alleen waardevol voor de evaluatie, maar ook noodzakelijk als er een meldplicht geldt bij de Autoriteit Persoonsgegevens of bij toezichthouders in het kader van NIS2.
Hoe test je of een incident response plan werkt?
Je test een incident response plan door regelmatig oefeningen te organiseren: van een papieren doorloop (tabletop exercise) waarbij het team een fictief scenario bespreekt, tot een realistische simulatie waarbij systemen daadwerkelijk worden geïsoleerd. Zonder testen blijft een plan theorie.
Er zijn drie niveaus van testen, elk met een eigen doel:
- Tabletop exercise: het team bespreekt een scenario aan tafel zonder systemen aan te raken. Doel: controleren of rollen duidelijk zijn, of het plan logisch is en of communicatie soepel verloopt. Geschikt als eerste test of als opfrissing.
- Functionele test: specifieke onderdelen van het plan worden in de praktijk getest, zoals het daadwerkelijk isoleren van een testomgeving of het doorlopen van de meldprocedure. Doel: technische procedures valideren.
- Volledige simulatie: een realistisch scenario wordt zo volledig mogelijk nagebootst, inclusief communicatie naar management en externe partijen. Doel: het volledige plan onder druk testen.
Na elke oefening stel je een verbeterrapport op. Noteer wat goed ging, wat onduidelijk was en welke aanpassingen nodig zijn. Een interne audit kan hierbij ondersteunen door objectief te beoordelen of de procedures aansluiten bij de praktijk en voldoen aan de gestelde normen.
Wanneer moet een incident response plan worden bijgewerkt?
Een incident response plan moet minimaal jaarlijks worden herzien, maar ook direct na elk significant incident, na organisatiewijzigingen, na de introductie van nieuwe systemen of na relevante wijzigingen in wet- en regelgeving. Een verouderd plan biedt bij een echte crisis weinig houvast.
Concrete aanleidingen om het plan bij te werken zijn:
- Een afgerond incident waarbij de evaluatie verbeterpunten heeft opgeleverd
- Wijzigingen in de organisatiestructuur, zoals nieuwe afdelingen of een andere Security Officer
- De introductie van nieuwe systemen, clouddiensten of leveranciers die het aanvalsoppervlak veranderen
- Nieuwe of gewijzigde wetgeving, zoals de inwerkingtreding van de Cyberbeveiligingswet (de Nederlandse vertaling van NIS2, naar verwachting medio 2026)
- Resultaten van een tabletop exercise of simulatie die hiaten in het plan blootleggen
- Externe incidenten in de sector die nieuwe risico’s zichtbaar maken
Behandel het incident response plan als een levend document. Leg vast wie verantwoordelijk is voor het onderhoud en wanneer de volgende geplande revisie plaatsvindt. Zo voorkom je dat het plan jarenlang ongewijzigd in een la blijft liggen terwijl de organisatie en het dreigingslandschap verder ontwikkelen.
Hoe Kwinzo helpt bij het opstellen van een incident response plan
Een werkbaar incident response plan opstellen vraagt om meer dan een sjabloon invullen. Het plan moet aansluiten op de specifieke processen, systemen en risico’s van jouw organisatie. Wij ondersteunen organisaties in zorg, ICT en onderwijs bij het opzetten van een compleet en praktisch toepasbaar plan, als onderdeel van een breder implementatietraject voor informatiebeveiliging.
Wat wij daarbij bieden:
- Een vaste consultant die jouw organisatie en sector kent en het plan afstemt op jullie bedrijfsvoering
- Begeleiding bij het inrichten van het volledige ISMS, inclusief incidentbeheer, op basis van erkende normen zoals ISO 27001 en NEN-7510
- Praktische hulpmiddelen, waaronder onze eigen ISMS-tool en voorbeelddocumenten, zodat je niet vanaf nul hoeft te beginnen
- Interne audits uitgevoerd door een onafhankelijke consultant, als generale repetitie voor de externe audit en als toets of het plan daadwerkelijk werkt
- Maandelijkse workshops voor Security Officers, gericht op specifieke onderdelen van de norm en het delen van praktijkervaringen
Wil je weten hoe wij jouw organisatie kunnen helpen bij het opstellen of verbeteren van een incident response plan? Neem contact met ons op voor een vrijblijvend adviesgesprek.