RTO

Wat is RTO?

RTO (Recovery Time Objective) is de maximale tijd die een systeem, dienst of proces na een incident buiten gebruik mag zijn voordat de gevolgen voor de organisatie onaanvaardbaar worden. De RTO is een doel dat u vooraf vastlegt, geen meting achteraf. Zij bepaalt welke herstelstrategie nodig is: een systeem met een RTO van vijf minuten vraagt om een redundante opstelling, een systeem met een RTO van drie dagen kan het af met een goede back-up en een herinstallatieprocedure. Samen met de RPO vormt de RTO de kern van elk disaster recovery- en business continuity-plan.

Hoe snel moet u weer operationeel zijn na een storing of cyberincident?

🧠 Hoe is de RTO precies gedefinieerd?

De Amerikaanse richtlijn NIST SP 800-34 Rev. 1 (mei 2010) voor contingency planning omschrijft de RTO als de maximale tijd dat een systeemonderdeel onbeschikbaar mag blijven voordat er onaanvaardbare gevolgen zijn voor andere systemen, de ondersteunde bedrijfsprocessen en de maximaal toelaatbare uitvaltijd. De continuïteitsnorm ISO 22301 hanteert dezelfde gedachte: de RTO is de periode na een incident waarbinnen een dienst of activiteit hervat moet zijn of middelen hersteld moeten zijn.

Belangrijk is wat de klok laat lopen en stoppen. Gangbaar is dat de RTO begint bij het moment van uitval of detectie, niet bij het moment dat iemand besluit te gaan herstellen. Zij eindigt wanneer het proces weer op een afgesproken minimumniveau draait, niet wanneer de server weer opstart. Leg beide momenten expliciet vast, anders praten IT, OT en de business over verschillende getallen.

Een voorbeeld: heeft een productiesysteem dat cruciaal is voor de fabriek een RTO van 2 uur, dan moet het proces binnen 2 uur na de storing weer draaien. Duurt het langer, dan loopt u risico op productiestilstand, financieel verlies, boetes of contractbreuk en reputatieschade.

🔄 Wat is het verschil tussen RTO, RPO, MTPD en MTTR?

RTO wordt vaak verward met verwante begrippen. Elk getal beantwoordt een andere vraag:

De volgorde volgt uit NIST SP 800-34: de RTO moet normaal korter zijn dan de MTD, omdat er na het technisch herstel nog werk volgt, zoals data opnieuw verwerken, de installatie opstarten en de productkwaliteit controleren. Moet een proces na 48 uur weer draaien en kost het opstarten van de installatie 12 uur, dan mag het herstel van de systemen niet langer dan 36 uur duren. De RPO maakt volgens NIST geen deel uit van de MTD; zij gaat over dataverlies, niet over tijd zonder dienst.

🔧 Hoe bepaalt de RTO uw herstelstrategie?

Hoe korter de RTO, hoe duurder de oplossing. NIST beschrijft dit als een kostenafweging: de schade van uitval stijgt met de tijd, de kosten van herstelvoorzieningen stijgen naarmate de RTO korter wordt. Ergens ligt een evenwichtspunt, en dat is voor elk systeem anders. De gangbare koppeling tussen RTO en strategie:

Een RTO is alleen geloofwaardig als de gekozen strategie haar in een test ook haalt. Klopt de gemeten hersteltijd niet met het doel, dan past u de voorzieningen aan of stelt u het doel bewust bij. NIST noemt voor dat laatste een Plan of Action and Milestones: leg vast dat het doel nog niet haalbaar is en wanneer dat verandert.

🏭 Waarom is RTO in OT-omgevingen anders?

In OT gelden andere spelregels dan in kantoor-IT. Drie verschillen springen eruit:

• Niet elk systeem stopt het proces - valt het SCADA-beeld uit, dan blijven de PLC’s meestal gewoon regelen. Operators verliezen wel zicht en bediening, en moeten dan vaak overschakelen op lokale bediening of het proces gecontroleerd stilzetten. De RTO van het SCADA-systeem hangt dus af van hoe lang een installatie veilig zonder centraal toezicht kan draaien.
• Herstel duurt langer dan herstarten - na een besmetting moeten firmware en programma’s van PLC’s worden gecontroleerd, sensoren en actuatoren getest en het proces stap voor stap opgestart. Een oven of reactor heeft soms uren of dagen nodig om weer op temperatuur en specificatie te komen.
• Veiligheid gaat voor snelheid - een veiligheidsfunctie zoals een SIS krijgt geen RTO in de gebruikelijke zin. Zij is zo ontworpen dat een storing tot een veilige toestand leidt (fail-safe), en de installatie mag pas weer draaien als de veiligheidsfunctie aantoonbaar werkt.

Illustratieve waarden, die per installatie sterk verschillen: een RTO van 5 minuten voor een SCADA-systeem met redundante servers, 30 minuten voor een alarmeringsplatform en 1 uur voor een historian-database. Elk van die getallen moet volgen uit de impact van uitval, niet uit gewoonte.

Hoe groot het gat tussen doel en werkelijkheid kan zijn, liet NotPetya in 2017 zien: bij Maersk werden circa 49.000 laptops en 4.000 servers onbruikbaar en lagen de terminals op de Maasvlakte ruim een week grotendeels stil. Bij Colonial Pipeline lag de pijpleiding in mei 2021 zes dagen stil, terwijl alleen de IT was getroffen. Beide gevallen tonen dat de RTO van OT-processen ook afhangt van IT-systemen voor planning, facturatie en logistiek.

🛠️ Hoe stelt u een RTO op in vijf stappen?

1. Breng systemen en afhankelijkheden in kaart - gebruik de asset-inventaris en noteer per proces welke servers, netwerken, licenties en leveranciers nodig zijn.
2. Voer een business impact analysis uit - bepaal per proces hoe de schade in de tijd oploopt en waar de MTPD ligt, met naast financiële schade ook veiligheid, milieu en leveringsplicht.
3. Leid de RTO af met marge - trek de tijd voor opstarten, kwaliteitscontrole en dataverwerking af van de MTPD. Stem de uitkomst af met productie en onderhoud.
4. Kies en realiseer de herstelstrategie - redundantie, reservehardware of onveranderbare back-ups van PLC-programma’s, HMI-projecten en configuraties.
5. Test en meet - oefen het herstel periodiek, bijvoorbeeld met een tabletop-oefening en een echte restore-test, en vergelijk de gemeten hersteltijd met de RTO.

🔐 Welke wetten en normen vragen om hersteldoelen?

• NIS2, artikel 21 lid 2 onder c - verplicht bedrijfscontinuïteit, zoals back-upbeheer en herstel na calamiteiten. Zonder vastgelegde hersteltijden is niet aan te tonen dat die maatregelen passend zijn.
• Cyberbeveiligingswet - de Nederlandse omzetting van NIS2, sinds 15 augustus 2026 van kracht. Het Cyberbeveiligingsbesluit vraagt in artikel 9 om herstelprocedures, periodiek geverifieerde back-ups en een continuïteits-, herstel- en crisisplan dat periodiek wordt getest.
• ISO 22301 - de norm voor business continuity management laat organisaties via de business impact analysis prioriteiten en hersteltijden per activiteit vastleggen.
• ISO 27001:2022 - beheersmaatregel A.5.30 (ICT-gereedheid voor bedrijfscontinuïteit) vraagt dat ICT-voorzieningen de continuïteitsdoelen kunnen halen.
• IEC 62443-3-3 - systeemeisen SR 7.3 (back-up van het besturingssysteem) en SR 7.4 (herstel en reconstitutie naar een bekende, veilige toestand) maken herstel binnen de RTO technisch mogelijk.
• NIST CSF 2.0 - de functie Recover verwacht geoefende herstelprocedures met haalbare doelen.

❓ Veelgestelde vragen

Wat is een goede RTO voor een OT-systeem?

Een goede RTO voor een OT-systeem volgt uit de business impact analysis en ligt altijd binnen de maximaal toelaatbare uitvaltijd van het proces. Voor een redundant SCADA-systeem kan dat enkele minuten zijn, voor een rapportageserver enkele dagen. Er bestaat geen standaardwaarde: dezelfde soort server kan in de ene fabriek kritiek zijn en in de andere niet.

Is een RTO van nul mogelijk?

Een RTO van nul betekent dat er geen merkbare uitval mag zijn, wat alleen haalbaar is met volledige redundantie en automatische omschakeling. Zelfs dan beschermt redundantie niet tegen alles: ransomware of een foutieve configuratie wordt vaak direct naar het tweede systeem gesynchroniseerd. Een RTO van nul vraagt daarom naast high availability ook gescheiden, onveranderbare back-ups.

Wie bepaalt de RTO?

De RTO wordt bepaald door de eigenaar van het bedrijfsproces, op basis van de business impact analysis, en niet door de IT- of OT-afdeling alleen. Beheerders adviseren over wat technisch haalbaar is en wat het kost. Het management accepteert de uiteindelijke keuze, inclusief het restrisico.

Hoe vaak moet u een RTO herzien?

Een RTO herziet u minimaal jaarlijks en bij elke wijziging van installatie, product of leverancier. Ook na een incident of een mislukte hersteltest moet de RTO opnieuw worden beoordeeld. Een verouderde RTO geeft een vals gevoel van zekerheid.

Wat is het verschil tussen RTO en beschikbaarheid?

De RTO zegt hoe lang één uitval mag duren, beschikbaarheid zegt welk deel van de tijd een systeem werkt. Een beschikbaarheid van 99,99% laat circa 53 minuten uitval per jaar toe, maar zegt niets over hoe lang één storing mag duren. Daarom legt u voor kritieke systemen beide vast.

Hoort de RTO in een incident response plan?

De RTO hoort vooral in het disaster recovery- en continuïteitsplan, maar het incident response plan moet ernaar verwijzen. Tijdens een incident helpt de RTO bij de keuze tussen snel herstellen en eerst grondig onderzoeken. Bij een cyberincident in OT weegt de zekerheid dat systemen schoon zijn vaak zwaarder dan het halen van de RTO.

📌 Samengevat

De RTO is de maximale tijd die een systeem of proces na een incident mag uitliggen, een vooraf vastgelegd doel dat de herstelstrategie en het budget bepaalt.

De RTO volgt uit de business impact analysis, ligt altijd binnen de maximaal toelaatbare uitvaltijd en wordt getoetst aan de gemeten MTTR. In OT telt niet alleen het herstarten van servers, maar ook het controleren van PLC’s, het veilig opstarten van de installatie en de afhankelijkheid van IT. NIS2, de Cyberbeveiligingswet, ISO 22301 en IEC 62443 vragen allemaal om herstel dat aantoonbaar binnen deze doelen blijft.