Incidentrespons: waar begin ik?

Achtergrond

De afgelopen jaren zien we dat diverse ontwikkelingen in toenemende mate de veiligheid van onze maatschappij en economie onder druk zetten. Denk aan COVID-19 en de oorlog in Oekraïne. Daarnaast maakt de grote afhankelijkheid van digitalisering ook dat we kwetsbaar zijn voor verstoringen in de keten, zoals de wereldwijde verstoring van CrowdStrike en de IT-storing bij Defensie onlangs lieten zien.

Sinds 2020 is er binnen de Europese Unie gewerkt aan de ‘Network and Information Security (NIS2) directive’. Deze richtlijn beoogt de digitale weerbaarheid van Europese lidstaten te verbeteren. In Nederland zal de NIS2-richtlijn geïmplementeerd worden in de Cyberbeveiligingswet (als vervanger van de Wnbi). De Rijksoverheid adviseert organisaties om niet af te wachten totdat de wet- en regelgeving volledig in werking zijn. De risico’s die organisaties lopen, zijn er immers nu ook al. Organisaties die nu in actie komen beveiligen zich niet alleen tegen deze bestaande risico’s, maar zijn straks ook beter voorbereid op de komst van de nieuwe wetgeving.

Wat is incidentrespons?

Incidentrespons gaat over het vermogen, de processen, tools en technologieën van een organisatie voor het detecteren en reageren op cyberdreigingen, cyberincidenten of cyberaanvallen. Een incidentresponsplan (IRP) is belangrijk omdat het de organisatie in staat stelt om schade te beperken, detecteren of te voorkomen. Het doel van incidentrespons is dat de bedrijfsvoering zo min mogelijk wordt verstoord tijdens een cyberincident.

Daarnaast is het de bedoeling dat een IRP ervoor zorgt dat betrokken partijen worden geïdentificeerd, de hersteltijd na een incident verbetert, je beter om kunt gaan met negatieve publiciteit en de interne en externe processen efficiënt kunt stroomlijnen. Denk aan verantwoordelijkheden en taken van bestuur of de afspraken met een leverancier.

Werken vanuit risicomanagement

Niet elke gebeurtenis behoeft een gecoördineerde reactie. Je incidentresponsprocessen zijn er alleen voor die gevallen dat reguliere werkprocessen niet meer voldoende zijn, omdat de impact te groot is of omdat het vraagt om besluiten van het bestuur of management.

Vanuit de risicoanalyse maak je een inschatting welk type van gebeurtenissen uitmonden in cyberincidenten, wat de impact daarvan is en hoe je daar al op bent voorbereid. Bedenk wel dat niet alle situaties vooraf in te schatten zijn met de risicoanalyse. Gebruik deze inzichten als richting waar je incidentrespons voor nodig hebt en wat je aan kennis, expertise en middelen in huis moet halen (of moet uitbesteden) om een effectieve incidentrespons op te zetten. Vanuit de risicoanalyse krijg je zicht op je weerbaarheid en weet je of de basis op orde is.

Wil je weten hoe je een risicoanalyse uitvoert en de basis op orde krijgt?

Lees verder over de risicoanalyse in het artikel: Hoe bepaal ik de meest relevante risico’s voor mijn organisatie?

Voor meer verdieping over risicomanagement: zie de routekaart risicomanagement.

Wil je meer weten over het op orde krijgen van de basis lees dan de publicatie: 5 basisprincipes van digitale weerbaarheid

Een gebeurtenis, alert of cyberincident?

Niet alle gebeurtenissen (‘events’) leiden tot cyberincidenten. Het is nuttig om onderscheid te maken tussen de begrippen ‘gebeurtenis’, ‘alert’ en ‘cyberincident’.

Definities:

Een gebeurtenis is te definiëren als: elk waarneembaar geval waar digitale middelen bij betrokken zijn, zoals fysieke en virtuele platforms, netwerken, services en cloudomgevingen. ( bron ) Dit zijn activiteiten die passen binnen regulier gebruik van je activiteiten en systemen. Ze kunnen malafide zijn of door een gebruikersfout komen, zoals een mislukte inlogpoging. Gebeurtenissen zijn eenvoudig in reguliere werkprocessen af te vangen en vragen niet om een incidentrespons.

Dit is anders bij cyberincidenten: cyberincidenten zijn gebeurtenissen die – zonder toestemming of juridische basis – de beschikbaarheid, integriteit of vertrouwelijkheid bedreigen. Deze gebeurtenissen verdienen een gecoördineerde reactie, omdat het een bedreiging kan vormen voor het leveren van jouw producten, diensten, andere organisaties kan treffen en kan leiden tot aansprakelijkheidsvraagstukken. Denk aan een aanval met ransomware door een criminele groep.

Een alert tot slot is: ‘een waarschuwing dat een bepaalde gebeurtenis zich heeft voorgedaan. Hiermee is er nog geen kwalificatie gegeven aan die gebeurtenis.’ Alerts worden gegenereerd door bijvoorbeeld een Security Operations Center (SOC) of door detectieapparatuur. Alerts zijn van groot belang om tijdig te kunnen reageren op cyberincidenten.

Bouw je incidentresponsplan

In het IRP staat beschreven wanneer een gebeurtenis een cyberincident wordt, hoe daar vervolgens op gereageerd dient te worden en wie daarin welke rollen en verantwoordelijkheden heeft. Dit hoofdstuk is zo geschreven dat het kan fungeren als een indeling van jouw IRP.

Stap 1: Mandaat en commitment

De NIS2 stelt dat het bestuur of management verantwoordelijk en aansprakelijk is op de cybersecurityrisico’s. Daarom is commitment van de bestuurders of managers rondom de inrichting van het incidentresponsproces cruciaal. Het reageren op cyberincidenten vraagt vaak om besluiten die alleen door een bestuur of management kan worden genomen (of gedelegeerd). Denk aan wie of wat een cyberincident mag uitroepen (‘incidentverklaring’) of wie de productie stil mag zetten tijdens een malware-infectie (‘stekkermandaat’). Dit moet je scherp hebben voordat je je incidentrespons inricht. De inrichting van je incidentresponsproces heeft bovendien consequenties voor de inzet van mens en middelen en ook dat zijn uiteindelijk keuzes die de manager of de bestuurder maken moet. Wil je je incidentrespons inrichten, dan heb je dus commitment en het mandaat nodig.

Hoe bereid ik me voor?

Betrek de bestuurders of het management bij het vaststellen van de noodzaak van incidentrespons. Een mooi moment om dit te doen is tijdens het voorbereiden op en actualiseren van de risicoanalyse.

Relevante vragen om te stellen zijn:

Hoe zit het met de risicobereidheid? Zijn er risico’s die een grote impact hebben op de bedrijfsdoelstellingen waarbij het noodzakelijk is de incidentrespons goed op in te richten? Voor welke risico’s geldt dat in mindere mate?

Hoe snel moet een product, dienst of proces weer operationeel zijn?

Zijn er wettelijke verplichtingen die opgevolgd moeten worden? Dit zijn vragen die benodigd zijn om de noodzaak van incidentrespons te onderbouwen.

Praktische tips

Maak voor de bestuurders of managers een heldere vertaalverslag hoe (ICT-)gebeurtenissen kunnen leiden tot cyberincidenten en bepaal samen wat de impact daarvan kan zijn op de business.

Stap 2: Doel en afbakening

Het mag een open deur lijken, maar het is van groot belang om vast te stellen welk doel je met het IRP beoogt. Afbakenen van wat je verstaat onder incidentrespons, wat niet, op wie en op wat het plan van toepassing is, wie de betrokkenen zijn en wat je uitbesteedt zijn eveneens belangrijke randvoorwaarden voor het inrichten van je incidentresponsproces

Hoe bereid ik me voor?

Bespreek samen met het management of bestuur op welke wijze incidentrespons een bijdrage levert aan het verwezenlijken en beschermen van de organisatiedoelstellingen. Denk aan het verminderen van kosten tijdens cyberincidenten of het versneld kunnen terugkeren naar business as usual.

Hoe voer ik het uit?

Stel vast waar het IRP betrekking op heeft (de scope). Het IRP richt zich in essentie op alle cyberincidenten die niet in reguliere processen kunnen worden afgevangen. Beschrijf het doel van het IRP. Doorgaans is het doel om inzichtelijk maken hoe het incidentresponsproces is ingeregeld en welke rollen en verantwoordelijkheden en afspraken en procedures deze behelzen. Beschrijf indien nodig de relatie van het IRP met ander beleid (zoals bijvoorbeeld een continuïteitsplan).

Praktische tips

Betrek altijd je interne en externe stakeholders bij het opstellen van je IRP. Denk aan je incidentrespons- en IT-leveranciers. Neem de tijd om met hen in gesprek te gaan over hun behoeftes, prioriteiten en doelen en hoe die aansluiten op de doelen van jouw organisatie in relatie tot incidentrespons.

Stap 3: Incidentdrempel en incidentverklaring

Het is nuttig om vast te stellen wat de ‘incidentdrempels’ zijn en welke criteria nodig zijn om een incident uit te roepen. Het uitroepen van een cyberincident heet de ‘incidentverklaring’.

Hoe bereid ik me voor?

Het bepalen van de incidentdrempel is cruciaal omdat je niet voor elke wissewasje je incidentresponsproces in gang wilt zetten. Stel daarom vast welke gebeurtenissen vallen binnen de scope van een cyberincident en welke niet. Met andere woorden: wat is de drempel waarna een gebeurtenis wordt omgedoopt tot een cyberincident? Bepaal dit voor verschillende gebeurtenissen (bijvoorbeeld phishing via e-mail, of het uitvallen van een applicatie) en zoek daarbij de aansluiting met de vastgestelde risicoanalyse. Het bepalen van de incidentdrempel vergt een goede afweging tussen het risico waarbij de kwetsbaarheid (of dreiging) en impact leidend is. Denk aan de mate van reputatieschade, verlies van data, financiële schade of impact op medewerkers.

Stel vast welk persoon (of gremium) op basis van de incidentdrempel een cyberincident mag uitroepen. Doorgaans is dit de bestuurder of iemand uit het managementteam (of een gemandateerde). Leg dit en de escalatielijnen vast in de beschrijving van het incidentresponsteam en je incidentresponsproces (zie het incidentresponsproces en incidentresponsteam rollen & verantwoordelijkheden).

Hoe voer ik het uit?

Maak een lijst in je IRP met diverse gebeurtenissen die kunnen leiden tot cyberincidenten (zie tabel 1). Denk aan een datalek of ransomware. Stel voor deze gebeurtenissen de incidentdrempels vast. Wees hierin wel flexibel. In de praktijk is het lang niet altijd duidelijk hoe een cyberincident zich manifesteert en op welke wijze dit een risico vormt.

Praktische tips

Gebruik een tabel om de belangrijkste categorieën van gebeurtenissen in op te nemen (zie tabel 1). Neem gebeurtenissen op die je kunt detecteren (zonder detectie immers geen respons) en identificeer de gebeurtenissen die je niet kunt detecteren (je blinde vlekken).

Bij het bepalen van de incidentdrempel kan gebruik worden gemaakt van een triageschema of een triagechecklist. Het doel daarvan is om bij het manifesteren van een gebeurtenis te bepalen hoe groot de ernst en de impact is op de business (laag, middel, hoog) door bijvoorbeeld te kijken naar financiële impact, impact op de veiligheid en impact op de reputatie. Bij het ondersteunen van de besluitvorming kan gebruik worden gemaakt van het BOB-model.

BOB staat voor Beeldvorming, Oordeelsvorming en Besluitvorming en wordt vaak toegepast in crisissituaties door crisisteams.

Tabel 1 – Voorbeeld incidententabel

Stap 4: Het incidentresponsproces

Tijdens een cyberincident is het incidentresponsproces je leidraad. Het proces maakt inzichtelijk hoe de opschaling van een gebeurtenis verloopt vanaf het moment dat de gebeurtenis is gedetecteerd, de opschaling (‘incidenttriage’ en ‘incidentverklaring’) en de stappen om het cyberincident het hoofd te bieden, daarvan te herstellen en te leren.

Hoe bereid ik me voor?

De wijze waarop je het incidentresponsproces vormgeeft is in grote mate afhankelijk van de inrichting van je organisatie, de afspraken die je gemaakt hebt met leveranciers en de eisen die je stelt aan de incidentrespons. Het incidentresponsproces bevat in elk geval de volgende componenten: detectiegebeurtenis, notificatie, triage van de gebeurtenis, uitroepen van een cyberincident, het in werking stellen van het communicatieplan, inschakelen van responsteam (al dan niet extern), het uitvoeren van de responsactiviteiten en herstelwerkzaamheden, het beëindigen van het cyberincident en tot slot de evaluatie*. Zorg ervoor dat deze componenten ‘landen’ in de organisatie en dat je afspraken maakt met betrokkenen over hun rollen en verantwoordelijkheden. Denk in het bijzonder ook aan de IT- en incidentresponsleveranciers.

*Afgeleid van het door SANS ontwikkelde PICERL: preparation, identification, containment, eradication, recovery, lessons learned.

Hoe voer ik het uit?

Het inrichten van je incidentresponsproces is sterk afhankelijk van de beschikbare mensen en middelen en de keuzes die zijn gemaakt over wat wel en wat niet uit te besteden aan leveranciers. Beschrijf in je proces helder wie betrokken zijn bij de verschillende fases en hoe de rollen en verantwoordelijkheden zijn belegd.
(zie verder ‘Het incidentresponsteam rollen & verantwoordelijkheden’).

Praktische tips

Breng met behulp van een procesdiagram je incidentresponsproces in kaart (zie tabel 2). Dit biedt overzicht en inzicht en kan fungeren als een routekaart tijdens een cyberincident.

Zorg voor zicht op je digitale omgeving. Weet hoe je netwerk er uitziet en uit welke segmenten deze bestaat. Daarnaast is het van belang om te weten wat er in je digitale omgeving gebeurt. Daar zijn logging, Endpoint Detection Response (EDR) Tools en monitoring middelen bij benodigd (al dan niet uitbesteed aan een SOC).

Stem je incidentresponsproces goed af met de betrokken leveranciers. Leg afspraken vast in een Service Level/License Agreement (SLA).

Tabel 2 – Voorbeeld procesdiagram van een incidentresponsproces

Stap 5: Het incidentresponsteam (rollen & verantwoordelijkheden)

Richt een incidentresponsteam in met gedefinieerde rollen en verantwoordelijkheden. Dit team bevat liefst leden uit verschillende afdelingen, zoals IT, juridisch, HR en communicatie. Denk ook aan een secretaris die acties noteert en alles bijhoudt. Dit is van belangrijk voor de evaluatie en verantwoording. Zo worden incidenten afgehandeld door de juiste mensen met de juiste vaardigheden. Dit zorgt voor een gecoördineerde en effectieve respons.

Niet iedere organisatie heeft zelf de middelen in huis om detectie, respons en herstelwerkzaamheden uit te voeren. Organisaties staan dus vaak voor de keuze tussen wat ze intern moeten afhandelen en wat ze moeten uitbesteden. Deze keuze hangt af van verschillende factoren, zoals de grootte van de organisatie, expertise, middelen, budget en risicobereidheid.

Hoe bereid ik me voor?

Mandaat tijdens een cyberincident is belangrijk, wie is waarvoor verantwoordelijk en welke afspraken zijn er met interne – en externe stakeholders . Ga na – voordat het IRP wordt opgesteld –welke stakeholders een rol hebben in het incidentresponsproces. Zoek aansluiting bij de reguliere crisisstructuur als deze is ingericht. Of het nu gaat om een cyberincident of om een crisis van andere aard; grotendeels hebben dezelfde personen een rol of verantwoordelijkheid in het managen van het incident.

Met betrekking tot het uitbesteden van taken en verantwoordelijkheden; gespecialiseerde, arbeidsintensieve en continu beschikbare diensten (denk aan een SOC en Computer Security Incidentrespons Team (CSIRT)) vereisen expertise en schaalbaarheid. Externe aanbieders kunnen die mogelijk efficiënter leveren. Het is verstandig al afspraken met een incidentresponsdienstverlener te hebben en een raamovereenkomst af te sluiten om zo ook hoge kosten te voorkomen.

Kernactiviteiten die diepgaande kennis van de organisatie vereisen zijn cruciaal om intern controle op te behouden en ervoor te zorgen dat incidentresponsacties afgestemd zijn op de bedrijfsdoelen en prioriteiten. Denk aan de incident coördinatie en strategische besluitvorming. Zorg ervoor dat je de tools, procedures en getrainde specialisten hebt om forensisch materiaal aan te kunnen leveren (forensic readiness). Door een balans te vinden in uitbesteding en zelf doen, optimaliseren organisaties hun incidentresponsproces.

Hoe voer ik het uit?

Beschrijf nauwkeurig welke rollen en verantwoordelijkheden personen of teams hebben in het incidentresponsproces. Dit kunnen zowel personen of teams binnen de organisatie zijn, als daarbuiten zoals leveranciers van detectie- en responsdiensten. Denk aan rollen als de CISO, een incidentcoördinator (dit is vaak een bestuurder of MT-lid) of een SOC-analist. Vaak worden rollen en verantwoordelijkheden belegd in teams zoals een monitoringteam, een incidentmanagementteam en een incidentresponsteam.

Praktische tips

Een RASCI-tabel biedt houvast om de diverse rollen en verantwoordelijkheden goed te documenteren (zie tabel 3 in de bijlage voor een voorbeeld). Plot de RASCI-tabel ook op je incidentresponsproces zodat je alle relevante onderdelen van het proces betrekt en je geen rollen en verantwoordelijkheden vergeet.

Neem ook een contactenlijst op van alle betrokkenen in het incidentresponsproces. Hou deze up-to-date en bewaar het naast digitaal ook op een fysieke plek. Denk in het bijzonder aan de contactgegevens van je externe incidentresponsdienstverlener op het moment dat dit is uitbesteed en aan contactgegevens van leveranciers en ketenpartners. De NIS2 schrijft ook voor in welke gevallen het CSIRT moet worden ingeschakeld (meldplicht). Zorg ervoor dat je de contactgegevens van het NCSC of jouw toegewezen CSIRT en toezichthouder hebt. Het kan namelijk zijn dat het cyberincident voldoet aan criteria voor de meld- en rapportageplicht.

Wees er ook op bedacht hoe de communicatie verloopt op het moment dat telefonie of bijvoorbeeld e-mail niet naar behoren functioneert. Zorg voor een back-up en wees bedachtzaam hoe je dat doet. Zorg dat alle incidentresponsteamleden een papieren versie (of digitale kopie op een andere locatie) van het IRP hebben en daar toegang tot hebben. Het is mogelijk dat je bij een incident geen toegang hebt tot je digitale bestanden.

Herzie gemaakte afspraken (SLA’s) op basis van je ervaringen met een externe partij (let wel: dit kan financiële gevolgen hebben). Stel prioriteiten vast op basis van risico-afwegingen. Bijvoorbeeld overresponstijden en verantwoordelijkheden in geval van een cyberincident.

Hou er rekening mee dat een cyberincident fysieke en mentale impact heeft op de betrokken medewerkers. Denk daarom aan het verspreiden van kennis, roulatie en psychische ondersteuning tijdens en na een incident. Ook praktische zaken als goed eten, voldoende rust e.d. zijn belangrijk om te organiseren.

RASCI staat voor Responsible, Accountable, Supporting, Consulted en Informed. Het RASCI-model is een matrix die gehanteerd wordt om de rollen en verantwoordelijkheden weer te geven. Zie tabel 3 als voorbeeld.

Stap 6: Communicatieplan

Ontwikkel een communicatieplan waarin je beschrijft hoe je informatie tijdens een incident deelt, zowel intern als extern. Duidelijke communicatie is essentieel voor een effectieve incidentrespons, het behoud van vertrouwen en het voldoen aan juridische vereisten.

Hoe bereid ik me voor?

Identificeer de interne en externe belanghebbenden. Interne belanghebbenden zijn bijvoorbeeld managementteam, IT, juridische afdeling, HR, PR en overige medewerkers. Externe belanghebbenden zijn klanten, partners, leveranciers, media, regelgevende instanties, CSIRT en toezichthouders en de politie.

Definieer communicatiedoelen zoals nauwkeurigheid, tijdigheid met betrekking tot updates en consistentie om verwarring te voorkomen.

Hoe voer ik het uit?

Stel communicatiekanalen vast voor interne en externe communicatie. Zorg ervoor dat deze kanalen veilig en betrouwbaar zijn. Vermeld aan de betrokkenen en medewerkers wie communiceert en wie niet.

Ontwikkel communicatie templates of sjablonen. Zorg vooraf voor goedgekeurde verklaringen voor verschillende soorten incidenten. Deze moeten aanpasbaar zijn, maar alsnog snel inzetbaar.

Ontwikkel een set van veelgestelde vragen (FAQ’s) om zorgen en vragen weg te nemen.

Praktische tips

Een RASCI-tabel helpt om vast te stellen wie je in je communicatie intern en extern moet betrekken (zie tabel 3 voor een voorbeeld).

Bereid communicatie voor op basis van de verschillende scenario’s en bepaal wanneer je deze communicatie inzet. Door de voorbereiding communiceer je tijdens een incident sneller en effectiever.

Besef dat interne communicatie óók externe communicatie kan worden. Stem daarom goed af wat er wordt gedeeld, door wie en wat de boodschap is. Communiceer wat je weet, maar ook wat je (nog) niet weet. Vermeld (indien je dit kunt zeggen) wanneer het volgende communicatiemoment is.

Vergeet daarnaast niet een concreet handelingsperspectief te bieden.

Tabel 3 – Template RASCI-matrix rollen en verantwoordelijkheden

Stap 7: Scenariokaarten (playbooks)

Het IRP is een plan op hoofdlijnen. Maar elk cyberincident is anders. Met scenariokaarten (of playbooks) kun je de respons op specifieke incidenten standaardiseren met procedures en acties. Een ransomware-incident vergt immers om een ander type reactie dan een stroomuitval. Het standaardiseren en oefenen van je respons stelt je in staat om effectiever op te treden wanneer incidenten werkelijkheid worden.

Hoe bereid ik me voor?

In het IRP beschrijf je welke gebeurtenissen passen binnen de scope van het incidentresponsproces. Deze gebeurtenissen zijn relevant omdat ze kunnen leiden tot cyberincidenten. Identificeer deze gebeurtenissen en bepaal samen met de risico-eigenaren, incidentresponsteam en je detectie- en responsleveranciers of het nuttig is gestandaardiseerde scenariokaarten op te stellen. Voorbeelden van gebeurtenissen die geschikt zijn voor scenariokaarten: ransomware, DDoS, softwarestoring, malware-infecties of een datalek.

De Informatiebeveiligingsdienst (IBD) heeft ook een aantal scenariokaarten ontwikkeld. Deze vind je hier: Producten – Informatiebeveiligingsdienst

Hoe voer ik het uit?

Scenariokaarten bieden een concreet houvast op het moment dat respons vereist is. Dit moet praktisch en op maat toegesneden zijn zodat de diverse betrokkenen weten wat zij moeten doen. Bouw de scenariokaarten samen met de relevante stakeholders zoals systeembeheerders, securitymedewerkers en de leveranciers van detectie- en incidentresponsactiviteiten.

Praktische tips

Besef dat elke cyberincident weer unieke kenmerken heeft en je dus een bepaalde mate van flexibiliteit nodig hebt om effectief te kunnen reageren op incidenten. Test en oefen je scenariokaarten als onderdeel van het testen en oefenen van je IRP.

Leren & Verbeteren

Een cyberincident biedt kostbare maar waardevolle lessen die je helpen om het IRP te verfijnen. Daarvoor is het wel nodig dat je gedurende het incident notuleert. Denk aan beslismomenten, het verloop en de communicatie. Door te leren van eerdere fouten of successen, kan het IRP zich ontwikkelen om toekomstige bedreigingen beter aan te pakken. Een incident dat slecht werd afgehandeld, laat bijvoorbeeld problemen in communicatie of technische middelen zien die je vervolgens aanpakt. Het is daarom belangrijk elk incident te evalueren en te rapporteren. Dit stelt je in staat te leren van wat werkte, wat niet en waarom.

Het tenminste jaarlijks oefenen van je plan is een absolute must. Een tabletop-oefening helpt je omdat het een gesimuleerde, laagdrempelige omgeving biedt waarin teams hun reactie op mogelijke cyberincidenten kunnen oefenen en evalueren. Deze oefening helpt bij het identificeren van problemen in het plan, verduidelijken van rollen en verantwoordelijkheden en het verbeteren van de communicatie en coördinatie tussen verschillende afdelingen. Door verschillende scenario’s door te lopen, kunnen organisaties ervoor zorgen dat hun IRP effectief, aanpasbaar en up-to-date is, wat uiteindelijk de paraatheid verbetert en de impact van cyberincidenten vermindert.

Tot slot

Dit artikel biedt handvatten om aan de slag te gaan met het incidentresponsproces en het incidentresponsplan. Met een goed uitgewerkt IRP ben je beter voorbereid op het moment dat een cyberincident jouw organisatie treft. Weten wat je moet beschermen, wat je kunt detecteren en welke respons- en herstelcapaciteiten je in huis hebt, zijn daar belangrijke voorwaarden voor.