"We hebben back-ups" is het antwoord dat de meeste MKB-bedrijven geven als je vraagt hoe ze een brand in de serverruimte, een kapotte RAID-array of een hele slechte dag bij hun cloudleverancier zouden overleven. Het is ook het verkeerde antwoord op de vraag die er eigenlijk toe doet. Een back-up zegt je of je data nog ergens bestaat. Een uitwijkplan zegt je hoelang je bedrijf daadwerkelijk plat ligt, in welke volgorde je systemen terugkomen, en wie wat doet terwijl die klok loopt. Genoeg bedrijven met uitstekende back-ups verliezen alsnog een hele week aan een op zich herstelbare storing, omdat niemand de tweede helft van het antwoord had opgeschreven.
Dit gaat niet specifiek over ransomware, en ook niet over Microsoft 365-retentie — die komen elders aan de orde. Een uitwijkplan moet werken ongeacht waarom een systeem uitvalt: een kapotte schijf, een mislukte update, een contractor die de verkeerde map verwijdert, een brand, of een storing bij een cloudregio waar u part noch deel aan heeft. De oorzaak verandert het forensisch onderzoek. Het verandert niets aan hoe herstel eruit moet zien.
RTO en RPO: de twee getallen die een herstel echt sturen
Twee metingen doen bijna al het werk in een uitwijkplan, en de meeste MKB-bedrijven die er nooit een hebben opgeschreven hebben er ook nog nooit bewust een vastgesteld.
Recovery Time Objective (RTO) is hoelang een systeem plat mag liggen voordat de schade onacceptabel wordt. Niet "hoelang zouden we het liever willen hebben" — hoelang kan het daadwerkelijk duren voordat bestellingen stilvallen, de salarisbetaling een deadline mist, of klanten een concurrent gaan bellen.
Recovery Point Objective (RPO) is hoeveel data u zich kunt veroorloven te verliezen, uitgedrukt in tijd in plaats van bestanden. Een RPO van vier uur betekent dat als de storing om 14:00 uur toeslaat, u kunt accepteren dat u alles verliest wat is veranderd sinds de back-up van 10:00 uur. Het is een directe uitspraak over hoe vaak een bepaald systeem daadwerkelijk geback-upt moet worden, geen abstract streefcijfer.
De fout die bijna elk MKB-bedrijf maakt, is één RTO en één RPO vaststellen voor "het bedrijf" als geheel. Dat is de verkeerde eenheid. Een ordersysteem dat het magazijn stillegt als het uitvalt, heeft een heel andere RTO dan een intern rapportagedashboard dat niemand bekijkt tot maandag. Ze per systeem vaststellen, ook al is het ruw, is wat het plan omzet in iets waar u tijdens een storing daadwerkelijk naar kunt handelen, in plaats van een vage belofte dat alles "snel" weer goed komt.
Wat een uitwijkplan daadwerkelijk moet bevatten
Een plan dat alleen bestaat als vage kennis in het hoofd van één persoon is geen plan — het is een single point of failure die toevallig een mens is. Het document zelf moet vier dingen dekken:
Een systeeminventarisatie met afhankelijkheden. Breng in kaart wat u draait en, cruciaal, wat van wat afhangt. Een ordersysteem dat een facturatietool voedt die weer een rapportagedashboard voedt, is één herstelvolgorde, geen drie losse — en het systeem aan het begin van die keten moet als eerst terug, ongeacht hoe "belangrijk" het op zichzelf lijkt.
Een prioriteitsvolgorde gekoppeld aan de RTO's die u heeft vastgesteld. Zodra u weet welke systemen een uur storing kunnen verdragen en welke een dag, volgt de herstelvolgorde daar grotendeels automatisch uit. Weersta de verleiding om degene die tijdens een incident het hardst roept die volgorde ter plekke te laten omgooien.
Stap-voor-stap herstelprocedures per systeem — niet "herstel vanuit back-up", maar welke back-up, waar opgeslagen, teruggezet naar welk doel, hoe gecontroleerd, en overgedragen aan welk team om te bevestigen dat het daadwerkelijk werkt voordat het als afgerond geldt. Een stap die alleen logisch is voor de ene persoon die het normaal doet, is een stap die faalt op de dag dat die persoon onbereikbaar is.
Benoemde rollen, geen benoemde personen. Wie verklaart dat dit een ramp is en geen storing van vijf minuten? Wie spreekt medewerkers toe, en als het klanten raakt, wie spreekt hen toe? Wie heeft het mandaat om een ongewone beslissing te nemen — noodhardware betalen, een tijdelijke omweg opzetten — zonder te wachten tot iemand die op vakantie is de telefoon opneemt? Wijs de rol toe, en benoem dan een vervanger voor die rol, want precies de persoon op het kritieke pad van uw herstelplan is ook precies het type persoon dat af en toe ziek wordt, op reis is, of simpelweg niet opneemt.
Een detail dat meer bedrijven struikelt dan het zou moeten: waar staat het plan zelf? Een uitwijkplan dat alleen op de fileserver staat die mogelijk zelf het probleem is, is niet beschikbaar op het moment dat u het nodig heeft. Houd een kopie ergens die daadwerkelijk onafhankelijk is van uw eigen infrastructuur — en in een vorm die een niet-technische manager kan volgen als net de gebruikelijke IT-contactpersoon onbereikbaar is.
Testen is de stap die bijna iedereen overslaat
Een plan dat nooit is getest, is een theorie. Drie niveaus van testen, ruwweg van goedkoopst naar meest realistisch:
Een tabletopoefening. Loop een scenario — een ransomware-versleuteling, een kapotte server, een overstroomd kantoor — hardop door met de mensen die er daadwerkelijk bij betrokken zouden zijn, zonder ook maar één systeem aan te raken. Hier ontdekt u dat twee mensen allebei dachten dat de ander het noodnummer van de leverancier had, of dat niemand eigenlijk weet waar het as-built netwerkdiagram ligt.
Een onderdeeltest. Zet daadwerkelijk één systeem terug vanuit de back-up naar een apart doel en bevestig dat het werkt, in plaats van erop te vertrouwen dat een back-upjob die zonder foutmelding afrondt, betekent dat de data erin bruikbaar is. Dit is de meest voorkomende tekortkoming: back-ups die elke nacht draaien, elke nacht succes melden, en nog nooit door een mens zijn teruggezet en geopend.
Een volledige uitwijktest. Simuleer de echte storing zo realistisch als redelijkerwijs kan en voer de daadwerkelijke herstelprocedure van begin tot eind uit, met de klok mee tegen de RTO die u heeft vastgesteld. Dit is lastiger in te plannen en is waar u leert of uw "RTO van vier uur" ooit realistisch was, of gewoon een getal dat acceptabel klonk in een vergadering.
U hoeft geen volledige uitwijktest maandelijks te draaien. U moet wel minstens één keer per jaar iets testen, en opnieuw na elke verandering die groot genoeg is om wat de vorige test bewees ongeldig te maken — een nieuw kernsysteem, een cloudmigratie, een andere back-upleverancier. Een plan dat twee reorganisaties geleden is geschreven en nooit herzien, is in de praktijk geen plan.
Waar dit raakt aan wat u al heeft
Een uitwijkplan gaat ervan uit dat u werkende back-ups heeft om vanuit te herstellen — het is de laag daarboven, geen vervanging ervan. Als Microsoft 365 onderdeel is van wat u zou moeten herstellen, behandelt onze gids over waarom Office 365-retentie geen back-up is dat specifieke gat rechtstreeks. Is de ramp in kwestie een cyberaanval in plaats van een hardwarestoring, dan behandelt onze gids over ransomware voorkomen in het MKB de maatregelen die verlagen hoe vaak u dit plan ooit nodig heeft. En zit u middenin een cloudmigratie, herzie dan uw herstelplan specifiek voor de nieuwe omgeving zodra u klaar bent — een plan geschreven voor uw oude on-premise server dekt niet automatisch wat er gebeurt als de storing zich bij uw cloudleverancier voordoet in plaats van in uw eigen pand, een punt dat onze gids over cloudmigratie ook benoemt.
De fouten die iedere keer terugkomen
Eén RTO voor alles. Een kritiek ordersysteem en een archief dat niemand opent even urgent behandelen, betekent dat het archief op tijd wordt herstelt en het ordersysteem niet.
Back-ups die nooit zijn teruggezet. Een groen vinkje op een back-upjob bewijst dat de job draaide, niet dat de data erin intact is of dat iemand zich nog herinnert hoe je onder druk moet terugzetten.
Een plan dat alleen in het hoofd van één persoon bestaat, of alleen op een systeem dat zelf plat kan liggen. Beide falen precies op het moment dat u ze nodig heeft.
Niemand die daadwerkelijk de leiding heeft tijdens het incident. Zonder een benoemde rol voor wie de beslissing neemt, gaat het eerste uur van een echte storing op aan een groepsapp vol goede bedoelingen en geen besluiten.
Het plan als afgerond beschouwen zodra het is opgeschreven. Een uitwijkplan is accuraat op de dag dat u het test, en vervalt een beetje met elke systeemwijziging daarna. Ongetest is, voor de praktijk, hetzelfde als niet-bestaand.
Veelgestelde vragen
Wat is het echte verschil tussen een back-up en een uitwijkplan? Een back-up is een kopie van uw data. Een uitwijkplan is het document en de geteste procedure voor hoe die kopie uw systemen weer aan de praat krijgt, in welke volgorde, hoe snel, en wie verantwoordelijk is voor elke stap. U kunt uitstekende back-ups hebben en toch geen echt herstelplan — dat is het meest voorkomende gat in dit onderwerp.
Hoe vaak moeten we ons uitwijkplan testen? Minimaal eens per jaar, plus opnieuw na elke verandering die groot genoeg is om het te beïnvloeden: een nieuw kernsysteem, een cloudmigratie, een andere back-upleverancier. Een plan dat twee jaar en drie systeemwijzigingen geleden accuraat was, is dat vandaag niet per definitie nog.
Wat moeten onze RTO en RPO eigenlijk zijn? Dat hangt volledig af van wat het systeem doet en wat een uur of een dag downtime uw bedrijf kost — er bestaat geen generiek getal dat voor elk MKB-bedrijf past. Stel het per systeem vast op basis van echte operationele impact, niet op wat geruststellend klinkt in een planningsoverleg, en verwacht dat klantgerichte of omzetgevende systemen een strakkere RTO nodig hebben dan interne tools.
Is een uitwijkplan wettelijk verplicht voor een MKB-bedrijf in Nederland? Dat hangt af van uw sector en omvang, en is een andere vraag dan of het een goed idee is — wat het is, los van het juridische antwoord. Onze gids over NIS2 voor het MKB behandelt welke bedrijven onder de reikwijdte van de richtlijn vallen en wat die daadwerkelijk vereist zodra de Nederlandse uitvoeringswet van kracht is. Voor iedereen daarbuiten is dit niet primair een compliancevraag — het gaat om hoeveel dagen omzet een herstelbare storing u kost.
Hoe lang moet het document zelf zijn? Lang genoeg dat iemand anders dan de auteur het onder druk kan volgen, kort genoeg dat het daadwerkelijk wordt bijgehouden. Een grondig plan dat niemand onderhoudt is slechter dan een korter plan dat accuraat weergeeft wat u vandaag draait — complexiteit om de complexiteit is hier de vijand van een plan dat actueel blijft.
De volgorde op orde hebben voordat u het nodig heeft
Een uitwijkplan verdient zijn kosten terug op de ene dag per jaar — of de ene dag in vijf jaar — dat er daadwerkelijk iets misgaat, en is nutteloos als dat ook de eerste keer is dat iemand het volgt. Ons team Cloud Infrastructure bouwt de inventarisatie, de RTO/RPO-doelen per systeem en de geteste herstelprocedures als één samenhangend geheel, geen document dat eenmalig wordt geschreven en vervolgens vergeten. En omdat een uitwijkplan alleen werkt als iemand daadwerkelijk de test draait en het document actueel houdt, kan onze dienst Managed IT-beheer & support dat doorlopende onderhoud overnemen als onderdeel van een breder contract, in plaats van dat het de taak blijft die nooit bovenaan een interne to-dolijst terechtkomt.