Veel organisaties beschikken over back-ups en hebben afspraken gemaakt over het herstel van hun IT-omgeving. Daarmee is een belangrijke basis gelegd voor de bedrijfscontinuïteit. Toch blijft vaak één vraag onbeantwoord: werkt het herstel ook wanneer een ernstige verstoring daadwerkelijk optreedt?
Een back-up kan succesvol zijn uitgevoerd terwijl het terugzetten van gegevens onverwacht veel tijd kost. Een server kan weer functioneren terwijl de bijbehorende applicatie niet bereikbaar is. En een recoveryplan kan zorgvuldig zijn opgesteld, maar afhankelijk blijken van een medewerker die op het beslissende moment niet beschikbaar is. Pas wanneer het herstel daadwerkelijk wordt uitgevoerd, wordt duidelijk of de gemaakte afspraken en technische voorzieningen voldoende zijn.
Een succesvolle back-up is nog geen geslaagd herstel
Back-upsoftware kan dagelijks rapporteren dat alle taken succesvol zijn uitgevoerd. Dat betekent in de eerste plaats dat gegevens volgens de ingestelde procedure zijn opgeslagen. Het zegt nog niet of deze gegevens binnen de gewenste tijd kunnen worden teruggezet, of de inhoud bruikbaar is en of de bijbehorende applicaties daarna correct functioneren.
Neem bijvoorbeeld een ERP-systeem waarvan de database dagelijks wordt veiliggesteld. Het terugzetten van die database kan technisch slagen, terwijl de applicatie vervolgens niet start door een ontbrekende configuratie of een incompatibele softwareversie. Ook kunnen koppelingen met andere systemen ontbreken, waardoor medewerkers nog steeds geen orders kunnen verwerken. Vanuit technisch perspectief zijn de gegevens hersteld, maar vanuit de bedrijfsvoering is het herstel nog niet geslaagd.
Daarom moet een hersteltest verder gaan dan de controle of bestanden kunnen worden teruggelezen. Het doel is vast te stellen of een bedrijfsproces weer bruikbaar is, binnen een aanvaardbare tijd en zonder onacceptabel gegevensverlies. Daarmee vormt de hersteltest de praktische toets van de eerder vastgestelde RPO- en RTO-doelstellingen.
Wat moet een hersteltest aantonen?
De omvang van een hersteltest hangt af van de systemen en processen die voor uw organisatie belangrijk zijn. Voor een relatief eenvoudige applicatie kan het voldoende zijn om gegevens terug te zetten in een afzonderlijke omgeving en de werking te controleren. Bij een complex bedrijfsproces kunnen meerdere servers, databases, netwerkvoorzieningen, gebruikersaccounts en externe diensten betrokken zijn.
Een goede test maakt zichtbaar welke onderdelen nodig zijn en in welke volgorde deze moeten worden hersteld. Daarbij wordt niet alleen gekeken naar de technische uitvoering, maar ook naar de beschikbaarheid van documentatie, benodigde toegangsrechten en de afspraken met leveranciers. Juist deze organisatorische afhankelijkheden kunnen tijdens een incident bepalend zijn voor de uiteindelijke hersteltijd.
Ook de betrouwbaarheid van de herstelde omgeving verdient aandacht. Na een beveiligingsincident is het niet vanzelfsprekend veilig om alle systemen onmiddellijk opnieuw in gebruik te nemen. Een herstelprocedure moet daarom ruimte bieden voor controles op de integriteit van gegevens, de toestand van systemen en de risico's van herbesmetting. Een snelle terugkeer naar productie heeft weinig waarde wanneer dezelfde verstoring daardoor opnieuw kan ontstaan.
Wat een hersteltest in een productieomgeving zichtbaar maakt
Een productiebedrijf maakt dagelijks back-ups van zijn ERP-omgeving. De back-uprapportages tonen geen bijzonderheden en de organisatie gaat ervan uit dat de administratie bij een verstoring binnen enkele uren beschikbaar kan zijn. Om die verwachting te toetsen, wordt besloten een hersteltest uit te voeren in een afgescheiden omgeving.
De database kan zonder problemen worden teruggezet, maar tijdens het starten van de ERP-applicatie blijkt dat een specifieke configuratie ontbreekt. Vervolgens blijkt een koppeling met het magazijnsysteem afhankelijk van een externe leverancier. Die leverancier moet eerst een aanvullende instelling herstellen voordat de volledige orderverwerking kan worden getest.
De technische herstelwerkzaamheden duren daardoor aanzienlijk langer dan vooraf was aangenomen. Bovendien blijkt dat bepaalde handelingen niet in het bestaande recoveryplan zijn vastgelegd. De test veroorzaakt geen verstoring van de dagelijkse productie, maar maakt wel duidelijk dat de organisatie bij een werkelijk incident waarschijnlijk langer stil zou staan dan verwacht.
Op basis van de bevindingen worden de ontbrekende configuraties veiliggesteld, de leveranciersafspraken aangescherpt en de herstelprocedure bijgewerkt. Bij een volgende test kan vervolgens worden vastgesteld of deze maatregelen het gewenste resultaat opleveren.
Belangrijkste inzicht
De waarde van de eerste test ligt daarmee niet alleen in wat goed ging, maar vooral in de tekortkomingen die tijdig zichtbaar werden.
Vier onderdelen van een bruikbare hersteltest
Een hersteltest levert de meeste waarde op wanneer vooraf duidelijk is wat wordt onderzocht, hoe het resultaat wordt beoordeeld en wat er met de bevindingen gebeurt. Vier onderdelen vormen daarvoor de basis.
Testdoel en scenario:
Welk bedrijfsproces moet worden hersteld, welke verstoring wordt nagebootst en welke systemen vallen binnen de test?Uitvoering en afhankelijkheden:
Kunnen gegevens, applicaties en verbindingen in de juiste volgorde worden hersteld en zijn de benodigde mensen en leveranciers beschikbaar?Functionele en veilige heringebruikname:
Kunnen medewerkers de noodzakelijke werkzaamheden uitvoeren en is vastgesteld dat de herstelde omgeving betrouwbaar is?Evaluatie en verbetering:
Welke hersteltijd en welk gegevensverlies zijn daadwerkelijk vastgesteld, welke problemen traden op en hoe worden deze opgelost?
Niet iedere test hoeft de volledige IT-omgeving te omvatten. Het is vaak verstandig om te beginnen met de belangrijkste bedrijfsprocessen en vervolgens verschillende scenario's te onderzoeken. Daarbij kan onderscheid worden gemaakt tussen het terugzetten van afzonderlijke gegevens, het herstellen van een complete applicatie en het hervatten van een bedrijfsproces met alle bijbehorende afhankelijkheden.
De resultaten moeten wel concreet worden vastgelegd. Alleen de conclusie dat een test is geslaagd, geeft onvoldoende inzicht in de werkelijke herstelmogelijkheden. Juist de gemeten hersteltijd, de actualiteit van de teruggezette gegevens en eventuele handmatige ingrepen maken duidelijk of de organisatie haar doelstellingen kan halen.
Testen zonder de dagelijkse bedrijfsvoering te verstoren
Een begrijpelijke reden om hersteltests uit te stellen, is de zorg dat zij de normale werkzaamheden kunnen beïnvloeden. Zeker bij productiebedrijven of organisaties met bedrijfskritische applicaties is het niet wenselijk om zonder noodzaak systemen buiten gebruik te stellen. Toch hoeft een hersteltest niet te betekenen dat de productieomgeving daadwerkelijk wordt uitgeschakeld.
Veel herstelwerkzaamheden kunnen worden uitgevoerd in een afzonderlijke testomgeving. Daar kunnen back-ups worden teruggezet, applicaties worden gestart en koppelingen worden gecontroleerd zonder dat medewerkers hun dagelijkse werkzaamheden hoeven te onderbreken. Wel moet worden voorkomen dat de testomgeving onbedoeld verbinding maakt met productiesystemen of echte transacties uitvoert.
Een geïsoleerde test heeft tegelijkertijd beperkingen. Niet alle afhankelijkheden en omstandigheden van een werkelijk incident kunnen volledig worden nagebootst. Daarom is het belangrijk om vooraf vast te stellen wat een test wel en niet aantoont. Waar nodig kunnen technische hersteltests worden aangevuld met oefeningen waarin ook besluitvorming, communicatie en leveranciersafspraken worden beoordeeld.
Herstelbaarheid verandert mee met uw IT-omgeving
Een herstelplan dat vorig jaar succesvol is getest, hoeft vandaag niet meer volledig te zijn. Nieuwe applicaties, gewijzigde netwerkverbindingen, software-updates en andere leveranciers kunnen invloed hebben op de manier waarop systemen moeten worden hersteld. Ook veranderingen in de bedrijfsvoering kunnen ervoor zorgen dat eerdere hersteldoelstellingen niet langer aansluiten op de werkelijke behoeften.
Daarom hoort hersteltesting niet uitsluitend bij de invoering van een nieuwe back-upvoorziening of het opstellen van een recoveryplan. Het moet onderdeel zijn van regulier IT-beheer, waarbij belangrijke wijzigingen aanleiding kunnen zijn om bestaande herstelprocedures opnieuw te beoordelen. Hoe vaak en hoe uitgebreid wordt getest, hangt af van het bedrijfsrisico en de gevolgen van een mogelijke verstoring.
Malenco benadert hersteltests vanuit die samenhang. We kijken niet alleen of gegevens beschikbaar zijn, maar ook of applicaties, infrastructuur en afhankelijkheden het hervatten van de bedrijfsvoering mogelijk maken. De uitkomsten gebruiken we om herstelprocedures, technische voorzieningen en organisatorische afspraken gericht te verbeteren.
Weet u wat uw herstelplan in de praktijk waard is?
Zolang herstel niet is getest, blijven belangrijke aannames bestaan over de tijd die nodig is, de beschikbaarheid van gegevens en de werking van afhankelijke systemen. Een hersteltest maakt deze aannames toetsbaar en helpt voorkomen dat tekortkomingen pas tijdens een ernstige verstoring zichtbaar worden.
Daarmee is testen geen eenmalige technische controle, maar een manier om de werkelijke herstelbaarheid van uw organisatie te beoordelen en stapsgewijs te verbeteren.
Wilt u weten of uw herstelplan in de praktijk uitvoerbaar is? Malenco helpt u bij het beoordelen, uitvoeren en verbeteren van hersteltests, zodat duidelijk wordt wat uw organisatie daadwerkelijk nodig heeft om na een IT-verstoring weer verder te kunnen.
