Maandagochtend, 8.15 uur: medewerkers kunnen niet aanmelden, facturen blijven hangen en de gedeelde bestanden zijn onbereikbaar. Of erger: een ransomwaremelding verschijnt op meerdere schermen. Wie dan pas moet uitzoeken welke systemen prioritair zijn en waar de laatste bruikbare back-up staat, verliest kostbare uren. Een disaster recovery plan opstellen zorgt ervoor dat uw organisatie ook onder druk doelgericht blijft handelen.
Een disaster recovery plan, vaak afgekort tot DR-plan, beschrijft hoe u kritieke IT-systemen, gegevens en communicatie herstelt na een ernstige storing. Denk aan een cyberaanval, brand, stroomprobleem, defecte server, menselijke fout of uitval bij een cloudleverancier. Het plan gaat verder dan een kopie van uw data. Het legt vast wie beslist, welke systemen eerst terug moeten werken, hoeveel gegevensverlies aanvaardbaar is en hoe u de werking tijdelijk voortzet.
Voor zelfstandigen, KMO’s en scholen is dat geen theoretisch document voor in een map. Het is een praktische afspraak over continuïteit. Want een back-up die niet teruggezet kan worden, een leverancier die niet bereikbaar is of een onduidelijke taakverdeling biedt weinig houvast op het moment dat het echt nodig is.
Begin met de bedrijfsimpact, niet met technologie
De eerste vraag is niet welke back-upsoftware u nodig hebt. De eerste vraag is: wat valt er stil als dit systeem morgen niet beschikbaar is? Een boekhoudpakket heeft voor sommige bedrijven een paar uur minder prioriteit dan een kassasysteem, productieapplicatie, leerlingenplatform of telefonie. Die volgorde verschilt per organisatie.
Breng daarom uw kritieke processen in kaart. Kijk naar wat nodig is om klanten te helpen, bestellingen te verwerken, les te geven, medewerkers te laten werken en betalingen te ontvangen. Noteer vervolgens welke toepassingen, databronnen, toestellen en externe partijen daarbij horen. Vergeet ook identiteiten niet: zonder Microsoft 365-account, multifactor-authenticatie of netwerktoegang kunnen medewerkers vaak nergens meer bij, ook al zijn de gegevens zelf veilig.
Bepaal per proces de maximaal aanvaardbare uitval. Voor telefonie kan dat bijvoorbeeld één uur zijn, voor historische archieven mogelijk een werkdag. Deze oefening voorkomt een veelgemaakte fout: elk systeem dezelfde bescherming geven. Dat maakt een oplossing duurder en complexer, zonder dat de bedrijfscontinuïteit er noodzakelijk beter van wordt.
Leg hersteldoelen concreet vast
Twee afspraken geven richting aan elk goed DR-plan. De Recovery Time Objective, of RTO, bepaalt hoe snel een dienst opnieuw moet werken. De Recovery Point Objective, of RPO, bepaalt hoeveel gegevensverlies u maximaal accepteert.
Stel dat uw RPO vier uur bedraagt. Dan moet uw back-upstrategie ervoor zorgen dat u bij een incident hoogstens vier uur werk verliest. Een RTO van twee uur betekent dat de betrokken toepassing binnen twee uur opnieuw beschikbaar moet zijn. Voor een kassa of planningstool kan dat realistisch en noodzakelijk zijn. Voor een oude archiefserver misschien niet.
Wees daarbij eerlijk over de kost. Bijna onmiddellijk herstel vraagt doorgaans om redundantie, replicatie en een goed voorbereide uitwijkomgeving. Dat is iets anders dan een dagelijkse back-up die handmatig moet worden teruggezet. De juiste keuze hangt af van de impact van stilstand, niet van de aantrekkelijkste technische belofte.
Een disaster recovery plan opstellen in zeven onderdelen
Een bruikbaar plan moet ook tijdens stress helder zijn. Lange technische documenten met verouderde screenshots helpen zelden. Werk met duidelijke scenario’s, concrete contactgegevens en herstelstappen die regelmatig gecontroleerd worden.
1. Beschrijf de incidenten waarvoor u voorbereid bent
Maak onderscheid tussen een lokaal defect, een volledige serveruitval, ransomware, verlies van internetverbinding, een foutieve verwijdering en uitval van een externe dienst. Niet elk incident vereist dezelfde reactie. Bij ransomware is isoleren vaak de eerste prioriteit. Bij een defecte internetverbinding kan een 4G- of 5G-failover de bedrijfswerking tijdelijk opvangen.
2. Wijs eigenaars en beslissers aan
Tijdens een incident moet duidelijk zijn wie het plan activeert, wie contact opneemt met de IT-partner, wie medewerkers informeert en wie klanten of ouders te woord staat. In kleinere organisaties kunnen meerdere rollen bij dezelfde persoon liggen. Dat is geen probleem, zolang er ook een vervanger is wanneer die persoon afwezig is.
Neem actuele telefoonnummers op van directie, verantwoordelijken, internetprovider, softwareleveranciers, verzekeraar en IT-partner. Bewaar die gegevens niet uitsluitend in het systeem dat mogelijk uitgevallen is. Een beveiligde offline kopie of een toegankelijke noodversie is onmisbaar.
3. Leg de herstelvolgorde vast
Herstel eerst wat andere systemen nodig hebben. In veel omgevingen zijn dat netwerk, internetverbinding, identiteit en toegangsbeheer. Daarna volgen de kernapplicaties, bestanden, e-mail, telefonie en minder kritieke diensten. De exacte volgorde moet aansluiten op uw bedrijfsimpactanalyse.
Beschrijf ook afhankelijkheden. Een toepassing kan bijvoorbeeld beschikbaar zijn, maar toch niet werken omdat de databank, licentiecontrole of koppeling met een externe partij ontbreekt. Door die relaties vooraf te documenteren, vermijdt u herstelwerk dat later opnieuw moet gebeuren.
4. Zorg voor back-ups die onafhankelijk en herstelbaar zijn
Een goede back-upstrategie bevat meerdere kopieën, op verschillende locaties en bij voorkeur ook een kopie die niet zomaar overschreven of verwijderd kan worden. Dat laatste is cruciaal bij ransomware. Als aanvallers toegang krijgen tot uw netwerk, zoeken ze vaak eerst naar back-ups.
Cloudopslag alleen is niet automatisch een disaster recovery oplossing. Bestanden in Microsoft 365 of andere cloudtoepassingen zijn beschermd tegen bepaalde problemen, maar niet noodzakelijk tegen foutieve verwijdering, kwaadwillige encryptie of verkeerde bewaartermijnen. Controleer dus expliciet wat er wordt geback-upt, hoe lang gegevens bewaard blijven en hoe snel herstel mogelijk is.
5. Voorzie een tijdelijke werkmethode
Sommige processen kunnen niet wachten op volledig technisch herstel. Denk aan een winkel die betalingen moet blijven ontvangen, een school die ouders moet bereiken of een dienstverlener die afspraken moet beheren. Leg vooraf vast welke tijdelijke werkwijze haalbaar is: werken via mobiele verbinding, uitwijken naar een cloudomgeving, een alternatieve telefoonroutering of beperkte registratie op papier.
Zo’n noodprocedure hoeft niet perfect te zijn. Ze moet vooral veilig, eenvoudig en uitvoerbaar zijn. Te complexe omwegen worden in een echte crisis meestal niet gebruikt.
6. Neem communicatie op in het plan
Een technisch incident wordt snel groter wanneer medewerkers zelf gaan gokken, klanten tegenstrijdige informatie krijgen of iemand publiek communiceert zonder afstemming. Bepaal daarom wie intern updates geeft, hoe vaak dat gebeurt en welke boodschap u extern gebruikt.
Bij een mogelijk datalek spelen ook privacyverplichtingen mee. Verzamel feiten voordat u conclusies trekt, bewaar logbestanden en stem communicatie af met de juiste verantwoordelijken. Een goed DR-plan vervangt geen juridisch advies, maar voorkomt wel dat cruciale eerste stappen worden overgeslagen.
7. Test, meet en verbeter
De belangrijkste vraag is niet of u een plan hebt, maar of het werkt. Test minstens jaarlijks een realistisch scenario. Laat bijvoorbeeld een medewerker een bestand terugzetten, simuleer de uitval van een kritieke server of controleer of u vanuit een alternatieve locatie kunt werken.
Meet de werkelijke hersteltijd en vergelijk die met uw RTO. Controleer of de back-up echt de verwachte gegevens bevat en of de betrokken contactpersonen bereikbaar zijn. Pas het plan aan na elke test, infrastructuurwijziging, nieuwe applicatie of belangrijke personeelswissel.
Veelgemaakte fouten die herstel vertragen
De meest voorkomende fout is vertrouwen op een back-up zonder een hersteltest. De tweede is een plan dat alleen door de IT-leverancier wordt begrepen. Directie en proceseigenaars moeten weten welke keuzes zijn gemaakt en wat zij zelf moeten doen.
Ook gevaarlijk: alle systemen als kritiek bestempelen. Daardoor ontstaat onduidelijkheid en worden middelen verkeerd ingezet. Kies liever een beperkt aantal processen waarvoor u aantoonbaar snel kunt herstellen, en bouw van daaruit verder.
Ten slotte is een disaster recovery plan geen eenmalig project. Een migratie naar Microsoft 365, nieuwe cloudapplicatie, verbouwing, overname of groei naar extra locaties verandert uw risico’s. Plan daarom een vaste evaluatie in, bijvoorbeeld elk kwartaal voor de belangrijkste wijzigingen en jaarlijks voor de volledige test.
Wanneer externe hulp verstandig is
Heeft uw organisatie geen intern IT-team, dan is het vaak moeilijk om risico’s, technische afhankelijkheden en hersteldoelen objectief te beoordelen. Een externe partner kan de inventarisatie begeleiden, back-up en recovery inrichten, scenario’s testen en bij een incident de coördinatie opnemen. Network-IT combineert daarbij dagelijkse IT-support met ervaring in cloud, cybersecurity, back-up en herstel, zodat een plan ook technisch uitvoerbaar blijft.
Wacht niet op een incident om te ontdekken dat uw herstelprocedure vooral uit aannames bestaat. Kies deze maand één kritisch proces, toets hoe snel het werkelijk hersteld kan worden en maak van dat resultaat het vertrekpunt voor een plan waarop uw organisatie kan rekenen.