Konsekvensanalyse (BIA)

En BIA er bevidst ligeglad med årsagen: den spørger ikke, hvad der kan gå galt, eller hvor sandsynligt det er, men kun hvad der sker med hver aktivitet, når den står stille, og hvordan skaden vokser over tid. Det er grænsen mellem en BIA og en risikoanalyse, som kobler trusler og sårbarheder med sandsynlighed. ISO 22301:2019 punkt 8.2.2 kræver, at organisationen fastlægger typer af konsekvenser og kriterier for dem, identificerer de aktiviteter, der leverer dens produkter og ydelser, vurderer konsekvenserne over tid, fastsætter prioriterede tidsrammer for genoptagelse af hver aktivitet og identificerer de afhængigheder og ressourcer, aktiviteterne bygger på, herunder leverandører. ISO/TS 22317:2021 giver den detaljerede vejledning, og NIST SP 800-34 Rev. 1 beskriver en BIA på systemniveau til beredskabsplanlægning.

Kerneresultatet er en række tidsparametre. Den maksimalt acceptable afbrydelsesperiode (MTPD i ISO, MTD i NIST SP 800-34) er det tidspunkt, hvor konsekvenserne bliver uacceptable. Recovery time objective (RTO) er målet for, hvornår en aktivitet skal være genoptaget eller et system genetableret, og den skal ligge et godt stykke inden for MTPD; recovery point objective (RPO) er det største acceptable datatab målt i tid og bestemmer, hvor ofte der skal tages backup eller replikeres. ISO bruger også minimum business continuity objective (MBCO), det reducerede serviceniveau, der kan accepteres under en afbrydelse. Kæden skal hænge sammen: En aktivitet med en RTO på fire timer kan ikke hvile på et system, der først er oppe efter et døgn, eller på en leverandør med support næste hverdag.

En BIA gennemføres typisk som interviews eller spørgeskemaer med procesejerne, hvor konsekvenskategorier som økonomi, kunder, lovgivning og myndigheder, omdømme samt liv og helbred vurderes ved tidspunkter som 1 time, 4 timer, 1 døgn, 3 døgn og 1 uge. Kurverne er sjældent lineære: Lønkørslen er ligegyldig i flere dage og så pludselig kritisk lige før lønudbetalingen, så spidsbelastningsperioder skal med. Derefter kortlægges afhængighederne fra aktivitet til applikationer, data, infrastruktur, personer, lokationer og tredjeparter, og det er her, skjulte single points of failure som en fælles identitetsudbyder dukker op.

Klassiske fejl er, at alle procesejere erklærer deres proces kritisk med en RTO på nul, at IT-drevne analyser lister systemer i stedet for forretningsaktiviteter, at RTO aldrig sammenholdes med den faktiske genetableringsevne, og at analysen ikke opdateres efter omorganiseringer eller flytning til SaaS. Regulering nævner nu BIA direkte: DORA (forordning (EU) 2022/2554) art. 11, stk. 5, kræver, at finansielle enheder udfører en BIA af deres eksponering for alvorlige forretningsforstyrrelser, og NIS2 art. 21, stk. 2, litra c, kræver foranstaltninger til driftskontinuitet og katastrofeberedskab, som en BIA er det praktiske grundlag for.