DRP en BCP

Wat is een RTO?

Q: Wat is het verschil tussen RTO en MTD?

De MTD (Maximum Tolerable Downtime) is de totale stilstand die de directie voor een activiteit aanvaardt, alle gevolgen inbegrepen. De RTO is de termijn om een IT-middel weer in gebruik te nemen. Het NIST verduidelijkt dat de RTO normaal korter moet zijn dan de MTD, om marge te laten voor de andere herstelstappen.

De RTO (Recovery Time Objective, doelstelling voor de hersteltijd) is de maximale duur waarin een dienst onbeschikbaar mag blijven. Hij wordt gemeten vanaf het incident, of vanaf de beslissing om om te schakelen, tot het moment waarop een gebruiker opnieuw een normale bedrijfshandeling uitvoert. Niet tot het opstarten van een machine waarvan de applicatie nog niet is gecontroleerd.

Bijgewerkt in oktober 20263 min leestijd4 geciteerde bronnen

De kern

De RTO telt zes termijnen op: detectie, beslissing, toegang zoeken, technische tijd, controle door de business, terugkeer van de gebruikers.
Het NIST onderscheidt hem van de maximaal toelaatbare onderbrekingsduur (MTD): de RTO moet normaal korter zijn dan de MTD.
Een RTO legt u per dienst vast: de telefooncentrale en de archieven hebben niet dezelfde.
Alleen een getimede test toont of de vastgelegde RTO gehaald wordt.
De openingsuren van de ondersteuning en het ontbreken van een wachtdienst maken deel uit van de werkelijke RTO.

Officiële definitie

Het NIST definieert de RTO als de maximale duur waarin een middel van het informatiesysteem onbeschikbaar mag blijven voordat de impact onaanvaardbaar wordt voor de activiteiten die het ondersteunt. Het onderscheidt hem van de maximaal toelaatbare onderbrekingsduur (MTD), de totale stilstand die de directie voor een activiteit aanvaardt. De RTO moet garanderen dat de MTD niet wordt overschreden: hij is dus normaal korter.

Het ANSSI, het Franse nationale agentschap voor cyberbeveiliging, gebruikt de term maximaal aanvaardbare onderbrekingsduur (DMIA). Het vraagt dat een back-upstrategie daar voor elk bedrijfsonderdeel rekening mee houdt, en dat vooraf een herstelvolgorde wordt bepaald, op basis van de afhankelijkheden (DNS, directory…) en de kriticiteit van de applicaties.

Waaruit de RTO bestaat

Voor een klassiek herstel:

de tijd om de storing op te merken;
de tijd om te beslissen en de persoon te bereiken die weet wat te doen;
de tijd om sleutels, wachtwoorden en procedure te vinden;
de technische tijd voor kopiëren of opstarten;
de tijd voor controle door iemand uit de business;
de tijd tot werkstations of externe klanten de dienst terugvinden (DNS, VPN, IP).

Een RTO ‘van twee uur’ die een softwarepakket belooft, telt vaak alleen stap 4, in labo-omstandigheden. De werkelijke RTO telt alle zes op. ‘s Nachts en in het weekend kan stap 2 alleen al meer dan twee uur duren als niemand van wacht is.

Bij een BCP worden stap 4 en 6 vooraf voorbereid. Wat overblijft, zijn de detectie en het risico van een omschakeling die niemand durft goed te keuren.

RTO en RPO ruilt u niet tegen elkaar in

U kunt een korte RPO hebben (frequente kopieën) en een lange RTO (traag herstel van een groot volume). U kunt een korte RTO hebben (noodomgeving al actief) en een matige RPO als de noodomgeving twee uur achterloopt. Beide cijfers worden allebei vastgelegd.

RPOMaximaal aanvaardbaar gegevensverlies

RTOMaximaal aanvaardbare stilstand

gemeten terug in de tijd

gemeten vooruit in de tijd

Gegevens vóór het incident

!Incident

Herstart van de diensten

	RPO	RTO
Gestelde vraag	Hoeveel werk mogen we verliezen?	Hoe lang mogen we stilliggen?
Gemeten	Terug in de tijd, vanaf het incident	Vooruit in de tijd, vanaf het incident
Bepaald door	De frequentie van de kopieën	De voorbereiding van de noodomgeving
Gecontroleerd via	De datum van de laatste geslaagde kopie	Een getimede test

Een RTO per dienst

De telefooncentrale en het documentbeheersysteem met de archieven hebben niet dezelfde RTO. ‘RTO 4 uur’ noteren voor het hele bedrijf dwingt u ofwel te veel te betalen voor de archieven, ofwel te liegen over de telefooncentrale. Eén regel per dienst volstaat.

Hoe weet u of de RTO wordt gehaald

Alleen met een stopwatch tijdens een test. Als de test zes uur duurde en de vastgelegde RTO twee uur is, dan is de vastgelegde RTO fout, tot de architectuur verandert. U ‘mikt’ niet op een RTO die de laatste meting heeft tegengesproken. Het ANSSI benadrukt dit: een herstelprocedure moet worden opgesteld en regelmatig worden uitgevoerd. Het testritme wordt besproken in Hoe vaak test u uw DRP?.

Bij WeDoBack

Op de site wordt geen unieke RTO in cijfers gepubliceerd, en het zou misleidend zijn er een te verzinnen: hij hangt af van het volume, de verbinding, de grootte van de instance en de beschikbaarheid van de mensen aan klantzijde. Wat de architectuur verandert, is de aard van de termijn. Bij een eenvoudig herstel moeten de gegevens worden teruggehaald en moet eventueel opnieuw worden geïnstalleerd. Met het DRP starten de servers opnieuw op noodinstances vanuit de gekozen versie: de technische termijn is die van deze herstart, niet die van de aankoop van een server. Elke maand vindt een opstarttest plaats, zonder de productie te raken. Met het BCP draaien cloudinstances permanent en worden ze via een agent op het netwerk van de klant ingeschakeld, zonder wijziging van IP-adres: de resterende RTO is vooral die van detectie en beslissing. Replicatie of synchronisatie van gegevens tussen de BCP-instance en de oorspronkelijke server is niet standaard: ze verloopt via een specifiek proces, aangepast aan de behoefte, dat WeDoBack op offerte kan opzetten. In alle drie de gevallen blijft de controle door de business binnen de gemeten tijd. De menselijke ondersteuning is bereikbaar van 9.00 tot 13.00 uur en van 14.00 tot 17.30 uur (Parijse tijd).

Het DRP bekijken Het BCP bekijken

Veelgestelde vragen

Wat is het verschil tussen RTO en MTD?

De MTD (Maximum Tolerable Downtime) is de totale stilstand die de directie voor een activiteit aanvaardt, alle gevolgen inbegrepen. De RTO is de termijn om een IT-middel weer in gebruik te nemen. Het NIST verduidelijkt dat de RTO normaal korter moet zijn dan de MTD, om marge te laten voor de andere herstelstappen.

Een softwarepakket belooft een RTO van enkele minuten. Is dat realistisch?

Dat cijfer omvat doorgaans alleen de technische opstarttijd, in een labo. Het omvat niet de detectie, niet de tijd om de bevoegde persoon te bereiken en niet de controle door een gebruiker. Uw werkelijke RTO is die welke u bij uw laatste test hebt gemeten, van de melding van het incident tot de eerste geslaagde bedrijfshandeling.

Is de RTO een wettelijke verplichting?

Geen enkele tekst legt een kmo een bepaalde duur op. De AVG (artikel 32) vraagt wel om middelen waarmee de beschikbaarheid van en de toegang tot persoonsgegevens bij een incident ‘tijdig’ kunnen worden hersteld. De RTO is de concrete manier om die passende termijn te bepalen.

Verder lezen

Bronnen

Documenten geraadpleegd in oktober 2026.

SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
Back-up van informatiesystemen – De basisprincipes (ANSSI-BP-100, v1.1, 27 november 2025) — ANSSI (Frans agentschap)
Verordening (EU) 2016/679 (AVG), artikel 32 — EUR-Lex
DRP-aanbod: herstel van de activiteit na een calamiteit — WeDoBack

Een project voor back-up, DRP of BCP?

Meer dan 20 jaar ervaring in de bescherming van bedrijfsgegevens.

Offerte aanvragen +33 9 72 50 78 28

Bescherm uw gegevens met WeDoBack

Versleutelde offsite back-up, onveranderlijke opslag, DRP en BCP: beschrijf uw servers en wij stellen de juiste combinatie voor.

Offerte aanvragen Bekijk aanbod en tarieven