Zijn de kernactiviteiten van uw bedrijf sterk afhankelijk van uw ICT-systemen? Zorg dan niet enkel voor een goede beveiliging, maar ook voor een deugdelijk Disaster Recovery Plan om de impact van onvoorziene ICT-calamiteiten zoveel mogelijk te beperken.
Zelfs de best beveiligde ICT-systemen zijn niet 100% bestand tegen rampen. En zo’n ramp hoeft helemaal geen zware overstroming of brand te zijn om catastrofale gevolgen te hebben. Ook een menselijke fout, een virus, een corrupt softwaresysteem, een cyberaanval, een serverstoring of een eenvoudige elektriciteitspanne kan substantiële schade aan een organisatie berokkenen.
Wat is een Disaster Recovery Plan?
Een Disaster Recovery Plan (DRP) beschrijft de te volgen aanpak bij onvoorziene ICT-incidenten die de bedrijfscontinuïteit in gevaar brengen, met als oogmerk de schadelijke impact ervan zoveel mogelijk te beperken. Het is een draaiboek dat stap voor stap zegt wie wat wanneer moet doen bij ICT-gerelateerde calamiteiten.
Zo’n plan schudt u natuurlijk niet zomaar uit uw mouw. Er komt heel wat voorbereiding en denkwerk bij kijken. Bovendien moet u een Disaster Recovery Plan ook regelmatig actualiseren.
Fase 1: Voorbereiding
De voorbereiding bestaat uit vier elementen: een risicoanalyse, een business-impactanalyse, het Recovery Time Objective en het Recovery Point Objective.
Risicoanalyse
Qua risicoscenario’s houden we in de IT-wereld vooral rekening met de (gedeeltelijke) vernietiging van de fysieke organisatie als gevolg van overmacht (zoals overstroming, brand en storm) en dataverlies of downtime als gevolg van een virus, cyberaanval, stroomstoring, diefstal of menselijke fout.
Tijdens de risicoanalyse bekijken we wat de impact zou zijn als bepaalde applicaties of diensten niet meer geleverd kunnen worden en schatten we de waarschijnlijkheid van zo’n scenario in. Hiervoor moeten we exact weten welke applicaties en diensten op welke onderdelen van uw ICT-infrastructuur draaien en waar ze zich bevinden.
Business-impactanalyse
Tijdens een business-impactanalyse bekijken we hoe verschillende businessunits werken, welke processen afhankelijk zijn van IT en welke gevolgen bepaalde risico’s zouden kunnen hebben voor deze processen én andere bedrijfsactiviteiten.
Van deze risico’s wordt een prioriteitenlijst gemaakt. Risico’s die mogelijk een impact op de hele organisatie hebben komen wellicht hoger op die lijst te staan dan risico’s die slechts een klein onderdeel kunnen aantasten. En risico’s die mogelijk operationele en financiële verliezen veroorzaken staan wellicht hoger gerangschikt dan calamiteiten die enkel de concurrentiepositie of reputatie van het bedrijf schaden.
De business-impactanalyse geeft een duidelijk beeld van alle mogelijke kosten en praktische gevolgen van een bepaald type ramp. Vervolgens moeten we beslissen hoe bestand bedrijfskritische applicaties en diensten tegen een mogelijke storing moeten zijn en wat de maximaal aanvaardbare downtime is. Pas daarna kunnen we de opties evalueren om hun resistentie te verhogen en de onderbrekingsduur te reduceren.
Bepaal het Recovery Time Objective
Het Recovery Time Objective (RTO) is de streeftijd waarbinnen een functie, proces of dienst opnieuw operationeel moet zijn na een storing opdat het bedrijf ervan kan herstellen. Op basis daarvan bepalen we welke maatregelen en budgetten ertegenover staan.
Als het RTO geschat wordt op vijf uur omdat het bedrijf een langere downtime niet zou overleven, zal het bedrijf de nodige investeringen moeten doen om de systemen in kwestie effectief binnen die tijdsspanne te kunnen herstellen. Als het RTO op twee weken wordt geschat, zal het volstaan om voor een minder snelle en goedkopere hersteloplossing te kiezen.
Bepaal het Recovery Point Objective
Het Recovery Point Objective (RPO) beschrijft het moment waarop de hoeveelheid verloren data de maximaal toelaatbare drempel overschrijdt. Dit objectief wordt bepaald op basis van de tijd tussen twee back-ups en de hoeveelheid data die in tussentijd verloren kan gaan.
In veel ICT-omgevingen wordt elke nacht een back-up gemaakt. Als de calamiteit zich echter tegen het einde van de werkdag of ’s nachts nog vóór de back-up voordoet, is de kans reëel dat de data van de volledige werkdag verloren gaan.
Is de organisatie in dat geval niet meer in staat om de verloren data te recupereren of opnieuw te verwerken zonder dat het bedrijf er zwaar onder lijdt? Dan moet het RPO verkort worden en is er dus meermaals per dag een nieuwe back-up nodig.
Fase 2: Breng de ICT-omgeving in kaart
Om te kunnen inschatten hoe kwetsbaar bepaalde activiteiten of diensten zijn, moet u precies weten hoe uw bedrijfsprocessen verlopen en welke onderdelen op welke ICT-infrastructuur draaien.
Terwijl we dit in kaart brengen, gaan we ook volgende zaken na:
- Wat is nodig om de betreffende systemen te laten draaien?
- Heeft het uitvallen van een systeem impact op andere systemen?
- Is elk systeem ontdubbeld en beveiligd?
- Welke garanties en Service Level Agreements zijn er van kracht?
- Werden er van elk systeem voldoende back-ups gemaakt en bewaard?
Fase 3: Disaster Recovery Strategie
Na de eerste twee fases zijn we klaar om concrete acties en procedures op te stellen om op terug te vallen als een calamiteit zich effectief zou voordoen.
Rollen en verantwoordelijkheden
Wie moet wat doen in geval van een calamiteit? Maak een overzichtelijke tabel met:
- de contactgegevens van de leden van het Disaster Recovery Team;
- de rol en verantwoordelijkheid van elk lid;
- de uitgavelimieten (bijvoorbeeld voor de aankoop van noodzakelijk materiaal);
- de beperkingen van hun autoriteit in geval van een incident.
Incident Response
Het Disaster Recovery Plan geeft aan wie de ernst van de situatie in eerste instantie zal evalueren, de juiste personen op de hoogte zal brengen en het incident onder controle zal proberen te krijgen.
Activatieplan
Op basis van die eerste respons beslissen de gemobiliseerde leden welke onderdelen van het Disaster Recovery Plan in werking treden. Het DRP beschrijft gedetailleerd en stap per stap hoe het geaffecteerde bedrijfsproces of netwerkelement zo snel en efficiënt mogelijk hersteld kan worden en of een ander systeem de taken ervan (tijdelijk) kan uitvoeren.
Documentatie
Een Disaster Recovery Plan bevat nog meer mogelijke nuttige informatie, zoals de contactgegevens van leveranciers, herstelprocedures beschreven door leveranciers, applicatie- en systeeminventarissen, netwerkbeschrijvingen en -schema’s, contracten en Service Level Agreements.
Fase 4: Testen en evaluatie
Testen
Test uw Disaster Recovery Plan regelmatig en stuur bij als u merkt dat de gedefinieerde procedures niet voldoen, bijvoorbeeld omdat ze de RTO’s of RPO’s niet halen.
Updaten
Update uw Disaster Recovery Plan minstens jaarlijks. Een DRP met verouderde contact- en contractinformatie laat u in de steek op het moment van de waarheid. Bekijk ook de impact van elke nieuwe ICT-investering op uw DRP: moet het plan hierdoor bijgewerkt worden of niet?
Business Continuity Plan
Het Disaster Recovery Plan is een onderdeel van het Business Continuity Plan, dat alle activiteiten bundelt die zorgen voor de continuïteit van de bedrijfsactiviteiten en de beschikbaarheid van bedrijfskritische functies voor klanten, leveranciers en andere stakeholders.
Hulp nodig bij het opstellen van een degelijk Disaster Recovery Plan? Contacteer ons dan snel!
