Een IT-herstelplan (DRP, disaster recovery plan) is het gedocumenteerde geheel van procedures waarmee een organisatie haar IT na een groot incident (brand, uitval van de infrastructuur, cyberaanval) opnieuw kan opstarten binnen een hersteltijd en met een maximaal gegevensverlies die vooraf met de business zijn afgesproken: de RTO en de RPO. Het legt vast wat moet worden hersteld, in welke volgorde, door wie, vanaf welke back-ups en op welke infrastructuur.
Veel IT-herstelplannen werden geschreven voor een brand in de serverruimte. Het dominante scenario vandaag is ransomware die de productie versleutelt, de back-ups viseert en de directory compromitteert. Deze gids toont hoe u een IT-herstelplan opbouwt, test en aantoont dat in beide gevallen standhoudt.
De versie in 30 seconden
- Een IT-herstelplan herstart de IT; een bedrijfscontinuïteitsplan houdt de activiteiten draaiende. Het DRP maakt deel uit van het BCP en vervangt het niet.
- De hersteldoelstellingen komen uit de BIA: elk systeem erft de strengste RTO van de processen die ervan afhangen.
- De herstelvolgorde is even belangrijk als de snelheid: identiteit, DNS en back-upinfrastructuur komen vóór de bedrijfsapplicaties.
- Tegen ransomware biedt alleen een offline of onveranderlijke kopie, hersteld in een schone omgeving, een betrouwbaar vertrekpunt.
- DORA eist dat herstelplannen minstens jaarlijks worden getest; NIS2 vermeldt uitdrukkelijk back-upbeheer en noodherstel.
Wat is een IT-herstelplan en hoe verschilt het van een BCP?
Een IT-herstelplan dekt de technische kant van de continuïteit: infrastructuur, applicaties, gegevens, netwerken, identiteiten. Het vertrekt van één veronderstelling: de dienst ligt stil. Zijn taak is die binnen de afgesproken tijd terug te brengen, met aanvaardbaar gegevensverlies, zonder de oorzaak van de uitval opnieuw binnen te halen.
| Plan | Vraag die het beantwoordt | Voorbeeld |
|---|---|---|
| BCP — bedrijfscontinuïteitsplan | Hoe blijven we klanten bedienen tijdens de verstoring? | Bestellingen aangenomen in degraded mode |
| DRP — IT-herstelplan | Hoe herstarten we de IT, en in welke volgorde? | ERP hersteld vanaf een offline kopie |
| IT-continuïteit / hoge beschikbaarheid | Hoe voorkomen we dat de IT überhaupt uitvalt? | Database gerepliceerd over twee datacenters |
Het BCP is de overkoepelende paraplu; het DRP en het ontwerp voor hoge beschikbaarheid zijn de technische bouwstenen ervan. Een DRP zonder BCP laat de businessteams zonder instructies terwijl de systemen worden hersteld; een BCP zonder DRP belooft een herstel dat niemand weet uit te voeren. De volledige methode vindt u in onze gids over het bedrijfscontinuïteitsplan.
Wat bevat een IT-herstelplan?
Een bruikbaar IT-herstelplan is leesbaar onder stress en uitvoerbaar door plaatsvervangers. Zes onderdelen volstaan.
1. Toepassingsgebied en scenario's
Sites, platformen (datacenter, cloud, SaaS) en scenario's: verlies van een site, van een cloudregio, van de directory, versleutelde of beschadigde gegevens, uitval van een leverancier.
2. Inventaris van systemen, gerangschikt per tier
Elk systeem erft de strengste RTO en RPO van de bedrijfsprocessen die ervan afhangen, zoals vastgelegd in de BIA. Systemen in tiers groeperen vereenvoudigt beslissingen over strategie en budget:
| Tier | Voorbeelden | Doel-RTO | Doel-RPO |
|---|---|---|---|
| 0 — Fundamenten | Directory, DNS, netwerk, back-up, kluis voor secrets | Vóór al de rest | Laatste schone kopie |
| 1 — Kritiek | Betalingen, orderinname, productie | Minder dan 4 u | Minder dan 15 min |
| 2 — Belangrijk | CRM, loonadministratie, logistiek | 24 u | 4 u |
| 3 — Uitstelbaar | Intranet, rapportering, archieven | Meerdere dagen | 24 u |
Deze waarden zijn illustratief: de uwe moeten uit de BIA komen. Tier 0 heeft geen "business-RTO", maar zonder deze tier start niets opnieuw op. Om te kalibreren: RTO vs RPO uitgelegd en de RTO/RPO-calculator.
3. Afhankelijkheden en herstelvolgorde
Het onderdeel dat het vaakst ontbreekt. Het Franse nationale cyberbeveiligingsagentschap, ANSSI, raadt aan een herstelvolgorde te bepalen die rekening houdt met de afhankelijkheden van infrastructuurdiensten (DNS, NTP, directory), de kriticiteit van applicaties en de hersteltijden. In de praktijk: een herstelgraaf waarin elk systeem zijn voorvereisten en zijn controles heeft.
4. Rollen en beslissingsbevoegdheden
Wie roept de ramp uit, wie beslist over de failover, wie keurt de terugkeer naar productie goed? Benoemde eigenaars en plaatsvervangers, bereikbaar buiten de bedrijfs-IT om. Een failover betekent het verlies van alle gegevens die nog niet zijn gerepliceerd, dus de beslissing ligt bij een aangewezen persoon, op basis van schriftelijke criteria.
5. Runbooks en communicatie
Eén runbook per systeem: voorvereisten, stappen, waar de back-ups en encryptiesleutels zich bevinden, break-glass-accounts, de duur gemeten bij de laatste test, alles offline beschikbaar. Voeg berichten toe voor businessteams, klanten en, als het incident meldingsplichtig is, toezichthouders (zie NIS2-incidentmelding: 24 u, 72 u en 1 maand).
6. Failback
De terugkeer naar de primaire infrastructuur is een tweede omschakeling: hersynchronisatie van gegevens, integriteitscontroles en afstemmingen (DORA eist die uitdrukkelijk na een ICT-gerelateerd incident), goedkeuring door de business, formele afsluiting.
Ons sjabloon voor een IT-herstelplan volgt deze structuur.
Welke herstelstrategie kiest u?
Vier herstelstrategieën dekken de meeste gevallen. Hoe korter de RTO, hoe hoger de factuur:
| Strategie | Principe | Haalbare RTO (indicatief) | Kost | Let op |
|---|---|---|---|---|
| Back-up en herstel | Infrastructuur heropgebouwd wanneer de ramp toeslaat | Uren tot dagen | Laag | Heropbouw duurt meestal langer dan gepland |
| Pilot light | Gegevens gerepliceerd, minimale kern actief, applicatieservers uit | Tientallen minuten tot uren | Gemiddeld | De omgeving op de dag zelf opstarten en opschalen |
| Warm standby | Afgeslankte maar actieve kopie van de productie | Minuten | Hoog | Opschaling, quota, licenties op de herstelsite |
| Multi-site active-active | Meerdere sites verwerken permanent verkeer | Bijna nul | Zeer hoog | Gegevenscorruptie verspreidt zich overal |
Twee fouten komen steeds terug. De eerste is replicatie verwarren met back-up. Replicatie kopieert een kwaadwillige verwijdering of een versleuteling binnen enkele seconden naar de herstelsite; alleen een point-in-time-back-up die buiten bereik wordt bewaard, laat u toe terug te gaan. Zelfs active-active heeft back-ups nodig. De tweede is een strategie kiezen op basis van technische voorkeur in plaats van op basis van de BIA. De kostenraming voor herstel helpt om de afweging expliciet te maken.
Back-ups: volstaat de 3-2-1-regel?
In zijn gids Sauvegarde des systèmes d'information – Les fondamentaux (versie 1.1, november 2025) beveelt ANSSI de 3-2-1-regel aan: drie afzonderlijke kopieën van de gegevens (productie plus twee back-ups), op verschillende media, waarvan één offline. Het agentschap acht een offline kopie onmisbaar, ook al is ze minder frequent. Onveranderlijke (WORM) kopieën zijn een aanvaardbaar compromis voor frequente back-ups, waarbij offline robuuster blijft. Leveranciers spreken ook van "3-2-1-1-0": één onveranderlijke of offline kopie, nul fouten bij de verificatie van het herstel.
Dezelfde ANSSI-gids voegt voorzorgsmaatregelen toe zonder welke de regel niet standhoudt:
- Isoleer de back-upinfrastructuur: buiten het Active Directory-domein van de productie, met onafhankelijke authenticatie en specifieke beheerdersaccounts.
- Maak een back-up van de back-up: catalogus, binaries, importprocedures, encryptiesleutels. Zonder die elementen zijn de media onbruikbaar.
- Test herstelacties regelmatig, volgens een schriftelijke procedure.
Ook de geografie speelt mee. Toen in de nacht van 9 op 10 maart 2021 brand uitbrak in het datacenter van OVHcloud in Straatsburg, ontdekten sommige klanten dat hun back-ups op dezelfde site als hun servers waren opgeslagen.
En een back-up die nooit is teruggezet, is slechts een hypothese. De enige maatstaf die telt, is de datum van de laatste geslaagde hersteltest, met de gemeten duur.
Hoe herstelt u na ransomware?
Ransomware verandert de aard van het herstel. Volgens ANSSI proberen aanvallers vaak de back-upinfrastructuur te versleutelen, te wissen of uit te schakelen om de heropbouw te vertragen. Het herstel wordt een remediëringsproject (indamming, verwijdering, uitroeiing, heropbouw) dat weken of zelfs maanden kan duren. Herstel na ransomware verdient een eigen onderdeel in het plan.
Isoleer eerst de back-ups
Dit is de prioritaire maatregel die ANSSI bij een beveiligingsincident aanbeveelt. Ze vereist een vooraf voorbereide "rode knop": een script, een netwerkswitch die u kunt loskoppelen.
Bewaar de bewijzen
Elke remediëringsactie vernietigt sporen die nodig zijn voor het onderzoek en voor eventuele gerechtelijke procedures. U moet herstelsnelheid afwegen tegen bewijsverzameling, samen met het forensische team. Gecompromitteerde servers meteen hergebruiken betekent bewijs verliezen; een incidentlogboek met tijdsaanduiding zal later van belang zijn voor de rechtbank en de verzekeraar.
Bouw eerst de vertrouwenskern opnieuw op
De directory (meestal Active Directory) en het IT-beheer vormen wat ANSSI de vertrouwenskern noemt. Blijft die gecompromitteerd, dan is alles wat daarna wordt hersteld ook gecompromitteerd; volgens het agentschap leidt een mislukte heropbouw doorgaans tot cycli van compromittering en remediëring die maanden, of zelfs jaren, kunnen duren. Een herstelsequentie na ransomware begint daarom met identiteit, niet met het ERP.
Herstel in een schone, geïsoleerde omgeving
Back-ups kunnen implants van de aanvaller bevatten. Installeer systemen opnieuw vanaf betrouwbare images en applicaties vanaf door de leverancier ondertekende binaries, controleer configuraties, scan gegevens vóór u ze opnieuw importeert. Het herstelpunt moet vóór de compromittering liggen, vaak ruim vóór de laatste back-up: uw werkelijke RPO overschrijdt dan de geplande. DORA eist van haar kant dat financiële entiteiten die met hun eigen systemen herstellen, systemen gebruiken die fysiek en logisch gescheiden zijn van het bronsysteem.
Voorzie ook hardware, licenties en externe expertise: de heropbouw van een schone omgeving vereist alle drie, en de contracten worden vóór de crisis onderhandeld. Om te oefenen, zie onze 10 scenario's voor crisisoefeningen, die openen met ransomware.
Herstel in de cloud en SaaS: wie is waarvoor verantwoordelijk?
Volgens het model van gedeelde verantwoordelijkheid is de provider verantwoordelijk voor de veerkracht van zijn infrastructuur; configuratie, gegevens, identiteiten en de herstelstrategie voor uw workloads blijven de uwe.
- Verlies van een regio. Meerdere beschikbaarheidszones beschermen u tegen het verlies van een gebouw, niet van een volledige regio. Op 20 oktober 2025 verstoorde een defect in het DNS-beheer van DynamoDB de AWS-regio us-east-1 meer dan veertien uur lang voor de belangrijkste diensten, volgens de post-event summary van AWS.
- Het account als single point of failure. Een gecompromitteerd beheerdersaccount kan de productie wissen en de back-ups die ernaast zijn opgeslagen. Bewaar kopieën in een afzonderlijk account, beveiligd tegen verwijdering.
- SaaS. De leverancier herstelt zijn dienst, niet noodzakelijk uw gegevens tot het punt dat u nodig hebt. Controleer bewaartermijnen, export- en exitvoorwaarden, en maak regelmatig exports van kritieke gegevens.
Nog een verborgen afhankelijkheid: op 19 juli 2024 legde een foutieve update van CrowdStrike ongeveer 8,5 miljoen Windows-toestellen plat, volgens Microsoft; de oplossing vereiste manueel ingrijpen op elk toestel, soms met de BitLocker-herstelsleutel. Waar bevinden die sleutels zich, en hoe bereikt u ze zonder de bedrijfs-IT?
Gedetailleerde architecturen: BCDR voor AWS en BCDR voor Azure.
Hoe test u een IT-herstelplan?
Elk type DR-test beantwoordt een specifieke vraag:
| Testtype | Wat het bewijst | Wat het niet bewijst | Indicatieve frequentie |
|---|---|---|---|
| Hersteltest | De back-up is leesbaar, volledig en herstelbaar in een gemeten tijd | Dat de applicatie werkt met haar afhankelijkheden | Maandelijks tot driemaandelijks (kritieke systemen) |
| Failovertest | De herstelsite neemt de belasting over; de technische RTO wordt gehaald | Failback en consistentie van de bedrijfsgegevens | Minstens jaarlijks |
| Volledige DR-oefening | Herstelvolgorde, coördinatie, end-to-end RTO goedgekeurd door de business, failback | Veerkracht tegen een aanvaller die nog binnen is | Jaarlijks (kritiek toepassingsgebied) |
| Heropbouwoefening (ransomware) | Heropbouw van de directory en een eerste dienst vanaf een offline kopie, in isolatie | Hoe lang de volledige remediëring duurt | Om de één à twee jaar |
Voor financiële entiteiten, met uitzondering van micro-ondernemingen, eist DORA dat deze tests scenario's van cyberaanvallen en omschakelingen naar redundante capaciteit omvatten.
De RTO-kloof: de maatstaf die telt
De RTO uit de BIA is een vereiste; de bij tests gemeten hersteltijd is een capaciteit. De kloof tussen beide is het nuttigste dat een IT-herstelplan het hoger management kan vertellen. Om ze eerlijk te meten:
- Meet end to end: van het uitroepen van de ramp tot de goedkeuring door de business, niet tot het moment waarop de virtuele machine opstart.
- Volg het kritieke pad: een ERP dat in 2 uur is hersteld, is nutteloos als de directory er 10 nodig heeft.
- Beslis: herzie de RTO, investeer, of aanvaard het risico formeel. De kloof onbeslist laten is geen optie.
Elke vaststelling wordt een corrigerende actie met een eigenaar en een deadline.
Is een IT-herstelplan verplicht? Wat NIS2, DORA en de AVG eisen
Geen van deze teksten gebruikt de woorden "disaster recovery plan" als documenttitel, maar allemaal eisen ze de capaciteit:
| Tekst | Bepaling | Vereiste |
|---|---|---|
| NIS2 | Art. 21(2)(c) | "bedrijfscontinuïteit, zoals back-upbeheer en noodherstel, en crisisbeheer" |
| NIS2 Uitvoeringsverordening (EU) 2024/2690 | Bijlage, punt 4.2 | Voor bepaalde digitale aanbieders (cloud, datacenters, beheerde diensten…): back-ups op een veilige locatie, regelmatige integriteitscontroles en hersteltests |
| DORA | Art. 11 | ICT-respons- en herstelplannen, intern onafhankelijk geaudit (behalve micro-ondernemingen), minstens jaarlijks en na substantiële wijzigingen getest |
| DORA | Art. 12 | Back-upbeleid, periodiek geteste herstelprocedures, herstel op systemen gescheiden van het bronsysteem, integriteitscontroles na herstel |
| AVG | Art. 32(1)(c) en (d) | De beschikbaarheid van en de toegang tot persoonsgegevens "tijdig" herstellen, en de maatregelen regelmatig testen |
DORA is van toepassing sinds 17 januari 2025 (tekst op EUR-Lex); de omzetting van NIS2 is in verschillende lidstaten nog onvolledig, maar de tekst van de richtlijn legt de lat al. Hoe dan ook zullen auditors vragen naar het plan, de datum en het resultaat van de laatste test, en hoe kloven worden opgevolgd. Zie onze DORA-gids 2026.
Wat ResiPlan concreet doet
ResiPlan is de beheerlaag voor uw IT-herstelplan, geen back-uptool: het voert geen back-ups, failovers of infrastructuurorkestratie uit.
- DRP vooraf ingevuld vanuit de BIA: een van 8 plantypes; de RTO's en RPO's uit de BIA worden de doelstellingen ervan.
- Eerste versie door AI, nagelezen en goedgekeurd door uw team.
- Herstelkloven zichtbaar gemaakt: koppelingen proces ↔ IT-dienst signaleren waar de RTO van een proces korter is dan de herstelcapaciteit van de systemen waarvan het afhangt.
- Simulator van afhankelijkheden: simuleer het verlies van een asset of leverancier en zie welke processen worden getroffen.
- Opgevolgde tests: oefeningen van het type "technische DR-test", vaststellingen omgezet in opgevolgde corrigerende acties.
- Bewijs: NIS2 artikel 21, DORA en ISO 22301 in kaart gebracht, downloadbaar bewijspakket.
Bedrijfsgegevens worden in de EU gehost. Software maakt niemand compliant en certificeert niemand: ResiPlan structureert en onderbouwt het werk dat uw team levert. Gratis proefperiode van 7 dagen, zonder kredietkaart.
Checklist: is uw IT-herstelplan klaar?
- Elk systeem heeft een tier, een RTO en een RPO afgeleid uit de BIA.
- Directory, DNS, back-up en sleutelbeheer hebben een eigen heropbouwprocedure.
- De herstelvolgorde is op papier gezet, met de voorvereisten van elk systeem.
- Minstens één kopie van kritieke gegevens is offline of onveranderlijk, op een afzonderlijke site.
- De back-upinfrastructuur bevindt zich buiten het productiedomein; de catalogus en encryptiesleutels zijn bereikbaar zonder de bedrijfs-IT.
- Ransomware wordt als afzonderlijk scenario behandeld: isolatie, bewijs, vertrouwenskern, schone omgeving.
- Cloud- en SaaS-afhankelijkheden zijn geïdentificeerd, met gecontroleerde exports en exitvoorwaarden.
- Kritieke systemen zijn in de afgelopen 12 maanden met succes hersteld, met gemeten duur.
- Dit jaar vond een DR-oefening plaats, failback inbegrepen, en de RTO-kloof wordt opgevolgd.
FAQ
Wat is het verschil tussen een IT-herstelplan en een bedrijfscontinuïteitsplan?
Een BCP houdt essentiële activiteiten draaiende tijdens een verstoring, over de hele organisatie heen: bedrijfsonderdelen, mensen, gebouwen, leveranciers en IT. Een IT-herstelplan herstart de IT na de uitval. Het DRP maakt deel uit van het BCP, dat op de hersteltijden ervan steunt om de procedures in degraded mode te dimensioneren.
Is een IT-herstelplan verplicht?
Geen enkele regelgeving eist een document met precies die titel. Maar NIS2, DORA en de AVG eisen allemaal de capaciteit die het beschrijft: back-ups, herstel, geteste herstelplannen, herstelde toegang tot gegevens. Zonder IT-herstelplan kunt u die niet aantonen.
Hoe vaak moet een IT-herstelplan worden getest?
Een significante oefening minstens eenmaal per jaar voor het kritieke toepassingsgebied, wat het minimum van DORA is, en na elke grote wijziging aan de infrastructuur. Hersteltests loont het om vaker uit te voeren: ze zijn goedkoop en brengen een falende back-up snel aan het licht.
Volstaan back-ups om te herstellen na ransomware?
Nee. U hebt een kopie nodig buiten het bereik van de aanvaller (offline of onveranderlijk), een back-upinfrastructuur die geïsoleerd is van het productiedomein, en een herstel in een schone omgeving nadat de directory opnieuw is opgebouwd. Anders herstelt u de aanvaller samen met de gegevens.
Maakt de overstap naar de cloud een IT-herstelplan overbodig?
Nee. De provider zorgt voor de veerkracht van zijn infrastructuur, niet voor het herstel van uw workloads: configuratie, gegevens, identiteiten, multiregio-ontwerp en back-ups blijven uw verantwoordelijkheid. Houd minstens rekening met het verlies van een regio en van uw beheerdersaccount.
Verder lezen
- Bedrijfscontinuïteitsplan (BCP): gids in 8 stappen voor 2026
- RTO vs RPO: matrix en sectorbenchmarks
- BIA-gids: het volledige draaiboek voor de bedrijfsimpactanalyse
- Sjabloon voor een IT-herstelplan
- RTO/RPO-calculator
Een IT-herstelplan is maar zo goed als zijn laatste geslaagde test: dat is de eerste datum die een auditor, een verzekeraar of een raad van bestuur u zou moeten vragen.