Wat is Disaster Recovery?
Disaster Recovery (DR) is het vooraf geplande en geteste geheel aan processen, middelen en technologie waarmee een organisatie haar kritieke systemen, data en infrastructuur binnen een afgesproken tijd herstelt na een ernstige verstoring, zoals een cyberaanval, brand, overstroming, langdurige stroomuitval of een menselijke fout. Waar Business Continuity bepaalt hoe de organisatie tijdens een crisis blijft leveren, regelt DR het technische herstel (recovery) van de onderliggende systemen. In omgevingen waar IT en OT samenkomen, gaat het daarbij niet alleen om servers en databases, maar ook om PLC-programma’s, SCADA-servers en netwerkconfiguraties die een fysiek proces aansturen.
🎯 Tegen welke scenario’s beschermt Disaster Recovery?
Een disaster-recoveryplan (DRP) wordt per scenario uitgewerkt, omdat elk scenario een andere herstelroute vraagt:
| Categorie | Voorbeelden | Typisch herstel |
|---|---|---|
| Cyberaanval | Ransomware, wipers, sabotage, langdurige DDoS | Schone herbouw vanuit offline back-ups, na forensisch onderzoek |
| Fysieke rampen | Brand in een serverruimte, wateroverlast, blikseminslag | Uitwijk naar een tweede locatie of vervangende hardware |
| Menselijke fouten | Verwijderde configuraties, corrupte databases, mislukte updates | Terugzetten van de laatste goede versie (restore) |
| Technisch falen | Defecte servers, storage, netwerkapparatuur of stroomvoorziening | Failover naar redundante componenten |
| OT-incidenten | Verloren PLC-logica, kapotte HMI, uitgevallen SCADA-server | Herladen van goedgekeurde projecten op reservehardware |
Het belangrijkste verschil tussen deze scenario’s: bij een technische storing zijn uw back-ups betrouwbaar, bij een cyberaanval niet vanzelfsprekend. Een aanvaller kan al weken in het netwerk zitten, zodat ook recente back-ups besmet kunnen zijn.
🔄 Wat is het verschil tussen back-up, Disaster Recovery en Business Continuity?
Deze drie begrippen worden vaak door elkaar gebruikt, maar ze bouwen op elkaar voort:
| Begrip | Vraag die het beantwoordt | Resultaat |
|---|---|---|
| Backup | Heb ik een bruikbare kopie van data en configuraties? | Herstelpunten, bepaald door de RPO |
| Disaster Recovery | Hoe krijg ik de systemen binnen de RTO weer werkend? | Herstelprocedures, uitwijklocatie, reservehardware |
| Business Continuity | Hoe blijft de organisatie leveren terwijl systemen uitliggen? | Noodprocedures, handmatige bediening, communicatie |
| Incidentrespons | Hoe beperk en onderzoek ik een beveiligingsincident? | Isolatie, analyse, melding |
Een back-up zonder herstelprocedure is dus nog geen DR, en een DR-plan zonder continuïteitsplan laat open wat de fabriek doet in de uren of dagen dat het herstel duurt. In de praktijk staan alle vier in één samenhangend raamwerk, vaak gestuurd vanuit ISO 22301.
🔢 Welke hersteldoelen en uitwijkvormen zijn er?
Het DR-ontwerp begint bij twee getallen uit de Business Impact Analysis: de RTO (Recovery Time Objective, hoe lang een systeem maximaal mag uitliggen) en de RPO (Recovery Point Objective, hoeveel data u maximaal mag verliezen, uitgedrukt in tijd). Beide moeten passen binnen de MTPD, de periode waarna uitval onaanvaardbaar wordt. Achteraf toetst u met de MTTR of de werkelijke hersteltijd binnen de RTO bleef.
Hoe korter de RTO, hoe duurder de uitwijkvorm. De gangbare indeling, met indicatieve hersteltijden:
| Uitwijkvorm | Wat staat klaar | Indicatieve hersteltijd | Toepassing in OT |
|---|---|---|---|
| High Availability-paar | Actieve tweede server met realtime synchronisatie | Seconden tot minuten | Redundante SCADA-servers, DCS-controllers |
| Hot site | Volledig ingerichte tweede locatie met actuele data | Minuten tot uren | Tweede controlekamer bij nutsbedrijven |
| Warm site | Hardware en netwerk aanwezig, data en software moeten nog worden geladen | Uren tot dagen | Reserveservers met virtuele machines |
| Cold site | Ruimte, stroom en koeling, maar geen ingerichte systemen | Dagen tot weken | Zelden geschikt voor productie |
| Reservehardware | Identieke PLC’s, voedingen en I/O-kaarten op voorraad | Uren | Standaard voor kritieke besturingen |
Een veiligheidsfunctie valt buiten dit rijtje: die wordt niet “hersteld”, maar zo ontworpen dat een storing tot een veilige toestand leidt (fail-safe), vaak met redundantie.
🔐 Welke wetten en normen eisen Disaster Recovery?
- NIS2, artikel 21 lid 2 onder c - noemt letterlijk “bedrijfscontinuïteit, zoals back-upbeheer en noodvoorzieningenplannen, en crisisbeheer” als verplichte maatregel; in de Engelse tekst staat daar “disaster recovery”
- Cyberbeveiligingswet - de Nederlandse omzetting van NIS2, sinds 15 augustus 2026 van kracht; het Cyberbeveiligingsbesluit vraagt in artikel 9 herstelprocedures, periodiek geverifieerde back-ups en een continuïteits-, herstel- en crisisplan dat periodiek wordt getest
- ISO 27001:2022 - beheersmaatregelen A.5.30 (ICT-gereedheid voor bedrijfscontinuïteit), A.8.13 (back-up van informatie) en A.8.14 (redundantie van informatieverwerkende faciliteiten)
- IEC 62443-3-3 - systeemeis SR 7.3 (back-up van het besturingssysteem, vanaf security level 1) en SR 7.4 (herstel en reconstitutie naar een bekende, veilige toestand)
- NIST CSF 2.0 (februari 2024) - de functie Recover met de categorieën RC.RP (uitvoering van het herstelplan) en RC.CO (communicatie tijdens herstel); RC.RP-03 eist dat u de integriteit van back-ups controleert voordat u ze terugzet
- NIST SP 800-34 Rev. 1 - de Amerikaanse handleiding voor contingency planning uit 2010, nog steeds een veelgebruikte bron voor de opbouw van een DR-plan
🏭 Waarom is Disaster Recovery in OT anders?
Een OT-omgeving herstelt u niet door simpelweg een server-image terug te zetten. Belangrijke verschillen:
- Volgorde is bepalend - eerst netwerk en Active Directory, dan engineering stations en licentieservers, daarna SCADA en historian, en pas dan het opstarten van het proces
- Software is tijdgebonden - een HMI-project draait alleen op de juiste softwareversie; oude installatiebestanden en licenties zijn vaak niet meer te downloaden en moeten zelf worden bewaard
- Online versus offline - het programma in de PLC kan afwijken van het projectbestand op de laptop; zonder change management en versiebeheer weet u niet welke versie de goede is
- Firmware - moet passen bij het project en zit meestal niet in een projectback-up; bewaar de juiste firmwarebestanden van de leverancier daarom zelf
- Fysiek opstarten - na herstel moet een installatie gecontroleerd worden opgestart, met operators en procesengineers, niet alleen met IT
- Segmentatie - goede scheiding tussen IT en OT beperkt hoeveel u moet herstellen; bij Colonial Pipeline (mei 2021) werd alleen IT geraakt, maar lag de pijpleiding uit voorzorg zes dagen stil
De bekendste les komt van NotPetya (juni 2017). Maersk moest ongeveer 4.000 servers en 45.000 pc’s opnieuw installeren. Back-ups van de servers waren er, maar alle domeincontrollers waren tegelijk gewist; het Active Directory kon alleen worden hersteld dankzij één domeincontroller in Ghana die door een stroomstoring offline was geweest.
🔧 Hoe stelt u een disaster-recoveryplan op?
- Inventariseer - leg vast welke systemen er zijn, met versies en afhankelijkheden, op basis van een actuele asset-inventaris
- Bepaal risico’s en hersteldoelen - een risicoanalyse, plus RTO en RPO per systeem uit de business impact analysis, afgestemd met productie
- Kies de herstelstrategie - HA, uitwijklocatie, reservehardware of herbouw, per systeem passend bij de RTO
- Borg de back-ups - 3-2-1-1-0 met minimaal één offline of immutable kopie, gescheiden van het domein; bewaar ook installatiemedia, licenties en golden images
- Schrijf runbooks - stap-voor-stap herstelprocedures per systeem, met herstelvolgorde, contactpersonen en leveranciers, ook op papier beschikbaar
- Test en oefen - van een tabletop-oefening tot een volledige hersteltest op reservehardware; een jaarlijkse hersteltest is een gangbaar minimum, en train ook de mensen die het plan moeten uitvoeren
- Evalueer en verbeter - verwerk testresultaten en incidenten in het plan, en werk het bij na elke wijziging in de installatie
Bij een cyberaanval komt daar één stap bij: zet niets terug voordat duidelijk is hoe de aanvaller binnenkwam. Controleer back-ups op malware en herbouw bij twijfel vanaf schone installatiemedia, anders herstelt u de aanvaller mee.
❓ Veelgestelde vragen
Wat is een disaster-recoveryplan (DRP)?
Een disaster-recoveryplan is het gedocumenteerde draaiboek dat beschrijft hoe een organisatie haar kritieke IT- en OT-systemen na een ernstige verstoring herstelt. Het bevat de hersteldoelen (RTO en RPO), de herstelvolgorde, de stap-voor-stap procedures per systeem, de verantwoordelijken en de contactgegevens van leveranciers.
Hoe vaak moet u een disaster-recoveryplan testen?
Een disaster-recoveryplan moet minimaal jaarlijks worden getest en daarnaast na elke grote wijziging in de installatie. Het Cyberbeveiligingsbesluit schrijft geen vaste termijn voor, maar eist periodieke tests die u kunt aantonen. Een hersteltest van een PLC-programma op reservehardware levert meer bewijs dan alleen een papieren controle.
Is een back-up hetzelfde als Disaster Recovery?
Nee, een back-up is een kopie van data of configuraties, terwijl Disaster Recovery het volledige herstelproces omvat: hardware, netwerk, software, licenties, herstelvolgorde en mensen. Een back-up is een noodzakelijk onderdeel van Disaster Recovery, maar zonder geteste herstelprocedure weet u niet of en hoe snel u ermee kunt herstellen.
Is Disaster Recovery verplicht onder NIS2?
Ja, artikel 21 van NIS2 noemt back-upbeheer en noodvoorzieningenplannen (in de Engelse tekst: disaster recovery) expliciet als verplichte maatregel voor essentiële en belangrijke entiteiten. In Nederland is dit uitgewerkt in de Cyberbeveiligingswet en artikel 9 van het Cyberbeveiligingsbesluit, die sinds 15 augustus 2026 gelden.
Wat is het verschil tussen RTO en RPO bij Disaster Recovery?
De RTO is de maximale tijd die een systeem mag uitliggen voordat de gevolgen onaanvaardbaar worden, de RPO is de maximale hoeveelheid data die verloren mag gaan, uitgedrukt in tijd. De RTO bepaalt de herstelstrategie en uitwijkvorm, de RPO bepaalt hoe vaak back-ups of replicatie moeten plaatsvinden.
Kan Disaster Recovery in OT via de cloud?
Gedeeltelijk: back-ups van projecten, historian-data en virtuele servers kunnen in de cloud worden bewaard, en sommige SCADA-servers kunnen daar tijdelijk draaien. De besturing van het fysieke proces blijft echter lokaal, en herstel van PLC’s vraagt altijd toegang tot de installatie zelf. Een offline kopie op de eigen locatie blijft daarom nodig.
📌 Samengevat
Disaster Recovery is het geplande en geteste herstel van kritieke systemen na een ernstige verstoring, gestuurd door RTO en RPO en verplicht onder NIS2 en de Cyberbeveiligingswet. In IT/OT-omgevingen draait het niet alleen om back-ups, maar om de juiste herstelvolgorde, bewaarde software en licenties, reservehardware en geoefende mensen die een installatie veilig weer kunnen opstarten.