Terug naar de blog
28 augustus 2026

MKB: binnen uren herstellen met een praktisch disaster recoveryplan

Handen die een netwerkkabel aansluiten in de serverruimte

Een disaster recovery plan (DRP) is het gedocumenteerde stappenplan waarmee je organisatie IT-diensten binnen afgesproken hersteltijd en toegestaan dataverlies weer laat draaien. Het beschrijft wie wat doet, welke systemen eerst terugkomen en hoe je terugkeert naar normale bedrijfsvoering. Begin klein: start een bedrijfsimpactanalyse en print je bellijst en runbooks. Astia helpt MKB-bedrijven dit praktisch en zonder overbodige complexiteit op te zetten.

Kort samengevat:

  • Een effectief DRP vereist het uitvoeren van een bedrijfsimpactanalyse om prioriteiten en RTO/RPO-waarden per systeem vast te leggen.
  • Het plannen en testen van failback-trajecten is cruciaal, omdat veel plannen stoppen bij herstel en niet rekening houden met het terugkeren naar de normale situatie.
  • Back-upregels zoals de 3-2-1 methode blijven essentieel, maar vereisen aanvullende replicatie en out-of-band planopslag bij strikte RTO-eisen.
  • Het periodiek testen van het DRP moet volgens een vaste frequentie, afhankelijk van de kritikaliteit van systemen, en moet inclusief communicatie- en rollenprocedures.
  • Een georganiseerde, gecommuniceerde en periodiek geactualiseerde aanpak voorkomt dat een DRP bij een echte crisis niet bruikbaar blijkt te zijn.

Inhoudsopgave

Wat staat er in een disaster recovery plan?

Een DRP verschilt van een bedrijfscontinuïteitsplan (BCP) en een incidentresponsplan (IRP), maar hangt er nauw mee samen. Het BCP kijkt naar de hele organisatie, inclusief mensen en processen. Het IRP richt zich op de eerste reactie bij een cyberincident. Het DRP is specifiek gericht op het herstellen van IT-systemen en data na een verstoring.

Een goed DRP bevat minimaal: een risico en impactanalyse, herstelprioriteiten per systeem, RTO en RPO-waarden, een technische herstelstrategie, contactgegevens en escalatiepaden, en een testschema. Het NCSC beschrijft een DRP als het geheel van procedures om een uitwijkvoorziening in gebruik te nemen en daarna veilig terug te keren naar de normale bedrijfsvoering. Die tweedeling, uitwijken en teruggaan, is precies waar veel plannen tekortschieten: ze stoppen bij het herstel en vergeten het failback-traject.

Schema van de onderdelen van een rampenherstelplan

Zo bouw je stap voor stap een disaster recovery plan

Een DRP schrijf je niet in één middag, maar de opbouw is wel logisch te volgen. De NCSC benadrukt dat elk scenario een eigen actieplan nodig heeft, met duidelijke rollen voor IT-beheerders.

  1. Voer een bedrijfsimpactanalyse uit. Bepaal welke processen bij uitval het meeste schade veroorzaken en binnen welke tijd ze terug moeten.
  2. Breng systemen en afhankelijkheden in kaart. Welke applicatie draait op welke server, welke koppelingen zijn er met leveranciers of cloudplatforms?
  3. Leg RTO en RPO per dienst vast. Niet elk systeem verdient dezelfde urgentie of hetzelfde budget.
  4. Kies een herstelstrategie. Hot, warm of cold standby, cloudreplicatie of een uitbestede DRaaS-oplossing (disaster recovery as a service).
  5. Stel runbooks en communicatieroutes op. Wie doet wat, in welke volgorde, en wie informeert klanten en medewerkers?

Deze volgorde voorkomt de meest gemaakte fout: eerst technologie kiezen en daarna pas bedenken wat je eigenlijk moet beschermen. Dat draait de zaak om.

Hoe bepaal je RTO en RPO met een bedrijfsimpactanalyse?

Een bedrijfsimpactanalyse (BIA) meet twee dingen: de financiële en operationele schade per uur uitval, en de afhankelijkheden tussen systemen. Je hebt hiervoor omzetcijfers per proces nodig, klantcontracten met serviceniveaus, en een overzicht van welke applicaties elkaar nodig hebben om te functioneren.

Uit de BIA volgen je herstelpunten vrijwel automatisch. RTO (recovery time objective) en RPO (recovery point objective) definiëren respectievelijk de maximale tolerantie voor downtime en dataverlies, en worden meestal per systeem apart vastgesteld op basis van businesskritikaliteit.

Een voorbeeld uit de praktijk: een webshop merkt dat elke uur downtime op de bestelmodule direct omzet kost. Die module krijgt een RTO van 1 uur en een RPO van 15 minuten. Het interne urenregistratiesysteem, dat niet klantgericht is, krijgt een RTO van 24 uur.

  • Kritieke klantsystemen: RTO onder 1 uur, RPO van minuten
  • Bedrijfskritische backoffice-applicaties: RTO van enkele uren, RPO van uren
  • Ondersteunende interne tools: RTO van één werkdag, RPO van een dag

Belangrijk: hoe strakker je RTO en RPO, hoe hoger de kosten voor redundantie en replicatie. Een BIA voorkomt dat je overal het duurste niveau kiest terwijl dat nergens nodig is.

Back-ups en redundantie: de 3-2-1 regel toepassen

De 3-2-1 backup-regel, drie kopieën van je data, op twee verschillende media, waarvan één off-site, blijft de meest praktische basis voor MKB-back-upbeleid. Voor een klein bedrijf betekent dit vaak: de productiedata, een lokale back-up op een NAS, en een versleutelde kopie in de cloud buiten het eigen netwerk.

Replicatie of een uitbestede DRaaS-oplossing wordt zinvoller zodra je RTO onder de vier uur zakt. Alleen back-ups terugzetten kost simpelweg te veel tijd als een systeem binnen een uur weer moet draaien; dan heb je een tweede, direct inzetbare omgeving nodig.

Er is één stap die bedrijven structureel overslaan: het DRP zelf en de bijbehorende runbooks bewaren op het netwerk dat je net probeert te herstellen. Bewaar het plan out-of-band, fysiek geprint of als versleutelde kopie buiten de productieomgeving.

Pro-tip: print je bellijst en de eerste vijf herstelstappen op papier en bewaar ze in een kluis. Bij ransomware is precies dat papieren exemplaar vaak het enige dat nog toegankelijk is.

Hoe test je een disaster recovery plan?

Een DR-testplan valideert of je RTO en RPO in de praktijk haalbaar zijn, niet alleen op papier. Een failover test en een volledige DR-test zijn niet hetzelfde: failover testing valideert uitsluitend de overstap naar back-upcomponenten, terwijl DR-testing breder is en ook dataherstel en communicatie onder crisisomstandigheden omvat. Voer failover tests vaker uit, bijvoorbeeld regelmatig per jaar, en plan volledige DR-tests minstens jaarlijks.

Typische testscenario’s zijn regionale uitval van een datacenter, databasecorruptie na een fout in een update, en netwerkpartitionering waarbij locaties elkaar niet meer bereiken.

  1. Pre-test checklist: communiceer de test vooraf, zet een rollback-moment vast, en isoleer testomgevingen van productie.
  2. Voer de test uit volgens het scenario en meet vanaf het eerste moment van simulatie.
  3. Leg een post-test rapport vast met afwijkingen tussen geplande en werkelijke tijden.

Een pre-test checklist voorkomt testfouten die onbedoeld productieproblemen veroorzaken, iets wat vaker gebeurt dan bedrijven willen toegeven.

Meetpunt Wat het meet Waarom het telt
TTD (time to detect) Tijd tussen incident en signalering Bepaalt hoe laat je herstel start
TTA (time to acknowledge) Tijd tussen signalering en actie van het team Toont of escalatie werkt
RTO gemeten Werkelijke hersteltijd tijdens de test Vergelijk met je afgesproken doel
RPO gemeten Werkelijk dataverlies bij herstel Toont of backupfrequentie klopt

Organisaties testen structureel te weinig en vertrouwen op schattingen in plaats van gemeten tijden, terwijl alleen echte metingen laten zien of het plan houdt.

Implementatiechecklist: rollen, bellijst en failback

Een DRP zonder duidelijke rolverdeling levert tijdens een echte crisis vooral verwarring op. Leg minimaal vast:

  • Wie mag officieel een ramp uitroepen en het DRP activeren
  • Wie de technische herstelacties uitvoert per systeem
  • Wie klanten, medewerkers en eventueel toezichthouders informeert
  • Welke escalatieniveaus gelden en na hoeveel tijd je opschaalt
  • Welke criteria bepalen of je mag failbacken naar de oorspronkelijke omgeving
Onderdeel Vastleggen als
Bellijst Namen, rollen, telefoonnummers, backup-contactpersoon
Escalatieniveau’s Tijdslimiet per niveau voordat je opschaalt
Failback-criteria Concrete voorwaarden: data-integriteit, prestatietest, akkoord verantwoordelijke
Versiebeheer runbooks Datum laatste update en naam van de eigenaar

Documenteer draaiboeken in een centrale kennisbank zodat iedereen dezelfde, actuele versie gebruikt. Een verouderd runbook dat naar een server verwijst die drie migraties geleden is uitgefaseerd, is geen theoretisch risico. Het gebeurt continu.

Hoe hou je het plan up-to-date?

Een DRP dat je één keer schrijft en daarna in een la legt, is over een jaar waardeloos. Koppel je testfrequentie aan het criticaliteitsniveau: kritieke systemen test je elk kwartaal, middelkritische systemen halfjaarlijks en ondersteunende systemen jaarlijks.

Verbind het plan aan je change management proces. Elke infrastructuurwijziging, nieuwe applicatie of leverancierswissel is een trigger om het DRP te controleren en zo nodig aan te passen. Zonder die koppeling loopt het plan binnen enkele maanden achter de werkelijkheid aan.

Wijs één eigenaar aan die verantwoordelijk is voor updates en rapportage. Een managementrapport na elke test bevat minstens: gemeten RTO en RPO tegenover de doelstelling, gevonden afwijkingen, en concrete actiepunten met deadline. Dat rapport hoort standaard op de agenda van het managementoverleg te staan, niet ergens onderaan een IT-notulen.

Risicobeoordeling en dreigingsanalyse in de praktijk

Een DRP zonder risicobeoordeling is giswerk. Voordat je herstelstrategieën bepaalt, moet je weten welke dreigingen je organisatie daadwerkelijk raken en hoe waarschijnlijk elk scenario is.

Onderscheid drie categorieën dreigingen: fysieke risico’s zoals stroomuitval, brand of wateroverlast, technische risico’s zoals hardwarefalen of softwarefouten, en menselijke risico’s zoals cyberaanvallen, phishing of onbedoelde verwijdering van data door een medewerker. Elke categorie vraagt een andere aanpak binnen je plan.

Voor elk risico bepaal je de kans van optreden en de impact bij optreden. Een overstroming is voor een bedrijf op een industrieterrein bij een rivier een reëel risico; voor een kantoor op de vierde verdieping in een stadscentrum nauwelijks. Ransomware daarentegen is voor vrijwel elk bedrijf met digitale systemen een reëel risico, ongeacht locatie.

Leg de uitkomst vast in een risicomatrix met twee assen: waarschijnlijkheid en impact. Risico’s met hoge waarschijnlijkheid én hoge impact krijgen voorrang in je herstelstrategie en verdienen een uitgewerkt scenario met concrete stappen. Risico’s met lage waarschijnlijkheid maar hoge impact, zoals een volledige brand in je serverruimte, verdienen minder gedetailleerde uitwerking maar wel een duidelijk vangnet, zoals een externe back-up.

Herhaal deze analyse jaarlijks of bij grote veranderingen in je IT-omgeving. Een dreigingslandschap van twee jaar geleden zegt weinig over de risico’s van vandaag. Ransomwaregroepen veranderen tactieken, nieuwe kwetsbaarheden duiken op in software die je al jaren gebruikt, en je eigen infrastructuur groeit mee met het bedrijf.

Risicobeoordeling en dreigingsanalyse in de praktijk — overview diagram

Welke bedrijfsprocessen krijgen voorrang bij herstel?

Niet elk systeem is even belangrijk, en dat is precies waarom prioritering de kern van een goed DRP vormt. Zonder duidelijke rangorde ga je bij een echte crisis kostbare tijd verliezen aan discussies over wat eerst moet.

Rangschik processen op basis van drie criteria: directe omzetimpact, wettelijke of contractuele verplichtingen, en afhankelijkheid van andere systemen. Een factureringssysteem dat de omzetstroom stillegt, staat vrijwel altijd hoger dan een intern planningstool, ook als beide “belangrijk” aanvoelen voor de afdelingen die ze gebruiken.

Werk met duidelijke niveaus in plaats van een lange, ongestructureerde lijst:

  • Niveau 1, bedrijfskritisch: systemen die binnen uren terug moeten, anders stopt de bedrijfsvoering direct
  • Niveau 2, belangrijk: systemen die binnen een werkdag terug moeten, met tijdelijke workarounds mogelijk
  • Niveau 3, ondersteunend: systemen die een paar dagen kunnen wachten zonder directe schade

Een veelgemaakte fout is dat elke afdeling haar eigen systeem als niveau 1 beschouwt. Leg de uiteindelijke prioritering daarom vast op directieniveau, gebaseerd op de uitkomsten van je bedrijfsimpactanalyse, niet op de mening van de luidste afdeling. Dat voorkomt scheve keuzes op het moment dat het er echt op aankomt.

Herstelstrategieën per type ramp

Niet elke verstoring vraagt om dezelfde herstelaanpak. Een natuurramp, een cyberaanval en een menselijke fout hebben andere kenmerken, en dus ook andere herstelstrategieën nodig binnen hetzelfde DRP.

Bij natuurrampen, zoals overstroming, brand of langdurige stroomuitval, is het probleem meestal fysiek: je apparatuur of locatie is niet meer bruikbaar. De oplossing ligt in geografische spreiding. Zorg dat je back-up en, indien van toepassing, je uitwijkomgeving in een andere regio staan dan je hoofdlocatie.

Bij cyberaanvallen, met name ransomware, ligt het probleem anders: je data is mogelijk versleuteld of gestolen, maar je fysieke infrastructuur werkt nog. Hier is de kwaliteit van je back-ups cruciaal, specifiek of ze onveranderbaar zijn (immutable) en gescheiden van het netwerk dat besmet kan raken. Herstel begint hier vaak met isolatie: koppel getroffen systemen los voordat je begint met terugzetten, anders herbesmet je je herstelde omgeving direct.

Bij menselijke fouten, zoals een medewerker die per ongeluk een database verwijdert of een verkeerde configuratie doorvoert, draait herstel vaak om snelheid en granulariteit. Kun je specifiek dat ene bestand of die ene tabel terugzetten, of moet je een volledige systeemherstel doen? Versiebeheer en point-in-time recovery zijn hier waardevoller dan bij de andere scenario’s.

Het gemeenschappelijke element in alle drie: test elk scenario apart. Een herstelprocedure die werkt bij stroomuitval, werkt niet automatisch bij ransomware, omdat de aannames over wat nog wél werkt volledig anders liggen.

Hoe past een DRP in je bedrijfscontinuïteitsplan?

Een DRP staat niet op zichzelf. Het is het technische fundament onder een breder bedrijfscontinuïteitsplan (BCP), dat ook kijkt naar mensen, locaties, leveranciers en klantcommunicatie tijdens een crisis.

Het verschil is concreet: je DRP beschrijft hoe je de e-mailserver, de boekhoudapplicatie en het CRM-systeem weer online krijgt. Je BCP beschrijft waar medewerkers werken als het kantoor onbereikbaar is, hoe je klanten informeert over vertraging, en welke leveranciers een alternatief bieden als je vaste partner uitvalt.

Beide plannen moeten op elkaar aansluiten. Als je BCP stelt dat medewerkers binnen een dag vanuit huis moeten kunnen werken, moet je DRP garanderen dat de cloudwerkplek en de bijbehorende samenwerkingstools binnen die tijd beschikbaar zijn. Zonder die afstemming loop je het risico dat je BCP beloftes maakt die je DRP technisch niet kan waarmaken.

In de praktijk werkt het goed om beide documenten los te beheren, maar met een gedeelde tabel van kritieke processen en bijbehorende RTO’s als koppelpunt. Zo hoeft niemand twee keer dezelfde impactanalyse te maken, en blijft de technische kant van herstel consistent met de organisatorische kant.

Waarom training het verschil maakt bij een echte uitval

Het beste DRP faalt als niemand weet dat het bestaat, of hoe het te gebruiken. Training is geen bijzaak, het is de reden dat een plan tijdens een crisis daadwerkelijk werkt in plaats van dat iedereen naar elkaar kijkt.

Begin met een jaarlijkse walkthrough voor het kernteam: de mensen die het plan bij een echte uitval moeten uitvoeren. Loop het scenario samen door zonder systemen daadwerkelijk uit te schakelen, en controleer of iedereen zijn rol en de eerste stappen kent.

Bredere medewerkers hebben geen technische kennis van het DRP nodig, maar wel bewustzijn: wat te doen bij een vermoeden van een cyberincident, wie te bellen, en dat ze zelf niets moeten proberen te herstellen. Een medewerker die uit paniek zelf bestanden terugzet vanaf een oude lokale kopie, kan een zorgvuldig opgebouwd herstelproces in de war schoppen.

Herhaling is hier belangrijker dan diepgang. Een korte jaarlijkse opfrissing van het kernteam, gecombineerd met een kwartaal e-mail of korte sessie voor de rest van de organisatie, houdt het plan levend zonder dat het een grote tijdsinvestering wordt. Actuele handleidingen en trainingsmateriaal helpen om die herhaling laagdrempelig te maken.

Wat kost een disaster recovery plan?

De kosten van disaster recovery vallen in drie categorieën: de tijd om het plan te schrijven en te onderhouden, de technische infrastructuur voor back-up en herstel, en de kosten van periodiek testen.

Het schrijven van het eerste plan kost vooral interne tijd: een bedrijfsimpactanalyse, gesprekken met afdelingshoofden, en het uitwerken van runbooks. Voor een MKB-bedrijf is dit meestal een project van enkele weken, niet maanden, als je de scope beperkt houdt tot je werkelijk kritieke systemen.

De technische kosten hangen sterk af van je gekozen RTO en RPO. Hoe strakker die doelen, hoe meer je uitgeeft aan redundante infrastructuur, replicatie of een uitbestede DRaaS-dienst. Een systeem met een RTO van 24 uur kan vaak toe met dagelijkse back-ups naar de cloud. Een systeem met een RTO van een uur vraagt om een tweede, direct inzetbare omgeving, en dat kost aanzienlijk meer per maand.

Testkosten worden vaak onderschat. Een volledige DR-test kost tijd van je IT-team en mogelijk een tijdelijke impact op productiesystemen als je niet zorgvuldig isoleert. Reken dit mee als structurele post, niet als eenmalige uitgave.

De meest kostenefficiënte aanpak is prioritering: geef je duurste beschermingsniveau alleen aan systemen die het echt verdienen, en houd de rest bewust eenvoudiger. Bedrijven die dit onderscheid overslaan, betalen vaak jaren lang voor bescherming die ze nergens gebruiken.

Astia-perspectief: wat er in de praktijk vaak misgaat

De meest gemaakte fout die ik zie: het DRP staat opgeslagen op hetzelfde netwerk dat het moet redden. Bij ransomware is dat plan dan net zo onbereikbaar als de rest. Op de tweede plaats staat een plan dat nooit getest is. Op papier klopt het, in de praktijk blijkt de back-up drie maanden oud te zijn. Mijn advies: begin klein, test binnen drie maanden je eerste scenario, en automatiseer herstelstappen waar het kan. Een plan dat je nooit uitprobeert, is geen plan. Het is een aanname.

— Mick

Hoe Astia je helpt met een werkend disaster recovery plan

Een DRP op papier is één stap, een DRP dat daadwerkelijk werkt tijdens een storing is een andere. Astia bouwt en test disaster recovery oplossingen die aansluiten op wat je als MKB-bedrijf echt nodig hebt, zonder de overkill van een enterprise-traject en zonder dat je zelf specialistische kennis in huis moet halen.

Astia

Onze back-up en disaster recovery diensten combineren geautomatiseerde back-ups, off-site opslag en periodieke failover tests, zodat je RTO en RPO geen schatting blijven maar een gemeten resultaat. Dat werkt het best in combinatie met beheerd netwerkbeheer, zodat redundantie niet alleen op dataniveau maar ook op infrastructuurniveau geregeld is. Bekijk via Astia hoe een managed werkplek herstel binnen uren mogelijk maakt in plaats van dagen, en vraag een vrijblijvende scan aan om te zien waar je huidige plan de grootste gaten vertoont.

Bronnen

Aanbevelingen