Vrijwel iedere organisatie heeft een back-up. Maar hoeveel hebben een bewijs dat kritieke systemen binnen de afgesproken tijd schoon terugkomen?
Als een ransomware-aanval het nieuws haalt, gaat het over de aanval. In de bestuurskamer begint het probleem daarna: hoe snel kunnen mensen weer werken, kunnen we klanten nog helpen, en wanneer draaien onze primaire processen weer?
De vraag is in vijf jaar tijd verschoven van “hebben we een back-up?” naar “hoe snel zijn onze processen weer op de been, en waar blijkt dat uit?”
Cyber recovery is het geheel van maatregelen, procedures en tests waarmee je systemen en gegevens herstelt na een cyberaanval, zodanig dat je kunt onderbouwen dat het herstelde systeem veilig terug kan naar productie. Het verschil met gewoon herstel zit in één woord: vertrouwen. Na een technische storing zoek je het meest recente werkende herstelpunt. Na een aanval moet je eerst vaststellen welke herstelpunten je überhaupt kunt vertrouwen. Een aanvaller die drie weken in je omgeving zat, zit ook in je back-ups van drie weken oud.
Cyber recovery is daarmee de scherpste vorm van data resilience: het punt waarop blijkt of alle voorgaande maatregelen daadwerkelijk werken.
Deze twee worden vaak door elkaar gebruikt, en dat leidt tot verkeerde verwachtingen. Een disaster recovery-plan dekt geen ransomware-aanval, hoe goed het ook is.
De consequentie
Als je disaster recovery-plan uitgaat van “we zetten de laatste back-up terug”, dan heb je geen cyber recovery-plan.
Er zijn drie ontwikkelingen die dit onderwerp van de serverruimte naar de bestuurstafel hebben verplaatst.
Het versleutelen van productiedata is niet meer genoeg. Wie zeker wil zijn van betaling, zorgt eerst dat herstel onmogelijk is. Back-upomgevingen zijn daarmee een primair doelwit geworden in plaats van een vangnet.
De Cyberbeveiligingswet, de Nederlandse implementatie van NIS2, treedt op 15 augustus 2026 in werking. De kern van die verschuiving is niet dat organisaties meer maatregelen moeten nemen, maar dat zij de werking ervan moeten kunnen aantonen. Wij schreven eerder waarom NIS2 vraagt om aantoonbare cyberweerbaarheid.
Klanten, verzekeraars en auditors vragen niet langer of je een herstelplan hebt. Ze vragen om de uitkomst van je laatste test.
Vraag in de bestuurskamer
Niet: zijn onze back-ups geslaagd? Maar: welk herstelpunt vertrouwen we, en hoe weten we dat systemen schoon terugkomen?
Vrijwel elke organisatie werkt met hersteldoelstellingen. De RTO, Recovery Time Objective, beschrijft hoe lang herstel maximaal mag duren. De RPO, Recovery Point Objective, beschrijft hoeveel gegevensverlies acceptabel is.
Op papier zijn die cijfers helder. Hun onderbouwing is dat zelden. Hersteldoelstellingen worden meestal vastgelegd bij een implementatie en verhuizen daarna mee in documenten, terwijl de omgeving eronder verandert: nieuwe applicaties, andere koppelingen, meer data, een migratie naar de cloud.
Een RTO van vier uur is geen feit. Het is een doelstelling. Het wordt pas een feit op het moment dat een systeem onder realistische omstandigheden binnen vier uur schoon is hersteld, en je dat hebt vastgelegd.
Cyber recovery voegt daar een tweede vraag aan toe: is het herstelde systeem voldoende gecontroleerd voordat het terugging naar productie?
Een cyber recovery-test is een gecontroleerde oefening waarin je vaststelt of systemen na een cyberincident binnen de afgesproken tijd en in veilige staat terug kunnen naar productie. Zo’n test gaat verder dan het terugzetten van data. Hij legt afhankelijkheden, ontbrekende kennis en beslismomenten bloot.
De vragen die tijdens zo’n test bijna altijd naar boven komen:
Een back-uprapport beantwoordt geen van deze vragen. Zo’n rapport bewijst dat een taak is uitgevoerd. Het bewijst niet dat een volledig systeem terugkomt, dat gekoppelde systemen daarna nog werken, of dat de omgeving schoon is.
Let op
Duurt een herstel zeven uur in plaats van vier? Dat is geen slecht resultaat, dat is bruikbare informatie. Je kunt het proces verbeteren of de doelstelling bijstellen. Beide zijn beter dan sturen op een getal dat nooit is gecontroleerd.
Bij cyber recovery draait herstel niet alleen om beschikbaarheid. Je moet voorkomen dat je met het herstel ook het probleem terugzet: schadelijke bestanden, aangepaste configuraties, gecompromitteerde accounts, achtergelaten toegang.
Een goede test beantwoordt daarom twee losse vragen. Kunnen we dit systeem binnen de afgesproken tijd terugbrengen? En kunnen we onderbouwen dat het schoon terugkomt?
Je hebt ze allebei nodig. Snel herstellen zonder controle betekent dat je het incident kunt herhalen. Uitputtend controleren zonder werkbare herstelvolgorde betekent dat de stilstand onnodig lang duurt.
Dat vraagt om afspraken die je vooraf vastlegt: wat controleer je, wie beoordeelt de uitkomst, en wie besluit dat een systeem terug mag. Die afspraken maak je niet tijdens een incident. Het Nationaal Cyber Security Centrum beschrijft de herstelfase om die reden als een eigen fase met eigen besluitvorming, niet als het staartje van de responsfase.
Bestuurders hoeven de techniek niet te kennen. Ze moeten kunnen uitleggen wat uitval betekent voor de organisatie, en waarop dat gebaseerd is. Dat komt neer op vijf vragen.
Komt het antwoord uit een testverslag, dan is je cyber recovery aantoonbaar. Komt het uit een plan, een leveranciersbelofte of een project van twee jaar geleden, dan weet je het nog niet.
Zelf checken
Kun je deze vijf vragen niet allemaal beantwoorden? Dan zit je in gezelschap. De Cyber Resilience Assessment loopt ze in 10 vragen met je door.
Geen van deze vragen is alleen door IT te beantwoorden. Cyber recovery raakt security, applicatiebeheer, continuïteitsmanagement en de eigenaren van de primaire processen. Als die rollen pas tijdens een incident bij elkaar komen, kost dat uren die je niet hebt.
De aanleiding voor een eerste hersteltest is vaak extern: een audit, een klantvraag, een verzekeraar. Dat is prima als vertrekpunt, maar het is niet waar de waarde zit. De waarde zit in wat je ontdekt. In de praktijk is dat bijna altijd hetzelfde:
Dat wil je ontdekken op een dinsdagochtend tijdens een geplande test, niet op het moment dat je omgeving plat ligt. Hoe dat er in de praktijk uitziet, staat in onze klantcases.
Organisaties worden niet weerbaarder doordat er een herstelplan ligt. Ze worden weerbaarder doordat ze hun aannames testen.
Eén vraag legt het meeste bloot: wanneer is voor het laatst aangetoond dat een kritiek systeem binnen de afgesproken hersteltijd schoon terug kon naar productie, en waar blijkt dat uit?
Kijk daarna naar de scope, want die bepaalt wat je conclusie waard is. Eén bestand terugzetten is iets anders dan een applicatie herstellen. Eén applicatie herstellen bewijst niet dat gekoppelde systemen daarna nog werken. Een technische component testen bewijst niet dat een primair proces kan hervatten.
Een test die niet verder komt dan een bestand, levert een conclusie op die niet verder komt dan een bestand.
Back-ups blijven noodzakelijk. Binnen cyber recovery zijn ze alleen niet het doel maar de grondstof. De relevante vraag is niet of de gegevens er zijn, maar of je kritieke systemen binnen de afgesproken tijd schoon terugkomen.
Dat kun je niet plannen. Dat moet je uitvoeren, controleren, meten en vastleggen.
Cyber recovery is het herstellen van systemen en gegevens na een cyberaanval, waarbij je naast beschikbaarheid ook controleert dat er niets van de aanval mee terugkomt. Denk aan schadelijke bestanden, aangepaste configuraties of gecompromitteerde accounts. Het combineert technisch herstel met validatie: een systeem is pas hersteld als je kunt onderbouwen dat het veilig terug kan naar productie.
Disaster recovery richt zich op herstel na verstoringen als technische uitval, brand of menselijke fouten, en draait om beschikbaarheid. Cyber recovery richt zich op herstel na een gerichte aanval en draait om beschikbaarheid én betrouwbaarheid. Het grote verschil zit in het herstelpunt: bij disaster recovery zoek je het meest recente werkende punt, bij cyber recovery het meest recente punt waarvan je weet dat het niet besmet is.
Een cyber recovery-test is een gecontroleerde oefening waarin je vaststelt of systemen na een cyberincident binnen de afgesproken tijd en in veilige staat terug kunnen naar productie. De test maakt werkelijke hersteltijden zichtbaar, plus technische afhankelijkheden, verouderde documentatie en de controles die nodig zijn. Resultaten, afwijkingen en verbeterpunten leg je vast, zodat je ze kunt aantonen aan een auditor of klant.
Een back-uprapport bewijst dat een back-uptaak is uitgevoerd. Het bewijst niet dat een volledig systeem terugkomt, dat gekoppelde systemen daarna functioneren, of dat het herstelpunt vrij is van sporen van een aanval. Een test controleert die drie dingen wel, en levert een gemeten hersteltijd op in plaats van een aangenomen hersteltijd.
Schoon herstellen betekent dat je controleert of schadelijke bestanden, ongewenste configuratiewijzigingen of achtergelaten toegang niet meeliften met het herstel. Welke controles daarvoor nodig zijn hangt af van het incident en de omgeving. Het uitgangspunt is dat een systeem pas hersteld is wanneer je kunt onderbouwen dat het veilig terug kan, niet wanneer het weer draait.
Cyber recovery is geen taak van alleen IT. De uitvoering ligt bij IT en security, maar de eigenaren van de primaire processen bepalen welke systemen als eerste terug moeten, en het bestuur is eindverantwoordelijk voor de aantoonbaarheid. Sinds de Cyberbeveiligingswet ligt die verantwoordelijkheid ook persoonlijk bij de leiding. Leg daarom vooraf vast wie welke beslissing neemt tijdens een herstel.
Begin bij de systemen die je primaire processen dragen, en werk van daaruit terug naar wat die systemen nodig hebben: applicaties, databases, identiteitsvoorzieningen en netwerkcomponenten. Test niet alleen losse onderdelen. Juist de herstelvolgorde en de onderlinge afhankelijkheden bepalen of een systeem na herstel daadwerkelijk bruikbaar is voor het proces eromheen.
De Cyberbeveiligingswet is de Nederlandse implementatie van de NIS2-richtlijn en treedt op 15 augustus 2026 in werking. De wet verplicht organisaties in aangewezen sectoren tot passende maatregelen voor onder meer bedrijfscontinuïteit en back-upbeheer, en tot het kunnen aantonen daarvan. Controleer bij het NCSC of jouw organisatie onder de wet valt en wat je registratieverplichting is.
