Hva er en virksomhetskonsekvensanalyse (BIA)?

En virksomhetskonsekvensanalyse (BIA) er prosessen med å finne ut hvilke av aktivitetene dine som betyr mest, hvor raskt de vil trenge å gjenopprettes etter et avbrudd, og hva de er avhengige av. Det er fundamentet i ethvert kontinuitetsprogram: uten den er hver gjenopprettingsbeslutning gjetting.

Hva en BIA er til for

En BIA svarer på et bedragersk vanskelig spørsmål: hvis vi ble rammet av et avbrudd, hva ville vi beskyttet først, og hvor raskt? I stedet for å prøve å gjenopprette alt på én gang (umulig) eller beskytte det som føles viktig (subjektivt), rangerer den aktivitetene dine etter konsekvensen av å miste dem over tid, slik at prioriteringene bygger på fakta framfor den høyeste stemmen i rommet.

Hva en BIA produserer

En god BIA gir deg fire ting for hver kritiske aktivitet:

• En kritikalitetsrangering: hvor mye et avbrudd skader, og hvor raskt den skaden eskalerer (økonomisk, operasjonelt, omdømmemessig, regulatorisk).
• Gjenopprettingsmål: RTO, RPO og MTPD som sier hvor raskt aktiviteten må være tilbake og hvor mye datatap som er tolererbart.
• Avhengigheter: menneskene, applikasjonene, leverandørene, dataene og lokalene aktiviteten er avhengig av. En prosess er bare så gjenopprettbar som det den er avhengig av, så det er her skjulte enkeltpunktsfeil kommer til overflaten.
• Minimumsressurser: det du trenger for å drive aktiviteten på et akseptabelt, muligens redusert, nivå under gjenoppretting.

Disse resultatene er nettopp det gjenopprettingsstrategiene og kontinuitetsplanene dine bygges av. BIA-en ligger oppstrøms for alt annet.

Hvordan en BIA fungerer, i praksis

Formen er den samme selv om detaljene varierer:

1. Identifiser aktiviteter. List opp prosessene og tjenestene organisasjonen leverer, på et fornuftig detaljnivå.
2. Vurder konsekvens over tid. For hver av dem, vurder hvordan skaden av et avbrudd vokser: en time, en dag, en uke. Det er dette som avdekker MTPD-en.
3. Sett gjenopprettingsmål. Utled RTO og RPO fra den konsekvenskurven, innenfor MTPD-en.
4. Kartlegg avhengigheter. Spor hva hver aktivitet trenger, inkludert leverandørene og systemene du ikke kontrollerer.
5. Prioriter. Gjør alt sammen om til en forsvarlig gjenopprettingsrekkefølge.

Hvor BIA-er går galt

• For detaljert, for tidlig. Å analysere hundrevis av mikrooppgaver begraver signalet. Start på nivået av virksomhetstjenester.
• Optimistiske RTO-er. Alle vil ha «umiddelbart». En BIA tvinger fram den ærlige avveiningen mellom hvor raskt og hvor mye det koster.
• Å overse avhengigheter. En RTO på fire timer på en prosess betyr ingenting hvis en leverandør den er avhengig av trenger tre dager.
• Gjort én gang, aldri revidert. Virksomheten endrer seg; en BIA som er to år utdatert gjenspeiler ikke lenger hva som er kritisk.

Hvorfor den kommer først

BIA-en er grunnen til at et kontinuitetsprogram er forsvarlig overfor en revisor eller en tilsynsmyndighet. Den er den dokumenterte koblingen mellom hva som betyr noe og hva du er forberedt på å gjenopprette, og den er et uttrykkelig krav i ISO 22301 og i regelverk som DORA og NIS2, som forventer at gjenopprettingsmål er BIA-utledet og deretter testet.

ResiliencePilot kjører BIA-en som levende data, og holder kritikalitet, gjenopprettingsmål og avhengigheter oppdatert framfor innelåst i et regneark. Se ISO 22301-løsningen eller bestill en demo.