En kontinuitetsplan beskriver hur din organisation håller prioriterade verksamheter igång på en acceptabel nivå när system, lokaler, personal eller leverantörer slutar fungera. Ur ett complianceperspektiv är den inte längre ett frivilligt beredskapsdokument. GDPR kräver att ni kan återställa tillgången till personuppgifter i tid. Cybersäkerhetslagen, som genomför NIS2 i svensk rätt, gör kontinuitetshantering, säkerhetskopiering och krishantering till lagstadgade säkerhetsåtgärder. Här går vi igenom vad planen ska innehålla, hur du tar fram den steg för steg och hur du visar en tillsynsmyndighet att den faktiskt fungerar.
Kort sagt
- En kontinuitetsplan ska innehålla reservrutiner, återställningsrutiner, återgångsrutiner, roller, ansvar och kontaktuppgifter, enligt MSB:s vägledning.
- För verksamheter som omfattas av cybersäkerhetslagen (gäller sedan den 15 januari 2026) är kontinuitetshantering ett uttryckligt krav, inte en rekommendation.
- Planen måste fungera parallellt med incidentrapporteringen: 72 timmar till IMY vid en personuppgiftsincident, 24 timmar för en tidig varning enligt NIS2.
- Leverantörer och deras avbrottstider hör hemma i planen. Det är oftast där kedjan brister.
- En plan som aldrig övas blir en hyllvärmare. Övningar, uppföljning och dokumentation är det som skapar efterlevnad.
Innehållsförteckning
- Vad en kontinuitetsplan är, och vad den inte är
- Därför är kontinuitet ett complianceområde
- Vad planen ska innehålla
- Så tar du fram kontinuitetsplanen steg för steg
- Exempel: när lönesystemet går ner
- Vanliga misstag
- Vår syn: kontinuitet är ett arbetssätt, inte ett dokument
- Samla kontinuitetsarbetet i Trustview
- Vanliga frågor om kontinuitetsplaner
- Källor
Vad en kontinuitetsplan är, och vad den inte är
Myndigheten för samhällsskydd och beredskap beskriver en kontinuitetsplan som ett stöd för personalen: den ska hjälpa medarbetarna att veta vad de ska göra när en prioriterad aktivitet eller resurs störs, så att verksamheten kan upprätthållas på en tolerabel nivå. Planen ska vara enkel och tydlig att använda och kommunicerad till dem som berörs.
Tre förväxlingar är vanliga:
- Kontinuitetsplan är inte samma sak som en IT-återställningsplan. Återställning av system är en del, men planen handlar om verksamheten: hur ni betalar ut löner, tar emot ärenden eller levererar till kunder medan systemen ligger nere.
- Kontinuitetsplan är inte samma sak som incidenthantering. Incidenthanteringen upptäcker, begränsar och rapporterar händelsen. Kontinuitetsplanen håller verksamheten igång under tiden och styr återgången till normalläge.
- Kontinuitetsplan är inte en krisledningsplan. Krisledningen fattar de strategiska besluten. Kontinuitetsplanen ger de operativa rutiner som besluten vilar på.
IMY betonar att kontinuitetshantering syftar till att minska sårbarheten och öka motståndskraften mot händelser som påverkar kritiska processer, och att arbetet ska vara en del av organisationens samlade informationssäkerhetsarbete. Det är just den kopplingen som gör kontinuitetsplanen till en compliancefråga.
Därför är kontinuitet ett complianceområde
Flera regelverk ställer krav på samma förmåga, men från olika håll. För en CISO, ett dataskyddsombud eller en chefsjurist är det värt att se dem tillsammans, eftersom en och samma plan kan täcka flera krav om den är rätt byggd.
GDPR: tillgänglighet är en del av säkerheten
Dataskyddsförordningen räknar tillgänglighet och motståndskraft som en del av säkerheten för personuppgifter, och den personuppgiftsansvarige ska kunna återställa tillgången till uppgifterna i rimlig tid efter en incident. IMY lyfter därför in dataskyddsperspektivet i kontinuitetshanteringen. Ett avbrott där personuppgifter blir otillgängliga, till exempel efter en ransomwareattack, kan i sig vara en personuppgiftsincident.
Då gäller också rapporteringskravet. Enligt IMY ska ni anmäla personuppgiftsincidenter som medför risk för de registrerades rättigheter och friheter, som utgångspunkt inom 72 timmar från att ni fått vetskap om dem. Kontinuitetsplanen måste alltså säga vem som bedömer incidenten och vem som anmäler, även när e-post, intranät och ärendesystem inte fungerar. Hur själva anmälan går till beskriver vi i guiden IMY-anmälan inom 72 timmar.
Cybersäkerhetslagen och NIS2: kontinuitet blir lagkrav
Cybersäkerhetslagen (2025:1506) trädde i kraft den 15 januari 2026. Säkerhetsåtgärderna ska utgå från ett allriskperspektiv, vilket betyder att planen ska täcka mer än cyberattacker: strömavbrott, brand, personalbortfall och leverantörsavbrott hör också hit.
Lagen genomför NIS2-direktivet, där artikel 21 räknar upp kontinuitetshantering, såsom hantering av säkerhetskopior och katastrofåterställning, samt krishantering bland de minimiåtgärder som verksamheterna ska vidta. Samma artikel kräver säkerhet i leveranskedjan, vilket i praktiken betyder att leverantörernas förmåga att leverera vid störning ska vägas in.
NIS2 har dessutom egna tidsfrister för betydande incidenter: en tidig varning inom 24 timmar, en incidentanmälan inom 72 timmar och en slutrapport inom en månad. Direktivet ger också ramar för sanktionsavgifter, för väsentliga verksamheter upp till 10 miljoner euro eller 2 procent av den globala årsomsättningen.
För vissa digitala leverantörer, som molntjänster, datacenter och leverantörer av förvaltade tjänster, preciserar kommissionens genomförandeakt för riskhanteringsåtgärder kraven ytterligare, bland annat med krav på en kontinuitets- och katastrofåterställningsplan som bygger på riskbedömningen och testas regelbundet. Även om din verksamhet inte omfattas direkt är akten ett bra riktmärke för vad en granskare förväntar sig.

Samhällsviktig verksamhet och offentlig sektor
Kommuner, regioner och andra aktörer inom samhällsviktig verksamhet har sedan länge arbetat med kontinuitet inom ramen för risk- och sårbarhetsanalyser. MSB beskriver hur kontinuitetshantering ger underlag till RSA-arbetet genom beroendeanalyser, riskbedömningar och åtgärdsförslag. Det arbetet går att återanvända i NIS2-efterlevnaden i stället för att göras två gånger.
Regelverken i överblick
| Regelverk | Vad som krävs | Tidsfrist vid incident |
|---|---|---|
| GDPR | Förmåga att upprätthålla och återställa tillgänglighet till personuppgifter | Anmälan till IMY inom 72 timmar vid risk |
| Cybersäkerhetslagen (NIS2) | Kontinuitetshantering, säkerhetskopiering, katastrofåterställning, krishantering, leverantörskedjans säkerhet | Tidig varning 24 timmar, anmälan 72 timmar, slutrapport en månad |
| Samhällsviktig verksamhet | Kontinuitetshantering som underlag för risk- och sårbarhetsanalys | Enligt egen plan och sektorns föreskrifter |
Vad planen ska innehålla
MSB:s vägledning och IMY:s rekommendationer pekar på samma grundinnehåll. En kontinuitetsplan som håller vid en granskning innehåller minst:
- Omfattning och syfte. Vilken verksamhet, process eller resurs planen gäller och vilken lägsta acceptabla nivå ni ska klara.
- Aktiveringskriterier. När planen träder i kraft, vem som beslutar det och när den avaktiveras.
- Roller och ansvar. Namngivna funktioner med ersättare, så att planen inte hänger på en enda person.
- Reservrutiner. Hur arbetet utförs under störningen: manuella blanketter, alternativ lokal, annan kommunikationskanal.
- Återställningsrutiner. I vilken ordning system och resurser återställs, och vilka mål för återställningstid (RTO) och acceptabel dataförlust (RPO) som gäller.
- Återgångsrutiner. Hur ni går tillbaka till normal drift, inklusive efterregistrering av det som hanterats manuellt.
- Kontaktlista. Interna nyckelpersoner, leverantörer, IMY, sektorsmyndighet och CERT-SE, tillgänglig även offline.
- Kommunikation. Färdiga underlag för information till personal, kunder, registrerade och tillsynsmyndighet.
- Koppling till incidentrapporteringen. Vem som bedömer rapporteringsplikt enligt GDPR och NIS2 och var underlaget dokumenteras.
Punkt 9 glöms ofta bort. Under ett avbrott är det lätt att all energi går till teknisk återställning, medan tidsfristerna för anmälan löper. En strukturerad incidentlogg enligt GDPR gör att beslut och tidpunkter dokumenteras löpande.
Så tar du fram kontinuitetsplanen steg för steg
1. Identifiera det som inte får stanna
Börja med en konsekvensanalys, ofta kallad BIA (business impact analysis). Vilka processer skulle orsaka allvarlig skada för kunder, registrerade eller samhälle om de stod still i en timme, en dag eller en vecka? MSB:s metodstöd för kontinuitetshantering utgår från just konsekvenserna av att informationstillgångar blir otillgängliga. Metoden liknar riskbedömningen i en ISO 27005-riskanalys, och resultaten bör hänga ihop.
2. Kartlägg beroenden
För varje prioriterad process: vilka system, personer, lokaler, data och leverantörer behövs? Här brister många organisationer. Det räcker inte att skydda de egna systemen om lönen körs i en extern molntjänst eller om kundtjänsten är beroende av en telefonileverantör.
3. Sätt maximala avbrottstider
Bestäm hur länge varje kritisk resurs får vara otillgänglig, och jämför med vad leverantörerna faktiskt lovar i sina avtal. Om er RTO för ett ärendesystem är fyra timmar men leverantörens avtal säger 48 timmar har ni ett gap som måste hanteras med en reservrutin eller ett nytt avtal.
4. Bedöm leverantörerna
NIS2 kräver säkerhet i leveranskedjan, och kontinuitet är en central del av det. Fråga efter leverantörens egen kontinuitetsplan, testresultat och backup-rutiner. En modell för leverantörsriskklassning hjälper dig att lägga mest tid på de leverantörer som bär upp de kritiska processerna, och checklistan för leverantörsbedömning enligt NIS2 ger frågorna.
5. Skriv rutinerna och förankra dem
Skriv reserv-, återställnings- och återgångsrutiner tillsammans med dem som ska använda dem. En rutin som skrivits av IT utan verksamheten fungerar sällan i praktiken. Låt ledningen fastställa planen, eftersom det är ledningen som ytterst ansvarar för att säkerhetsåtgärderna finns på plats.
6. Öva
En plan som ingen känner till är en hyllvärmare. Börja med en skrivbordsövning där ni går igenom ett scenario och följ upp med tekniska tester av återställning från backup. MSB:s checklista för kontinuitetshantering kan användas för att följa upp att alla delar finns på plats.
7. Följ upp och uppdatera
Uppdatera planen efter varje övning, incident, organisationsförändring och nytt leverantörsavtal. Dokumentera vad som ändrades och varför. Det är den dokumentationen som visar en tillsynsmyndighet att arbetet är systematiskt.
Exempel: när lönesystemet går ner
Scenario. Ett medelstort företag som omfattas av cybersäkerhetslagen får ett meddelande en torsdagsmorgon: leverantören av löne- och HR-systemet har drabbats av en ransomwareattack. Systemet är otillgängligt, och det är oklart om personuppgifter om de anställda har kopierats. Löneutbetalning ska ske på måndag.
Med en fungerande kontinuitetsplan händer följande:
- Aktivering. HR-chefen aktiverar planen enligt fastställda kriterier och kallar in den utsedda gruppen.
- Reservrutin. Föregående månads löneunderlag, som exporteras och lagras separat, används för en preliminär utbetalning. Avvikelser justeras nästa månad.
- Incidentbedömning. Dataskyddsombudet startar en incidentlogg, begär information från leverantören och bedömer om det är en personuppgiftsincident med risk. 72-timmarsfristen räknas från att ni fick vetskap, inte från att leverantören är klar med sin utredning.
- NIS2-bedömning. CISO bedömer om händelsen är en betydande incident som kräver tidig varning inom 24 timmar.
- Kommunikation. Färdiga meddelanden till de anställda anpassas och skickas via en reservkanal.
- Återgång. När systemet är tillbaka stäms utbetalningarna av, och lärdomarna förs in i planen och i leverantörsbedömningen.
Utan plan hade samma timmar gått åt till att leta kontaktuppgifter, diskutera vem som beslutar och upptäcka att ingen visste var det senaste löneunderlaget fanns.
Vanliga misstag
- Planen är en IT-plan. Verksamhetens reservrutiner saknas och personalen vet inte hur de ska arbeta manuellt.
- Planen ligger på samma server som drabbas. Den måste finnas tillgänglig offline eller i en separat miljö.
- Leverantörerna saknas. Kritiska beroenden utanför den egna organisationen är inte kartlagda.
- Ingen koppling till rapporteringen. Teknisk återställning prioriteras medan tidsfristerna till IMY och sektorsmyndighet löper.
- Ingen övning. Planen har fastställts men aldrig testats.
- Ingen spårbarhet. Ändringar, övningar och beslut dokumenteras inte, och det går inte att visa efterlevnad.
Den sista punkten är den som oftast blir synlig vid en tillsyn. Läs mer om hur du visar att du följer GDPR och om vad som krävs i en NIS2-gap-analys för ledningen.
Vår syn: kontinuitet är ett arbetssätt, inte ett dokument
Vi ser ofta organisationer som har en välskriven kontinuitetsplan i en mapp, men där planen inte är kopplad till riskanalysen, incidentloggen eller leverantörsregistret. Då blir den inaktuell nästan direkt. När en leverantör byts, en process ändras eller en ny risk identifieras uppdateras ett register, men inte planen.

Vår erfarenhet som jurister som arbetar med svensk och europeisk dataskydds- och säkerhetsreglering är att efterlevnad uppstår i sambandet mellan delarna. Riskbedömningen ska peka ut de kritiska processerna, leverantörsbedömningen ska visa om leverantörerna klarar era avbrottstider, incidentloggen ska fånga när planen aktiveras och åtgärderna ska ha en ägare och ett datum. GDPR och cybersäkerhetslagen ställer samma grundfråga: kan ni visa att ni har kontroll? Det kan man sällan med ett fristående dokument.
Vi rekommenderar därför att du behandlar kontinuitetsplanen som ett levande ramverk med tydligt ansvar, en fast plats på ledningens agenda och en uppföljning som syns.
— Jesper
Samla kontinuitetsarbetet i Trustview
Trustview är en svenskutvecklad plattform byggd av jurister där du samlar riskbedömningar, konsekvensbedömningar, incidentloggning, leverantörsbedömningar, åtgärdsuppföljning och delegerat ansvar på ett ställe. Du kan skapa egna ramverk, till exempel för kontinuitetshantering, och få realtidsöversikt och automatiserade rapporter för GDPR, NIS2 och ISO 27000. Plattformen kostar från 2 500 kr per månad. Se priser och upplägg för Trustview, eller läs hur ett statligt bolag använder plattformen. Behöver ni stöd med tolkningen av kraven finns även juridisk rådgivning.
Vanliga frågor om kontinuitetsplaner
Är en kontinuitetsplan ett krav enligt GDPR?
GDPR nämner inte ordet kontinuitetsplan, men kräver att ni kan upprätthålla och återställa tillgängligheten till personuppgifter efter en incident. I praktiken är en kontinuitetsplan det enklaste sättet att visa den förmågan. IMY behandlar kontinuitetshantering som en del av informationssäkerheten enligt dataskyddsreglerna.
Vem ska äga kontinuitetsplanen?
Ledningen fastställer planen och ansvarar för att resurser finns. Den operativa ägaren är ofta CISO eller säkerhetschef, medan varje process har en verksamhetsansvarig som äger sina reservrutiner. Dataskyddsombudet bör granska kopplingen till incidentrapporteringen.
Hur ofta ska planen övas?
Varken GDPR eller cybersäkerhetslagen anger ett exakt intervall, men planen ska testas regelbundet. En rimlig utgångspunkt är minst en övning per år för varje kritisk process samt tester av återställning från backup. Uppdatera planen efter varje övning och verklig incident.
Vad är skillnaden mellan RTO och RPO?
RTO (recovery time objective) är hur lång tid det får ta innan en resurs fungerar igen. RPO (recovery point objective) är hur mycket data ni har råd att förlora, mätt i tid sedan senaste säkerhetskopia. Båda ska sättas per kritisk resurs och jämföras med leverantörernas avtal.
Räcker det med en mall?
En mall ger struktur, men innehållet måste bygga på er egen konsekvensanalys och era faktiska beroenden. En generisk plan som inte speglar verksamheten håller sällan vid en verklig störning eller vid en granskning.
Källor
- MSB: Fördjupning om kontinuitetsplan
- MSB: Kontinuitetshantering inom samhällsviktig verksamhet
- MSB: Kontinuitetshantering för informationstillgångar
- MSB: Checklista för verksamhetens arbete med kontinuitetshantering
- IMY: Kontinuitetshantering
- IMY: Personuppgiftsincidenter
- Riksdagen: Cybersäkerhetslag (2025:1506)
- EUR-Lex: NIS2-direktivet, artikel 21
- EUR-Lex: NIS2-direktivet (EU) 2022/2555
- EUR-Lex: Genomförandeakt om riskhanteringsåtgärder enligt NIS2




