Blog Archives

Waarom is dit een dilemma?

Een cyberaanval brengt enorme druk met zich mee, vooral op management- en bestuursniveau. Operationele teams willen de systemen weer online krijgen, terwijl securityteams en externe forensische specialisten willen achterhalen hoe de aanval heeft plaatsgevonden en of de dreiging volledig is geëlimineerd.

Te snel herstel kan betekenen dat je een aanvaller per ongeluk laat ontsnappen of dat je niet goed begrijpt hoe de aanval heeft plaatsgevonden. Aan de andere kant kan een langdurig onderzoek de bedrijfsvoering ernstig verstoren en imagoschade vergroten.

De voor- en nadelen bij de keuzes

Voordelen van uitgebreid forensisch onderzoek:

• Inzicht in aanvalspad – Begrijpen hoe de aanvaller binnenkwam en zich lateraal bewoog binnen de organisatie.
• Detectie van achterdeurtjes – Voorkomen dat een aanvaller ongezien terugkeert.
• Verbetering van toekomstige verdediging – Kennis gebruiken om preventieve maatregelen te versterken.
• Juridische en compliance-verplichtingen – Voldoen aan regelgeving zoals de AVG, DORA of NIS2.

Nadelen van uitgebreid forensisch onderzoek:

• Verlengde downtime – Systemen blijven langer offline, wat operationele en financiële schade oplevert, waar klanten en partners ook last van (kunnen) hebben.
• Imagoschade – De organisatie komt negatief in het daglicht, omdat bekend wordt dat er een cyberaanval heeft plaatsgevonden.
• Kosten – Externe forensische specialisten en de impact van downtime kunnen flink in de papieren lopen.

Voordelen van snel herstel:

• Minimalisatie van operationele schade – Organisatie kan sneller weer functioneren.
• Beperkte klantimpact – Klanten ondervinden minder hinder van verstoringen.
• Beheerste kosten – Minder tijd en middelen nodig voor langdurige analyses.

Nadelen van snel herstel:

• Onvolledig onderzoek – Mogelijk missen van sporen of actieve dreigingen.
• Risico op herinfectie – Als de achterliggende oorzaak niet goed wordt begrepen, kan de aanvaller terugkomen.
• Mogelijke compliance-risico’s – Wettelijke rapportageverplichtingen kunnen worden bemoeilijkt zonder goed onderzoek.

Hoe dit geen groot dilemma hoeft te zijn

Het goede nieuws: met de juiste voorbereiding en strategie kunnen organisaties het conflict tussen onderzoek en herstel grotendeels oplossen. Een veelgebruikte oplossing is het maken van een forensische kopie van getroffen systemen voordat herstel plaatsvindt. Hierdoor kunnen analisten achteraf een diepgaand onderzoek uitvoeren zonder dat dit de hersteloperatie vertraagt.

Om te voorkomen dat herstel overhaast of juist te traag verloopt, moeten organisaties vooraf de juiste maatregelen nemen. Dit zijn de belangrijkste stappen:

1. Real-time logging en monitoring inrichten

Goed ingerichte logging en detectie zorgen ervoor dat je direct inzicht hebt in een aanval. Dit kan niet alleen de schade beperken, maar versnelt ook het forensisch onderzoek en herstel. Echter, omdat aanvallen snel kunnen worden uitgevoerd, vaak sneller dan de verdediging op gang komt – iets wat met hulp van AI verbeterd kan worden – wil er wel eens een aanval tussendoor glippen. Het hebben van de juiste (en betrouwbare) logging kan dan helpen het forensisch onderzoek te versnellen en tegelijkertijd zorgen voor een beter gefundeerd herstelplan.

2. De processtappen voor forensisch onderzoek vooraf gereed hebben

Hoe eerder je kunt starten met forensisch onderzoek, hoe eerder je kunt herstellen. De volgende factoren spelen daarbij een rol:

• Werk, nog voordat er sprake is van een (cyber)incident / tijdens de “business as usual,” samen met gekwalificeerde forensische experts en stel vooraf vast welke certificeringen en competenties nodig zijn om effectief onderzoek te kunnen doen. Een gekwalificeerde forensisch expert beschikt idealiter over certificeringen zoals GCFA (GIAC Certified Forensic Analyst) of CHFI (Computer Hacking Forensic Investigator). Een helder contract met SLA’s en duidelijke verwachtingen en een gemakkelijk (ook niet-digitaal) te raadplegen contactenboekje met daarin de gegevens van de forensisch expert kan ervoor zorgen dat de expert direct en efficiënt kan handelen bij een incident.
• Zorg voor vooraf gedefinieerde forensische procedures, zodat duidelijk is welke systemen, logs en metadata veiliggesteld moeten worden. Bepaal daarbij vooraf welke kritieke assets bij een aanval altijd moeten worden gekopieerd, zodat er geen tijd verloren gaat aan discussie.
• Gebruik geautomatiseerde tooling voor forensische kopieën en logging, zodat dit proces snel en gestandaardiseerd verloopt.

3. Scheiding tussen onderzoek en herstelacties

Terwijl forensische kopieën worden geanalyseerd, kunnen al bepaalde herstelstappen worden ingezet. Welke stappen parallel kunnen worden ingezet is echter situatieafhankelijk en (soms) al dan niet deels afhankelijk van de eerste resultaten vanuit het forensisch onderzoek. Als incidenten de cyclus “Analyse – Inperking (containment) – Opschoning (eradication) – Herstel” doorlopen, is het in de fase van (parallel) herstel wel handig om alvast wat richting te krijgen vanuit analyses. Frequente communicatie tussen forensisch onderzoekers en herstelteams is dan ook cruciaal.

Desalniettemin kan in voorkomende gevallen – al is dat soms ten overvloede – alvast gestart worden met de voorbereiding op herstel gedurende het onderzoek. Om goed te kunnen herstellen moet vaak niet simpelweg op een knop gedrukt worden. Er zijn verschillende handelingen noodzakelijk, al helemaal naar mate de cyberaanval grootschaliger is.

• Zijn herstelteams al (technisch) in staat met elkaar te communiceren?
• Kunnen herstelprocedures (technisch) al in gang worden gezet?

Indien het antwoord op een van deze vragen “nee” is, kan daar in ieder geval aan gewerkt worden.

In feite kan dus alles parallel aan het forensisch onderzoek worden voorbereid om – zodra het bestuur/management vindt dat er voldoende onderzoek is gedaan – direct aan de slag te gaan met herstel; te beginnen met opschoning (eradication), gevolgd door het daadwerkelijk herstel.

Let wel, uit het onderzoek kan blijken dat de inhoud van back-ups ook opgeschoond moet worden. Mede daarom is het niet verstandig klakkeloos back-ups te herstellen.

4. Oefenen met tabletop-exercises

Organisaties die vooraf crisisscenario’s oefenen, zijn beter voorbereid op de balans tussen onderzoek en herstel en wanneer de balans welke kant op wijst. Simulaties kunnen helpen om de juiste afwegingen voor te bereiden onder tijdsdruk.

5. Oefenen (back-up) restore testen

In deze blog staat tijdsdruk en het dilemma tussen langer onderzoek versus sneller herstel centraal. “Sneller herstellen” betekent echter niet dat direct na het besluit te kunnen gaan herstellen een IT-omgeving (of deel ervan) gelijk hersteld is. Ook herstel kost tijd. Daarom is het goed om als input voor de afwegingen die hierboven genoemd zijn (bij de tabletop-exercises) te weten hoe lang je daadwerkelijk doet over herstel. De enige manier om daar een serieuze inschatting van te maken, is door het herstel te oefenen. Daarbij geldt daarnaast dat hoe vaker iets geoefend is hoe sneller het proces gaat, technische beperkingen daargelaten.

6. Communicatie en stakeholdermanagement

Heldere communicatie met interne en externe stakeholders helpt de verwachtingen te managen en voorkomt paniekbeslissingen. Een cybercrisiscommunicatieplan voorkomt onnodige druk om systemen te snel online te brengen.

Conclusie

Het conflict tussen forensisch onderzoek en snel herstel is een klassieke uitdaging binnen incident response. Toch kan dit dilemma grotendeels worden weggenomen door vooraf goed na te denken over responsstrategieën. Door snel en efficiënt forensische kopieën te maken, parallelle herstelstappen te nemen, kunnen organisaties zowel snel herstellen als waardevolle inzichten uit het forensisch onderzoek behouden. Zoals vaak met (ogenschijnlijke) dilemma’s: het gaat om het vinden van de juiste balans.

Hoe gaat jouw organisatie om het vinden van die balans en hoe valt de balans uit: staat snelheid of zorgvuldigheid bij jullie voorop?

Vooruitplannen: structuur versus inflexibiliteit

Een gedetailleerd herstelplan heeft duidelijke voordelen. Het biedt structuur en houvast in een chaotische situatie. Iedereen weet wat ze moeten doen, in welke volgorde, en welke stappen prioriteit hebben. Maar te veel structuur kan ook een valkuil zijn. Wat als je plan uitgaat van een bepaald type aanval dat nét anders blijkt te zijn? Wat als de vooraf bedachte volgorde niet past bij de situatie, en niemand de autoriteit heeft om af te wijken?

Een voorbeeld: stel, dat jouw plan voorschrijft om eerst kritieke productie-applicaties te herstellen, maar blijkt dat de kritieke klantapplicaties sneller moeten worden opgestart om reputatieschade te voorkomen. Wie beslist dan om het plan los te laten en te improviseren? Het risico is dat een rigide plan meer tijd kost dan het bespaart.

Flexibiliteit: improvisatie of chaos?

Aan de andere kant kan een flexibel herstelpad waardevol zijn, omdat het ruimte laat om in te spelen op de specifieke situatie. Maar hier schuilt ook gevaar: zonder een helder kader kan flexibiliteit al snel omslaan in chaos. Wie neemt beslissingen? Op basis van welke informatie bepaal je prioriteiten? En hoe voorkom je dat verschillende teams elkaar tegenwerken?

Een hybride aanpak, waarbij bepaalde kritieke onderdelen strak gepland zijn en andere flexibel blijven, kan helpen om het beste van beide werelden te combineren. Maar dat vraagt voorafgaand overleg en duidelijke afspraken over wie welke beslissingen mag nemen.

Wat moet altijd eerst?

Er zijn delen van je IT-infrastructuur waar je simpelweg geen of in ieder geval weinig keuzevrijheid hebt. Basisinfrastructuur zoals AD, DNS, DHCP, NTP en je virtualisatieplatform vormen de ruggengraat van je IT-omgeving. Deze componenten zijn vaak sterk afhankelijk van elkaar. Dit betekent dat je voor deze lagen van je infrastructuur een vast en goed getest herstelplan nodig hebt (zie ook mijn eerdere blog over testen).

Op applicatieniveau is er vaak meer speelruimte. Hier kun je prioriteiten stellen op basis van de impact op je organisatie én de situatie waarin je verkeert. Zijn klantgerelateerde systemen het belangrijkst? Of richt je je eerst op interne processen zoals HR en finance? De keuzes die je maakt, zouden idealiter gebaseerd moeten zijn op een Business Impact Analysis (BIA), waarin je vooraf vastlegt welke applicaties cruciaal zijn voor je bedrijfscontinuïteit. Toch hoeven de resultaten van de BIA geen definitief uitsluitsel te bieden.

De rol van testen en simuleren

Of je nu kiest voor een strakke planning, flexibiliteit, of een combinatie van beide, een succesvol herstel staat of valt met testen. Tijdens een cyberaanval neemt stress vaak over, wat kan leiden tot fouten of vertraagde beslissingen. Het testen van je herstelplannen helpt niet alleen om technische fouten te ontdekken, maar ook om organisatorische zwaktes bloot te leggen. Wie neemt de leiding? Hoe stressbestendig is die persoon? Hoe reageren teams onder druk? Zijn de rollen en verantwoordelijkheden duidelijk?

Het simuleren van verschillende scenario’s, inclusief onvoorspelbare elementen, kan helpen om je organisatie voor te bereiden op het onverwachte. Denk aan scenario’s waarbij bepaalde systemen langer uitvallen dan verwacht, of waarbij sleutelpersonen niet beschikbaar zijn.

Strategische keuzes: alles voorbereiden of niet?

Het antwoord op dit dilemma is niet zwart-wit. Een 100% uitgewerkt herstelpad geeft duidelijkheid en snelheid, maar beperkt je wendbaarheid. Volledig vertrouwen op improvisatie biedt flexibiliteit, maar vergroot de kans op fouten. De beste aanpak is vaak een balans: een solide plan voor je basisinfrastructuur en ruimte voor flexibiliteit op applicatieniveau.

Belangrijk is dat je vooraf nadenkt over de verantwoordelijkheden. Wie beslist welke onderdelen volledig voorbereid worden? Wie heeft tijdens een crisis de autoriteit om beslissingen te nemen? En hoe zorg je ervoor dat deze rollen goed op elkaar zijn afgestemd?

Een plan voor het onverwachte

Een cyberaanval is altijd onverwacht, maar je herstelstrategie hoeft dat niet te zijn. Door kritisch te kijken naar je IT-afhankelijkheden en duidelijke keuzes te maken in wat je voorbereidt en wat je flexibel laat, kun je je organisatie wapenen tegen de gevolgen van een aanval. Combineer dit met regelmatig testen en een heldere rolverdeling, en je creëert een hersteltactiek die zowel robuust als wendbaar is.

De vraag blijft: ben jij voorbereid op het onverwachte? Of laat je het over aan de improvisatie van het moment?

On-premise vs. cloud: wat verandert er voor herstel?

In het kader van cyber recovery maakt het absoluut uit welk sourcing model van toepassing is: gaat het om on-premise IT, of public cloud? En als het om (public) cloud gaat, is het dan op basis van IaaS, PaaS of SaaS? De verantwoordelijkheden die bij jou liggen verschillen dan namelijk nogal, zoals ook in onderstaande afbeelding is weergegeven.

Bron: https://www.ncsc.gov.uk/collection/cloud/understanding-cloud-services/cloud-security-shared-responsibility-model

Als je on-premise werkt, heb je volledige controle over je infrastructuur en data. Dit betekent echter ook dat je zelf verantwoordelijk bent voor alle herstelmaatregelen, inclusief back-ups en recovery. De cloud biedt flexibiliteit en schaalbaarheid, maar ook een verschuiving in verantwoordelijkheden. De mate van verantwoordelijkheid hangt af van het gebruikte cloudmodel: SaaS, PaaS of IaaS.

Wie is waarvoor verantwoordelijk? SaaS, PaaS en IaaS

SaaS (Software-as-a-Service)

Bij SaaS-diensten, zoals Microsoft 365 en Salesforce, biedt de leverancier een kant-en-klare oplossing. Je hoeft je geen zorgen te maken over infrastructuur of software-updates, maar je bent wel zelf verantwoordelijk voor het beschermen van je data.

• Voorbeeld: Wat gebeurt er als een storing of ransomware-aanval de SaaS-dienst treft? Kun je je bedrijf draaiende houden zonder toegang tot de applicatie(s)? Hoewel je je data kunt veiligstellen, kunnen workflows, rechtenstructuren en andere applicatie-afhankelijke data verloren gaan. Mogelijk valt je proces daardoor stil en moet je op pen en papier verder.

PaaS (Platform-as-a-Service)

PaaS-oplossingen, zoals Heroku en Google App Engine, bieden meer flexibiliteit, maar leggen ook meer verantwoordelijkheid bij de klant. De leverancier beheert de infrastructuur, maar applicaties, databases en configuraties zijn jouw verantwoordelijkheid.

• Voorbeeld: Als de platforminfrastructuur crasht, kun je je data en applicaties hebben, maar de onderliggende runtime-omgeving ontbreekt. Zijn je applicaties dusdanig ontwikkeld dat ze gemakkelijk in een andere cloudomgeving of zelfs lokaal kunnen worden uitgevoerd?

IaaS (Infrastructure-as-a-Service)

Bij IaaS-oplossingen zoals AWS of Google Cloud krijg je maximale flexibiliteit om je IT-infrastructuur in te richten, van virtuele servers tot alles wat daar op draait.

• Voorbeeld: Wat als een hele regio van je cloudleverancier wordt getroffen door uitval? Het repliceren van je virtuele machines naar een andere regio of zelfs een andere provider kan de sleutel zijn tot een succesvol herstel. Dit vereist echter niet alleen technische voorbereiding, maar ook aandacht voor de bijkomende kosten en licentievoorwaarden.

Het dilemma: vertrouw je je leverancier (genoeg)?

Zoals hierboven al een paar keer beschreven; hetgeen waarvoor je verantwoordelijk bent verschuift op het moment dat je gebruik maakt van cloud – en eigenlijk ook bij IT-dienstverleners in het algemeen. Als het gaat om cyber recovery van hetgeen buiten jouw verantwoordelijkheid valt, wordt het vertrouwen in je IT-dienstverlener mogelijk toch op een weegschaal gelegd: Vertrouw ik volledig op mijn leverancier, wil ik zelf kunnen herstellen, of is er een tussenweg?

1. Volledig vertrouwen op de leverancier: Dit is de eenvoudigste optie, waarbij je vertrouwt op de SLA’s en herstelmaatregelen van de provider. Maar hoe zeker ben je dat de leverancier je data en applicaties op tijd herstelt en je niet dagen- of wekenlang met pen en papier verder moet? Zorg ervoor dat je precies weet wat ze wel en niet bieden.
2. Zelf back-ups en herstelplannen beheren: Het zelf opslaan van data en configuraties biedt meer controle, maar roept vragen op: Kun je zonder toegang tot de cloudomgeving iets met die data en configuraties? Hoe kom je aan een alternatief voor de cloudomgeving waarin je de data en configuraties kunt toepassen? Heb je voldoende capaciteit en kennis om zo’n herstelplan uit te voeren? Zie dit als een variant op het exit-plan dat je mogelijk al hebt met je IT-dienstverlener maar met de waarschijnlijke afwijking dat je alle maatregelen al klaar hebt staan (“in place” hebt) om zonder inbreng van de IT-dienstverlener het exit-plan uit te voeren. Let wel op: dit kan tot complicaties leiden op het gebied van licenties, intellectueel eigendom, restricties ten aan zien van dataverplaatsing, middleware en/of API’s die wel/niet mogen worden gebruikt, etc. Hoewel een IT-dienstverlener dus mogelijk niet zit te wachten op het laten back-uppen van zijn IT buiten zijn omgeving, is er voor die partij ook een positief punt. Op het moment dat jij een cyber recovery oplossing inricht voor hetgeen de IT-dienstverlener aanbiedt, kun jij ook fungeren als (vertrekpunt voor) cyber recovery van de gehele dienstverlening van de IT-dienstverlener. Jij bent dan als het ware dus zijn cyber recovery-oplossing. De vraag is dan echter: “Wil je dat wel?
3. De tussenweg: Waar volledig vertrouwen wellicht te ver gaat, is een tussenweg tussen dit vertrouwen en zelf alles in beheer willen nemen rondom cyber recovery de meest voor de hand liggende keuze. Immers, in het verleden is niet voor niets de keuze gemaakt om naar de cloud te gaan (of uit te besteden). Door juist alles zelf (weer) op je te nemen, doe je de redenen voor uitbesteding grotendeels of zelfs volledig, teniet. Hoewel het ook in dit scenario tot juridische complicaties kan leiden, valt er wel wat te zeggen voor het zo nu en dan (laten) back-uppen van je data naar een omgeving waar jij zelf (ook) toegang tot hebt en zelf volledig in de hand hebt wat er met de back-ups gebeurt. Er valt zelfs iets te zeggen voor het  opzetten van een tweede (stand-by, standaard offline) omgeving die met beperkte functionaliteit en grootte. Zo’n omgeving kan de minimaal noodzakelijke procesgang ondersteunen die normaliter door je primaire cloud-dienstverlener wordt ondersteund. De noodzaak voor zo’n omgeving is vrijwel volledig afhankelijk van de noodzaak voor (zeer) snel herstel van procesgang. Er is een risico dat in zo’n omgeving de back-ups van je primaire dienstverlener niet (een op een) ingelezen kunnen worden – logisch, want meestal is het totaal verschillende techniek die wordt toegepast – dus voor (historische) gegevenskritieke processen is dit wellicht niet de optie. En fin, veel keuzes; allemaal met hun voor- en nadelen.

Wat past bij jouw organisatie?

Cyber Recovery in de cloud is geen eenvoudige keuze tussen vertrouwen en controle. Het vereist een balans tussen afhankelijkheid van de leverancier en maatregelen in huis hebben om zelf te kunnen herstellen. Overweeg daarbij de mogelijke technische oplossingen, juridische beperkingen en operationele haalbaarheid om een strategie te ontwikkelen die aansluit bij jouw organisatiebehoeften en risicobereidheid.

Wil je controle of gemak? Kun je vertrouwen op de beloften van je leverancier, of ga je voor zekerheid door middel van een eigen herstelplan? De belangrijkste vraag blijft: Ben je voorbereid op een cyberaanval, ongeacht waar je IT zich bevindt?

Cyber Recovery-testen: Welke variabelen moet je afwegen?

Wist je dat meer dan 50% van de organisaties er bij een cyberaanval niet in slaagt om hun IT-systemen binnen de gestelde tijd te herstellen? De vraag is dan: hoe zorg je ervoor dat jouw organisatie niet in deze statistiek terechtkomt? Een goede cyber recovery-strategie valt of staat bij de kwaliteit van je tests. Maar wat moet je precies testen en hoe diep moet je gaan? In deze blog geen pasklare antwoorden, want elk bedrijf is uniek. Wel geven we handvatten: variabelen die je helpen bepalen hoe jouw organisatie kan aantonen dat ze klaar is voor het moment suprême.

Waarom testen voor cyberaanvallen meer omvat dan disaster recovery

Bij een disaster recovery-test focus je vaak op één lokaal probleem, bijvoorbeeld het herstellen van data na een hardwarefout in een datacenter. Maar wat als je organisatie wordt getroffen door een ransomware-aanval die je hele IT-landschap lamlegt?

In zo’n scenario gaat het niet alleen om dataherstel. Je moet applicaties opnieuw opstarten, interfaces herstellen en een volledig functionerende IT-infrastructuur weer opbouwen. Dit vraagt om een veel bredere, holistische aanpak: cyber recovery.

Hoewel cyber recovery verder gaat dan de traditionele focus van disaster recovery, is het niet vanzelfsprekend dat de huidige disaster recovery-tests volledig aansluiten bij wat een cyberaanval vereist. De kernvraag blijft: zijn al die losse testen samen voldoende om een geïntegreerde aanpak te waarborgen? Of is er meer nodig om voorbereid te zijn op een grootschalige cybercrisis?

In die context zijn er drie belangrijke variabelen om rekening mee te houden bij een cyber recovery test.

1. Mate van simulatie versus daadwerkelijk herstel

Wil je vooral de theorie doornemen of echt oefenen hoe je systemen zou herstellen in een crisis? Met een tabletop-oefening kunnen rollen en verantwoordelijkheden helder worden, maar geeft minder zekerheid over de daadwerkelijke werking van je systemen. Een parallelle test, waarin je systemen in een niet-productieomgeving herstelt, biedt meer realisme maar vraagt ook meer middelen en planning. De vraag is dan of je voldoende middelen hebt (o.a. geschikte testomgevingen) en of het noodzakelijk is om het herstel volledig te testen. Als het goed is worden er al disaster recovery testen uitgevoerd. Omdat cyber recovery een complexere vorm daarvan is, kun je overwegen om bepaalde elementen uit disaster recovery niet opnieuw te testen. Ook kun je aannames maken over herstelbaarheid, gebaseerd op eerder succes in een disaster recovery-scenario.

Concrete overwegingen: als je alleen tabletop-oefeningen uitvoert, weet je zeker dat de processen op papier kloppen, maar hoe weet je of jouw team ook onder druk kan presteren als systemen daadwerkelijk offline zijn? Aan de andere kant, het volledig simuleren van een black-out situatie, inclusief herstel van onderliggende IT-platforms, kan maanden aan voorbereiding en resources vereisen.

2. Mate van integratie

Test je alleen individuele systemen, of neem je ook interfaces en integraties mee? Vaak vereisen effectieve hersteloperaties dat applicaties en de onderliggende infrastructuur naadloos samenwerken. Hoe complexer de integratie tussen systemen, hoe belangrijker het is om deze samenwerking te testen. Je wilt voorkomen dat een goed werkend herstelproces vastloopt door gebrekkige communicatie tussen systemen. Deze communicatie moet je zien in het licht van:

1. “Verticale integratie”: Herstel van software op onderliggende platforms
   Hierbij kun je je afvragen of je de software wil hersteltesten een hersteld platform of dat je uitgaat van een bestaand, operationeel platform. In een volledige black-out is het mogelijk dat je eerst de platforms moet herstellen voordat je software kunt installeren. Daarentegen kan het ook zijn dat slechts een deel van de infrastructuur hersteld hoeft te worden, omdat sommige platformen operationeel blijven. De vraag is dus in welke mate, wederom in het licht van het al uitvoeren van disaster recovery testen en/of andere testen, je alles volledig wilt herstellen tijdens een hersteltest.
2. “Horizontale integratie”: Testen van communicatie tussen systemen (interfaces)
   Hierbij kun je je afvragen of en, zo ja, welke interfaces je in een hersteltest wilt herstellen. Met name de complexiteit rondom het testen van interface kan daarbij een remmende factor zijn en daarmee een rol spelen. Vragen die helpen bij het bepalen van de complexiteit zijn:
   • Betreffen het interfaces in hetzelfde netwerkdomein?
   • Betreffen het interfaces met externe partijen? En zo ja, hebben die externe partijen dan ook testomgevingen beschikbaar waarmee geconnecteerd kan worden? In welke mate kun je stubs toevoegen?
   • Is er een omgeving waarin we deze interfaces kunnen hersteltesten?

3. Testfrequentie en scope

Hoe vaak en hoe uitgebreid je test, hangt af van de veranderlijkheid van je omgeving en je risicoprofiel. In een dynamische IT-omgeving, waar regelmatig nieuwe systemen of updates worden toegevoegd, kan een hogere testfrequentie noodzakelijk zijn. Je kunt hierbij ook variëren in scope – een keer alleen de kritieke systemen testen en een andere keer een bredere oefening doen – of in diepgang van de testen.

Kortom: het bepalen van de juiste diepgang, vorm en reikwijdte van je hersteltesten is niet zo eenvoudig. Het algemene advies is dan ook om vooral aan de slag te gaan en iteratief te ondervinden wat acceptabel is, rekening houdend met onderstaande.

Drie essentiële stappen in elke Cyber Recovery-test

Naast bovenstaande variabelen zijn er enkele stappen die iedere test zou moeten bevatten om waardevol te zijn:

1. Betrokkenheid van de juiste stakeholders en heldere rolverdeling: Voor een effectieve test is het belangrijk dat alle relevante partijen meedoen. Van eindgebruikers die hun data moeten kunnen herstellen tot applicatiebeheerders die ervoor zorgen dat applicaties functioneren en IT-beheerders die verantwoordelijk zijn voor de infrastructuur. Duidelijke rolverdelingen en een gedeeld begrip van risico’s helpen om een samenhangende test te realiseren.
2. Evaluatie en vastleggen van verbeteracties: De waarde van je test hangt af van wat je ermee doet. Plan na elke test een grondige evaluatie in om te bepalen wat goed werkte en waar het beter kan. Leg de verbeterpunten vast en zorg dat deze bij de volgende test worden meegenomen. Dit continue leerproces is cruciaal voor een up-to-date en effectieve recovery-strategie.
3. Communicatie tijdens een incident simuleren: Heldere communicatie is essentieel tijdens een crisis. Het testen van communicatie – welke informatie wanneer en met wie wordt gedeeld – kan chaos en vertraging voorkomen. Denk aan wie op de hoogte moet zijn van de status en wie beslissingen moet nemen. Dit aspect wordt in tests vaak over het hoofd gezien, terwijl het in de praktijk een grote rol speelt in de effectiviteit van je respons. Dit zou je overigens ook enigszins losstaand van het herstellen van je IT kunnen testen.

Ga vooral aan de slag met oefenen, maak het geen theoretisch (eindeloos) verhaal

Er is geen one-size-fits-all aanpak voor cyber recovery testen. Maar één ding is zeker: niet testen is geen optie. Betrek je IT-beheerders, stel kritische vragen en durf keuzes te maken die passen bij je risicobereidheid. Zo maak je van je tests geen formaliteit, maar een cruciale stap richting echte cyber resilience. De vraag is: hoe zeker ben jij dat je voorbereid bent?

Bij ARC People begrijpen we dat effectieve cyber recovery meer vraagt dan alleen theorie. Onze experts helpen je met het opzetten van praktijkgerichte hersteltests die aansluiten bij jouw specifieke risico’s en IT-omgeving. Samen zorgen we ervoor dat jouw organisatie niet alleen voldoet aan de eisen, maar ook echt voorbereid is op het onverwachte. Met onze ervaring en hands-on aanpak maken we cyber resilience haalbaar én meetbaar. Durf jij de eerste stap te zetten? Neem contact op met Toine van den Hurk voor een oriënterend gesprek.

Herstellen na een cyberaanval

Bij cyberaanvallen is het tegenwoordig niet meer de vraag óf, maar wannéér ze plaatsvinden. Voor organisaties is het cruciaal om snel en efficiënt te kunnen herstellen. Maar wat moet je precies veiligstellen om dit zo snel en efficiënt mogelijk te maken? In mijn vorige blog stond ik stil bij het type informatie. In deze blog ga ik in op de vorm waarin die informatie is opgeslagen.

Wat moet er veiliggesteld worden?

Om snel weer operationeel te zijn na een cyberaanval, moet je minimaal de volgende drie lagen veiligstellen in je back-ups:

• Data: Zonder toegang tot je data staat je bedrijf stil. Data vormt de basis van alles en moet dus als eerste worden veiliggesteld.
• Configuraties: Netwerk-, server- en applicatieinstellingen, zowel de functionele als die verband houden met beveiliging, zijn net zo belangrijk als data. Zonder juiste configuraties kan het opzetten van je systemen dagen, zo niet weken, langer duren.
• Broncode: Voor organisaties die zelf software ontwikkelen of installeren is de broncode essentieel. Als je deze verliest, kan het maanden duren om weer op hetzelfde niveau te komen.

Hoewel dit de basis is, moet je goed nadenken over wat je misschien over het hoofd ziet. Bijvoorbeeld: zijn de wachtwoorden die ik nodig heb voor installatie inbegrepen? En hoe zit het met eventueel benodigde certificaten?

Hoe ga ik herstellen: herstellen of opnieuw opbouwen?

Soms is het handig om van achter naar voren te denken: wat is het eindresultaat, hoe wil ik daar komen en wat heb ik nu nodig? Dit principe geldt in feite voor vrijwel alles bij Cyber Recovery, dus ook voor het bepalen wat je moet veiligstellen. Als je weet welke data en functionaliteit wilt kunnen herstellen en je weet hoe je dat wil doen, ben je er al zo’n beetje.

Hoe je kunt herstellen is in grofweg twee strategieën op te delen:

• Restore: Hierbij herstel je systemen vanuit bestaande back-ups.
• Rebuild: Bij deze strategie bouw je de systemen helemaal opnieuw op.

Belangrijk om te realiseren: je data zelf moet eigenlijk altijd vanuit een back-up worden hersteld.

Restore

Veel organisaties maken al back-ups, maar vaak niet doordacht genoeg. Denk na over

1. Wat: Maak je back-ups van alleen data, of ook van applicatiefunctionaliteit en netwerkconfiguraties?
2. Hoe: Maak je back-ups van volledige servers, specifieke bestanden of databases?

Een goede vuistregel is: back-up alles wat je nodig hebt om weer te kunnen draaien. Heb je bijvoorbeeld al nagedacht over hoe je een compleet systeem kunt herstellen, en niet alleen losse bestanden?

Het is verstandig om periodiek te controleren wat er nu in je back-ups zit, met name door te testen of je vanuit niets kunt herstellen wat je wilt herstellen. Pas dan weet je of je genoeg in je back-ups hebt opgenomen. Wellicht mis je bepaalde data, configuraties of gehele IT-systemen.

Rebuild

Het opnieuw opbouwen van je IT klinkt als veel werk, maar dat hoeft het niet te zijn. Tegenwoordig wordt steeds meer als code opgeslagen, zelfs je IT-infrastructuur (infrastructure as code). Zolang die code is veiliggesteld en je beschikt over de juiste tools om die code uit te rollen, kun je met automatisering snel functionaliteit herstellen.

Checklist: Ben jij voorbereid?

1. Heb je duidelijk wat er hersteld moet worden? (zie ook mijn vorige blog)?
2. Is je herstelstrategie helder (restore of rebuild)?
3. Restore-strategie: Ben je zeker van wat je nu veiligstelt in je back-ups?
4. Rebuild-strategie: Heb je de benodigde code en configuraties veiliggesteld om een herbouw te faciliteren?

Met deze benadering ben je goed voorbereid op een cyberaanval, ongeacht de complexiteit van je IT-omgeving. Wil je sparren over hoe je jouw cyber recovery-strategie verder kunt versterken? Neem gerust contact op. Samen zorgen we ervoor dat je snel en efficiënt kunt herstellen, zonder verrassingen.

Cyber Recovery: wat moet je echt herstellen en wat niet?

In eerdere blogs stonden we stil bij het belang van kunnen herstellen na een cyberaanval. Maar: hoe bepaal je wat je moet herstellen en wat minder urgent is? Moet je alles herstellen of richt je je op de belangrijkste onderdelen? Wat zijn eigenlijk de belangrijkste onderdelen? En: hoe bepaal je dat? Dit zijn enkele cruciale vragen die organisaties zichzelf moeten stellen wanneer ze een Cyber Recovery-plan opstellen.

Uiteindelijk komt het neer op het maken van doordachte keuzes op basis van functionele en technische inzichten. Echter, uit onderzoek blijkt dat veel organisaties nog onvoldoende overzicht in hebben in wat hun kritieke functies zijn. Sterker nog, onderzoek bevestigt ook dat veel organisaties überhaupt het overzicht missen in welke activiteiten zij uitvoeren, in welke mate deze bijdragen aan de organisatiedoelstellingen en welke IT daarin (en in welke mate) een rol speelt*.

Alles herstelbaar maken dan maar? Vanuit kosten perspectief is dat op de lange termijn wellicht ook niet handig: heb je een of meerdere (cloud)datacenters beschikbaar waarin alles hersteld kan worden? En, o ja, die datacenters moet je eigenlijk nooit hoeven te gebruiken.

Kortom: het lijkt erop dat het maken van doordachte keuzes in wat wel en niet hersteld moet worden de beste / meest langdurige oplossing is. Maar waar moet ik aan denken? Laten we dat verkennen aan de hand van een gestructureerde aanpak, waarbij we kijken naar kritieke functies, afhankelijkheden en hoe je prioriteiten stelt in je herstelstrategie.

Hoe bepaal je wat je moet herstellen?

Een van de grootste uitdagingen in Cyber Recovery is het bepalen van wat je echt nodig hebt om snel weer operationeel te zijn. De meeste organisaties werken met een Business Impact Analysis (BIA) om te bepalen welke functies en systemen prioriteit hebben. De BIA helpt bij het classificeren van activiteiten en tooling die cruciaal zijn voor je bedrijfsvoering. Maar hoe gedetailleerd is dat inzicht werkelijk? Vaak blijft het beperkt tot de tools die worden gebruikt en missen we een duidelijk beeld van de afhankelijkheden tussen systemen en (bedrijfs)activiteiten. Behalve dat dit laatste wat mij betreft cruciaal is om een BIA goed uit te kunnen voeren, mist er nog iets. Waar de BIA meestal is gericht op de afhankelijkheden van IT voor de continuïteit van de organisatie, mist vaak (terecht) in de BIA de afhankelijkheden van IT om de IT te continueren. Bijvoorbeeld: de BIA maakt (hopelijk) een verbinding tussen bedrijfsvoering en ondersteunende applicaties en andere IT-systemen. Echter, de IT-systemen die in de BIA zijn opgenomen, zijn op hun beurt ook weer afhankelijk van allerlei elementen. Denk aan certificaten, wachtwoordkluizen waarin wachtwoorden van beheeraccounts staan, besturingssystemen met bepaalde instellingen en ga zo maar door. Om goed te kunnen herstellen is ook dit inzicht een must.

Kortom, om te bepalen wat kritiek is, is inzicht nodig in:

1. De bedrijfsactiviteiten, in welke mate deze van belang zijn voor de continuïteit van de organisatie en welke (soort) informatie gebruikt/verwerkt wordt in die activiteiten;
2. De applicaties en andere IT-systemen die de bedrijfsactiviteiten ondersteunen en in welke mate dat ze dat doen;
3. De afhankelijkheden die de IT-systemen kennen om te kunnen functioneren.

Zonder deze inzichten herstel je niet de belangrijkste zaken en/of duurt herstel mogelijk (veel) langer dan nodig. Het mooie? De meeste organisaties zijn al zo ingericht dat deze drie inzichten opgehaald kunnen worden bij verschillende afdelingen:

Voor inzicht #1 en #2 zijn het de mensen op de werkvloer en/of management die de inzichten zou moeten kunnen geven:

• Het hebben van een dataclassificatiemodel, waarin ten minste classificaties ten aanzien van de beschikbaarheid, integriteit en vertrouwelijkheid van data wordt stilgestaan, helpt bij het bepalen van het bepalen van belang van activiteiten. Tegelijkertijd kan op basis van gestructureerde analyses en onderbouwingen er best wel eens een scheef beeld ontstaan over wat belangrijk is en wat minder. Daarom is het goed om ongeacht wat de modellen als uitkomst bieden altijd de resultaten onderling te vergelijken van activiteit tot activiteit en desnoods het gehanteerde model te overrulen.

Voor #3 moet je bij IT zijn:

• Een goed CMDB kan het gemakkelijk maken om het inzicht snel te bieden.
• Is beheer van je IT uitbesteed? Nog mooier, dan is het meestal aan de IT-dienstverlener om dit inzicht te hebben en is het aan jou om goede afspraken te maken over beschikbaar maken van IT na een cyberaanval.

Maar wat als je je vergist?

Hoewel automatisering van bovenstaande absoluut kan helpen, is er altijd een kans dat je wat zaken mist of verkeerd hebt opgenomen in de gevraagde inzichten. Er is immers in ieder van de uit te voeren activiteiten sprake van enige mate van afhankelijkheid van mensen. En waar mensen werken, worden fouten gemaakt.

Wat dus als die fouten zijn gemaakt bij het maken van die inzichten? Je zult het in deze reeks nog wel een paar keer lezen: testen, testen, testen. De enige manier om er echt achter te komen is door te gaan testen. Hoe en wat te testen, dat komt later nog wel eens aan bod.

Cyber Recovery-plan in kaart brengen

Veel organisaties hebben hun recovery-plannen nog niet volledig in kaart, vooral als het gaat om het bepalen van prioriteiten en afhankelijkheden. Zonder gedegen inzicht in wat er hersteld moet worden en in welke volgorde, loop je het risico op onnodige vertragingen en extra schade. Het is tijd om je herstelstrategie tegen het licht te houden: Heb jij helder wat er hersteld moet worden na een aanval?

Neem contact op om te ontdekken hoe we jouw Cyber Recovery-plan kunnen optimaliseren. Samen zorgen we ervoor dat je snel en effectief herstelt, zonder dat je iets over het hoofd ziet. Afspraak maken voor een vrijblijvend gesprek? Bel me op 06 417 731 52 of mail naar toine@arcpeople.nl.

* Kanttekening: wat dat betreft ligt er voldoende uitdaging om te gaan voldoen aan DORA en in iets mindere mate NIS2.

Uitbesteden van Cyber Recovery

Het uitbesteden van IT-diensten is voor veel organisaties een slimme zet. Met toegang tot gespecialiseerde kennis en schaalvoordelen lijkt de IT-infrastructuur in goede handen. Toch blijkt er vaak een grote misvatting: dat Cyber Recovery bij een uitbestede IT-omgeving ook volledig kan worden uitbesteed. Terwijl IT-providers de technische kant van zaken kunnen regelen, zijn er essentiële onderdelen van cyber recovery die altijd onder jouw verantwoordelijkheid vallen. In deze blog ontdek je waarom jouw betrokkenheid cruciaal is voor effectieve herstelstrategie na een cyberaanval, zelfs als je IT niet meer in eigen beheer is.

Wat je zelf moet regelen

Cyber Recovery betekent meer dan alleen vertrouwen op de diensten van een externe partij. Het gaat om het waarborgen van continuïteit, het beperken van schade, en het snel weer up and running zijn na een cyberincident van jouw organisatie. De kans is aannemelijk dat jouw organisatie het nieuws haalt en niet jouw IT-dienstverlener.

1. Grip op jouw herstelprioriteiten en -strategie

IT-dienstverleners kunnen je helpen met technische recovery-aspecten. Maar stel jezelf de vraag: begrijpen zij écht welke systemen voor jou cruciaal zijn? Jij kent je eigen organisatie het best. Dit betekent dat het bepalen van hersteldoelstellingen, bijvoorbeeld ten aanzien van doorlooptijden en toegestaan dataverlies, altijd bij jou moet liggen. Die doelstellingen moeten vervolgens worden vertaald naar praktische afspraken met je dienstverleners, want ons brengt bij het volgende punt.

2. Heldere afspraken in je contracten en SLA’s

Je IT-dienstverlener kan veel bieden, maar niet alles is automatisch geregeld.

Heb je ooit je Service Level Agreements (SLA’s) en contracten kritisch onder de loep genomen? Het vastleggen van herstel- en escalatieprocedures lijkt misschien vanzelfsprekend, maar heb je echt controle over de details? Kun je echt vertrouwen op die standaardafspraken of is maatwerk hier een noodzaak?

Het is belangrijk om specifiek vast te leggen hoe herstel- en escalatieprocedures worden uitgevoerd, welke systemen worden beschermd, en hoe vaak deze procedures worden getest. Dit vraagt om helder geformuleerde contracten en SLA’s. En ja, ook om een duidelijke en regelmatige evaluatie van die afspraken. De afstemming over herstelprocessen mag geen vaag gebied zijn; het is een gebied waarin je als organisatie moet investeren in duidelijkheid en samenwerking.

3. Eigen toegang tot back-ups en immutable data

Wanneer je vertrouwt op een externe partij voor het beheren van back-ups, is het cruciaal dat deze back-ups gescheiden van de productienetwerken én onveranderbaar (immutable) zijn. Denk aan situaties waarin je IT-dienstverlener zelf (ook) getroffen is door een aanval. Heb je dan de toegang tot je eigen data om deze te herstellen? Neem geen genoegen met aannames. Weet je zeker dat je toegang hebt tot je eigen data in het geval van een cyberaanval bij je dienstverlener? Zorg ervoor dat dit zwart op wit staat en regelmatig wordt getest. Dit vraagt om een combinatie van technische oplossingen en goede contractuele afspraken.

4. Test regelmatig je herstelplannen samen met je leverancier

Testen is een essentieel onderdeel van elke Cyber Recovery-strategie. IT-dienstverleners bieden vaak standaard testmomenten aan, maar hoe relevant zijn deze voor jouw specifieke behoeften? En bovendien, biedt de IT-dienstverlener wel echt Cyber Recovery testen aan, of zijn dat vooral disaster recovery testen? Zorg dat je als organisatie zelf betrokken bent bij het uitvoeren en evalueren van tests. Dit is geen kwestie van wantrouwen, maar van zorgen dat je op elk moment weet wat er nodig is om weer snel en veilig operationeel te zijn.

5. Verantwoordelijkheid voor crisismanagement en communicatie blijft intern

Een snelle reactie bij een cyberaanval is van cruciaal belang. Terwijl externe partijen een rol kunnen spelen in technische ondersteuning en herstel, ligt de verantwoordelijkheid voor crisismanagement en communicatie altijd bij jouw organisatie. Jij bepaalt de communicatielijnen, de responsstrategie en de prioriteiten tijdens een crisis. Dienstverleners kunnen ondersteunen, maar ze zullen nooit de beslissingen nemen die jouw reputatie kunnen redden of breken. Zijn jouw teams klaar om de touwtjes in handen te nemen als het nodig is? Hebben ze geoefend voor deze scenario’s?

Heb jij je IT (groten)deels of volledig uitbesteed?

Het is tijd om af te stappen van de illusie dat Cyber Recovery volledig uitbesteed kan worden. De verantwoordelijkheid blijft bij jou, en dat is maar goed ook. Sta niet stil bij wat je nu hebt geregeld; stel jezelf de vraag of het genoeg is. Denk je dat jouw huidige strategie robuust genoeg is? Of is het tijd voor een nieuwe aanpak? Laten we dit samen uitzoeken en zorgen dat je niet alleen uit hoeft te gaan van vertrouwen, maar ook zeker kunt weten dat je voorbereid bent. Neem gerust contact op.

Afspraak maken voor een vrijblijvend gesprek? Bel me op 06 417 731 52 of mail naar toine@arcpeople.nl.

Waarom een sterk Cyber Recovery plan onmisbaar is

Cyberaanvallen raken ons steeds harder en frequenter, met vaak desastreuze gevolgen. Vraag je willekeurige AI-assistent om een lijst met recente cyber-aanvallen binnen je branche en binnen enkele seconden krijg je een vrijwel eindeloos overzicht. Bekende voorbeelden van cyberaanvallen zijn de ransomware-aanvallen de KNVB^[1], Universiteit Maastricht^[2] en Hof van Twente^[3].

De consequenties van deze incidenten? Wekenlange verstoringen van de dienstverlening en miljoenen euro’s aan (in)directe schade. Zulke incidenten laten zien dat het niet langer voldoende is om enkel te vertrouwen op preventie; organisaties moeten ook voorbereid zijn om snel en effectief te herstellen wanneer een aanval plaatsvindt.

Dit is waar Cyber Recovery om de hoek komt kijken. Maar wat houdt Cyber Recovery precies in, en hoe verschilt het van traditionele vormen van Disaster Recovery?

Wat is Cyber Recovery?

Cyber Recovery is het proces van herstellen na een cyberaanval die je data, systemen of bedrijfsprocessen compromitteert. Waar cybersecurity zich veelvuldig richt op het voorkomen van aanvallen, bereidt Cyber Recovery je organisatie voor op het snel en effectief herstellen nadat een aanval heeft plaatsgevonden. Het omvat een combinatie van technische, organisatorische en procesmatige maatregelen die ervoor zorgen dat je niet alleen weer snel operationeel bent, maar ook dat je data en systemen veilig en intact blijven.

Hoe verschilt Cyber Recovery van traditionele Disaster Recovery?

Hoewel zowel Cyber Recovery als traditionele Disaster Recovery gericht zijn op het herstel van kritieke systemen, zijn er belangrijke verschillen:

In tegenstelling tot traditionele Disaster Recovery, dat vaak draait om het fysiek herstellen van infrastructuur na een ramp of technische storingen (zoals hardware-falen), is Cyber Recovery gericht op het herstellen van systemen en data na een cyberaanval. Waar rampen, zoals een brand, en technische storingen vaak lokaal beperkt blijven, kunnen cyberaanvallen wereldwijd en gericht zijn, waarbij meerdere lagen van het netwerk van de gehele organisatie worden aangetast. Cyber Recovery vereist dan ook striktere herstelstrategieën zoals:

1. Immutable back-ups: Back-ups moeten ongewijzigd blijven (‘immutable’), zelfs na een succesvolle aanval.
2. Isolatie van operationele omgevingen: Cyber Recovery vereist isolatie van operationele (productie) omgevingen, zodat hackers geen toegang krijgen tot zowel de operationele als de Cyber Recovery systemen. Een zero trust architectuur, waarin elke toegang tot data, applicaties en systemen continu geverifieerd wordt, zelfs binnen je interne netwerken, kan daar aanvullend bij helpen.
3. Beschikbaarheid van de juiste forensische middelen: Omdat hackers vaak al lange tijd aanwezig kunnen zijn, zonder dat ze hun aanval daadwerkelijk uitvoeren, is het van groot belang dat de juiste forensische middelen beschikbaar zijn om sporen van de aanvaller(s) te signaleren en te verwijderen.

Waarom is Cyber Recovery cruciaal voor jouw organisatie?

Naast de toenemende frequentie en impact van cyberaanvallen, dwingt ook regelgeving organisaties om zich voor te bereiden op dergelijke incidenten. Denk aan de Europese NIS2-richtlijn^[4], die vanaf 17 oktober 2024 van kracht is, voor bedrijven in vitale sectoren en aan de Digital Operational Resilience Act (DORA)^[5], die vanaf 17 januari 2025 van kracht is voor financiële instellingen.

Het niet naleven van deze voorschriften kan op korte termijn leiden tot hoge boetes, juridische stappen en reputatieschade. De indirecte gevolgen kunnen ook enorm zijn: verhoogde verzekeringspremies, nieuwe IT-middelen en de noodzaak om extra (externe) expertise in te schakelen. In sommige gevallen kan dit zelfs leiden tot rechtszaken van klanten of partners, die ook aanzienlijke kosten met zich meebrengen.

Een goed doordacht Cyber Recovery plan minimaliseert niet alleen de operationele downtime en schade, maar beschermt ook de integriteit van je data en stelt je in staat te voldoen aan de wetgeving. Dit maakt het een essentieel onderdeel van je algehele bedrijfscontinuïteit.

Ben jij voorbereid?

Stel jezelf de vraag: (hoe snel) kan jouw organisatie herstellen na een cyberaanval? Ben je zeker dat jouw recovery-plan voldoet aan de laatste good practices en wetgeving? Het is nu de tijd om te evalueren of jouw huidige strategie voldoende is om een cyberaanval te doorstaan.

Wil je hulp bij het ontwikkelen of verbeteren van een Cyber Recovery plan? Neem vandaag nog contact met me op om te bespreken hoe we jouw organisatie weerbaarder kunnen maken tegen de cyberdreigingen van morgen. Bel of mail me gerust op 06 417 731 52 of via toine@arcpeople.nl.

In mijn volgende blog sta ik stil bij Cyber Recovery in een omgeving met (vooral) veel uitbestede IT. Want ook in die gevallen is verantwoordelijkheid niet volledig af te schuiven…

[1] KNVB betaalt losgeld aan hackers om vertrouwelijke gegevens te beschermen (nos.nl)

[2] Hoe een phishingmail in oktober met Kerst de universiteit platlegde (nos.nl)

[3] Heropbouw ict Hof van Twente na hack vergt 2,5 jaar – Computable.nl

[4] Richtlijn – 2022/2555 – EN – EUR-Lex (europa.eu)

[5] https://eur-lex.europa.eu/legal-content/NL/TXT/HTML/?uri=CELEX:32022R2554#d1e2483-1-1