Hoe documenteer je een herstelplan dat collega’s ook begrijpen?

Schrijf een herstelplan dat ook onder tijdsdruk uitvoerbaar is — met de juiste structuur en heldere stappen.

Herstelplan document op modern bureau met gekleurde sticky notes, collega die meekijkt in lichte Nederlandse werkomgeving.

Een herstelplan documenteer je door het te schrijven voor de mensen die het straks moeten uitvoeren, niet voor de mensen die het hebben bedacht. Dat betekent: geen technisch jargon, geen aannames over voorkennis, en een structuur die ook werkt als er tijdsdruk is. De secties hieronder geven concrete antwoorden op de meest gestelde vragen over disaster recovery documentatie.

Waarom begrijpen collega’s een herstelplan vaak niet?

Collega’s begrijpen een herstelplan vaak niet omdat het is geschreven door en voor technici, terwijl de uitvoering in de praktijk ook bij andere medewerkers terechtkomt. Het plan gebruikt vakjargon, verwijst naar systemen zonder context, en gaat ervan uit dat de lezer al weet wat er moet gebeuren en waarom.

Een IT-manager kent de omgeving van binnen en buiten. Daardoor is het verleidelijk om stappen samen te vatten of te verwijzen naar documentatie die ergens op een netwerkschijf staat. Maar op het moment dat iemand anders het plan moet uitvoeren, is die achtergrondkennis er niet. Het resultaat is een document dat technisch klopt, maar in de praktijk onbruikbaar is.

Een goed herstelplan schrijf je alsof de uitvoerende persoon de situatie nog nooit heeft meegemaakt en er geen tijd is om vragen te stellen. Dat is het uitgangspunt dat de kwaliteit van disaster recovery documentatie het meest verbetert.

Wat moet er minimaal in een herstelplan staan?

Een herstelplan voor een cyberincident of IT-verstoring bevat minimaal: een overzicht van kritieke systemen en applicaties, duidelijke rollen en verantwoordelijkheden, contactgegevens van betrokkenen, stapsgewijze herstelstappen per systeem, en criteria om te bepalen wanneer het herstel geslaagd is.

Veel organisaties hebben een plan dat te algemeen is. Het beschrijft het proces op hoofdlijnen, maar mist de operationele details die nodig zijn om daadwerkelijk te handelen. Denk daarbij aan:

Welke systemen zijn bedrijfskritisch en in welke volgorde worden die hersteld?
Wie is verantwoordelijk voor welk onderdeel van het herstel?
Waar staan back-ups, en hoe worden die teruggezet?
Welke externe partijen moeten worden ingeschakeld, en hoe bereik je die?
Wat zijn de acceptabele hersteltijden per systeem (RTO) en hoeveel dataverlies is acceptabel (RPO)?

Het concept van de Minimum Viable Company helpt hierbij: bepaal eerst wat de minimale set aan systemen en processen is die de organisatie operationeel houdt. Dat geeft prioriteit aan wat er in het herstelplan als eerste moet staan.

Hoe schrijf je herstelstappen die iedereen kan uitvoeren?

Herstelstappen schrijf je zo dat iemand zonder voorkennis ze stap voor stap kan volgen. Gebruik korte zinnen, actieve werkwoorden, en vermijd afkortingen zonder uitleg. Elke stap beschrijft één handeling, met het verwachte resultaat erbij zodat de uitvoerende persoon weet of het gelukt is.

Een goede manier om te testen of stappen begrijpelijk zijn: laat iemand buiten het IT-team het plan doorlezen. Waar die persoon vastloopt of vragen heeft, is de tekst nog niet concreet genoeg. Dit klinkt eenvoudig, maar in de praktijk slaan veel organisaties deze stap over.

Enkele praktische schrijfregels voor herstelstappen:

Begin elke stap met een werkwoord: “Open”, “Controleer”, “Start opnieuw op”
Schrijf het verwachte resultaat erbij: “Na deze stap is het systeem bereikbaar via het netwerk”
Voeg screenshots of verwijzingen naar handleidingen toe waar dat helpt
Geef aan wat te doen als een stap niet werkt

Welke structuur werkt het beste voor een herstelplan?

De meest werkbare structuur voor een IT-herstelplan combineert een algemeen deel met systeemspecifieke bijlagen. Het algemene deel beschrijft het proces, de rollen en de communicatieafspraken. De bijlagen bevatten de technische herstelstappen per systeem of applicatie, zodat uitvoerenden direct naar het relevante onderdeel kunnen gaan.

Een bewezen opbouw voor business continuity documentatie ziet er als volgt uit:

Doel en scope — wat dekt het plan, en wat niet?
Rollen en verantwoordelijkheden — wie doet wat, inclusief vervangers
Contactenlijst — intern en extern, inclusief leveranciers en partners
Overzicht kritieke systemen — met RTO en RPO per systeem
Algemene herstelprocedure — het stappenproces op hoofdlijnen
Systeemspecifieke bijlagen — gedetailleerde stappen per applicatie of omgeving
Testresultaten en versiehistorie — wanneer is het plan getest en wat is er aangepast?

Door het plan modulair op te bouwen, kun je bijlagen aanpassen zonder het hele document te herschrijven. Dat maakt onderhoud een stuk eenvoudiger.

Wie moet het herstelplan reviewen en goedkeuren?

Een herstelplan moet worden gereviewd door zowel de mensen die het hebben geschreven als de mensen die het moeten uitvoeren. Daarnaast is goedkeuring van de directie of een eindverantwoordelijke nodig, zodat het plan ook formeel is vastgesteld en de bijbehorende middelen beschikbaar zijn.

In de praktijk betekent dit minimaal drie reviewrondes. De technische review controleert of de stappen kloppen. De operationele review kijkt of het plan uitvoerbaar is voor de mensen die het straks in handen krijgen. De bestuurlijke goedkeuring bevestigt dat de organisatie achter het plan staat en dat er capaciteit en budget is om het te onderhouden.

Voor organisaties die werken met een externe CISO of CTO is dit ook een logisch moment om die betrokken te houden. Zij kunnen beoordelen of het plan aansluit op bredere governance- en compliancevereisten, zoals die vanuit NIS2 of ISO 27001.

Hoe zorg je dat het herstelplan actueel blijft?

Een herstelplan blijft actueel door het te koppelen aan vaste momenten: bij wijzigingen in de IT-omgeving, na een test of oefening, en minimaal één keer per jaar als onderdeel van een reviewcyclus. Zonder die koppeling veroudert het plan stiller dan verwacht.

De meest voorkomende reden dat herstelplannen verouderen, is dat ze worden behandeld als een eenmalig project in plaats van een levend document. Systemen veranderen, mensen vertrekken, applicaties worden vervangen. Als het plan dat niet bijhoudt, klopt het op het moment dat je het nodig hebt niet meer.

Praktische maatregelen om het plan actueel te houden:

Wijs een eigenaar aan die verantwoordelijk is voor het onderhoud
Voeg een vervaldatum toe aan het document zodat review verplicht is
Test het plan minimaal één keer per jaar met een tabletop-oefening of praktijktest
Koppel het plan aan je cyber resilience platform zodat wijzigingen in de omgeving direct zichtbaar zijn

Een getest plan is altijd beter dan een perfect geschreven plan dat nooit is uitgeprobeerd. Testen onthult hiaten die je bij het schrijven niet ziet.

Hoe wij helpen bij het documenteren van een herstelplan

Wij helpen organisaties om van een globaal idee over herstel naar een werkbaar, gedocumenteerd en getest plan te komen. Dat begint met het in kaart brengen van kritieke systemen en processen, inclusief de hersteltijden en afhankelijkheden die daarbij horen. Vanuit dat overzicht bouwen we een herstelplan op dat aansluit op de werkelijkheid van de organisatie, niet op een generieke template.

Waar nodig combineren we dat met technische maatregelen op het gebied van back-up, recovery en identiteitsbeveiliging, zodat het plan ook daadwerkelijk uitvoerbaar is. Wil je weten waar je nu staat en wat de volgende stap is? Vraag een risk assessment aan en we kijken samen naar de staat van jouw herstelplan en digitale weerbaarheid.