Welke systemen moet je als eerste herstellen na een cyberincident?

Verkeerde herstelvolgorde na een cyberaanval vergroot schade — ontdek welke systemen prioriteit krijgen en waarom.

Technicus die een kritieke server herstelt in een donker datacenter, met gloeiende amber statusindicatoren op het serverrek.

Na een cyberincident staat één vraag centraal: hoe snel kun je weer operationeel zijn? Niet alles kan tegelijk hersteld worden, en in de praktijk is de volgorde van herstel net zo belangrijk als het herstel zelf. Een doordacht disaster recovery-plan bepaalt welke systemen als eerste online komen, hoeveel dataverlies acceptabel is en of je organisatie uren of weken stilstaat. Dit artikel geeft directe antwoorden op de vragen die IT-managers en directie stellen als het erop aankomt.

Wat zijn kritieke systemen binnen een organisatie?

Kritieke systemen zijn de digitale voorzieningen zonder welke een organisatie haar primaire bedrijfsprocessen niet kan uitvoeren. Denk aan identiteitsbeheer, communicatieplatforms, ERP-systemen, financiële applicaties en de infrastructuur die deze systemen draaiende houdt. Zonder deze systemen stopt de operatie, ongeacht hoe goed de rest van de IT-omgeving functioneert.

Wat precies kritiek is, verschilt per organisatie. Een logistiek bedrijf kan niet zonder zijn warehouse management systeem. Een financiële dienstverlener staat stil zonder zijn transactieverwerking. Een productiebedrijf met OT-omgevingen heeft andere kritieke assets dan een SaaS-bedrijf dat volledig in de cloud werkt.

Toch zijn er categorieën die voor vrijwel elke organisatie gelden:

Identiteit en toegang: Active Directory, Azure AD, MFA-systemen
Communicatie: e-mail, Microsoft 365, telefonie
Netwerk en connectiviteit: firewalls, DNS, VPN
Bedrijfsapplicaties: ERP, CRM, financiële systemen
Data en back-up: back-upoplossingen, data recovery-systemen

Het in kaart brengen van deze systemen is de eerste stap van elk serieus disaster recovery-traject. Zonder dit overzicht kun je geen herstelprioriteiten stellen.

Hoe bepaal je welke systemen het eerst hersteld moeten worden?

De volgorde van systeemherstel bepaal je op basis van de bedrijfsimpact van elk systeem. Systemen die direct bijdragen aan inkomsten, veiligheid of wettelijke verplichtingen krijgen prioriteit. Daarna volgen systemen die andere kritieke systemen ondersteunen, en ten slotte alles wat operationeel nuttig maar niet direct noodzakelijk is.

Een praktische aanpak is het uitvoeren van een Business Impact Analysis (BIA). Daarin stel je per systeem vast wat de gevolgen zijn van uitval na één uur, vier uur, één dag en één week. Die analyse levert een herstelprioriteit op die niet gebaseerd is op technische voorkeur, maar op zakelijke noodzaak.

Stel jezelf bij elk systeem de volgende vragen:

Kunnen medewerkers zonder dit systeem hun werk doen?
Heeft uitval directe impact op klanten of omzet?
Zijn er wettelijke of contractuele verplichtingen aan gekoppeld?
Zijn andere kritieke systemen afhankelijk van dit systeem?
Hoe lang duurt herstel van dit systeem?

De antwoorden op deze vragen bepalen de herstelprioriteit. Identiteitssystemen staan doorgaans bovenaan, omdat vrijwel alle andere systemen afhankelijk zijn van werkende authenticatie en toegangsbeheer. Zonder identiteit kun je ook andere systemen niet veilig herstellen.

Wat is het verschil tussen RTO en RPO bij systeemherstel?

RTO (Recovery Time Objective) is de maximale tijd die een systeem offline mag zijn na een incident. RPO (Recovery Point Objective) is het maximale dataverlies dat een organisatie accepteert, uitgedrukt in tijd. Samen bepalen RTO en RPO hoe snel je moet kunnen herstellen en hoe recent je back-ups moeten zijn.

Een voorbeeld: een RTO van vier uur betekent dat een systeem binnen vier uur na een incident weer operationeel moet zijn. Een RPO van één uur betekent dat je maximaal één uur aan data mag verliezen. Hoe strikter deze waarden, hoe zwaarder de eisen aan je back-upfrequentie, herstelinfrastructuur en testprocedures.

In de praktijk is het verleidelijk om voor alle systemen een lage RTO en RPO te willen. Maar dat brengt aanzienlijke kosten en complexiteit met zich mee. Daarom is het verstandig om RTO en RPO per systeem te differentiëren op basis van de eerder vastgestelde herstelprioriteiten. Kritieke systemen krijgen strikte waarden, ondersteunende systemen kunnen ruimere marges hebben.

Een goed disaster recovery-plan documenteert de RTO en RPO per systeem en koppelt hier concrete technische maatregelen aan. Denk aan back-upfrequentie, replicatie, failover-mogelijkheden en herstelscenario’s.

Welke systemen behoren tot de Minimum Viable Company?

De Minimum Viable Company (MVC) is de minimale set aan systemen, applicaties en processen die een organisatie nodig heeft om na een cyberincident operationeel te blijven of snel weer op te starten. Het gaat niet om volledig herstel, maar om het zo snel mogelijk hervatten van de meest kritieke bedrijfsactiviteiten in een schone, veilige omgeving.

De MVC verschilt per organisatie, maar bestaat doorgaans uit vier bouwstenen:

Identiteit: een werkende, schone identiteitsomgeving zodat medewerkers veilig kunnen inloggen
Communicatie: e-mail en basiscommunicatie om intern en extern te kunnen schakelen
Kernapplicaties: de twee of drie systemen zonder welke de primaire bedrijfsvoering stilvalt
Data: toegang tot recente, schone back-ups van bedrijfskritische gegevens

Het MVC-concept dwingt organisaties om vooraf na te denken over wat echt onmisbaar is. Dat is waardevoller dan het lijkt. In een crisissituatie is er geen tijd voor discussie. Als de MVC vooraf is vastgesteld, gedocumenteerd en getest, kunnen teams direct handelen zonder te wachten op besluitvorming. Meer over de Minimum Viable Company-aanpak lees je op onze dienstenpagina.

Waarom is de volgorde van systeemherstel zo belangrijk?

De volgorde van systeemherstel is cruciaal omdat een verkeerde volgorde herstel kan vertragen, nieuwe risico’s kan introduceren of zelfs aanvallers de kans kan geven om opnieuw toegang te krijgen. Systemen die worden hersteld voordat de omgeving schoon is, kunnen opnieuw gecompromitteerd raken.

Een veelgemaakte fout is het als eerste herstellen van productiesystemen zonder dat de identiteitsomgeving is gesaneerd. Als aanvallers nog toegang hebben via gecompromitteerde accounts of gestolen credentials, helpt het herstellen van servers weinig. De aanvaller zit er simpelweg opnieuw in.

De juiste volgorde volgt een logische opbouw:

Isoleer en saneer de identiteitsomgeving
Herstel netwerk- en beveiligingsinfrastructuur
Breng communicatiesystemen online
Herstel kernapplicaties op basis van schone back-ups
Valideer de integriteit van herstelde systemen vóór ingebruikname
Herstel ondersteunende systemen stapsgewijs

Bij elke stap geldt: herstel alleen wat noodzakelijk is en valideer voordat je verder gaat. Een solide cyber resilience-platform ondersteunt dit proces door herstel gestructureerd en controleerbaar te maken, ook onder tijdsdruk.

Hoe test je of je herstelplan echt werkt bij een cyberaanval?

Een herstelplan werkt alleen als het is getest onder realistische omstandigheden. De meest effectieve manier is een tabletop exercise of een gesimuleerde hersteltest waarbij teams daadwerkelijk de herstelstappen doorlopen, zonder dat de productieomgeving in gevaar komt. Een plan dat alleen op papier bestaat, is geen herstelplan.

Testen kan op meerdere niveaus:

Tabletop exercise: een scenariobespreking waarbij teams doorlopen wat ze doen bij een ransomware-aanval of data-exfiltratie
Technische hersteltest: het daadwerkelijk terugzetten van back-ups in een geïsoleerde omgeving om te valideren dat data intact en bruikbaar is
Volledig herstelscenario: een gesimuleerde crisis waarbij de MVC wordt opgebouwd alsof de productieomgeving volledig is uitgevallen

Wat je bij elke test wilt meten: haalt je team de vastgestelde RTO? Is de herstelde data volledig en betrouwbaar? Weten medewerkers wat hun rol is? Zijn er afhankelijkheden die je over het hoofd had gezien?

Testen is geen eenmalige activiteit. Omgevingen veranderen, teams wisselen en aanvallers passen hun methoden aan. Een jaarlijkse hersteltest is een minimum. Organisaties die serieus zijn over disaster recovery testen vaker en gebruiken de resultaten om hun plannen continu te verbeteren.

Hoe OpenSight helpt met disaster recovery en systeemherstel

Weten welke systemen je eerst moet herstellen is één ding. Het daadwerkelijk geregeld hebben is een ander. Wij helpen organisaties om van inzicht naar uitvoering te gaan, zodat je niet pas tijdens een incident ontdekt dat je plan tekortschiet.

Wat wij concreet voor je doen:

We brengen je kritieke systemen en afhankelijkheden in kaart via een risk assessment
We helpen je de Minimum Viable Company te definiëren en documenteren
We stellen realistische RTO- en RPO-waarden op per systeem, gebaseerd op jouw bedrijfsdoelstellingen
We implementeren en beheren back-up- en hersteloplossingen, onder andere via Commvault
We testen je herstelplan in gesimuleerde scenario’s en verbeteren het op basis van de uitkomsten
We ondersteunen je bij identiteitsherstel, zodat je omgeving schoon en veilig is voordat productiesystemen worden opgestart

Ons doel is dat je organisatie na een cyberincident herstelt in uren, niet in weken. Wil je weten hoe jouw huidige herstelplan ervoor staat? Vraag een risk assessment aan en ontdek waar de grootste kwetsbaarheden zitten.

Frequently Asked Questions

Hoe lang duurt een gemiddeld hersteltraject na een ransomware-aanval?

De hersteltijd na een ransomware-aanval varieert sterk en hangt af van de voorbereiding die een organisatie heeft getroffen. Zonder een getest disaster recovery-plan en een gedefinieerde Minimum Viable Company kan herstel weken tot maanden duren. Organisaties die wél beschikken over gedocumenteerde herstelplannen, schone back-ups en getrainde teams herstellen hun kritieke systemen doorgaans binnen enkele uren tot dagen. De investering in voorbereiding betaalt zich dus direct terug op het moment dat het er echt toe doet.

Wat als onze back-ups ook zijn getroffen door de aanval?

Dit is een van de meest gevreesde scenario's en helaas geen zeldzaamheid: aanvallers richten zich steeds vaker bewust op back-upsystemen om herstel te bemoeilijken. De oplossing zit in het toepassen van de 3-2-1-regel: minimaal drie kopieën van je data, op twee verschillende opslagmedia, waarvan één offsite of air-gapped is opgeslagen. Aanvullend bieden immutable back-ups — back-ups die na aanmaak niet meer gewijzigd of verwijderd kunnen worden — een sterke bescherming tegen ransomware die actief back-ups probeert te versleutelen of te wissen.

Hoe betrek je de directie bij het opstellen van een disaster recovery-plan?

Directiebetrokkenheid begint bij het vertalen van technische risico's naar zakelijke impact. Presenteer geen technische specificaties, maar laat zien wat een uitval van 24 of 48 uur concreet kost in omzet, reputatieschade en mogelijke boetes bij niet-naleving van regelgeving zoals NIS2 of AVG. Laat de directie actief meebeslissen over de RTO- en RPO-waarden per systeem, want die keuzes hebben directe budgettaire consequenties. Zo wordt disaster recovery een strategische prioriteit in plaats van een IT-onderwerp dat onder de radar blijft.

Welke veelgemaakte fouten zien jullie bij organisaties zonder getest herstelplan?

De meest voorkomende fout is het verwarren van een back-up hebben met herstelklaar zijn. Een back-up die nooit is getest, kan corrupt, incompleet of simpelweg te oud zijn om bruikbaar te zijn op het moment van een incident. Andere veelgemaakte fouten zijn: het ontbreken van een duidelijke eigenaar per systeem tijdens herstel, geen rekening houden met de volgorde van systeemherstel, en het niet documenteren van handmatige herstelstappen voor systemen die normaal geautomatiseerd werken. Al deze hiaten komen pas aan het licht tijdens een echte crisis — tenzij je ze eerder ontdekt via een hersteltest.

Is een disaster recovery-plan ook verplicht vanuit wet- en regelgeving?

Ja, steeds meer wet- en regelgeving verplicht organisaties expliciet tot aantoonbare herstelcapaciteit. De NIS2-richtlijn, die in Nederland via de Cyberbeveiligingswet wordt geïmplementeerd, stelt eisen aan business continuity en incidentrespons voor organisaties in essentiële en belangrijke sectoren. Ook de AVG vereist dat je persoonsgegevens kunt herstellen na een incident. Organisaties die onder DORA (Digital Operational Resilience Act) vallen — met name in de financiële sector — hebben bovendien specifieke verplichtingen rondom het testen van herstelplannen. Het niet kunnen aantonen van een werkend herstelplan kan leiden tot toezichthoudende handhaving en aanzienlijke boetes.

Hoe vaak moet je de RTO- en RPO-waarden per systeem herzien?

RTO- en RPO-waarden zijn geen statische getallen: ze moeten worden herzien zodra er significante wijzigingen plaatsvinden in de organisatie, het IT-landschap of de bedrijfsstrategie. Denk aan het introduceren van nieuwe bedrijfskritische applicaties, cloudmigraties, fusies of overnames, en wijzigingen in wet- en regelgeving. Als vuistregel geldt een formele herziening minimaal één keer per jaar, gecombineerd met een update na elk significant incident of grote infrastructuurwijziging. Verouderde RTO- en RPO-waarden geven een vals gevoel van veiligheid en leiden tot onderbemensing of onderdimensionering van herstelcapaciteit.

Kunnen kleinere organisaties ook een volwassen disaster recovery-plan opzetten, of is dat alleen weggelegd voor grote bedrijven?

Disaster recovery is zeker niet exclusief voor grote organisaties — en de gevolgen van een cyberincident zijn voor een kleinere organisatie vaak relatief zwaarder omdat er minder financiële buffer is om langdurige uitval op te vangen. Voor kleinere organisaties is het MVC-concept bijzonder waardevol: begin klein, identificeer de vijf tot tien systemen die echt onmisbaar zijn en bouw je herstelplan rondom die kern. Cloud-gebaseerde back-up- en hersteloplossingen maken professionele recovery bovendien toegankelijk zonder grote investeringen in eigen infrastructuur. Een externe partner zoals OpenSight kan hierbij helpen, ook voor organisaties zonder grote interne IT-teams.