Van een cyberaanval tot een systeemcrash of stroomuitval terwijl je data nog op servers staan. Allerlei IT-incidenten waarvan je denkt dat ze je nooit zullen overkomen, maar toch zit het gevaar in een klein hoekje. Dit soort calamiteiten zijn redenen om je omgeving te moeten herstellen. De kunst van het herstellen is dat dit zo snel mogelijk gebeurt, zodat je dagelijkse werkzaamheden niet onnodig lang stil komen te liggen. Om dat voor elkaar te krijgen, is een herstelplan erg belangrijk. Maar wat houdt zo’n plan precies in?  

Met Gerrit Smit.

Het herstelplan 

Laten we eerst even kort ingaan op het begrip “herstelplan”. We kennen het ook wel als het Disaster Recovery Plan en wordt ingezet bij IT-calamiteiten binnen een organisatie. Een herstelplan is er om de schade van een calamiteit of incident te beperken en de werkzaamheden binnen de organisatie zo snel mogelijk weer op de rit te krijgen. Idealiter wordt het herstelplan vóóraf aan de eerste calamiteit uitgewerkt en intern beschikbaar gesteld. In dit plan staan duidelijke, efficiënte processen omschreven om de IT-storing snel te herstellen. Dit dwingt jouw organisatie bovendien ook om vooraf na te denken over de omgang met bepaalde situaties. Het voorkomt ook stress wanneer er een incident plaatsvindt. Vaak is een herstelplan verweven met het Business Continuïteitsplan. Toch zijn het twee verschillende dingen.  

Wat staat er in het herstelplan? 

Een herstelplan is inhoudelijk voor elke organisatie verschillend. Echter, zijn er een aantal onderdelen te benoemen die in elk goed herstelplan terug moeten komen om snel te kunnen acteren bij een IT-incident. Dat begint bij de prioritering van de systemen en eindigt bij de uitvoering van het plan.  

1. Identificeren van de risico’s 

Allereerst ga je kritisch en realistisch kijken naar de risico’s die jouw organisatie loopt op het gebied van IT-incidenten en -calamiteiten. Per risico kan je namelijk andere mitigerende maatregelen nemen. Zo bepaal je waar de focus en prioritering ligt in jouw herstelplan en kan je snel acteren op een situatie die zich voordoet.  

2. Prioriteren van je belangrijke business applicaties 

Is het je ERP-programma, CRM-systeem, webshop- of website hosting of een andere business software waar jouw organisatie écht door platligt als deze niet werkt? Aan de voorkant prioriteer je de business applicaties die in jouw organisatie draaien. Je identificeert welke applicaties voorrang krijgen op anderen als het gaat om de volgorde waarin ze worden onderzocht en hersteld. Stel, we moeten ooit herstellen: waar beginnen we?  

3. Inventariseren hoe lang je zonder kunt 

Wat is het gevolg als één of meerdere van je applicaties niet meer goed draaien en hersteld moeten worden? Verschilt dit per applicatie? Zonder welke applicaties staan jouw dagelijkse werkzaamheden stil en zonder welke kan je best even doordraaien?  

 4. Testen van het herstelplan 

Door middel van een hersteltest weet je hoe veel tijd jouw business applicaties nodig hebben om terug op de rit te komen. Je inventariseert dit ook voor elke applicatie apart. Met deze kennis kom je er bijvoorbeeld achter hoelang het duurt tot je van je hoogst geprioriteerde applicatie over kunt gaan op het herstel van de volgende prioriteit. Zijn er verder nog extra maatregelen nodig of hebben we voldoende uitgedacht?  

 5. Leg de opties vast 

Buiten het herstelplan is er ook nog de mogelijkheid tot een back-up van jouw omgeving en (belangrijkste) applicaties. Een herstelplan is namelijk niet bij alle typen calamiteiten nodig. Het kan ook zijn dat een standaard back-up van je data op een externe locatie de schade kan beperken of voldoende is om je dagelijkse werkzaamheden snel weer op te pakken na een calamiteit. Wanneer je samenwerkt met leveranciers, is de kans echter groot dat je samen een Business Continuïteitsplan opstelt waar het herstelplan ook een onderdeel van of aanvulling op is. Vaak komt dit ook terug in het Service Level Agreement (SLA) dat je met elkaar opstelt. Bespreek dit aan de voorkant met jouw leverancier.  

 

Side note 

Vaak spreek je in het Service Level Agreement met jouw leverancier af dat jouw IT-omgeving 99% van de tijd online moet zijn. Dat klinkt optimaal, maar die 1% kan cruciaal zijn voor de resultaten van jouw dagelijkse werkzaamheden. Als je dat namelijk terugrekent, mag jouw omgeving er drie dagen per jaar uit liggen. Kan jouw organisatie wel drie dagen zonder die SaaS-applicatie? Dat moet je jezelf afvragen. Daar komt ook het belang van een goed herstel- of eventueel restoreplan weer terug.  

De rol van de IT-leverancier 

De IT-leverancier kan de klant niet adviseren over de prioritering van de business applicaties en de indicatie van hoe lang de dagelijkse werkzaamheden kunnen doordraaien zonder de betreffende tools en systemen.  De IT-leverancier kan wél meedenken over randzaken die nodig zijn om de applicaties te laten functioneren. Zoals antwoord op de vraag: welke servers moeten we terugzetten voordat applicatie X het weer doet? Uiteindelijk is het echter aan de klant om het herstelplan uit te denken. Wanneer dit plan op papier staat en de IT-leverancier wordt betrokken bij het herstellen, gaat de leverancier adviseren op basis van het RPO en het RTO. De Recovery Point Objective (RPO) gaat over de frequentie waarin er een back-up wordt gemaakt naar een externe locatie. Stel, je kiest ervoor om één back-up per dag in te richten. Wanneer jouw IT-omgeving hersteld moet worden, kan je dus één dag aan data verliezen. Kan je daarmee als organisatie overleven? De IT-leverancier adviseert vervolgens op basis van deze kennis over de praktische realisatie van het herstelplan. Dit geldt ook voor het RTO: de Recovery Time Objective. Hoe lang mogen we over het herstel doen? Wanneer ook dit bekend is, kunnen de Consultants van de IT-leverancier een back-up strategie neerzetten en inrichten. Hoe zorgen we ervoor dat die objectives haalbaar zijn en welke praktische opties hebben we? Daarna is het een kwestie van testen. Je bootst het herstelplan na en identificeert of de RTO en RPO haalbaar zijn. Dit doe je minimaal twee keer per jaar. Waarom? Jouw organisatie verzamelt elke dag meer en meer data. Dit zorgt er automatisch voor dat een restore of back-up meer tijd nodig heeft om al die gegevens terug te zetten of te herstellen. Zo blijf je samen valideren of de objectives nog haalbaar zijn.   

Een incident vindt plaats: en dan? 

Het herstelplan staat klaar. Maar wat gebeurt er precies wanneer er daadwerkelijk een IT-calamiteit plaatsvindt? Dan ga je werken volgens het Incident Management Proces. Iemand binnen jouw organisatie detecteert het probleem en belt de interne helpdesk óf het beheerteam van de leverancier. Vervolgens wordt vaak standaard een aantal stappen doorlopen: 

1. Kort onderzoek. Wat is er precies aan de hand? Is er iets gecrasht, vastgelopen of is er een cyberincident aan de gang?  
2. Kwantificeren van de gemelde issue. Welke systemen zijn er geraakt? Wat is er precies aan de hand? Hoe lang denken we nodig te hebben om de issue te verhelpen of troubleshooting uit te voeren? Afhankelijk van de situatie kan dit 10 minuten tot 2 uur duren; 
3. Gesprek tussen de klant en IT-leverancier. Er is een probleem gevonden en we kunnen twee dingen doen. Er wordt allereerst tijd besteed aan troubleshooten óf we gaan meteen herstellen. Samen beslis je wanneer je van strategie één naar strategie twee overstapt of je besluit zelfs om het troubleshooten over te slaan. Hier wordt ook weer gekeken naar de RPO en RTO. Op basis daarvan wordt een tijdsplanning gemaakt; 
4. Het herstel. 

Conclusie 

Een cyberaanval, crash of datalek is dichterbij dan je denkt. De kunst is om goed voorbereid te zijn op een dergelijke situatie. Door vooraf te bepalen bij welke applicaties je begint met herstellen en hoe lang elke applicatie maximaal stil mag komen te liggen. Een herstelplan kan ook een back-up- of restoreplan zijn. Het gaat erom dat je als organisatie – al dan niet samen met je IT-leverancier – direct kunt schakelen en zo kan voorkomen dat je dagelijkse werkzaamheden onnodig lang stil komen te liggen.  

Maak je je zorgen over jouw herstel- of restoreplan, wil je inzicht in de risico’s van IT-incidenten voor jouw organisatie of even sparren over dit onderwerp? Wij zijn er voor je.

Maak bijvoorbeeld makkelijk een afspraak met Dave.