Wat is een Incident Response Plan?

Een Incident Response Plan (IRP) is een vooraf vastgesteld en goedgekeurd document waarin een organisatie beschrijft hoe zij cybersecurity-incidenten zoals ransomware, malware, datalekken of systeeminbraken detecteert, beoordeelt, indamt, herstelt, meldt en evalueert, en wie daarbij welke beslissing neemt. Waar Incident Response het proces is, is het IRP de concrete uitwerking daarvan voor uw eigen organisatie: rollen, escalatieregels, contactlijsten, meldtermijnen en playbooks per scenario. In industriële omgevingen hoort daar ook bij hoe SCADA, PLC’s en HMI’s veilig blijven draaien of gecontroleerd worden afgeschakeld.

Het IRP zorgt ervoor dat iedereen weet wat te doen, wie te bellen en wie mag beslissen wanneer een incident zich voordoet, zodat schade beperkt blijft en herstel sneller gaat.


🎯 Waarom heeft u een Incident Response Plan nodig?

Tijdens een incident is er tijdsdruk, onvolledige informatie en stress. Beslissingen die u dan pas gaat bedenken, kosten uren. Een IRP haalt die beslissingen naar voren:

  • Beperkt impact en downtime - indamming start sneller als vooraf vastligt wie een netwerk mag isoleren of een account mag blokkeren
  • Versnelt besluitvorming en communicatie - escalatiecriteria en mandaten voorkomen een leiderschapsvacuüm
  • Haalt wettelijke termijnen - de meldplicht onder de Cyberbeveiligingswet start met een vroegtijdige waarschuwing binnen 24 uur na kennisname; een datalek met risico voor betrokkenen meldt u onder de AVG binnen 72 uur na ontdekking
  • Ondersteunt compliance en audits - NIS2, ISO 27001, de BIO en IEC 62443-2-1 vragen allemaal om gedocumenteerde incidentprocedures
  • Verbindt IT, OT, security en management - iedereen werkt vanuit hetzelfde draaiboek
  • Maakt oefenen en verbeteren mogelijk - een plan op papier kunt u toetsen met een tabletop-oefening

📦 Wat staat er in een Incident Response Plan?

Een volwassen IRP bestaat meestal uit een vast kerndocument en losse bijlagen die vaker veranderen, zoals contactlijsten en playbooks.

Onderdeel Beschrijving
Doel en scope Voor welke systemen en locaties het plan geldt: kantoor-IT, OT, cloud, leveranciers
Definities en classificatie Wat is een event, wat een incident, en hoe ernstig is het (prioriteitsniveaus)
Incident Response Team Rollen, mandaten en vervangers (IRT, CSIRT, extern SOC)
Contactinformatie Interne sleutelpersonen, leveranciers, verzekeraar, NCSC, toezichthouder, politie
Fasemodel en procedures Stappen volgens NIST, SANS of ISO/IEC 27035, van detectie tot evaluatie
Escalatiebeleid Wanneer schaalt u op naar crisisteam en directie, en wie besluit over stilleggen
Playbooks Uitgewerkte stappen per scenario: ransomware, phishing, leveranciersaccount, OT-verstoring
Communicatieplan Interne updates, pers, klanten en wettelijke meldingen via het crisiscommunicatieplan
Documentatie en logging Logboek van tijdlijn, beslissingen en bewijs voor forensisch onderzoek
Oefening en evaluatie Testkalender, evaluatie na elk incident en versiebeheer van het plan

Bewaar het plan en de contactlijsten ook offline of op papier. Bij een ransomware-aanval zijn het intranet, de mail en soms de telefonie niet beschikbaar.


🧭 Welk fasemodel volgt een Incident Response Plan?

Vaak wordt gesproken van “zes fasen volgens NIST”, maar die zes stappen komen van het SANS Institute. Er bestaat niet één verplicht model, maar uw plan moet er wel één kiezen.

Model Uitgever Indeling
SP 800-61 Rev. 2 (2012) NIST 4 fasen: voorbereiding; detectie en analyse; indamming, eradicatie en herstel; nazorg
SP 800-61 Rev. 3 (april 2025) NIST Koppeling aan de zes functies van het NIST CSF 2.0: Govern, Identify, Protect, Detect, Respond, Recover
PICERL SANS Institute 6 stappen: voorbereiding, identificatie, indamming, eradicatie, herstel, lessons learned
ISO/IEC 27035-1:2023 ISO/IEC 5 fasen: plannen en voorbereiden, detecteren en melden, beoordelen en besluiten, reageren, leren

In de praktijk gebruiken veel plannen de zes SANS-stappen als hoofdstukindeling:

  1. Voorbereiding - team, tools, back-ups, contactlijsten en oefeningen
  2. Identificatie - signalen uit SIEM, EDR of operators beoordelen en classificeren
  3. Indamming - verspreiding stoppen, bijvoorbeeld door de IT/OT-koppeling te verbreken
  4. Eradicatie - malware, persistentie en toegang van de aanvaller verwijderen
  5. Herstel - systemen schoon terugzetten via herstelprocedures en verscherpt monitoren
  6. Lessons learned - evaluatie en oorzaakanalyse, met acties, eigenaren en deadlines

🔄 Hoe verschilt een IRP van een continuïteits- en herstelplan?

Een IRP wordt vaak verward met andere plannen. Ze overlappen, maar hebben elk een eigen vraag:

Plan Kernvraag Eigenaar
Incident Response Plan Hoe stoppen we deze aanval en ruimen we hem op? CISO of security officer
Bedrijfscontinuïteitsplan Hoe houden we kritieke processen draaiende? Directie en bedrijfsvoering
Disaster recovery-plan Hoe herstellen we systemen en data binnen RTO en RPO? IT- en OT-beheer
Crisiscommunicatieplan Wat zeggen we, tegen wie en wanneer? Communicatie

Het IRP verwijst naar de andere plannen op het moment dat een incident uitgroeit tot een crisis. De business impact analysis bepaalt welke systemen eerst terug moeten.


🏭 Wat maakt een Incident Response Plan voor OT anders?

In productieomgevingen gaat het niet alleen om data, maar om draaiende processen, mensen en milieu. Daarom staat het ICS-specifieke incidentresponsplan op de eerste plaats in de SANS ICS Five Critical Controls: de scenario’s uit dat plan bepalen wat architectuur en monitoring moeten kunnen. Ook NIST SP 800-82 Rev. 3 uit september 2023 past incidentrespons aan op OT. Een OT-plan bevat aanvullend:

  • Veiligheid eerst - elke ingreep wordt getoetst op het effect op procesveiligheid en het SIS
  • Vooraf goedgekeurde indamming - wie mag de IT/OT-koppeling verbreken, overschakelen op handbediening of een installatie naar een veilige toestand brengen
  • Impactanalyse - gevolgen voor productie, veiligheid, milieu en ketenpartners
  • Specifieke herstelprocedures - voor SCADA, PLC, HMI en historian, inclusief bekende goede versies van PLC-programma’s en configuraties
  • Samenwerking met operations - procesoperators, maintenance en HSE beslissen mee
  • Leveranciers en integrators - afspraken over ondersteuning en veilige toegang op afstand
  • Lokale bewijsvoering - offline logging waar centrale logging ontbreekt

Twee bekende incidenten laten zien waarom. Bij Colonial Pipeline in mei 2021 trof ransomware het kantoornetwerk en werd de pijpleiding uit voorzorg stilgelegd. Bij NotPetya in juni 2017 viel bij rederij Maersk vrijwel het hele netwerk weg; het herstel lukte mede doordat één domeincontroller in Ghana door een stroomstoring toevallig offline was gebleven. Een onveranderbare back-up moet zo’n toeval overbodig maken.


🔐 Welke normen en wetten vragen om een Incident Response Plan?

Kader Eis
NIS2 art. 21 lid 2 Onder (b) incidentbehandeling, onder (c) bedrijfscontinuïteit, back-ups, disaster recovery en crisisbeheer
Cyberbeveiligingsbesluit Art. 8 vraagt een schriftelijk vastgelegd en aantoonbaar toegepast beleid voor incidentbehandeling; art. 9 regelt continuïteit
Uitvoeringsverordening (EU) 2024/2690 Gedetailleerde eisen aan incidentbehandeling voor onder meer cloud-, datacenter- en managed (security) service providers
ISO 27001:2022 Beheersmaatregelen 5.24 tot en met 5.28: planning, beoordeling, respons, leren en bewijsverzameling
IEC 62443-2-1:2024 Securityprogramma voor asset owners met een programma-element voor event- en incidentmanagement
AVG Datalekken met risico voor betrokkenen binnen 72 uur na ontdekking melden aan de Autoriteit Persoonsgegevens (art. 33)

De Cyberbeveiligingswet geldt sinds 15 augustus 2026. Voor de meeste sectoren is het NCSC het CSIRT; voor de waterschappen is dat CERT-WM. Een IRP dat deze meldroutes, de 24-uursklok en de vereiste inhoud van de vroegtijdige waarschuwing al bevat, voorkomt dat u tijdens het incident zelf moet uitzoeken bij wie u meldt.


🛠️ Hoe stelt u een Incident Response Plan stap voor stap op?

  1. Bepaal scope en kroonjuwelen - gebruik uw risicoanalyse en assetinventaris om te kiezen welke systemen en processen het plan dekt.
  2. Kies een fasemodel - NIST, SANS of ISO/IEC 27035; consistentie is belangrijker dan de keuze.
  3. Leg rollen en mandaten vast - incidentmanager, technisch lead, OT-lead, communicatie, juridisch en directie, elk met een vervanger.
  4. Definieer classificatie - bijvoorbeeld vier niveaus van laag tot kritiek, met criteria voor wanneer het crisisteam opschaalt en wanneer de meldplicht in beeld komt.
  5. Schrijf playbooks - begin met de twee à drie meest waarschijnlijke scenario’s. Het NCSC publiceerde in 2022 een vrij te gebruiken Incidentresponsplan Ransomware, en CISA bracht in november 2021 incident- en kwetsbaarheidsplaybooks met checklists uit.
  6. Regel externe hulp vooraf - contract met een incidentresponspartij of OT SOC, afspraken met leveranciers en een eventuele cyberverzekeraar.
  7. Laat het plan goedkeuren - door de directie, die onder NIS2 eindverantwoordelijk is.
  8. Oefen en evalueer - minstens jaarlijks een tabletop-oefening en na elk echt incident een evaluatie.

Voorbeeld van een classificatie:

Niveau Voorbeeld Opschaling
Laag Geblokkeerde phishingmail Afhandeling door servicedesk of SOC
Middel Besmette werkplek zonder verspreiding IRT, geen crisisteam
Hoog Gecompromitteerd beheeraccount of server IRT plus management, meldplicht beoordelen
Kritiek Ransomware in het productienetwerk of verlies van procesbeeld Crisisteam, OT-lead en directie direct; vroegtijdige waarschuwing voorbereiden

❓ Veelgestelde vragen

Wat is het verschil tussen incident response en een incident response plan?

Incident response is het proces van detecteren, indammen, herstellen en leren bij een cyberincident. Een incident response plan is het document dat dat proces voor één organisatie vastlegt, met rollen, mandaten, contactlijsten, playbooks en meldroutes. Zonder plan moet het team die afspraken tijdens het incident zelf maken.

Is een incident response plan verplicht?

Een incident response plan is voor essentiële en belangrijke entiteiten onder NIS2 en de Cyberbeveiligingswet in feite verplicht, omdat zij een schriftelijk beleid voor incidentbehandeling moeten hebben. ISO 27001 en IEC 62443-2-1 vragen eveneens om gedocumenteerde incidentprocedures. Voor andere organisaties is een plan niet wettelijk vereist, maar wel de basis om een datalek binnen 72 uur bij de Autoriteit Persoonsgegevens te kunnen melden.

Hoe vaak moet u een incident response plan testen?

Een incident response plan test u minstens één keer per jaar, bijvoorbeeld met een tabletop-oefening, en daarnaast na elke grote wijziging in organisatie of architectuur. Het Cyberbeveiligingsbesluit spreekt van periodiek testen zonder vaste termijn. Na elk echt incident hoort ook een evaluatie die het plan bijwerkt.

Wat is een playbook in een incident response plan?

Een playbook is een uitgewerkte stappenlijst binnen een incident response plan voor één type incident, zoals ransomware, een gecompromitteerd leveranciersaccount of een OT-verstoring. Het beschrijft per fase welke acties nodig zijn, wie ze uitvoert en welke beslissingen vooraf zijn goedgekeurd. Het kerndocument blijft stabiel, de playbooks worden vaker bijgewerkt.

Waarom heeft OT een apart incident response plan nodig?

OT heeft een eigen incident response plan of een apart OT-hoofdstuk nodig, omdat ingrepen effect hebben op draaiende processen en op veiligheid. Een server isoleren kan in OT het zicht op het proces wegnemen of een installatie laten stilvallen. Daarom regelt een OT-plan vooraf wie mag overschakelen op handbediening of een installatie veilig mag afschakelen.

Wie is eigenaar van het incident response plan?

Het incident response plan heeft meestal de CISO of security officer als inhoudelijk eigenaar, terwijl de directie het plan goedkeurt en eindverantwoordelijk blijft. In OT-omgevingen is een OT-lead of plant manager mede-eigenaar van de OT-playbooks. Het plan noemt voor elke rol ook een vervanger.


📌 Samengevat

Een Incident Response Plan legt vooraf vast hoe uw organisatie een cybersecurity-incident detecteert, indamt, herstelt, meldt en evalueert, en wie daarover beslist. Met een gekozen fasemodel, duidelijke mandaten, playbooks, meldroutes voor de Cyberbeveiligingswet en de AVG, een OT-hoofdstuk dat veiligheid voorop zet en regelmatige oefeningen wordt het plan een werkend instrument voor veerkracht en compliance.