- Een incident response plan geeft het team een beslissingskader op het moment dat de cognitieve belasting het hoogst is. Zonder plan worden alle vragen over wie wat doet en wie wat mag autoriseren midden in een incident beantwoord, onder druk, met onvolledige informatie.
- De zes fasen zijn Voorbereiding, Identificatie, Inperking, Verwijdering, Herstel en Evaluatie. Elke fase heeft afgebakende activiteiten, eigenaren en uitkomsten.
- De AVG verplicht organisaties een datalek binnen 72 uur na ontdekking te melden bij de Autoriteit Persoonsgegevens. NIS2 vereist een vroegtijdige melding bij de bevoegde autoriteit binnen 24 uur. Beide termijnen lopen vanaf het moment van ontdekking, niet vanaf het begin van het incident.
- Playbooks zijn scenariospecifieke uitbreidingen op het IRP voor ransomware, zakelijke e-mailfraude, credential-diefstal, datalekken en supply chain-compromis als minimum.
- Een ongetest plan is een aanname. Voer minimaal jaarlijks een tabletop-oefening uit. Test back-upherstel elk kwartaal tegen uw maximale acceptabele uitvaltijd.
- Het IRP is een deliverable in fase 1 van uw cybersecurity-roadmap en moet er zijn voordat uw beveiligingsprogramma volwassen is.
Waarvoor dient een incident response plan
Een beveiligingsincident plaatst het responsteam gelijktijdig onder druk vanuit meerdere richtingen: technische triage, juridische blootstelling, escalatie naar het management, mogelijke melding bij de AP, klantcommunicatie, mediavorisico en besluiten over bedrijfscontinuïteit, allemaal tegelijk. Het incident response plan neemt die druk niet weg. Het neemt de noodzaak weg om structurele beslissingen eronder te nemen.
Wie beslist een gecompromitteerde server te isoleren? Wie kan in het weekend externe forensische expertise autoriseren? Wie keurt de klantmail goed? Wie neemt contact op met de AP? Die vragen hebben één juist moment om te worden beantwoord: tijdens de planningsfase, vóór een incident. Een gedocumenteerd IRP, door het team getest, zet die beslissingen om in procedures. Dat is het rendement.
Het plan hoeft niet lang te zijn. Een document van tien pagina's dat het IR-team heeft gelezen, geoefend en kan vinden zonder te vertrouwen op gecompromitteerde systemen, is meer waard dan een document van zestig pagina's dat in een SharePoint-map staat die niemand heeft geopend.
De zes fasen van incident response
De NIST-levenscyclus voor incident response onderscheidt vier fasen. De meeste IR-specialisten breiden dit uit naar zes door Inperking en Verwijdering afzonderlijk te behandelen, wat operationeel nuttiger is. De zes fasen hieronder weerspiegelen de standaardpraktijk voor Nederlandse organisaties.
Het incident response team samenstellen
Het IR-team is geen permanent team dat staat te wachten op incidenten. Het is een lijst van benoemde personen met gedefinieerde rollen die worden geactiveerd zodra het responsproces wordt gestart. Voor de meeste Nederlandse organisaties buiten het enterprise-segment vervullen dezelfde mensen meerdere rollen.
Elke rol heeft een benoemde primaire persoon en een benoemde vervanger. Incidenten passen hun planning niet aan vakantierooster aan. De contactlijst moet persoonlijke mobiele nummers bevatten en een escalatiepad buiten kantooruren dat niet afhankelijk is van zakelijke e-mail, die mogelijk gecompromitteerd is.
Uw IRP moet vooraf geïdentificeerde contactgegevens bevatten voor: de incidentresponsehotline van uw cyberverzekeraar (bij de meeste polissen 24/7 beschikbaar), een extern forensisch bedrijf als uw interne team de capaciteit mist, uw managed security provider indien van toepassing, het NCSC.nl-meldpunt voor cyberincidenten en het meldportaal van de Autoriteit Persoonsgegevens. Deze contacten midden in een incident opzoeken, verspilt tijd die u niet heeft.
Wettelijke meldverplichtingen
Nederlandse wettelijke meldtermijnen lopen vanaf het moment dat u zich bewust wordt van het incident, niet vanaf het begin ervan. Een datalek dat drie maanden heeft gelopen voordat het werd ontdekt, start nog steeds een 72-uurstermijn op het moment van ontdekking. Het plan moet een procedure bevatten voor het beoordelen of een meldplicht is ontstaan en wie verantwoordelijk is voor die beoordeling en het indienen van de melding.
| Toezichthouder | Trigger | Termijn | Wie meldt | Wat is vereist |
|---|---|---|---|---|
| AP (AVG) | Datalek dat waarschijnlijk risico oplevert voor rechten en vrijheden van betrokkenen | 72 uur | Verwerkingsverantwoordelijke (FG of aangewezen lead) | Aard van het lek, categorieën en geschat aantal betrokkenen, waarschijnlijke gevolgen, genomen of voorgestelde maatregelen. Fasemeldingen toegestaan als volledige informatie nog niet beschikbaar is. |
| NCSC.nl / CSIRT (NIS2) | Significant incident dat netwerk- of informatiesystemen van een essentiële of belangrijke entiteit treft | 24 uur vroege waarschuwing; 72 uur volledige melding; 1 maand eindrapport | Aangewezen NIS2-contactpersoon | Vroege waarschuwing: significant incident, vermoedelijke kwaadaardige oorzaak. Volledige melding: initiële beoordeling, ernst, indicatoren van compromittering. Eindrapport: grondoorzaak, genomen acties, grensoverschrijdende impact. |
| DNB / AFM | Operationeel incident met aanzienlijke (potentiële) impact voor financiële instellingen; tevens DORA-meldplicht voor in-scope entiteiten | Zo spoedig mogelijk; geen specifiek uurlimiet, maar DNB verwacht prompte melding | Compliance of aangewezen contactpersoon | Aard van het incident, feitelijke of potentiële impact, ondernomen maatregelen. Vervolgmeldingen naarmate de situatie evolueert. |
De 72-uuurtermijn onder de AVG wordt consequent verkeerd begrepen. Een volledige schets van het datalek is niet vereist. Artikel 33 lid 4 staat fasemeldingen toe met de instructie aanvullende informatie te verstrekken zodra die beschikbaar is. Wachten tot het onderzoek is afgerond, riskeert een toezichtrechtelijke bevinding van te late melding. De FG of aangewezen lead moet binnen de eerste uren na een incident een initiële beoordeling maken en een voorlopige melding doen als er enige mogelijkheid bestaat dat persoonsgegevens zijn getroffen.
Incident-playbooks
Een playbook is een scenariospecifieke checklist die aan het IRP is toegevoegd. Elk playbook behandelt één incidenttype en legt vast: de detectiesignalen die op dit type incident wijzen, de eerste vijf acties in de eerste 30 minuten, de inperkingsstappen op volgorde, vereisten voor bewijsbehoud, de meldplichtchecklist voor dit scenario, communicatiesjablonen en de herstelprocedure.
Vijf playbooks dekken de incidenten die in 2025 en 2026 het meest waarschijnlijk Nederlandse organisaties treffen:
| Incidenttype | Belangrijkste detectiesignalen | Directe inperkingsprioriteit | Meldtrigger |
|---|---|---|---|
| Ransomware | Bestanden met onbekende extensie, losgeldbriefje op bureaublad, EDR-melding voor massale bestandsversleuteling, plotselinge piek in I/O-activiteit | Getroffen systemen direct isoleren van het netwerk. Niet uitzetten (bewaart geheugenforensica). Patient zero identificeren voordat herstel vanuit back-up plaatsvindt. | AP melden als persoonsgegevens zijn versleuteld of geëxfiltreerd. NCSC.nl als NIS2-entiteit. Cyberverzekeraar binnen uren. |
| Zakelijke e-mailfraude (BEC) | Frauduleuze betalingsopdracht ontvangen, leverancier meldt niet-betaling van omgeleide factuur, doorstuuregel naar extern adres, inlogpoging vanuit ongebruikelijke locatie | Openstaande betalingsopdracht bevriezen. Direct contact opnemen met de ontvangende bank voor terugvordering. Gecompromitteerde mailbox identificeren en alle actieve sessies intrekken. | AP melden als persoonsgegevens zijn benaderd in de mailbox. Finance en management direct informeren. Overweeg melding bij de politie. |
| Credential-diefstal / account-overname | Password spray-melding, impossible travel-inlogsignaal, MFA-vermoeidheidsmelding van een medewerker, onbekende OAuth-app met toegang tot bedrijfsdata | Wachtwoord resetten en alle actieve sessies van het gecompromitteerde account intrekken. Controleer op persistentiemechanismen: nieuwe mailverwerkingsregels, OAuth-app-rechten, toegevoegde herstelcontacten of nieuwe MFA-methoden. | AP melden als het gecompromitteerde account toegang had tot persoonsgegevens. Reikwijdte van datatoegang bepalen vóór meldbeslissing. |
| Datalek / exfiltratie | Melding van grote uitgaande gegevensoverdracht, DLP-melding voor gevoelige bestandsupload, afpersingsmail met verwijzing naar bedrijfsdata, derde partij meldt ontvangst van uw klantdata | Exfiltratieroute identificeren en sluiten. Logboeken bewaren voordat ze roteren. Juridisch inschakelen om privilege te beoordelen vóór het uitvoeren van interviews. | AP-melding zeer waarschijnlijk als persoonsgegevens bevestigd zijn. NIS2-melding als in-scope entiteit. Betrokkenen informeren bij hoog risico op schade. |
| Supply chain-compromis | Melding van softwareleverancier over gecompromitteerde update, ongebruikelijk gedrag van vertrouwde applicatie, MSP meldt ongeautoriseerde toegang via hun tooling | Getroffen systemen isoleren. Toegang van de leverancier opschorten. Software niet verder bijwerken totdat de leverancier een schone versie bevestigt. Onderzoek starten naar wat de leverancier kon bereiken. | AP melden als persoonsgegevens bereikbaar waren via de leverancierstoegang. Cyberverzekeraar informeren. NCSC.nl als significante impact op kritieke diensten. |
Bewijsbehoud
Digitaal bewijs dat tijdens een incident wordt verzameld, dient twee doelen: het technisch onderzoek informeren en mogelijke juridische of regelgevingsprocedures ondersteunen. Die twee hebben verschillende standaarden. Bewijs dat toelaatbaar is in rechtbank of toezichtprocedures moet worden verzameld en behandeld op een manier die de integriteit aantoont. Geïmproviseerde bewijsverzameling ondermijnt beide.
Het plan specificeert: wie bevoegd is forensisch bewijs te verzamelen, welke tools zijn goedgekeurd voor verzameling, hoe bewijs wordt opgeslagen en de bewakingsketen wordt gedocumenteerd, en op welk punt een extern forensisch bedrijf moet worden ingeschakeld. Voor de meeste Nederlandse organisaties is die drempel elk incident met realistisch potentieel voor rechtszaken, toezichtrechtelijke acties of strafrechtelijk onderzoek.
Gecompromitteerde systemen niet herimageren of herstellen vóór forensische vastlegging van geheugen- en schijfafbeeldingen. Het bewijs is weg zodra het systeem is gewist. Forensisch contact inschakelen vóór het besluit tot herstel wordt genomen.
Communicatie tijdens een incident
Communicatiefouten tijdens incidenten zijn even schadelijk als technische fouten. Twee afzonderlijke problemen doen zich voor. Interne communicatie loopt stuk wanneer het responsteam tegelijkertijd via te veel kanalen opereert, mensen zonder volledig beeld escaleren naar het management of dezelfde update via verschillende mensen met verschillende formuleringen doorgaat. Externe communicatie gaat mis wanneer iemand zonder toestemming met pers, klanten of toezichthouders spreekt.
Interne communicatie
Wijs één kanaal aan voor coördinatie van de incidentrespons en één voor managementupdates. Houd ze gescheiden. Het coördinatiekanaal is voor technische details; het managementkanaal is voor impact en besluiten. Wijs de scribe aan voor getimede updates op het coördinatiekanaal. De communicatielead verwerkt deze tot managementbriefings op vastgestelde intervallen, niet op verzoek.
Externe communicatie
Vooraf goedgekeurde communicatiesjablonen in het plan besparen tijd en voorkomen fouten. Sjablonen moeten bestaan voor: klantnotificatie (datalek), leveranciersnotificatie (als het incident de supply chain betreft), persverklaring en AP-melding. Sjablonen zijn geen scripts, maar startpunten. Juridische beoordeling vóór verzending is vereist voor alles dat de organisatie verlaat.
De vraag is nooit óf u communiceert tijdens een incident. Het is hóe u accuraat communiceert, binnen de juiste termijn, naar de juiste mensen, zonder de juridische positie te verslechteren.
Het plan testen
Een ongetest IRP is een document. Een getest IRP is een capaciteit. Het verschil is significant wanneer een echt incident om 2 uur 's nachts op een vrijdag plaatsvindt.
Tabletop-oefeningen
Een tabletop-oefening loodst het IR-team door een realistisch incidentscenario zonder dat echte systemen worden beïnvloed. Een facilitator presenteert een scenario (ransomware heeft uw bestandsserver versleuteld, het is zaterdagochtend en de dienstdoende IT-medewerker heeft zojuist gebeld). Het team werkt in real time door hun besluiten: wie belt u, wat isoleert u, wanneer meldt u bij de AP, wie informeert de directeur, betaalt u het losgeld?
Tabletops brengen besluiten aan het licht die niet van tevoren zijn genomen, contacten die ontbreken op de lijst en bevoegdheidshiaten waarbij niemand weet wie wat kan goedkeuren. Ze kosten een halve dag en zijn de meest kosteneffectieve beveiligingsinvestering die beschikbaar is. Voer minimaal jaarlijks één uit. Werk het IRP binnen twee weken na elke oefening bij met de bevindingen.
Technische simulaties
Een technische simulatie test specifieke responseprocedures op echte systemen in een gecontroleerde omgeving. Herstel een systeem vanuit back-up en meet de tijd af tegen uw maximale tolerabele uitvaltijd. Voer een gesimuleerde phishingcampagne uit en test de detectie- en escalatieprocedure. Bevestig dat uw EDR-tooling daadwerkelijk de verwachte melding geeft wanneer een bekend kwaadaardig tool op een endpoint wordt uitgevoerd. Technische simulaties bevestigen dat de tools werken zoals verwacht en dat het team weet hoe ze onder druk te gebruiken.
Back-uphersteltests
Test back-upherstel elk kwartaal. Niet controleren of de back-up bestaat, maar daadwerkelijk een systeem of dataset herstellen vanuit back-up en bevestigen dat het werkt. Valideer de hersteltijd tegen uw maximale tolerabele uitvaltijd. Als het herstel acht uur duurt en uw MTD vier uur is, heeft u een hiaat dat vóór een incident moet worden opgelost, niet ertijdens.
Het plan actueel houden
Een IRP dat niet wordt bijgewerkt, wordt een last. Het bevat verouderde contactnummers, verwijzingen naar systemen die niet meer bestaan en roltoewijzingen aan mensen die de organisatie hebben verlaten. Een plan waarvan het team weet dat het verouderd is, wordt niet gevolgd onder druk.
Beoordeel het plan op drie triggers: na elk incident (binnen twee weken), na elke tabletop-oefening (binnen twee weken) en jaarlijks als onderdeel van de bredere beveiligingsprogrammareviiew. De jaarlijkse review controleert of alle contacten actueel zijn, of de wettelijke meldvereisten de huidige wetgeving weerspiegelen, of de bedrijfsmiddeleninventaris in het plan overeenkomt met de werkelijke omgeving en of organisatorische wijzigingen (nieuwe systemen, nieuwe bedrijfsonderdelen, nieuwe leveranciers) zijn verwerkt.
Ken het plan een benoemde eigenaar toe met een gedefinieerde beoordelingsdatum. Wanneer die datum verstrijkt zonder beoordeling, is het plan achterstallig. Behandel het met dezelfde bestuursdiscipline als uw cybersecurity-roadmap.
Het incident response plan is een deliverable in fase 1 van uw cybersecurity-roadmap. Het moet bestaan en getest zijn voordat uw bredere beveiligingsprogramma volwassen is, omdat u een responscapaciteit nodig heeft voordat u een volledig beveiligingsprogramma heeft. Als u nog geen gedocumenteerd IRP heeft, behandel het dan als het hoogste prioriteitsitem in uw beveiligingsachterstand, voor tooling, voor beleid, voor training. U kunt al het andere verbeteren terwijl het plan er is. U kunt uw respons op een incident dat plaatsvindt voordat het plan bestaat niet verbeteren.
