Wat is een disaster recovery plan? Onderdelen, RTO/RPO, testen en checklist

Een disaster recovery-plan (DR-plan) is een vastgelegde, geteste procedure om IT-systemen en data te herstellen na een grote storing, een cyberaanval of het verlies van een locatie. Het benoemt wie de ramp uitroept, welke systemen als eerste terugkomen, hoe snel (RTO), hoeveel dataverlies acceptabel is (RPO) en welke stappen u zet om over te schakelen naar de noodomgeving en weer terug.

Belangrijkste punten

• Een DR-plan herstelt technologie; een bedrijfscontinuïteitsplan houdt het hele bedrijf draaiend. U hebt beide nodig en het DR-plan hoort een onderdeel van het continuïteitsplan te zijn.
• Elke herstelbeslissing begint met twee getallen per systeem: de recovery time objective (RTO) en de recovery point objective (RPO).
• Cloud-DR kent vier standaardstrategieën: back-up en herstel, pilot light, warm standby en multi-site active/active. Kosten en herstelsnelheid stijgen samen.
• Een niet-geteste plan is een gok. Test minstens één keer per jaar, en vaker voor kritieke systemen, van tabletop-oefening tot volledige failover.
• In de EU noemt NIS2 artikel 21 "backupbeheer en disaster recovery" als minimale beveiligingsmaatregel. In Zweden geldt dit via de Cybersecurity Act (Cybersäkerhetslagen) vanaf 15 januari 2026.

Wat is een disaster recovery-plan?

Het is het technische draaiboek om systemen terug te krijgen na een gebeurtenis die de gewone veerkracht niet kan opvangen. Typische oorzaken zijn ransomware, een uitval van een datacenter of cloudregio, een beschadigde database, een mislukte wijziging, brand of overstroming.

NIST SP 800-34 definieert een DR-plan als "een schriftelijk plan voor het herstellen van een of meer informatiesystemen op een alternatieve locatie naar aanleiding van een ernstige hardware- of softwarestoring of de vernietiging van faciliteiten" (NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems). Dezelfde gids benadrukt dat een DR-plan op informatiesystemen is gericht, terwijl een bedrijfscontinuïteitsplan bedrijfsprocessen dekt, zoals salarisadministratie of klantenservice.

U komt ook de termen "IT disaster recovery-plan" en "DRP" tegen. Ze betekenen hetzelfde. Een goed plan is kort genoeg om onder druk te gebruiken: beslisbevoegdheden, prioriteiten, runbooks, contactgegevens en bewijs van testen. Een lang beleidsdocument dat niemand sinds de laatste audit heeft geopend, telt niet.

Disaster recovery versus bedrijfscontinuïteit

Disaster recovery herstelt de IT. Bedrijfscontinuïteit zorgt dat de organisatie producten en diensten blijft leveren terwijl IT, mensen, panden of leveranciers verstoord zijn. Het AWS-whitepaper over DR zegt het ronduit: het DR-plan "moet een onderdeel zijn van het bedrijfscontinuïteitsplan (BCP) van uw organisatie en mag geen op zichzelf staand document zijn."

Voor een uitgebreidere vergelijking, inclusief BCDR in AWS, Azure en Google Cloud, leest u onze gids over disaster recovery en bedrijfscontinuïteit in de cloud.

Back-up versus disaster recovery

Een back-up is een kopie van data. Disaster recovery is het vermogen om de dienst weer draaiende te krijgen. U kunt perfecte back-ups hebben en toch dagenlang stilliggen als niemand heeft uitgewerkt hoe servers, netwerken, identiteiten en DNS eromheen worden herbouwd. Back-ups zijn één invoer voor het DR-plan; de 3-2-1-regel (drie kopieën, twee soorten opslagmedia, één extern) is daarvoor een verstandige basis.

Wat is het doel van een DR-plan?

Het doel is herstel voorspelbaar te maken. Als een ramp toeslaat, vervangt het plan improvisatie door beslissingen die vooraf rustig zijn genomen.

• Uitvaltijd beperken. Kritieke systemen komen binnen een afgesproken tijd en in een afgesproken volgorde terug.
• Dataverlies beperken. Back-ups en replicatie draaien met de frequentie die het bedrijf heeft goedgekeurd.
• Onduidelijkheid wegnemen. Iedereen weet wie een ramp mag uitroepen, wie leiding geeft en wie met klanten en autoriteiten praat.
• Kosten beheersen. Niet elk systeem heeft een hot standby nodig. Het plan legt vast welke wel en waarom.
• Naleving aantonen. Toezichthouders, auditors, verzekeraars en zakelijke grootklanten vragen steeds vaker om aantoonbaar geteste herstelcapaciteit, niet alleen om een beleidsstuk.

Dit zijn ook de voordelen waar kopers naar vragen. Een plan dat is geoefend, verkort echte storingen, omdat mensen de stappen al hebben geoefend.

RTO en RPO: de twee getallen die het plan bepalen

De recovery time objective (RTO) is hoe lang een systeem uit de lucht mag zijn. De recovery point objective (RPO) is hoeveel data, uitgedrukt in tijd, u zich kunt veroorloven te verliezen. AWS definieert RTO als "de maximaal acceptabele vertraging tussen de onderbreking van de dienst en het herstel van de dienst" en RPO als "de maximaal acceptabele hoeveelheid tijd sinds het laatste herstelpunt."

Rekenvoorbeeld. Een webshop spreekt voor het bestelsysteem een RTO van 4 uur en een RPO van 15 minuten af. Als de database om 10:00 uitvalt, moeten bestellingen uiterlijk om 14:00 weer worden geaccepteerd, en hooguit de bestellingen tussen 09:45 en 10:00 moeten opnieuw worden ingevoerd of op andere wijze worden hersteld. Een nachtelijke back-up haalt die RPO niet; de shop heeft log shipping of replicatie nodig, minstens elke 15 minuten. De interne wiki kan daarentegen een RTO van 3 dagen en een RPO van 24 uur accepteren, en dat dekt een dagelijkse back-up.

Twee praktische regels helpen:

• Stel doelen per systeem vast via een business impact analysis, niet één getal voor "IT". De impact kan ook in de tijd veranderen: AWS merkt op dat een storing in de salarisadministratie vlak voor de uitbetaling veel meer pijn doet dan vlak erna.
• Houd de RTO onder de maximaal toelaatbare uitvaltijd van het bedrijfsproces. NIST SP 800-34 legt uit dat de RTO "normaal gesproken korter moet zijn" dan die grens, omdat data nadat de systemen terug zijn nog verwerkt moet worden.

Voor meer voorbeelden en een stapsgewijze methode om beide doelen vast te stellen, zie RPO en RTO bij disaster recovery uitgelegd.

DR-strategieën: van back-up en herstel tot active/active

Het AWS-whitepaper Disaster Recovery of Workloads on AWS deelt cloud-DR in vier strategieën in. Dezelfde patronen gelden voor Azure (waar Azure Site Recovery virtuele machines naar een tweede regio repliceert) en voor Google Cloud.

Het verschil tussen pilot light en warm standby verwart veel teams. AWS formuleert het zo: een pilot light-omgeving "kan zonder aanvullende handelingen geen verzoeken verwerken", terwijl een warm standby "direct verkeer kan afhandelen (met verminderde capaciteit)." Ons artikel over pilot light disaster recovery behandelt dat patroon in detail.

Twee punten uit het whitepaper worden vaak over het hoofd gezien. Ten eerste: een multi-AZ-ontwerp binnen één regio "voldoet mogelijk al aan een groot deel van uw risicobeperkingsbehoeften" bij uitval op datacenterniveau; een tweede regio is bedoeld voor regiobrede gebeurtenissen of wettelijke eisen. Ten tweede werkt back-up en herstel alleen snel als de infrastructuur als code is gedefinieerd, omdat u naast data ook netwerken, servers en configuratie opnieuw moet uitrollen.

DRaaS en disaster recovery in de cloud

Disaster recovery as a service (DRaaS) betekent dat een aanbieder uw servers naar zijn cloud repliceert en de failover-tooling beheert. AWS Elastic Disaster Recovery en Azure Site Recovery zijn de native opties; managed service providers bouwen er runbooks, monitoring en tests omheen. DRaaS maakt van een kapitaalproject (een tweede datacenter) een doorlopende kostenpost, maar neemt uw verantwoordelijkheid niet weg om RTO/RPO vast te stellen, het plan goed te keuren en aan tests deel te nemen.

Hot, warm en cold sites

Vóór de cloudregio's werden DR-strategieën beschreven aan de hand van de paraatheid van de alternatieve locatie. NIST SP 800-34 beschrijft cold sites als ruimte met stroom, koeling en connectiviteit maar zonder apparatuur, warm sites als gedeeltelijk uitgerust met hardware en telecom, en hot sites als volledig ingericht met hardware, infrastructuur en personeel. Een cold site is het goedkoopst, maar kan dagen of weken kosten om in gebruik te nemen. De cloudequivalenten komen grofweg overeen met back-up en herstel (cold), pilot light of warm standby (warm) en active/active (hot). Lees meer in wat is een hot site bij disaster recovery.

Wat hoort er in een DR-plan? Checklist

Gebruik deze checklist om een nieuw plan op te stellen of een bestaand plan te auditen. Elke regel moet bestaan als een benoemd, gedateerd product, niet als een belofte.

Een DR-plan opstellen in zeven stappen

1. Voer een business impact analysis en risicobeoordeling uit. Dit is de eerste stap van elk DR-traject. Maak een lijst van bedrijfsprocessen, wat een storing per uur kost en welke systemen elk proces nodig heeft.
2. Stel RTO en RPO per systeem vast. Groepeer systemen in drie of vier niveaus, zodat u voor niveaus ontwerpt en niet voor honderden afzonderlijke servers.
3. Kies een strategie per niveau. Koppel elk niveau aan back-up en herstel, pilot light, warm standby of active/active. Toets de kosten aan de impact die u in stap 1 hebt gemeten.
4. Bouw de technische capaciteit. Back-ups, kopieën tussen regio's of accounts, replicatie, infrastructure as code, en ook monitoring en alarmering in de herstelomgeving.
5. Schrijf de runbooks. Korte, genummerde stappen die een engineer met storingsdienst om 03:00 kan volgen, inclusief failback.
6. Test en verbeter. Begin met een tabletop-oefening, daarna hersteltests en vervolgens een failover. Leg de gemeten RTO en RPO vast.
7. Onderhoud het plan. Evalueer minstens jaarlijks en na elke belangrijke wijziging in systemen, leveranciers of organisatie.

Disaster recovery bij cyberincidenten en ransomware

Voor veel bedrijven is de ramp waarvoor ze echt moeten plannen ransomware of een gecompromitteerd beheerdersaccount, geen overstroming. Dat verandert het plan op drie punten.

• Replicatie is niet genoeg. AWS waarschuwt dat continue replicatie "mogelijk minder bescherming biedt dan point-in-time-back-ups tegen rampen zoals datacorruptie of kwaadwillende aanvallen (zoals ongeoorloofd verwijderen van data)." Bewaar point-in-time-back-ups die aanvallers niet kunnen verwijderen, bij voorkeur in een apart account met andere inloggegevens.
• Herstel begint na insluiting. Het incident response-plan bepaalt wanneer de omgeving schoon genoeg is om naartoe te herstellen. Herstellen op gecompromitteerde infrastructuur besmet die opnieuw.
• Identiteit is een afhankelijkheid. Als uw identiteitsprovider of wachtwoordmanager uitvalt of gecompromitteerd is, moeten de runbooks aangeven hoe hulpverleners toegang krijgen.

Wanneer wordt een DR-plan in werking gesteld?

Het plan gaat in werking wanneer een storing groter is, of duidelijk groter gaat worden, dan wat het gewone incidentbeheer binnen de RTO kan oplossen. Leg de criteria vast, bijvoorbeeld "primaire regio meer dan 30 minuten niet beschikbaar" of "productiedata versleuteld door ransomware", en benoem wie beslist. Zie wanneer moet u een disaster recovery-plan activeren voor typische aanleidingen.

Hoe vaak moet een DR-plan worden getest?

Test minstens één keer per jaar en na elke belangrijke wijziging. Kritieke systemen verdienen vaker een oefening. Het voorbeeldbeleid voor contingency van NIST stelt dat herstelcapaciteiten "jaarlijks moeten worden getest", en de gids adviseert het plan "ten minste jaarlijks" en na belangrijke wijzigingen te evalueren.

NIST schaalt de testdiepte ook naar het impactniveau van het systeem. Voor systemen met lage impact volstaat een tabletop-oefening; systemen met gemiddelde impact vragen een functionele oefening inclusief herstel vanaf een back-up; systemen met hoge impact vragen een volledige functionele oefening inclusief "een systeemfailover naar de alternatieve locatie."

De kolom met frequentie is onze aanbeveling voor een gemiddeld middelgroot bedrijf; uw toezichthouder of klanten kunnen meer eisen. AWS vat samen waarom testen ertoe doet: "het enige foutherstel dat werkt, is het pad dat u regelmatig test." Leg na elke test de gemeten hersteltijd en het dataverlies vast, vergelijk ze met uw doelen en wijs voor elke kloof een eigenaar aan.

NIS2 en de Zweedse Cybersecurity Act

Voor organisaties die onder NIS2 vallen, is disaster recovery geen vrijblijvende best practice meer. Artikel 21, lid 2, onder c van Richtlijn (EU) 2022/2555 (NIS2) eist dat de risicobeheersmaatregelen ten minste omvatten: "bedrijfscontinuïteit, zoals backupbeheer en disaster recovery, en crisisbeheer". Artikel 23 voegt meldtermijnen toe voor significante incidenten: een vroegtijdige waarschuwing binnen 24 uur nadat u ervan op de hoogte bent en een incidentmelding binnen 72 uur. Uw DR-plan en uw proces voor incidentmeldingen moeten dus samenwerken.

In Zweden is NIS2 geïmplementeerd door de Cybersecurity Act (Cybersäkerhetslag, SFS 2025:1506), die op 15 januari 2026 in werking is getreden. Hoofdstuk 2, paragraaf 3 noemt "kontinuitetshantering och krishantering" (continuïteitsbeheer en crisisbeheer) onder de minimale beveiligingsmaatregelen. Verwacht dat toezichthouders om bewijs vragen: een actueel plan, testrapporten en afgesloten bevindingen.

Hoe Opsio helpt

Opsio ontwerpt, beheert en test DR voor workloads op AWS en Azure als onderdeel van de cloud disaster recovery-dienst.

Veelgestelde vragen

Wat zijn de belangrijkste onderdelen van een disaster recovery-plan?

De kernonderdelen zijn een business impact analysis en risicobeoordeling, RTO en RPO per systeem, een herstelstrategie per niveau, back-up en replicatie, activeringscriteria, rollen en contactpersonen, stapsgewijze runbooks inclusief failback, een communicatieplan en een test- en onderhoudsschema.

Wat is de eerste stap in een disaster recovery-traject?

De eerste stap is een business impact analysis in combinatie met een risicobeoordeling. Die laat zien welke processen en systemen het belangrijkst zijn en hoe lang ze uit de lucht mogen zijn, en bepaalt daarmee de RTO en RPO waar elke latere beslissing van afhangt.

Hoe vaak moet een disaster recovery-plan worden getest?

Minstens één keer per jaar en na elke grote wijziging in systemen of leveranciers. Voer tabletop-oefeningen uit voor alle plannen en herstel- of failovertests voor kritieke systemen, zoals NIST SP 800-34 aanbeveelt voor systemen met hogere impact.

Wat is het verschil tussen disaster recovery en bedrijfscontinuïteit?

Disaster recovery herstelt IT-systemen en data. Bedrijfscontinuïteit houdt het bedrijf operationeel tijdens een verstoring en omvat ook mensen, panden, leveranciers en communicatie. Het DR-plan hoort deel uit te maken van het bedrijfscontinuïteitsplan.

Wat zijn de vier disaster recovery-strategieën in de cloud?

Back-up en herstel, pilot light, warm standby en multi-site active/active. Volgens het DR-whitepaper van AWS lopen ze uiteen van hersteltijden van uren tegen de laagste kosten tot vrijwel realtime herstel tegen de hoogste kosten.

Vereist NIS2 planning voor disaster recovery?

NIS2 artikel 21, lid 2, onder c vereist dat essentiële en belangrijke entiteiten bedrijfscontinuïteit afdekken, "zoals backupbeheer en disaster recovery, en crisisbeheer". In de praktijk betekent dat een gedocumenteerde, geteste DR-capaciteit die u aan de toezichthouder kunt tonen.