---
title: "Restore-test na ransomware: kun je echt schoon herstellen?"
date: 2026-03-23
author: "Redactie Ransomware Simulator"
---

# Restore-test na ransomware: kun je echt schoon herstellen?

Herstel onder druk

## Restore-test na ransomware: kun je echt schoon herstellen?

Een restore-test na ransomware gaat niet alleen over of er een back-up bestaat, maar over of je onder druk schoon, volledig en in de juiste volgorde kunt terugkomen.

Deze pagina helpt je bepalen wat je in een hersteltest echt wilt bewijzen voordat een echt incident dat voor je doet.

[Ga naar identity-herstel](/identity-access-en-herstelvolgorde/)[Bekijk het incidentresponsplan](/incidentresponsplan-ransomware/)

- Voor IT, beheer, security en proceseigenaren
- Richt zich op schone restore, prioriteit en afhankelijkheden
- Gaat over herstel onder druk, niet over papieren back-upzekerheid



**Kort antwoord:** een restore-test is pas geslaagd als je kunt laten zien welke systemen eerst terugkomen, hoe je schoon herstelt, welke afhankelijkheden meespelen en hoe lang dat in de praktijk kost. Een back-up hebben is daarvoor niet genoeg.

## De vraag die je eigenlijk wilt beantwoorden

Niet of er ergens een kopie bestaat, maar of je na ransomware echt gecontroleerd terug kunt komen. Kun je de juiste systemen eerst herstellen, weet je welke data en configuraties nodig zijn en is de omgeving schoon genoeg om weer op te bouwen zonder nieuw risico te introduceren?

Dat is de vraag waar veel teams pas in een echt incident achter komen. Daarom is restore-testen een aparte oefenlaag en geen voetnoot bij back-upbeheer.

## Waar restore-tests in de praktijk op stuklopen

Restore faalt zelden op één groot punt. Vaker gaat het mis op de randen: een cruciale afhankelijkheid ontbreekt, credentials zijn niet beschikbaar, een golden image is verouderd, een SaaS-koppeling vertrouw je nog niet of een back-up blijkt technisch aanwezig maar operationeel onbruikbaar.

Juist daarom wil je een restore-test zo opzetten dat hij niet alleen data terugzet, maar ook blootlegt waar de echte blokkades zitten.

- welk systeem, proces of klantkanaal als eerste terug moet komen
- welke data, images, scripts en configuraties echt nodig zijn voor bruikbaar herstel
- welke identity-, MFA- of leveranciersafhankelijkheden het tempo kunnen blokkeren
- hoe je bepaalt dat een omgeving schoon genoeg is om weer op te bouwen
- hoe lang herstel werkelijk duurt in plaats van hoeveel tijd je op papier dacht nodig te hebben

## Een realistisch mini-scenario

Stel: de back-up is bruikbaar, maar de identiteitslaag is nog niet vertrouwd, een kritieke koppeling loopt via een externe partij en het bestuur wil weten welke dienst als eerste weer live kan. Dan merk je direct dat restore geen simpele technische handeling is, maar een keten van keuzes.

Dat is precies waarom je herstel vooraf wilt oefenen: zodat volgorde, eigenaarschap en veiligheidsgrenzen niet pas tijdens het echte incident ontstaan.

- ### 1. Prioriteit
    
    Bepaal welke dienst of omgeving als eerste terug moet komen en wie die keuze formeel maakt.
- ### 2. Schone bron
    
    Test of images, back-ups, configuraties en scripts echt bruikbaar zijn voor veilige wederopbouw.
- ### 3. Afhankelijkheden
    
    Controleer welke directory-, MFA-, cloud- of leverancierslagen herstel direct vertragen.
- ### 4. Werkelijke hersteltijd
    
    Meet hoe lang herstel echt duurt inclusief checks, handoffs en besluitmomenten.

## Veelgemaakte fout: alles tegelijk willen terugzetten

Onder druk klinkt het logisch om zo veel mogelijk tegelijk te herstellen. In de praktijk creëert dat juist ruis: teams jagen dezelfde prioriteiten na, afhankelijkheden blijven onzichtbaar en niemand weet meer welke dienst eerst echt nodig was.

Een sterke restore-test dwingt daarom volgorde af. Niet alles tegelijk, maar eerst wat veilig en bedrijfskritisch als eerste terug moet komen.

## Restore werkt alleen samen met identity, leveranciers en plan

Een technisch hersteltestje zonder identity, leveranciers of eigenaarschap blijft te smal. Zodra MFA, adminrechten, cloudbeheerders of proceseigenaren meespelen, verandert restore in een bestuurlijk en operationeel spoor.

Daarom hoort herstel altijd gekoppeld te zijn aan identity, leveranciers en het incidentresponsplan. Anders test je slechts een deel van het echte probleem.

- Bekijk [incidentresponsplan ransomware](/incidentresponsplan-ransomware/) als rollen en herstelprioriteiten nog niet scherp genoeg zijn
- Lees [identity, access en herstelvolgorde](/identity-access-en-herstelvolgorde/) voor accounts en privileged access
- Open [leveranciers en incidentrespons](/leveranciers-en-incidentrespons-bij-ransomware/) voor MSP-, cloud- en verzekeringsafhankelijkheden
- Gebruik [tabletop](/tabletop-oefening-voor-ransomware/) als je herstelkeuzes eerst bestuurlijk wilt toetsen
- Gebruik [de FAQ](/faq-ransomware-simulatie/) voor korte antwoorden op restore- en back-upvragen

- [CISA: #StopRansomware Guide](https://www.cisa.gov/stopransomware/ransomware-guide)
- [NCSC: Incidentresponsplan Ransomware](https://www.ncsc.nl/documenten/publicaties/2022/juni/3/incidentresponsplan-ransomware)
- [DTC: Wat te doen bij een ransomware-aanval?](https://www.digitaltrustcenter.nl/menu/informatie-advies/ransomware/wat-te-doen-bij-een-ransomware-aanval)



## Waarom een restore-test anders is dan een back-upcheck

Een back-upstrategie geeft pas rust als je weet dat herstel ook onder druk werkt. Bij ransomware is de vraag niet alleen of er een kopie bestaat, maar of die kopie schoon is, wie toegang mag gebruiken en welk proces als eerste terug mag. Een restore-test maakt die keuzes zichtbaar voordat klanten, medewerkers of leveranciers wachten op duidelijkheid.

Begin met één kritisch proces. Noteer welke systemen, accounts, leveranciers en afhankelijkheden nodig zijn. Test daarna of de gekozen back-up in een afgescheiden omgeving terugkomt en welke controles nodig zijn voordat gebruikers opnieuw toegang krijgen. Zo voorkom je dat hersteltempo belangrijker wordt dan bewijs.

Gebruik de herstelprioriteit-tool op deze pagina om systemen te ordenen op impact, identity-risico, back-upbewijs en externe afhankelijkheden. Combineer de uitkomst met de [scenario-keuzehulp](/ransomware-check/) als je de restore-test wilt verwerken in een bredere tabletop-oefening.