Auteur: Manu Steens
In deze bijdrage geef ik mijn eigen mening, niet die van enige organisatie
Weet je hoe een effectief bedrijfscontinuïteitsplan te creëren? Mensen onderschatten de uitdagingen van disaster recovery in de echte wereld de dag van vandaag. Het hebben van een continuïteitsplan is niet enkel een bezorgdheid van ICT. Want het gaat om het overleven van de gehele business, en daarbij moet men alle invalshoeken van calamiteiten in rekening brengen.
We krijgen van tevoren amper te horen of een crisis kan toeslaan. Zelfs met een korte verwittigingstijd vooraf kunnen er talloze dingen fout gaan. Bovendien is elke calamiteit uniek. Daarom is het alsof we moeten straatvechten. We vechten met alle trucjes die we kennen tegen de crisis, die zelf ook vaak onverwacht uit de hoek komt.
Het is precies daarom dat we een BCP nodig hebben. Om jou als CMT van uw organisatie de beste wapens te geven voor een succesvolle aanpak van de ramp. Daarvoor heb je plannen nodig, en moet je ze testen. Iedereen die een rol heeft in dat plan moet zijn plaats kennen. Ook zij die niets moeten doen, moeten weten dat ze niet in de weg moeten lopen. Zonder plan heb je er waarschijnlijk nog nooit over nagedacht, en zonder gevormde gedachten is de kans groot dat je er langer over doet om tot een goed resultaat te komen. Als dan de hersteltijd langer is dan de MTPD dan is de kans zeer reëel dat er zware blijvende schade is aangericht, die de organisatie wellicht niet te boven kan komen. Ze kan zelfs ophouden te bestaan.
Inhoud
Hoe BCP’s en DRP’s verschillen
Bedrijfscontinuïteit (BC) verwijst naar het behouden van de noodzakelijke bedrijfsfuncties en de bedrijfsproductie of het snel genoeg herstellen ervan in het geval van een grote calamiteit. Dit kan gaan van een overstroming, een bommelding, een brand, een terreuraanslag of een pandemie of een cyberaanval of –oorlog. Een BCP geeft de richtlijnen aan die een organisatie moet volgen wanneer het geconfronteerd wordt met dergelijke zaken. Het BCP doet een verhaal over mensen, middelen, processen, gebouwen, partners en ICT e.d.
Momenteel is de vakliteratuur ervan doordrongen dat een disaster recovery plan (DRP) NIET hetzelfde is als een BCP. Volgens velen concentreert een DRP zich op het herstellen van de ICT functies en heeft alles te maken met wat in ITIL “ICT Continuity services” genoemd wordt. Het concentreert zich op ICT en komt vaak pas op gang wanneer de ernstigste slagen en verwondingen (de directe impact) door de crisis achter de rug zijn. Daarom maakt het integraal deel uit van een BCP, omdat een BCP zich focust op het overleven van heel de organisatie.
Een voorbeeld
Bijvoorbeeld, als een treinramp een gebouw onbruikbaar maakt voor langere tijd, weet je dan hoe de loketdiensten aan de klant zullen worden verdergezet? Zullen ze tijdelijk van thuis uit werken, of telewerken in de brede zin van het woord? Of ga je alternatieve werkplekken voorzien? Of ga je bureelcontainers inhuren?
Een BIA
Noteer dat een business impact analysis (BIA) ook deel uitmaakt van het proces om tot een BCP te komen. Een BIA identificeert de impact van een plots verlies van bedrijfsprocessen of producten (zie BIA, hoe doe je dat). Die analyse geeft een antwoord op de vraag welke processen belangrijk zijn in uw organisatie. Het resultaat daarvan kan zijn een opdeling van de processen in tijdskritieke, essentiële en noodzakelijke processen. Zo’n analyse geeft tevens een eerste idee van wat je kan doen als strategische aanpak van de gevonden problemen. (Zie strategische keuzes).
Waarom een BCP er toe doet.
Of je nu een kleine organisatie hebt of een grote, wat er toe doet is de klant (be)dienen. Reputatie is dus belangrijk, overleven als organisatie dus ook. En er is geen betere test dan “the real thing”.
Omdat herstel van IT functionaliteiten enorm is doorgedrongen in onze maatschappij, zijn er enorm veel DR oplossingen voorhanden. Maar wat met de rest van de bedrijfsprocessen? De reputatie van de organisatie hangt er van af. Het positief afhandelen van een crisissituatie heeft doorgaans een goede invloed op de reputatie. Het kan het vertrouwen van de klant verbeteren. Daarom doet een BCP er echt wel toe !
Eerste stap: maak een BCP: een overzicht van stapjes.
- Als je nog geen BCP hebt, begin dan bij het begin: leer de organisatie en haar processen kennen. Je maakt best een volledige oplijsting van de processen, en brengt deze in kaart. Een goede techniek daarvoor kan een procesflow zijn, of “swimlanes” in BPMN. Een belangrijk voordeel hiervan is dat je het kan hergebruiken voor organisatiemanagement. Of omgekeerd: maak gebruik van de inspanningen van organisatiebeheersing !
- Bepaal nadien in een operationele risicoanalyse welke processen kwetsbaar zijn en waarvoor. Maak dan een impactanalyse op per functie, inventariseer alle afhankelijkheden en betrek daarbij de risicoanalyse die al dan niet speciaal voor deze BCM-oefening werd gemaakt. Dit leidt ons tot de BIA. (zie ook Een BIA, hoe doe je dat).
- Dan bepaal je de fundamentele strategieën die je wil gebruiken, gebaseerd op de BIA, voor de zaken die het management belangrijk acht.
- En dan maak je een BC Plan. (Zie hieronder).
- En dan test je het. Zie ook volgende paragraaf.
- En dan evalueer je het.
Bovenstaande is opnieuw een checklist, of een plan van aanpak als je wil.
Betrokken partijen
Verifieer dat alle betrokken partijen hun zeg en inzage krijgen in het plan. Iedereen die er een rol in te vervullen heeft moet dat weten, die rol kennen en geoefend hebben.
Herinner u dat het DRP deel uitmaakt van het BCP, dus je kijkt best eens bij de IT afdeling of je tot een vergelijk komt, en of de toepassingen van de tijdskritieke processen opgenomen zijn in hun DRP voor u. Of om afspraken te maken om het op te nemen.
Naargelang het plan vordert, is het interessant om de nodige betrokken partijen aan tafel te krijgen (niet noodzakelijk allemaal samen) voor een gesprek / interview. Spreek eveneens over ervaringen van mensen die reeds een calamiteit succesvol (of niet) hebben doorstaan. Het is een goede bron van frisse ideetjes, mensen delen namelijk graag hun “oorlogsverhalen” en de slimme zetten uit het veld die de dag gered hadden.
Een BCP, wat staat daar zoal in?
Opmerking vooraf: maak er een BCP van, geen handleiding van het maken van een BCP…
Deel 1 – de grote hoofdlijnen van het plan | o Plan doelstelling, zoals opgelegd door het management o Plan scoop, zoals opgelegd door het management o Lijst met kritieke processen, met RTO en RPO o Niveau van herstel voor elk proces o Prioriteit van herstel o De single points of failure die de processen kunnen treffen o Bepaling van de types van situaties voor het plan o Referentie aan andere documenten |
Deel 2 – Rollen en verantwoordelijkheden | o Welke teams zijn nodig en welke taken hebben ze? Welke rollen hebben ze? o Wie heeft leiding waarover? Welke autoriteit om wat te doen? o Wat moet elke rol doen? Voorzie instructies o Voorzie een eenvoudige template voor logging |
Deel 3 – Wat er gebeurt als men het plan activeert | o Hoe activeer je het plan? Hoe zet je de relevante teams in gang? o Kan het plan ten dele geactiveerd zijn? Wanneer? Hoe? o Wie kan het plan in gang zetten? o Wie moet op de hoogte zijn? o Wie moet wat doen als hij denkt dat het plan actief moet worden? o Wat zijn de noodprocedures? o Wat als de werkplek onbeschikbaar is? o Hoe zal men de kritieke processen herstellen? |
Deel 4 – Wat zijn de communicatieprocessen? | o Wie rapporteert aan wie? o Belboom; WhatsApp groep,… o Escalatieprocedure o Intern en extern communicatieplan en communicatieplatformen |
Deel 5 – Opsommingen van benodigdheden en contacten | o Sleutelpersonen en hun contactgegevens o Crisisvergaderzalen en herstel-locaties o Contactlijsten van stakeholders, contractors, onderhoudsdiensten, firma’s met SLA’s, … o Faciliteiten en voorraden o Technologie en communicaties o Informatie, data en applicaties o Wettelijke documenten en regelgeving o Transport en logistiek o Petty cash en noodbudgetten |
Deel 6 – Hoe je het plan beëindigt | o Proces voor het beëindigen van de crisis en het ophouden van de werking van het plan |
Deel 7 – Document management informatie | o Wie is de eigenaar van het plan? o Wie autoriseert het plan? o Triggers voor het herzien van het plan o Aan wie verspreidt men het plan ter nazicht? o Wijzigingsbeheer o Versiebeheer |
Deel 8 – Verwijzingen | o Verwijzingen naar wet- en regelgeving o Verwijzingen naar wettelijke documenten en overeenkomsten o Statement van confidentialiteit o … |
Deel 9 – Navigatie | o Inhoudspagina Geen overbodige uitleg die er niet toe doet o Zet afvinklijsten en operationele informatie vooraan. o Zet bijkomstigheden in appendices. |
Testen, wat kan dat allemaal zijn?
Een plan moet rigoureus in elkaar zitten. Daarom moet het ook stevig getest worden. Maar dat doe je best gradueel opbouwend. De testkalender hangt af van uw organisatie. Of van het sleutelpersoneel. Of van de bedrijfsprocessen, of het ICT, of van het wijzigingsbeheer, of…
De meest gebruikte tests staan hieronder vermeld.
Type test | Doel van de test | Wat en hoe |
Bureau testen | Test en kwaliteitsinschatting van de inhoud van het BCP. | Stap 1: Desk check: De inhoud van de documenten worden doorlopen door de auteur en de ICT manager van Operations ICT. Hierbij wordt de inhoud van de documenten bekeken en besproken tussen beide partijen. |
Test van de inhoud van het BCP | Stap 2: Desktop walkthrough: De auteur spreekt af met elk van de leden van het crisismanagement en zit met elk van hen in vergadering om door dezelfde documenten te lopen als bij de stap “Desk check” De auteur legt de werking en het doel van de documenten nader uit. | |
Gebruik een BCP Scenario en een recovery schema om te wandelen door het continuïteitsplan om te valideren dat het BCP zowel de nodige als voldoende informatie bevat om een succesvol herstel mogelijk te maken. | Stap 3: Desktop scenario: De deelnemers komen samen en nemen een concreet geval, waarbij ze de passende scenario’s en schema’s bespreken als test of ze de eerste twee stappen begrepen hebben. | |
Communicatietest | Test de contactnummers (telefoonnrs) uit voor de mensen in het crisistelefoonboek en het cascade van oproep BCM schema. (zijn ze up to date?) | Het eerste jaar wordt een communicatietest van tevoren afgesproken. De latere jaren wordt deze test onaangekondigd opgezet. Het doel is dat de deelnemers de juiste mensen (elkaar) opbellen binnen een vooraf opgestelde tijdspanne. |
Pijler BCP Scenario en Recovery-aanpak-schema oefening(kleine zandbak) | Gebruik een BCP-scenario van een incident voor een rollenspel voor het management om te testen dat voor het continuïteitsplan van één pijler de recovery schema’s functioneel goed zijn. | De werkgroep organisatiebeheersing maakt een rollenspel gebaseerd op een scenario. Hierbij is het de bedoeling om de deelnemers binnen een enkele pijler te trainen en de scenariostappen van die pijler te testen. Voor de pijler die getraind wordt, nemen de BCP-beheerder en de BCP teams deel. De overige rollen in het crisisteam worden gespeeld door de respectieve leden van de werkgroep organisatiebeheersing. Deze test gebeurt voor elke pijler. |
Volledig BCP Scenario en Recovery-aanpak-schema oefening(grote zandbak) | Gebruik een BCP-scenario van een incident voor een rollenspel voor het management om te testen dat het continuïteitsplan en de recovery schema’s functioneel goed zijn. Deze test kan gebruikt worden om de samenwerking tussen de werkgroepen te testen nadat deze elk apart al een test gedaan hebben. | De werkgroep organisatiebeheersing maakt een rollenspel gebaseerd op een scenario. Hierbij is het de bedoeling om de deelnemers van alle pijlers samen te trainen en de scenariostappen te testen. Deelnemers zijn de leden van het crisisteam en de BCP teams. |
Disaster Recovery test | D/R test: test dat de ICT systemen kunnen hersteld worden in de D/R site. | ICT Operations maakt jaarlijks een scenario betreffende de werkzaamheid en werkbaarheid van de D/R-site. |
Test crisisvergaderzalen | Test het functioneren van de crisisvergaderzalen. | Team Security houdt een vergadering in de crisisvergaderzaal op de hoofdlocatie en op de alternatieve locatie. De telefoon- en Internetverbindingen worden uitgetest door ICT Operations. De inhoud van de kasten wordt nagekeken aan de hand van de inventaris. |
Activiteitstest | Verplaats de business activiteiten naar alternatieve locatie of tele/thuiswerk voor een vooraf vast bepaalde tijd, om te testen dat de deelnemers hun systemen, toepassingen en informatie kunnen gebruiken, en hun kritieke processen kunnen blijven uitvoeren. | De telewerkers van de entiteit kunnen allemaal samen worden gevraagd om te thuiswerken gedurende een periode (nader te bepalen, bijv. een dag). Daarbij worden enkel aan ICT-operationsmensen en voor vergaderingen uitzonderingen toegestaan. Er wordt gewerkt op de servers te Brussel. |
Bij elke fase van het testen van het BCP betrek je best (nieuwe) observatoren. Zij zien de gaten zitten die de auteurs al lang niet meer zien.
En dan, herzie en verbeter uw BCP
Je stak veel tijd en zweet in je eerste versie, alsook in het testen en communiceren van het BCP. Het is nu niet de bedoeling dat dit plan stof vangt op een schab in een kast of in een map op een server. Dan wordt het plan onbruikbaar, en zelfs vaak onvindbaar als je ‘t nodig hebt.
Technologie evolueert, mensen komen en gaan, processen wijzigen, personeel, zowel als klanten als leveranciers eveneens. Dus het plan moet up-to-date gehouden worden. Herzie het daarom best periodiek. Een veelgebruikte vuistregel is: jaarlijks. Discussieer erover met alle betrokken partijen.
Wat je ook moet doen is te rade gaan bij het personeel, nog voordat je het BCP herziet. Vraag aan alle afdelingen in de organisatie om het plan te reviewen. Betrek daarbij ook buitenposten en VAC’s, zelfs de buitenlandse posten. Na elke test en na elke crisis maak je een lessons identified en lessons learned op van wat gewerkt heeft, en wat niet.
Hoe voorzie je draagvlak voor het BCP, en awareness?
Wat je niet moet doen is niets doen à la “laissez faire, laissez passer”. Elk BCP moet gedragen zijn door de organisatie, top down, waarbij het topmanagement het voorbeeld geeft door het belang ervan te onderschrijven. Zij moeten dus weet hebben van het plan, zijn inhoud en zijn revisies en de testen en hun resultaten. Deze goedkeuring en het dragen van het plan kan en mag niet gedelegeerd worden naar het middelmanagement, of ondergeschikten.
Management is ook belangrijk voor de awareness van de man op de vloer. Deze blijft immers niet ongevoelig voor de wensen van zijn management. En als het personeel geen weet heeft van een plan, hoe zouden zij dan in Gods naam een gepaste reactie kunnen hebben? Je moet iemand van de top hebben achter je staan die de zaak in gang trekt. Daarvoor kan je van alles doen. Een gezamenlijke teambuilding (op verschillende niveau’s) rond BCM waarbij het plan moet gebruikt worden, maar waar ook plaats is voor fantasie, kan zeer goed werken. Niets werkt immers zo goed als wanneer men er een goede mate van plezier aan heeft. En het plan krijgt meer credibiliteit daardoor.
Bijlage: onderwerpen voor zandbakken.
Gebouw out | Infrastructuur out (Faciliteiten) | Gebrek aan technologie | Gebrek aan sleutelpersonen | Gebrek aan Leverancier / fabrikant | Andere |
Elektriciteits-panne | Watervoor-ziening panne | Telecom faling | Epidemie / Pandemie | Fabrikant gaat failliet | Interne fraude |
Brand | Verwarmings- panne | Netwerk faling | Werken vanaf recovery locatie met minimale ruimte | Leverancier ondergaat eigen supply chain faling | Reputatie issue |
Overstroming | Airco faling | Malware | Terreuraanslag NBC / Anthrax etc | Leverancier technologisch netwerk faalt | Diefstal van gegevens |
Bom(melding) | Stookolie problemen | In beslag name ICT systemen door gerecht na fraude | Bom(melding) | Terreuraanslag | Corruptie van data door (ex) interne medewerker |
Terreuraanslag | Elektriciteits-panne | (Cyber)Oorlog | Voedsel vergiftiging | (Cyber)oorlog | Milieuramp |
Verzegeling locaties door gerecht na fraude | Oorlog | Onderhouds-firma’s falen | Milieuramp | Elektriciteits-panne | (Cyber)Oorlog |
Verzegeling locaties door gerecht na aanslag / moord | Leveranciers falen | Gebouw met ICT-servers out | Transport staking / problemen | Interne fraude leverancier | Malware (Business faling) |
Oorlog | Onderhouds-firma’s falen | Elektriciteits-panne | Oorlog | Aardbeving | Elektriciteits-panne (Business faling) |
Aardbeving | Aardbeving | IT Leverancier faalt / failliet (HB) | Aardbeving | Euro faalt (?) | IT Leverancier faalt / failliet (Business faling) |
Verdacht gedrag | Aardbeving | Internet faalt | Sabotage | Monsterboete Europa etc | |
Vandalisme | Internet faalt | Euro faalt | België scheurt | ||
Inbraak | Euro faalt (?) | hittegolf | Euro faalt | ||
Sabotage | hittegolf | Sabotage | Vergrijzing | ||
Verdacht voorwerp of pakje | Sabotage | Fysieke agressie | Massieve inflatie | ||
Hold up | |||||
Gijzeling | Relatie met de pers | ||||
Tiger Kidnapping | Tiger Kidnapping | ||||
Dolle schutter | Dolle schutter | ||||
Zelfmoord | Zelfmoord | ||||
Verdwijning kind | Verdwijning kind |