Incident response plan
Een incident response plan is een vastgelegd draaiboek waarin staat wie wat doet zodra uw organisatie door een cyberincident wordt geraakt. Het legt rollen, mandaat, meldtermijnen en de eerste handelingen per scenario vast. Het doel is dat niemand tijdens een incident nog hoeft uit te zoeken wie mag beslissen.
Op deze pagina leest u wat er in het plan hoort, hoe u het in zes stappen opstelt, welke meldtermijnen de Cyberbeveiligingswet (CBW) van u vraagt, en hoe u het plan aantoonbaar houdt voor een audit.
Wij komen deze vraag meestal tegen nadat er iets is gebeurd bij een branchegenoot, of als een grote klant erom vraagt in een leveranciersvragenlijst. De vraag is dan zelden of er een plan moet komen, maar wat erin hoort.
Wat is een incident response plan?
Een incident response plan beschrijft hoe uw organisatie een verstoring van de informatiebeveiliging herkent, beperkt, oplost en meldt.
Het verschil met een algemeen calamiteitenplan zit in de aard van de verstoring. Bij een cyberincident is vaak onduidelijk wat er precies aan de hand is, hoe lang het al speelt en welke systemen te vertrouwen zijn. Dat vraagt andere beslissingen dan bij brand of stroomuitval.
Een goed plan is kort en bruikbaar. Wij zien met enige regelmaat documenten van veertig pagina’s die niemand tijdens een incident openslaat. Wat werkt is een kern van enkele pagina’s met rollen, telefoonnummers, beslisregels en meldtermijnen, met de uitwerking als bijlage.
Het plan hoort ook offline beschikbaar te zijn. Als uw netwerk versleuteld is of uw accounts geblokkeerd zijn, kunt u niet bij een document dat alleen in uw eigen omgeving staat. Een geprinte versie bij de sleutelfiguren thuis klinkt ouderwets en is in de praktijk vaak het enige dat werkt.
Incident, crisis of continuïteit: waar de plannen elkaar raken
Een incident response plan gaat over de afhandeling. Een crisisplan gaat over sturing en communicatie, een continuïteitsplan over doorwerken zonder de getroffen systemen.
Die drie worden vaak door elkaar gehaald, waardoor organisaties of drie overlappende documenten hebben of één document dat niets goed doet. In de praktijk is de grens eenvoudig te trekken.
Zolang het incidentteam het aankan en de dienstverlening doorloopt, is het een incident. Zodra er besluiten nodig zijn die buiten het mandaat van dat team vallen, of zodra klanten, media of toezichthouders in beeld komen, wordt het een crisis. Loopt de dienstverlening zelf gevaar, dan komt het continuïteitsplan erbij.
Leg in uw incident response plan één ding hierover vast: bij welke signalen u opschaalt en wie dat besluit neemt. Dat is de koppeling tussen de plannen en meteen het punt waarop het in oefeningen het vaakst misgaat.
Wat er in een incident response plan hoort te staan
Loop deze onderdelen langs. Ontbreekt er één, dan valt het plan tijdens een incident precies daar stil.
- Een definitie van wat bij u een incident is, met voorbeelden en een indeling naar ernst.
- Hoe een melding binnenkomt: bij wie, via welk kanaal, en wat er buiten kantoortijd geldt.
- De samenstelling van het incidentteam, met vervangers en bereikbaarheid buiten uw eigen systemen om.
- Het mandaat: wie mag besluiten systemen af te sluiten, en tot welke gevolgen zonder ruggespraak.
- De meldtermijnen en bij wie u meldt, met de contactgegevens erbij.
- De eerste handelingen per scenario, zodat de eerste dertig minuten niet aan overleg opgaan.
- Afspraken met uw IT-leverancier, uw clouddienstverlener en uw verzekeraar, inclusief telefoonnummers.
- Wat u vastlegt tijdens het incident, en waar, zodat bewijs bruikbaar blijft.
- Interne en externe communicatie: wie praat met medewerkers, klanten en pers, en wie juist niet.
- Hoe u afschaalt, herstelt en achteraf evalueert, met een eigenaar voor de verbeterpunten.
Het plan hoeft niet elk denkbaar geval te dekken. Het moet ervoor zorgen dat de eerste uren gestructureerd verlopen, want daar wordt het verschil gemaakt.
Rollen, mandaat en besluitvorming tijdens een incident
De meeste plannen benoemen rollen. Weinig plannen leggen vast wie welk besluit mag nemen, en dat is precies wat onder druk misgaat.
Een incidentteam bestaat meestal uit een coördinator, iemand met technische kennis van de omgeving, iemand namens de directie, en iemand voor communicatie. Bij persoonsgegevens sluit de privacy officer aan. Belangrijker dan de bezetting is de vraag wie waarover gaat.
Leg minimaal vier bevoegdheden expliciet vast. Wie mag besluiten een systeem of een locatie van het netwerk te halen, ook als daarmee de dienstverlening stilvalt. Wie escaleert naar de directie en vanaf welk moment. Wie neemt het woord richting klanten en pers. En wie beslist er bij een losgeldeis, want die vraag komt onherroepelijk bij de bestuurder terecht.
Neem over dat laatste vooraf een standpunt in, in alle rust. Overleg met uw verzekeraar en met uw juridisch adviseur wat uw uitgangspunt is en wie u inschakelt. Een besluit dat om drie uur ’s nachts voor het eerst wordt besproken, is zelden een goed besluit.
Ontbreekt binnen uw organisatie iemand die het incidentteam kan leiden, dan kan die rol tijdelijk extern worden ingevuld via CISO as a Service, tot iemand intern is ingewerkt.
Vier scenario's en de eerste stappen per scenario
Deze vier situaties komen het vaakst voor. Neem ze uitgeschreven op in uw plan, zodat de eerste handelingen vastliggen.
- Ransomware, ook de back-ups geraakt. Eerste drie handelingen: Getroffen systemen isoleren, back-ups offline controleren, incidentteam bijeenroepen. Melden: CSIRT en toezichthouder, en de Autoriteit Persoonsgegevens als er persoonsgegevens in het spel zijn. Wie stuurt: Coördinator, met de directie voor besluiten over uitschakelen.
- Datalek bij een leverancier in uw keten. Eerste drie handelingen: Opvragen wat er precies is geraakt, eigen risico bepalen, afspraken uit de verwerkersovereenkomst erbij pakken. Melden: Autoriteit Persoonsgegevens binnen 72 uur bij persoonsgegevens. Wie stuurt: Privacy officer, samen met contractbeheer.
- Gecompromitteerd account van een bestuurder. Eerste drie handelingen: Sessies intrekken en wachtwoord opnieuw zetten, mailregels en doorstuurinstellingen controleren, verzonden berichten nalopen. Melden: Afhankelijk van wat er is ingezien of verstuurd. Wie stuurt: Coördinator, met de directie voor communicatie.
- Uitval van een IT-leverancier of clouddienst. Eerste drie handelingen: Impact per proces bepalen, uitwijk of handmatige werkwijze starten, klanten informeren. Melden: Alleen als er gegevens zijn geraakt of als u meldplichtig bent voor de dienst. Wie stuurt: Continuïteitsverantwoordelijke.
Wat deze scenario’s gemeen hebben is dat de eerste beslissing bijna altijd gaat over isoleren tegenover doordraaien. Leg vast wie die afweging maakt, dan hoeft dat niet op het moment zelf te worden uitgevonden.
Melden onder de Cyberbeveiligingswet: de termijnen in uw plan
De Cyberbeveiligingswet (CBW), de Nederlandse uitwerking van NIS2, geldt vanaf 15 augustus 2026 en kent een meldketen in drie stappen.
Die keten wordt in de praktijk vaak samengevat als “melden binnen 24 uur”, maar zo werkt het niet. Er zijn drie momenten met elk een eigen inhoud. Neem ze zo op in uw plan, inclusief wie het doet.
- Vroegtijdige waarschuwing. Termijn: Binnen 24 uur na constatering. Wat u meldt: Dat er een significant incident speelt, en of er een vermoeden is van opzet of grensoverschrijdende gevolgen.
- Incidentmelding. Termijn: Binnen 72 uur na constatering. Wat u meldt: Een eerste beoordeling van ernst en impact, en wat u tot dan toe weet over de oorzaak.
- Eindverslag. Termijn: Binnen een maand na de incidentmelding. Wat u meldt: Wat er is gebeurd, welke maatregelen zijn genomen en welke verbeteringen volgen.
Daarnaast blijft de AVG gewoon gelden. Zijn er persoonsgegevens geraakt, dan meldt u dat binnen 72 uur bij de Autoriteit Persoonsgegevens, en bij hoog risico informeert u ook de betrokkenen. Dat is een aparte melding bij een andere instantie, met een eigen beoordeling.
De klok begint te lopen op het moment dat u het incident constateert. Leg daarom vast wie bepaalt dat er sprake is van een significant incident en hoe dat moment wordt vastgelegd. Zonder dat is achteraf niet aantoonbaar of u op tijd was. Meer over de wet zelf staat op onze pagina over de Cyberbeveiligingswet.
Wat u vooraf vastlegt met uw leveranciers en uw verzekeraar
Bij uitbesteed IT-beheer ligt de uitvoering bij een ander. Uw plan is pas bruikbaar als die afspraken erin staan.
Dit is het onderdeel dat in vrijwel elk plan ontbreekt, terwijl het bij een incident als eerste nodig is. Zoek nu uit wat er in uw contracten staat, niet straks.
Van uw IT-leverancier legt u vast wie u buiten kantoortijd bereikt, binnen welke tijd zij reageren, wie bij hen mag besluiten systemen te isoleren en welke logging zij bewaren en hoelang. Dat laatste bepaalt of achteraf te reconstrueren is wat er is gebeurd.
Van uw clouddienstverlener legt u vast waar u een incident meldt en welke gegevens zij op verzoek kunnen leveren. Van uw verzekeraar legt u vast welk nummer u belt, binnen welke termijn u moet melden en of zij een eigen partij aanwijzen voor het onderzoek. Meldt u te laat, dan kan dat gevolgen hebben voor de dekking.
Zet die gegevens in het plan zelf, niet als verwijzing naar een contract in een systeem dat mogelijk niet bereikbaar is.
Een incident response plan opstellen in zes stappen
Een werkbaar plan is in enkele weken op te stellen. Het meeste werk zit in het maken van keuzes, niet in het schrijven.
1. Bepaal de scope en de uitgangspunten
Wij bepalen samen welke locaties, systemen en diensten onder het plan vallen en wat bij u als incident telt. U levert een overzicht van uw belangrijkste processen en systemen. Dat levert een afbakening op die voorkomt dat het plan te algemeen wordt.
2. Leg rollen en mandaat vast
Wij werken de rollen uit met bevoegdheden, vervangers en bereikbaarheid. U wijst de personen aan en laat de directie het mandaat bevestigen. Dat levert de bevoegdheden op die tijdens een incident niet meer ter discussie staan.
3. Werk de scenario’s uit
Wij schrijven de scenario’s uit die bij uw organisatie passen, met de eerste handelingen per scenario. U vertelt wat er in het verleden is misgegaan en waar u zich zorgen over maakt. Dat levert draaiboeken op die aansluiten op uw eigen omgeving.
4. Regel de meldketen
Wij nemen de termijnen en instanties op, met een beslisboom voor wat wanneer meldplichtig is. U levert de contactgegevens van leveranciers en verzekeraar aan. Dat levert een meldparagraaf op die ook bruikbaar is voor wie de wet niet kent.
5. Stel vast en verspreid
Wij leveren het plan op in een korte kernversie met bijlagen. U laat het vaststellen door de directie en zorgt dat het offline beschikbaar is. Dat levert een document op met een versie, een datum en een eigenaar, precies wat een auditor vraagt.
6. Oefen het plan
Wij begeleiden een oefening waarin het team het plan onder tijdsdruk gebruikt. U zorgt dat de juiste mensen aanschuiven, inclusief de directie. Dat levert een oefenverslag op met verbeterpunten, en meteen het bewijs dat het plan is beproefd.
Het plan oefenen en aantoonbaar houden
Een plan dat nooit is geoefend, is een aanname. Pas tijdens een oefening blijkt of de rollen kloppen en of de gegevens nog actueel zijn.
De lichtste vorm is een tabletop, waarbij het team rond de tafel een scenario doorloopt zonder dat er iets in de techniek gebeurt. Dat kost een dagdeel en levert verrassend veel op, vooral rond besluitvorming en communicatie. Zwaardere vormen simuleren een uitval of testen technisch mee.
Voor ISO 27001 en NEN 7510 is de bewijslast concreet. Een auditor wil een vastgesteld document met versiebeheer zien, een oefenverslag, een lijst met verbeterpunten en het bewijs dat die punten zijn opgevolgd. Datzelfde dossier gebruikt u voor de zorgplicht onder de Cyberbeveiligingswet.
Plan het onderhoud als vast ritme. Eén oefening per jaar, een korte controle na elke wijziging in systemen of leveranciers, en een evaluatie na elk werkelijk incident. Het plan hoort bij de documenten die u binnen uw ISMS beheert, zodat het niet los komt te staan.
Wat de omvang van het traject bepaalt
De inspanning verschilt sterk per organisatie. Deze factoren bepalen het verschil.
- Aantal locaties en entiteiten. Meer entiteiten betekent meer rollen, meer mandaatvragen en meer afstemming.
- Uitbesteed of eigen IT-beheer. Bij uitbesteding kost het uitvragen van de leveranciersafspraken vaak meer tijd dan het schrijven.
- Wat er al ligt. Een bestaand continuïteitsplan of calamiteitenplan scheelt werk, mits het actueel is.
- Aantal scenario's. Vier uitgewerkte scenario's is een werkbare basis, sectorspecifieke situaties komen daarbij.
- Wel of geen productieomgeving. Machines en installaties vragen andere afwegingen dan kantoorautomatisering.
- Gewenste oefenvorm. Een tabletop vraagt een dagdeel, een simulatie meer voorbereiding van uw eigen mensen.
Wij maken de omvang van uw traject inzichtelijk in een vrijblijvend gesprek.
Zo helpt QENSORA bij uw incident response plan
Wij stellen het plan op, richten de meldketen in en oefenen het met uw team. De technische afhandeling tijdens een incident doen wij niet.
Die grens is bewust en het is goed dat u die kent. Forensisch onderzoek, herstel en bijstand op locatie zijn het werk van een gespecialiseerd responsteam dat daar dag en nacht op is ingericht. Wij zorgen dat u weet wie u belt, dat de afspraken vooraf liggen en dat uw organisatie weet wat zij zelf moet doen.
Wat wij toevoegen is de combinatie van techniek en compliance. Veel plannen zijn geschreven door juristen en missen de technische werkelijkheid, of ze zijn geschreven door IT en missen de meldplichten. Wij kijken naar beide, en toetsen het plan aan de eisen die uw auditor straks stelt.
René van der Horst werkt dertig jaar in IT-leiderschap en begeleidt organisaties bij de Cyberbeveiligingswet, ISO 27001 en NEN 7510. Hij voert de intake zelf en beoordeelt of u met een compacte versie klaar bent of dat er meer speelt.
Wilt u eerst weten hoe uw beveiliging er technisch voor staat, dan is een security assessment een logischer beginpunt. Wilt u het bestuur meenemen in wat de wet van hen vraagt, kijk dan naar de boardroom training NIS2.
Voorbereid zijn op het moment dat het misgaat
De waarde van een incident response plan zit niet in het document. Die zit in de gesprekken die u voert bij het opstellen ervan, en in het feit dat de moeilijke keuzes al zijn gemaakt voordat het spannend wordt.
Wilt u weten wat er in uw situatie nodig is? Neem vrijblijvend contact op. In een eerste gesprek wordt meestal snel duidelijk of u met een compacte versie klaar bent of dat er meer speelt.
Veelgestelde vragen over het incident response plan
Is een incident response plan verplicht?
Voor organisaties die onder de Cyberbeveiligingswet vallen wel. De zorgplicht vraagt om incidentafhandeling, en zonder vastgelegde werkwijze is die niet aantoonbaar. Ook ISO 27001 en NEN 7510 vragen om een procedure voor informatiebeveiligingsincidenten. Valt u onder geen van drie, dan is het niet verplicht maar wel verstandig.
Hoe uitgebreid moet ons plan zijn?
De kern past op enkele pagina’s. Rollen, mandaat, meldtermijnen, contactgegevens en de eerste handelingen per scenario. De uitwerking hoort in bijlagen. Een plan dat tijdens een incident wordt opengeslagen, moet in een paar minuten leesbaar zijn. Lengte is hier geen kwaliteitskenmerk.
Wij hebben al een continuïteitsplan. Is dat hetzelfde?
Nee. Een continuïteitsplan gaat over doorwerken zonder de getroffen systemen. Een incident response plan gaat over het afhandelen van de verstoring zelf: vaststellen wat er speelt, beperken, melden en herstellen. De twee sluiten op elkaar aan. Leg vast op welk moment het continuïteitsplan erbij komt.
Binnen welke termijn moeten wij een incident melden?
Onder de Cyberbeveiligingswet geldt een vroegtijdige waarschuwing binnen 24 uur, een incidentmelding binnen 72 uur en een eindverslag binnen een maand. Zijn er persoonsgegevens geraakt, dan geldt daarnaast de meldplicht bij de Autoriteit Persoonsgegevens binnen 72 uur. Dat zijn twee losse trajecten bij twee instanties.
Wie moet er meedoen aan een oefening?
Het volledige incidentteam, inclusief iemand namens de directie. Juist de bestuurlijke besluiten lopen tijdens een oefening vast, en die kunt u niet namens iemand anders oefenen. Bij uitbesteed IT-beheer is het waardevol om uw leverancier te laten aanschuiven, al is het maar voor één scenario.
Hoe vaak moeten wij het plan actualiseren?
Jaarlijks als vast ritme, en tussentijds bij elke wijziging die het plan raakt. Denk aan een nieuwe IT-leverancier, een overname, een verhuizing of een wijziging in het team. Na een werkelijk incident volgt altijd een evaluatie. Leg de wijzigingen vast met versienummer en datum, dat is meteen uw auditbewijs.
Wat doen wij bij een losgeldeis?
Neem dat besluit niet tijdens het incident. Bepaal vooraf wie erover gaat, betrek uw verzekeraar en uw juridisch adviseur, en leg uw uitgangspunt vast in het plan. Schakel bij een werkelijke eis altijd een gespecialiseerde partij in. Betaling biedt geen zekerheid over herstel en verandert niets aan uw meldplicht.
Wat als wij nog helemaal geen plan hebben?
Dat is de meest voorkomende startsituatie. Wij beginnen dan met een korte inventarisatie van uw processen en leveranciers, en leveren een compacte kernversie op. Die is direct bruikbaar. Uitbreiden met extra scenario’s en bijlagen kan daarna, in uw eigen tempo.
Improved Security, Smarter Compliance.
Weten waar uw organisatie staat op het gebied van cybersecurity, compliance of IT? Of bent u benieuwd welke risico’s of verplichtingen voor uw organisatie relevant zijn?
Neem vrijblijvend contact op met QENSORA voor een kennismaking of adviesgesprek. Samen kijken we hoe uw organisatie veiliger en slimmer kan worden.
