Varför er organisation behöver en DRP – bortom det uppenbara

Att driftstopp kostar pengar är ingen nyhet. Men det finns fler dimensioner som driver behovet av en formaliserad DRP under 2026:

Regulatoriska krav har skärpts

NIS2-direktivet, som nu implementerats i svensk lag, ställer explicita krav på incidenthantering och driftkontinuitet för väsentliga och viktiga entiteter. Rapportering av betydande incidenter ska ske inom 24 timmar. Integritetsskyddsmyndigheten (IMY) bevakar GDPR-efterlevnad, och en incident som leder till dataförlust utan adekvat DRP kan betraktas som bristande tekniska och organisatoriska åtgärder enligt artikel 32.

Ransomware-landskapet kräver offline-förmåga

I Opsios SOC ser vi att ransomware-attacker under 2025–2026 i allt högre grad riktar sig mot backupsystem först. Det innebär att en DRP som bara förlitar sig på online-replikor kan vara otillräcklig. Isolerade, oföränderliga backuper (immutable backups) och förmågan att återställa från dem i en ren miljö är inte längre en lyxåtgärd – det är baslinjen.

Leverantörsberoendet ökar

Fler svenska organisationer kör arbetsbelastningar i publika molnplattformar. Det reducerar risken för fysiska katastrofer men introducerar nya beroenden: regionsavbrott, API-ändringar, kontoproblem. Flexeras State of the Cloud har konsekvent visat att de flesta organisationer använder multicloud-strategier, men långt ifrån alla har DR-planer som täcker scenarier där en primär molnleverantör har ett större avbrott.

Mallstruktur för en disaster recovery-plan

Nedan följer en konkret struktur som ni kan använda som utgångspunkt. Anpassa den till er organisations storlek och komplexitet.

1. Dokumentöversikt och scope

• Planens syfte och avgränsning
• Vilka system, tjänster och platser som omfattas
• Senaste revisionsdatum och godkännande
• Koppling till övergripande BCP och informationssäkerhetspolicy

2. Roller och ansvarsområden

OOB-kanal (Out-of-Band) är kritisk. Om er primära kommunikation (exempelvis Microsoft Teams) ligger i samma infrastruktur som drabbats, behöver ni en alternativ kanal – mobiltelefon-kedja, Signal-grupp, satellittelefon för extremscenarier.

3. Systemklassificering och återställningsprioritet

Det här är kärnan i planen. Varje system klassificeras efter affärspåverkan:

Denna klassificering bör vara förankrad med verksamheten, inte enbart IT. En CTO:s uppfattning om vad som är kritiskt kan skilja sig markant från sälj- eller logistikchefens.

4. Tekniska återställningsprocedurer

För varje P1- och P2-system, dokumentera steg-för-steg:

• Förutsättningar: vilken infrastruktur behöver vara på plats innan återställning kan starta?
• Datakällor: var finns backuper/replikor? Vilken retention?
• Procedur: konkreta steg, kommandon, kontrollpunkter
• Verifiering: hur bekräftar ni att systemet faktiskt fungerar korrekt efter återställning?
• Beroenden: vilka andra system måste vara uppe först?

Om er infrastruktur hanteras som Infrastructure as Code (Terraform, Pulumi, CloudFormation) bör era IaC-repos vara en del av DR-strategin – men förvara dem inte enbart i samma molnkonto som produktionsmiljön.

Managerad DevOps

5. Kommunikationsplan

Definiera för varje scenario:

• Intern kommunikation: vem informeras, när, via vilken kanal
• Kundkommunikation: statusuppdateringar, förväntad återställningstid
• Myndighetskontakt: NIS2-rapportering (24 timmar), GDPR-anmälan till IMY (72 timmar vid personuppgiftsincident)
• Leverantörskontakt: eskalering till molnleverantör, MSP, nätverksoperatör

6. Testplan och övningsschema

Det oannonserade testet är det mest avslöjande. I Opsios NOC har vi genomfört sådana med kunder och resultatet är nästan alltid att den faktiska återställningstiden överstiger den dokumenterade med faktor 2–3 vid första försöket.

Molnbaserad disaster recovery – det realistiska alternativet

För de flesta medelstora svenska organisationer är traditionell DR (dedikerat sekundärt datacenter) orimligt kostnadskrävande. Molnbaserad DR förändrar ekvationen fundamentalt.

AWS-baserad DR

AWS Elastic Disaster Recovery (DRS) i eu-north-1 (Stockholm) replikerar servrar kontinuerligt till en staging-miljö med lågkostnadsinstanser. Vid failover startas fullstora instanser – ni betalar för produktionskapacitet först när den behövs. Cross-region replikering till exempelvis eu-west-1 (Irland) ger geografisk redundans inom EU.

Azure-baserad DR

Azure Site Recovery med Sweden Central som primär region och Sweden South eller West Europe som DR-region erbjuder liknande funktionalitet. Fördelen med Azure för svenska organisationer med Microsoft 365-beroende är den integrerade ekosystemupplevelsen.

Multicloud-DR

Att använda en molnleverantör som DR för en annan (exempelvis Azure som DR för AWS-baserad produktion) ger maximal oberoende men kräver betydligt mer kompetens och underhåll. Det är sällan värt komplexiteten om inte regulatoriska krav specifikt kräver det.

Managerade molntjänster

Molnmigrering

Vanliga misstag vi ser i DR-planer

Baserat på hundratals granskningar av kundmiljöer i Opsios SOC/NOC, här är de vanligaste bristerna:

Planen finns men har aldrig testats. Ett dokument som ingen har övat på ger en falsk trygghet som kan vara värre än ingen plan alls – för det skapar en illusion av beredskap.

RTO/RPO-mål saknar förankring i verkligheten. Planen lovar 15 minuters RTO, men den faktiska proceduren tar 4 timmar. Testa, mät, justera.

Backup-verifiering saknas. Backuper körs schemalagt och rapporteras som "lyckade", men ingen har verifierat att en faktisk restore fungerar. Vi har sett fall där krypterade backuper saknade tillgängliga dekrypteringsnycklar.

Kontaktinformation är inaktuell. Medarbetare byter roller, telefonnummer ändras. En kontaktlista som inte uppdateras löpande är värdelös under en kris.

Molnkontots root-credentials är inte skyddade. Om er DR-plan kräver åtkomst till ett AWS-konto eller Azure-prenumeration, och MFA-enheten ligger i samma brandhärjade kontor, har ni ett problem.

Molnsäkerhet

Steg-för-steg: så bygger ni er DR-plan

1. Genomför en Business Impact Analysis (BIA) – identifiera kritiska processer och deras toleranser för nedtid och dataförlust

2. Inventera IT-tillgångar – alla system, beroenden, dataflöden och ägare

3. Definiera RTO/RPO per system – baserat på BIA, inte önsketänkande

4. Designa teknisk DR-arkitektur – backup-strategi, replikeringsmetod, failover-mekanism

5. Dokumentera procedurer – steg-för-steg per system, inklusive verifieringskriterier

6. Tilldela roller – med backup-personer för varje roll

7. Etablera kommunikationsplan – inklusive OOB-kanaler

8. Testa – börja med tabletop, eskalera till fullskalig simulation

9. Iterera – uppdatera efter varje test, organisationsförändring eller ny hotbild

10. Förvara planen säkert – inte enbart digitalt i samma infrastruktur den ska rädda. Utskriven kopia i kassaskåp, kopia hos MSP.

Cloud FinOps

Opsios perspektiv: vad vi ser i produktion

Vårt NOC i Karlstad och Bangalore hanterar incidenter dygnet runt. En observation som genomsyrar vår erfarenhet: organisationer som övar regelbundet återhämtar sig snabbare – inte för att tekniken är bättre, utan för att människorna vet vad de ska göra. Stress under en incident reducerar kognitiv förmåga drastiskt. Inövade procedurer kompenserar för det.

Vi rekommenderar också att DR-planen ägs av verksamheten, inte enbart av IT. En CIO eller CTO bör ha mandat att aktivera planen, men beslutet om prioriteringsordning vid återställning är i grunden ett affärsbeslut.

Om ni saknar intern kapacitet att bygga och underhålla en DRP finns det ett starkt argument för att lägga den löpande förvaltningen hos en managerad tjänsteleverantör (MSP) med 24/7-beredskap – inte för att outsourca ansvaret, utan för att säkerställa att planen faktiskt lever.

Managerade molntjänster

Vanliga frågor

Vad är skillnaden mellan en disaster recovery-plan och en business continuity-plan?

En disaster recovery-plan (DRP) fokuserar specifikt på att återställa IT-system och data efter en incident – den handlar om teknisk återhämtning med definierade RTO- och RPO-mål. En business continuity-plan (BCP) är bredare och täcker hela verksamhetens förmåga att fortsätta leverera under och efter en störning, inklusive personal, lokaler och leverantörskedjor. DRP är en delmängd av BCP.

Hur ofta bör vi testa vår disaster recovery-plan?

Minst kvartalsvis för kritiska system, och alltid efter större infrastrukturändringar. I Opsios NOC ser vi att organisationer som testar sällan (en gång per år eller mindre) i snitt har tre gånger längre faktisk återställningstid än vad deras plan utlovar. Testa med tabletop-övningar varje kvartal och fullskaliga simuleringar minst årligen.

Vilka krav ställer NIS2 på disaster recovery?

NIS2-direktivet, som implementerats i svensk lag, kräver att väsentliga och viktiga entiteter har dokumenterade åtgärder för incidenthantering och driftkontinuitet. Det inkluderar riskanalyser, incidentrapportering inom 24 timmar och verifierade återställningsrutiner. Bristande efterlevnad kan leda till sanktionsavgifter på upp till 10 miljoner euro eller 2 % av global omsättning.

Vad är rimliga RTO- och RPO-mål för ett medelstort svenskt företag?

Det beror helt på vilket system vi pratar om. För affärskritiska system (ERP, kundplattformar) siktar de flesta på RTO 1–4 timmar och RPO 15–60 minuter. För stödsystem kan RTO 24 timmar och RPO 4–8 timmar vara acceptabelt. Nyckeln är att definiera mål per tjänst baserat på affärspåverkan – inte sätta ett enda mål för allt.

Kan vi bygga disaster recovery i molnet utan egen serverinfrastruktur?

Ja, och för de flesta medelstora organisationer är det det smartaste alternativet. AWS i eu-north-1 (Stockholm) och Azure Sweden Central erbjuder DR-tjänster som Azure Site Recovery och AWS Elastic Disaster Recovery som replikerar arbetsbelastningar till en sekundär region. Ni betalar för standby-kapacitet snarare än full duplicerad infrastruktur, vilket drastiskt sänker DR-kostnaden.