Een business impact analysis die mensen echt gebruiken
Gepubliceerd op 6 min. leestijd
Hoe u een business impact analysis nuttig maakt buiten het auditdossier: vertrek van diensten en processen, bepaal RTO en RPO, breng afhankelijkheden in kaart, houd ze levend en koppel ze aan herstelplannen en oefeningen.
Bijna elke organisatie met een continuïteitsprogramma heeft een business impact analysis (BIA). Veel minder organisaties gebruiken ze ook. Vaak is de BIA een groot rekenblad dat eens per jaar wordt ingevuld, afgetekend en opgeborgen, en pas weer wordt geraadpleegd wanneer de auditor erom vraagt. Bij een echte verstoring werken mensen uit het hoofd en via de telefoon.
Dat is zonde van een waardevolle oefening. Een goede BIA beantwoordt de vragen die in een crisis het belangrijkst zijn: wat moet eerst terugkomen, hoe snel, en waarvan hangt het af. Dit artikel beschrijft hoe u er een opbouwt die mensen echt openen.
Vertrek van diensten en processen, niet van systemen
De meest gemaakte fout is te beginnen met een inventaris van applicaties en te vragen hoelang elke applicatie onbeschikbaar mag zijn. Dat levert een lijst IT-herstelobjectieven op zonder verband met wat de organisatie werkelijk levert.
Vertrek in plaats daarvan van wat de organisatie doet voor haar klanten, burgers of patiënten: de diensten die ze levert en de processen die ze leveren. Vraag voor elke dienst aan de businessverantwoordelijke wat er na verloop van tijd gebeurt als ze stilvalt. De impact groeit zelden gelijkmatig; ze maakt meestal sprongen op bepaalde momenten, zoals het einde van een werkdag, een betalingsdeadline of een regelgevende termijn.
Beoordeel de impact over een klein aantal consistente categorieën, bijvoorbeeld:
- financieel verlies,
- schade voor klanten of andere personen,
- regelgevende en juridische gevolgen,
- reputatie,
- operationele kettingreacties op andere processen.
Gebruik voor elk proces dezelfde schaal, zodat de resultaten vergelijkbaar zijn. Het doel is een rangschikking die het managementteam herkent en kan verdedigen.
Bepaal herstelobjectieven die iets betekenen
Leid uit de impactbeoordeling de herstelobjectieven af:
- Maximaal toelaatbare verstoringsperiode (MTPD): het punt waarna de impact onaanvaardbaar wordt.
- Recovery time objective (RTO): de beoogde tijd om het proces op een aanvaardbaar niveau te hervatten, die korter moet zijn dan de MTPD.
- Recovery point objective (RPO): hoeveel gegevensverlies, uitgedrukt in tijd, het proces kan verdragen.
Het helpt ook om het minimale dienstverleningsniveau te vermelden dat u tijdens het herstel zou aanvaarden. Binnen vier uur hervatten op 40 procent van de capaciteit kan realistischer, en nuttiger, zijn dan een volledig herstelobjectief dat niemand haalt.
Wees eerlijk over het verschil tussen wat de business nodig heeft en wat de huidige opzet kan leveren. Dat verschil is geen falen van de BIA; het is een van haar belangrijkste resultaten.
Breng de afhankelijkheden in kaart
Een proces hangt van meer af dan een applicatie. Leg voor elk geprioriteerd proces vast wat het nodig heeft om te draaien:
- Mensen: sleutelrollen, minimale bezetting en schaarse vaardigheden.
- IT: applicaties, infrastructuur en gegevens, bij voorkeur gekoppeld aan uw assetinventaris of CMDB in plaats van overgetypt.
- Leveranciers: derde partijen en uitbestede diensten, inclusief de contracten die ze regelen.
- Locaties: kantoren, datacenters en andere faciliteiten, en of het werk naar elders kan verhuizen.
- Andere processen: input stroomopwaarts en afnemers stroomafwaarts.
In de afhankelijkheden bewijst de BIA haar waarde. Ze tonen wanneer een proces met een RTO van vier uur steunt op een applicatie met een herstelvermogen van twee dagen, of op één enkele leverancier zonder getest alternatief. Deze herstelkloven moet het management als eerste zien.
Houd ze levend
Een BIA veroudert om dezelfde redenen als elk register: organisaties reorganiseren, systemen worden vervangen, leveranciers veranderen en niemand werkt het bestand bij. Een paar gewoonten houden ze actueel:
- Wijs per proces een eigenaar aan die verantwoordelijk is voor de impactbeoordeling en de afhankelijkheden.
- Herzie bij elke wijziging, niet alleen jaarlijks: nieuwe systemen, nieuwe leveranciers, fusies en incidenten moeten allemaal leiden tot een herziening van de processen die ze raken.
- Koppel in plaats van te kopiëren. Wanneer de BIA verwijst naar assets en leveranciers die elders worden beheerd, stromen wijzigingen automatisch door.
- Houd ze klein genoeg om te onderhouden. Een gerichte set goed begrepen processen is beter dan honderden rijen die niemand controleert.
Koppel ze aan herstelplannen en oefeningen
Een BIA die op zichzelf staat, blijft een document. Haar waarde komt van wat ze aanstuurt.
Herstelplannen. Disaster-recovery- en bedrijfscontinuïteitsplannen moeten worden opgebouwd voor de processen en afhankelijkheden die de BIA prioriteert, en herstelobjectieven vermelden die overeenkomen met haar RTO en RPO. Wanneer de BIA een objectief wijzigt, moet de eigenaar van het plan dat weten.
Oefeningen. Testen moet voorrang geven aan de meest kritieke processen en de meest risicovolle afhankelijkheden. Een oefening is ook de beste manier om na te gaan of de herstelobjectieven realistisch zijn. Als een test aantoont dat het herstel twaalf uur duurt tegenover een RTO van vier, moet ofwel het plan ofwel het objectief veranderen, en die beslissing ligt bij de business.
Incidenten. Tijdens een echte verstoring vertelt de BIA het crisisteam wat eerst moet worden hersteld. Na het incident moet de evaluatie terugvloeien naar de BIA: was de impact zoals verwacht, waren de afhankelijkheden volledig?
Rapportering. Het management heeft het rekenblad niet nodig. Het moet weten welke kritieke diensten herstelkloven hebben, welke plannen verouderd zijn en welke oefeningen problemen aan het licht brachten die nog openstaan.
Een praktisch vertrekpunt
Is uw huidige BIA een rekenblad dat niemand opent, dan hoeft u niet opnieuw te beginnen. Kies de vijf tot tien diensten die het belangrijkst zijn, bevestig hun eigenaars, valideer samen met hen de impact en de herstelobjectieven, en breng hun afhankelijkheden degelijk in kaart. Koppel die aan de herstelplannen en de volgende oefening. Breid daarna het toepassingsgebied uit.
Tools kunnen helpen door processen, assets, leveranciers, plannen en oefeningen als gekoppelde records bij te houden, zodat een herstelkloof zichtbaar wordt zodra het herstelvermogen van een afhankelijkheid tekortschiet tegenover de RTO van een proces. Maar het zijn de gesprekken met proceseigenaars die de analyse geloofwaardig maken.
Dit artikel is algemene informatie, geen juridisch advies.