Een incidentresponsplan opstellen doe je door vijf kernonderdelen vast te leggen: een duidelijke definitie van wat een incident is, de rollen en verantwoordelijkheden van betrokkenen, een stapsgewijze responsprocedure, communicatieprotocollen en een evaluatieproces na afloop. Zonder dit plan reageert een organisatie chaotisch op een cyberaanval, datalekken of ransomware. In dit artikel beantwoorden we de meest gestelde vragen over het opzetten van een effectief incidentresponsplan.
Wat moet er in een incidentresponsplan staan?
Een incidentresponsplan bevat minimaal zes onderdelen: een scope en doelstelling, een classificatiesysteem voor incidenten, rollen en verantwoordelijkheden, een stapsgewijze responsprocedure, communicatieprotocollen en een evaluatieproces. Samen vormen deze elementen de ruggengraat van gestructureerd incidentbeheer binnen een organisatie.
Begin met de scope: voor welke systemen, processen en locaties geldt het plan? Daarna leg je vast wat jouw organisatie verstaat onder een incident, zodat iedereen hetzelfde beeld heeft bij een beveiligingsgebeurtenis. Vervolgens beschrijf je de stappen die worden gezet vanaf het moment van ontdekking tot en met het herstel en de evaluatie.
De incident response procedure volgt doorgaans deze volgorde:
- Voorbereiding: tools, trainingen en contactlijsten op orde hebben
- Detectie en melding: het incident signaleren en intern rapporteren
- Analyse: de aard, omvang en ernst bepalen
- Indamming: verdere schade beperken
- Herstel: systemen en processen terugbrengen naar normale werking
- Evaluatie: lessen trekken en het plan verbeteren
Naast de technische procedure hoort ook een communicatieprotocol in het plan. Wie informeert intern de directie? Wie communiceert extern richting klanten, toezichthouders of de pers? Onder de NIS2-regelgeving geldt bovendien een meldplicht: een significant incident moet binnen 24 uur worden gemeld bij de bevoegde autoriteit, gevolgd door aanvullende informatie binnen 72 uur en een eindverslag binnen een maand. Dit meldproces hoort expliciet in het plan beschreven te staan.
Welke rollen en verantwoordelijkheden horen in een incidentresponsplan?
In een incidentresponsplan leg je minimaal vier rollen vast: een incident response manager (of CISO), een technisch team, een communicatieverantwoordelijke en een beslissingsbevoegde uit het bestuur. Elke rol heeft een duidelijk omschreven taak zodat er geen overlap of gat ontstaat op het moment dat het misgaat.
De incident response manager coördineert de respons en bewaakt de voortgang. Het technisch team analyseert het incident, damt het in en herstelt systemen. De communicatieverantwoordelijke beheert alle interne en externe berichten. De bestuurder neemt beslissingen over escalatie, externe melding en eventuele bedrijfsonderbreking.
Een veelgemaakte fout is dat organisaties geen vervangers benoemen. Stel dat de CISO ziek is op het moment van een aanval: wie neemt dan de leiding? Leg per rol een primaire en een secundaire verantwoordelijke vast, inclusief contactgegevens. Bewaar deze contactlijst ook offline, want bij een ransomware-aanval zijn digitale systemen mogelijk niet bereikbaar.
Voor organisaties zonder fulltime beveiligingspersoneel biedt een virtuele CISO-dienst uitkomst. Hierbij fungeert een extern team als de interne beveiligingsverantwoordelijke, inclusief beschikbaarheid bij incidenten.
Hoe classificeer je een cybersecurity-incident?
Een cybersecurity-incident classificeer je op basis van drie factoren: de impact op de bedrijfsvoering, de gevoeligheid van de betrokken data en de omvang van de verstoring. Doorgaans worden incidenten ingedeeld in drie of vier niveaus, van laag naar kritiek, waarbij elk niveau een bijbehorende responstijd en escalatieprocedure heeft.
Een praktisch classificatiemodel werkt als volgt:
- Niveau 1 (laag): beperkte impact, geen gevoelige data betrokken, systemen functioneren nog. Voorbeeld: een phishingmail die niet is geopend.
- Niveau 2 (gemiddeld): beperkte verstoring, mogelijk gevoelige data geraakt. Voorbeeld: een medewerker heeft op een phishinglink geklikt maar er is nog geen data gelekt.
- Niveau 3 (hoog): aanzienlijke verstoring van dienstverlening of bewijs van data-exfiltratie. Voorbeeld: een systeem is versleuteld door ransomware.
- Niveau 4 (kritiek): volledige uitval van kritieke systemen, grote hoeveelheden persoonsgegevens gelekt of reputatieschade op grote schaal.
Onder de NIS2-meldplicht is een incident significant als het de continuïteit van de dienstverlening aanzienlijk kan verstoren. Factoren die daarbij meewegen zijn het aantal getroffen personen, de duur van de verstoring en de mogelijke financiële schade. Door je interne classificatie af te stemmen op deze criteria weet je direct wanneer een extern meldingsproces in werking treedt.
Wat is het verschil tussen een incidentresponsplan en een bedrijfscontinuïteitsplan?
Een incidentresponsplan richt zich op de directe reactie op een beveiligingsincident: detecteren, indammen, analyseren en herstellen. Een bedrijfscontinuïteitsplan (BCP) richt zich op het waarborgen van kritieke bedrijfsprocessen tijdens en na een verstoring, ongeacht de oorzaak. De twee plannen vullen elkaar aan maar hebben een andere focus en tijdshorizon.
Het incidentresponsplan is operationeel en technisch van aard. Het beschrijft wat het beveiligingsteam doet in de eerste uren en dagen na een aanval. Het bedrijfscontinuïteitsplan is strategischer: het beschrijft hoe de organisatie essentiële diensten draaiende houdt als systemen uitvallen, ook als dat weken duurt.
In de praktijk verwijzen de twee plannen naar elkaar. Zodra een incident zo ernstig is dat het de bedrijfsvoering langdurig verstoort, schakelt de incident response over naar de continuïteitsprotocollen. Stel beide plannen daarom samen op en zorg dat de betrokken teams van elkaars bestaan weten. Een organisatie die alleen een incidentresponsplan heeft maar geen continuïteitsplan, weet wel hoe ze reageert op een aanval, maar niet hoe ze daarna de boel weer op de rit krijgt.
Hoe vaak moet je een incidentresponsplan testen en bijwerken?
Een incidentresponsplan test je minimaal één keer per jaar en update je na elk significant incident, elke grote organisatiewijziging of relevante wijziging in het dreigingslandschap. Een plan dat nooit wordt getest, geeft een vals gevoel van veiligheid: pas tijdens een oefening blijkt of procedures werkbaar zijn en of medewerkers weten wat ze moeten doen.
Er zijn verschillende manieren om een plan te testen:
- Tabletop-oefening: een scenariobespreking waarbij betrokkenen stap voor stap doorlopen wat ze zouden doen bij een fictief incident. Laagdrempelig en geschikt als startpunt.
- Simulatieoefening: een realistische naspeling van een aanval waarbij teams daadwerkelijk handelen alsof het een echt incident is.
- Red team-oefening: een ethisch hacker probeert actief in te breken, waarna de respons van het interne team wordt geëvalueerd.
Na elke test stel je een evaluatierapport op met verbeterpunten. Verwerk deze verbeterpunten direct in het plan. Hetzelfde geldt na een echt incident: de ervaringen uit de praktijk zijn waardevoller dan elke theoretische oefening. Wil je weten hoe je organisatie reageert op een echte aanvalspoging, dan biedt een penetratietest inzicht in kwetsbaarheden voordat een aanvaller ze vindt.
Wat zijn veelgemaakte fouten bij het opstellen van een incidentresponsplan?
De meest voorkomende fouten bij het opstellen van een incidentresponsplan zijn: het plan nooit testen, rollen niet concreet genoeg vastleggen, communicatieprotocollen vergeten en het plan niet actueel houden. Veel organisaties beschikken wel over een document, maar dat document werkt niet omdat het te vaag, te verouderd of te onbekend is bij de mensen die het moeten uitvoeren.
Andere veelgemaakte fouten zijn:
- Geen offline back-up van het plan: bij een ransomware-aanval zijn interne systemen mogelijk niet bereikbaar. Bewaar het plan ook buiten het netwerk.
- Contactlijsten niet actueel: medewerkers vertrekken, leveranciers wisselen. Een verouderde contactlijst is nutteloos op het moment dat het misgaat.
- Geen aandacht voor externe meldverplichtingen: organisaties die onder de NIS2 vallen, zijn verplicht significante incidenten te melden. Als dit niet in het plan staat, wordt het in de chaos vergeten.
- Het plan is alleen van IT: een cyberincident raakt de hele organisatie. HR, juridische zaken, communicatie en het bestuur moeten allemaal weten wat hun rol is.
- Geen escalatiecriteria: zonder duidelijke drempelwaarden weet niemand wanneer een incident groot genoeg is om de directie te informeren of externe hulp in te schakelen.
Een goed incidentresponsplan is geen statisch document maar een levend instrument dat meegroeit met de organisatie en het dreigingslandschap. Wie het plan alleen opstelt om een vinkje te zetten, mist het punt volledig.
Hoe Q-Cyber helpt met een incidentresponsplan opstellen
Wij begrijpen dat het opstellen van een werkbaar incidentresponsplan meer vraagt dan het invullen van een sjabloon. Het vereist inzicht in de specifieke risico’s van jouw organisatie, kennis van wet- en regelgeving zoals NIS2 en de praktische ervaring om een plan te schrijven dat ook onder druk werkt.
Wat wij voor jouw organisatie kunnen doen:
- Een gap-analyse uitvoeren om te bepalen wat er ontbreekt in de huidige responsprocedures
- Een incidentresponsplan op maat schrijven, afgestemd op jouw sector, omvang en risicoprofiel
- De meldprocedures inrichten conform de NIS2-vereisten, inclusief tijdlijnen en rapportageformats
- Tabletop-oefeningen begeleiden om het plan te testen en medewerkers voor te bereiden
- Het plan periodiek reviewen en actualiseren via onze Continuous-Q virtuele CISO-dienst
We werken onafhankelijk, zonder binding aan softwarepartijen, en adviseren altijd vanuit het belang van jouw organisatie. Wil je weten waar jouw organisatie nu staat en hoe we je kunnen helpen? Neem contact met ons op voor een vrijblijvend gesprek.