Een cyberincident kan ook jouw organisatie treffen. In sommige gevallen duurt het weken of zelfs maanden voordat alle bedrijfsfuncties weer zijn hersteld en ook je klanten en zakenpartners kunnen schade oplopen. Het is daarom belangrijk dat je weet hoe je op cyberincidenten moet reageren. Zo verminder je de impact van het incident en kun je snel weer aan de slag.
De NIS2 stelt dat organisaties maatregelen moeten nemen voor de behandeling van incidenten; de ‘incidentresponse’. Met een incidentresponseplan (IRP) zet je daar de eerste stappen voor. In deze publicatie vind je de eerste handvatten voor het opstellen van een IRP.
Doelgroep: Deze publicatie over incidentresponse is geschreven voor CISO’s van organisaties die onder de NIS2 vallen.
Aan deze publicatie hebben bijgedragen: Eye Security, Tesorion, Longamanu bv, Provincie Zeeland, Gemeente Leeuwarden en Gemeente Tynaarlo.
NIS2: De zorgplicht van de NIS2-richtlijn verplicht essentiële en belangrijke entiteiten passende en evenredige technische, operationele en organisatorische maatregelen te nemen, afgestemd op de risico’s die zich voordoen.
Inleiding
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 incidentresponse
Incidentresponse 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 incidentresponse 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.
Niet elke gebeurtenis behoeft een gecoördineerde reactie. Je incidentresponseprocessen 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 incidentresponse voor nodig hebt en wat je aan kennis, expertise en middelen in huis moet halen (of moet uitbesteden) om een effectieve incidentresponse 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?
Niet alle gebeurtenissen (‘events’) leiden tot cyberincidenten. Het is nuttig om onderscheid te maken tussen de begrippen ‘gebeurtenis’, ‘alert’ en ‘cyberincident’.
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.1 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 incidentresponse.
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 incidentrespons plan
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 incidentresponseproces 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 incidentresponse inricht. De inrichting van je incidentresponse proces 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 incidentresponse inrichten, dan heb je dus commitment en het mandaat nodig.
Betrek de bestuurders of het management bij het vaststellen van de noodzaak van incidentresponse. 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 incidentresponse 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 incidentresponse te onderbouwen.
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 incidentresponse, 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 incidentresponseproces
Bespreek samen met het management of bestuur op welke wijze incidentresponse 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.
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 incidentresponseproces is ingeregeld en welke rollen en verantwoordelijkheden en afspraken en procedures deze behelsen. Beschrijf indien nodig de relatie van het IRP met ander beleid (zoals bijvoorbeeld een continuïteitsplan).
Betrek altijd je interne en externe stakeholders bij het opstellen van je IRP. Denk aan je incidentresponse- 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 incidentresponse.
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’.
Het bepalen van de incidentdrempel is cruciaal omdat je niet voor elke wissewasje je incidentresponseproces 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 incidentresponseteam en je incidentresponseproces (zie het incidentresponseproces en incidentresponseteam rollen & verantwoordelijkheden).
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.
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 response) 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.
Stap 4: Het incidentresponseproces
Tijdens een cyberincident is het incidentresponseproces je leidraad. Het proces maakt inzichtelijk hoe de opschaling van een gebeurtenis verloopt vanaf het moment dat de gebeurtenis is getecteerd, de opschaling (‘incidenttriage’ en ‘incidentverklaring’) en de stappen om het cyberincident het hoofd te bieden, daarvan te herstellen en te leren.
De wijze waarop je het incidentresponseproces 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 incidentresponse. Het incidentresponseproces bevat in elk geval de volgende componenten: detectie gebeurtenis, notificatie, triage van de gebeurtenis, uitroepen van een cyberincident, het in werking stellen van het communicatieplan, inschakelen van responseteam (al dan niet extern), het uitvoeren van de responseactiviteiten en herstelwerkzaamheden, het beëindigen van het cyberincident en tot slot de evaluatie.2 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 incidentresponseleveranciers.
2. Afgeleid van het door SANS ontwikkelde PICERL: preparation, identification, containment, eradication, recovery, lessons learned.
Het inrichten van je incidentresponseproces 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 incidentresponseteam rollen & verantwoordelijkheden’).
Breng met behulp van een procesdiagram je incidentresponseproces 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 uibesteed aan een SOC).
Stem je incidentresponseproces goed af met de betrokken leveranciers. Leg afspraken vast in Service Level/License Agreement (SLA’s).
Stap 5: Het incidentresponseteam (rollen & verantwoordelijkheden)
Richt een incidentresponseteam 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 response.
Niet iedere organisatie heeft zelf de middelen in huis om detectie, response 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.
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 incidentresponse proces. 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 Incidentresponse Team (CSIRT)) vereisen expertise en schaalbaarheid. Externe aanbieders kunnen die mogelijk efficiënter leveren. Het is verstandig al afspraken met een incidentresponse dienstverlener 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 incidentresponse-acties afgestemd zijn op de bedrijfsdoelen en prioriteiten. Denk aan de incident coordinatie 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 incidentresponseproces.
Beschrijf nauwkeurig welke rollen en verantwoordelijkheden personen of teams hebben in het incidentresponseproces. Dit kunnen zowel personen of teams binnen de organisatie zijn, als daarbuiten zoals leveranciers van detectie- en responsediensten. 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 incidentresponseteam.
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 incidentresponseproces 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 incidentresponseproces. 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 incidentresponse dienstverlener 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 incidentresponseteamleden 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 overresponsetijden 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.
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.
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/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.
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.
Stap 7: Scenariokaarten (playbooks)
Het IRP is een plan op hoofdlijnen. Maar elk cyberincident is anders. Met scenariokaarten (of playbooks) kun je de response 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 response stelt je in staat om effectiever op te treden wanneer incidenten werkelijkheid worden.
In het IRP beschrijf je welke gebeurtenissen passen binnen de scope van het incidentresponseproces. Deze gebeurtenissen zijn relevant omdat ze kunnen leiden tot cyberincidenten. Identificeer deze gebeurtenissen en bepaal samen met de risico-eigenaren, incidentresponseteam en je detectie- en responseleveranciers 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.
Scenariokaarten bieden een concreet houvast op het moment dat response 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 incidentresponseactiviteiten.
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
Deze publicatie biedt handvatten om aan de slag te gaan met het incidentresponseproces en het incidentresponseplan. 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 response- en herstelcapaciteiten je in huis hebt zijn daar belangrijke voorwaarden voor.
