BIA-exempel – så prioriterar ni kritiska processer, RTO och RPO

Av Mallbutiken · Sakuppgifter kontrollerade 30 september 2026 · Cirka 8 minuters läsning

En BIA blir användbar först när den leder till prioriteringar. Analysen ska hjälpa verksamheten förstå vilka processer som måste återställas först, hur konsekvenserna växer över tid, vilka beroenden som är kritiska och vilka återställningsmål som faktiskt behövs.

Exempel: ett mindre e-handels- och tjänsteföretag

Anta att bolaget säljer digitala och fysiska produkter online. Verksamheten är beroende av webbshop, betalning, kundservice, orderadministration, ekonomi och flera externa SaaS-tjänster. Ledningen vill veta vad som måste fungera först efter ett större IT-avbrott.

För varje aktivitet intervjuas processägaren om konsekvenser efter exempelvis 2 timmar, 8 timmar, 24 timmar, 3 dagar och 1 vecka. Konsekvenserna bedöms inom ekonomi, kund, juridik/compliance, drift, rykte och säkerhet.

Förenklat BIA-exempel

Tabellen är bara slutprodukten av resonemanget. Det viktiga är varför checkout hamnade före kundservice och vilka antaganden som ligger bakom RTO/RPO.

Bedöm hur konsekvensen förändras över tid

En process är inte automatiskt ”kritisk” bara för att den är viktig i vardagen. BIA:n behöver fråga när konsekvensen blir oacceptabel. Ett tvåtimmarsavbrott kan vara hanterbart medan ett dygn kan innebära stora ekonomiska eller rättsliga konsekvenser.

Dokumentera därför trösklar. Exempel: efter fyra timmar börjar större intäktsförlust, efter åtta timmar bryts ett kundlöfte, efter ett dygn uppstår manuella köer som inte kan arbetas ikapp. Då får kontinuitetsmålen en faktisk grund.

Skilj mellan maximal tolerans och återställningsmål

Organisationer använder ibland termer som MTPD eller maximal tolerabel avbrottstid för den punkt där konsekvensen inte längre kan accepteras. RTO bör i praktiken sättas med tillräcklig marginal före en sådan gräns, eftersom återställning aldrig bör planeras till exakt sista möjliga minut.

RTO och RPO – använd dem rätt

RTO, Recovery Time Objective, beskriver målet för hur snabbt tjänsten eller processen behöver vara återställd efter ett avbrott. RPO, Recovery Point Objective, beskriver hur långt tillbaka i tiden organisationen kan acceptera dataförlust vid återställning.

Om checkout har RTO 4 timmar men den tekniska lösningen kräver 12 timmar att återställa finns ett gap. BIA:n har då hittat en risk som måste hanteras genom bättre redundans, snabbare återställning, reservrutin eller ett omprövat affärsmål.

Om RPO är 15 minuter men backup bara tas en gång per dygn finns samma typ av gap. RPO är alltså inte ett önskemål som kan skrivas in i en plan utan tekniskt stöd.

Kartlägg människor, system och leverantörer

För varje kritisk process bör BIA:n identifiera beroenden. Det kan vara:

• nyckelpersoner och minsta bemanning,
• lokaler och utrustning,
• affärssystem och integrationer,
• identitets- och inloggningstjänster,
• data och dokumentation,
• telefoni och kommunikation,
• kritiska leverantörer och underleverantörer,
• el, nätverk och andra infrastrukturtjänster.

Det är vanligt att en ”sekundär” tjänst visar sig vara ett single point of failure. Ett exempel är identitetsleverantören: e-handeln kan vara tekniskt uppe men personalen kan ändå inte administrera den om SSO ligger nere.

Så förs BIA-resultatet över till kontinuitetsplanen

BIA:n svarar på vad som behöver prioriteras. Kontinuitetsplanen svarar på hur verksamheten ska fortsätta och återställas.

För processer med högst prioritet bör planen därför ange aktiveringskriterier, ansvar, reservrutiner, kontaktlistor, leverantörseskalering, återställningsordning, kommunikation och när normal drift kan återtas. Läs vad en kontinuitetsplan bör innehålla.

Om den tekniska tjänsten köps som SaaS bör återställningsmålen dessutom jämföras med leverantörens SLA. Se guiden om SLA, RTO och RPO.

Vanliga misstag i BIA-arbetet

• Alla processer blir kritiska. Då har analysen inte prioriterat.
• RTO sätts av IT ensam. Målet ska utgå från verksamhetens konsekvensbehov och därefter testas mot teknisk förmåga.
• RPO saknar koppling till data. Olika datamängder kan kräva olika tolerans.
• Beroenden missas. Särskilt identitet, integrationer och externa leverantörer.
• Ingen äger resultatet. Varje kritisk process behöver ansvarig processägare.
• BIA:n uppdateras aldrig. Nya system, produkter och leverantörer kan ändra prioriteringen.

Checklista för er egen BIA

• Lista verksamhetens aktiviteter och processägare.
• Bedöm konsekvens vid flera tidsintervall.
• Identifiera när konsekvensen blir oacceptabel.
• Prioritera processerna i återställningsordning.
• Sätt preliminära RTO- och RPO-mål.
• Kartlägg personal, system, data och leverantörer.
• Jämför målen mot faktisk återställningsförmåga.
• Dokumentera gap och åtgärder.
• För över resultatet till kontinuitetsplanen.
• Testa och ompröva efter större förändringar.

Behöver ni BIA och kontinuitetsplan i samma arbetsflöde?

Mallbutikens Kontinuitetsplan + BIA Mall 2026 kombinerar analys, prioritering och kontinuitetsplanering i Word, PDF och Excel. Pris i butiken: 249 kr.

Se Kontinuitetsplan + BIA

Vanliga frågor

Är RTO samma sak som maximal tolerabel avbrottstid?

Nej. RTO är ett återställningsmål. Den maximalt tolerabla avbrottstiden beskriver en yttre toleransgräns. Återställningsmålet bör normalt ligga tidigare.

Måste alla processer ha RPO?

RPO är framför allt relevant där återställning av data är en central del. För manuella processer kan andra återställningsmått vara mer användbara.

Hur ofta bör BIA uppdateras?

Det finns ingen universell intervall som passar alla. Gör regelbunden översyn och ompröva även när kritiska system, leverantörer, processer eller krav förändras.