DORA – vad varje företagsledare behöver veta

Digital operativ motståndskraft är inte längre ett IT-ansvar, det är ett ledningsansvar. EU-förordning 2022/2554, den så kallade Digital Operational Resilience Act, trädde i kraft den 17 januari 2025 och ställer nu direkta krav på hur finansiella entiteter i Sverige hanterar sina digitala risker. Sanktionerna är kännbara: böter upp till 10 miljoner euro och personligt ansvar för ledningen. Frågan är inte om DORA påverkar er verksamhet, utan hur väl ni är rustade när Finansinspektionen granskar er.

Innehållsförteckning

• Så identifierar du om DORA gäller för er verksamhet
• DORAs fem pelare – ramverk för digital motståndskraft
• Så hanterar du tredjepartsrisker och avtal under DORA
• DORA och NIS2 – skillnader, överlapp och ansvar
• Vår erfarenhet: DORA-efterlevnad handlar om ledarskap och pragmatism
• Efterlevnad och digital resiliens – ta nästa steg med TrustView
• Vanliga frågor om DORA

Viktiga Insikter

Så identifierar du om DORA gäller för er verksamhet

Efter att ha etablerat varför DORA är relevant, är nästa naturliga steg att förstå exakt vilka företag och roller som faktiskt träffas av förordningen. Det är en vanlig missuppfattning att DORA bara berör storbankerna. Verkligheten är bredare och mer komplex.

DORA omfattar finansiella entiteter i Sverige som står under Finansinspektionens tillsyn, vilket inkluderar banker, försäkringsbolag, betalningsinstitut, värdepappersbolag, kreditinstitut, AIF-förvaltare och fondbolag. Men det stannar inte där. Förordningen sträcker sig även till kritiska IKT-tredjepartsleverantörer, det vill säga molntjänstleverantörer, datacenterleverantörer och andra teknikleverantörer som spelar en avgörande roll i de finansiella entiteternas drift.

Frågor du bör ställa för att avgöra om DORA gäller din organisation:

• Är vi auktoriserade eller registrerade av Finansinspektionen?
• Levererar vi kritiska IKT-tjänster till finansiella entiteter?
• Är vi beroende av tredjepartsleverantörer för affärskritiska processer?
• Har vi avtal med finansiella entiteter som ger oss tillgång till deras kärninfrastruktur?

Svaret “ja” på någon av dessa frågor innebär att ni sannolikt berörs av DORA, antingen direkt som finansiell entitet eller indirekt som leverantör. Notera att undantagen är begränsade och kräver aktiv analys för att fastställas.

“Finansinspektionen prioriterar digital resiliens som en kärnfråga för den finansiella stabiliteten. Att bygga digital motståndskraft med DORA är inte bara regelefterlevnad, det är ett strategiskt skydd för hela verksamheten.”

Det är också viktigt att förstå att DORA inte tillämpas enhetligt. En liten betalningsinstitution har inte samma krav som en systemviktig bank. Det kallas proportionalitetsprincipen och innebär att kraven skalas efter organisationens storlek, riskprofil och verksamhetens komplexitet. Det ger viss flexibilitet, men befriar er inte från grundkraven.

Praktiskt exempel: En mellanstor försäkringsbolag som outsourcar sin kärnsystemmiljö till en extern molnleverantör måste säkerställa att den leverantören uppfyller DORAs krav. Om leverantören klassas som kritisk IKT-tredjepartsleverantör, faller de direkt under förordningens tillsyn. Det handlar inte om att skjuta ansvaret vidare, utan om att förstå att hela kedjan ska vara motståndskraftig.

DORAs fem pelare – ramverk för digital motståndskraft

Nästa steg är att förstå kärnan. DORA bygger på fem pelare som tillsammans utgör ett ramverk för digital operativ motståndskraft:

1. IKT-riskhantering – Ni måste ha ett dokumenterat ramverk för identifiering, skydd, upptäckt, respons och återhämtning vid IKT-relaterade hot.
2. Incidentrapportering – Allvarliga digitala incidenter ska rapporteras till Finansinspektionen via systemet FIDAC inom strikta tidsfrister.
3. Resiliensprovning – Regelbunden testning av era digitala system, inklusive avancerade penetrationstester för utvalda entiteter.
4. Tredjepartsriskhantering – Krav på due diligence, register och avtal med alla IKT-leverantörer.
5. Informationsutbyte – Möjlighet och uppmuntran att dela information om cyberhot och incidenter med andra aktörer i sektorn.

Incidentrapporteringen är en av de mest konkreta och tidskänsliga kraven. Rapporteringsfrister till FI via FIDAC är strikta:

Det är korta tidsramar som kräver att ni har etablerade rutiner, ansvariga roller och fungerande kommunikationskanaler redan innan en incident inträffar. En organisation som försöker skapa dessa processer i realtid under en kris riskerar att missa tidsfristerna och därmed utlösa sanktioner.

IKT-riskhanteringen, den första pelaren, har en direkt koppling till AI-krav och till hur organisationer ska hantera risker i komplexa teknologimiljöer. Det handlar om att bygga ett systematiskt skydd som inte bara reaktivt hanterar incidenter, utan proaktivt identifierar sårbarheter.

Resiliensprovning är mer nyanserat. Alla entiteter måste utföra grundläggande tester, men vissa, typiskt sett de som klassas som systemviktiga, måste även genomföra Threat-Led Penetration Testing (TLPT). Det är avancerade simulerade cyberattacker som utförs av godkända externa testare. Kostnaden och komplexiteten är hög, och det kräver noggrann planering i god tid.

Proffstips: Starta med en strukturerad GAP-analys mot DORAs fem pelare innan ni beslutar vilka investeringar som krävs. Styrelsen måste äga denna process. Det räcker inte med en IT-chefs rapport: ledningen behöver förstå riskbilden tillräckligt väl för att fatta informerade beslut. Integrera gärna DORA-analysen med er befintliga GDPR-konsekvensbedömning för att undvika dubbelarbete och skapa en sammanhållen bild av er efterlevnadsstatus.

DORA tillämpar även en proportionalitetsprincip som innebär att kraven anpassas efter storlek och komplexitet. Det är en viktig nyans: en liten kreditförmedlare behöver inte implementera samma testnivåer som en storbank, men alla måste ha ett fungerande IKT-riskramverk.

Så hanterar du tredjepartsrisker och avtal under DORA

När DORAs pelare är tydliga, framträder leverantörsrisken som en av de mest praktiskt krävande frågorna. Tredjepartshantering är det mest utmanande området för de flesta finansiella entiteter, med krav på register, avtalsförhandlingar och due diligence mot leverantörer som ibland är stora globala aktörer med lite intresse av att anpassa sina standardvillkor.

Vad kräver DORA konkret på tredjepartssidan?

• Ett fullständigt register över alla IKT-tredjepartsleverantörer, inte bara de kritiska.
• Riskbedömning av varje leverantör, med fördjupad analys för kritiska leverantörer.
• Avtal som innehåller specifika klausuler om tillgänglighet, integritet, återhämtning och exit.
• Revisions- och granskningsrättigheter som ger er möjlighet att kontrollera leverantörernas efterlevnad.
• Exitstrategier som säkerställer att ni kan byta leverantör utan att den operativa verksamheten störs.

Jämförelse: register kontra riskbedömningar

Studier av svenska bankers situation visar att regulatorisk fragmentering och TLPT-krav skapar betydande utmaningar, och att proaktiv due diligence är den viktigaste framgångsfaktorn.

Kontraktsklausuler är ofta det svåraste att förhandla. Stora molntjänstleverantörer, som hyperscalers, har sällan vilja att ändra sina standardvillkor. Här måste organisationer vara tydliga med vad som är absolut nödvändigt enligt DORA, kontra vad som är önskvärt. De obligatoriska punkterna inkluderar: beskrivning av tjänstens art och nivå, platser för databehandling, incidenthanteringsrutiner, revisionsrättigheter och exitplaner.

Vanliga fallgropar att undvika:

• Att förlita sig på befintliga avtal utan att granska om de uppfyller DORAs krav
• Att underskatta tiden det tar att förhandla om avtal med stora leverantörer
• Att inte ha en tydlig ägare av tredjepartsregistret internt
• Att glömma underleverantörer, det vill säga leverantörers egna leverantörer

Proffstips: Inled dialogen med era viktigaste leverantörer tidigt. Presentera DORAs krav som ett gemensamt intresse, inte som ett ensidigt krav. Leverantörer som förstår att deras egna kunder står under regulatorisk granskning är ofta mer samarbetsvilliga. Koppla gärna detta arbete till er strategi kring NIS2 och leverantörskedjan, eftersom kraven delvis överlappar.

DORA och NIS2 – skillnader, överlapp och ansvar

Många företag hanterar flera regulatoriska ramverk parallellt, och frågan uppstår naturligt: hur förhåller sig DORA till NIS2?

Svaret är att DORA fungerar som lex specialis gentemot NIS2 för finansiella entiteter. Det innebär att DORA, som mer specifik förordning, i regel går före NIS2 när det gäller IKT-risk och incidentrapportering för finanssektorn. Men i gränsfall, till exempel för enheter som både tillhandahåller finansiella tjänster och klassas som samhällsviktig tjänsteleverantör inom ett annat sektor, kan parallell tillämpning bli aktuell.

Viktiga skillnader mellan DORA och NIS2:

• Sektor: DORA gäller enbart finanssektorn; NIS2 gäller bredare samhällsviktiga sektorer.
• Tillsyn: DORA tillsynas primärt av Finansinspektionen; NIS2 av NCSC och sektorsspecifika myndigheter.
• Krav: DORAs IKT-riskhantering och incidentrapportering är mer detaljerade och specifika än NIS2.
• Tredjeparter: DORA reglerar IKT-tredjepartsleverantörer direkt; NIS2 riktar sig primärt mot de entiteter som är auktoriserade.

När kan DORA och NIS2 överlappa?

• Ett betalningsinstitut som också driver kritisk infrastruktur inom energiförsörjning
• En bank som tillhandahåller digitala identitetstjänster med samhällsvikt
• En försäkringsgrupp med dotterbolag i reglerade sektorer utanför finans

För att undvika regulatorisk förvirring bör styrelsen fastslå en tydlig ansvarskarta: vilka delar av verksamheten lyder under DORA, vilka under NIS2, och var behövs samordning. Dokumentera detta formellt och uppdatera det vid organisationsförändringar.

Statistik som sätter frågan i perspektiv: Finansinspektionen analyserar löpande dussintals finansiella entiteter för DORAs tillämpning, och arbetet med tillsyn intensifieras under 2025 och 2026. Det är inte en fråga om “om” ni granskas, utan “när.”

Att arbeta strukturerat med NIS2-efterlevnad parallellt med DORA ger dessutom stordriftsfördelar: gemensamma riskbedömningsprocesser, delade incidenthanteringsrutiner och en samlad bild av er organisations sårbarhetsprofil.

Vår erfarenhet: DORA-efterlevnad handlar om ledarskap och pragmatism

Det finns en frestelse att behandla DORA som ett dokumentationsprojekt. Producera ett IKT-riskramverk, uppdatera några avtal, bocka av checklistorna. Det fungerar inte i praktiken, och FI kommer att se igenom det.

Den viktigaste insikten vi har är att DORA-efterlevnad hänger på ledarskapskvalitet. Styrelseansvar för IKT-riskramverket är inte symboliskt, det är juridiskt. Styrelseledamöter som inte kan redogöra för organisationens digitala riskhantering är exponerade för personligt ansvar.

Varningen vi ger är mot överimplementering. Många organisationer lägger tid och resurser på avancerade tekniklösningar för icke-kritiska system, medan kärnan, tredjepartsregistret, avtalsdokumentation och incidentrutiner, saknar substans. Prioritera rätt.

Den rekommenderade approachen är fasvis: börja med GAP-analys och styrelseförankring, fortsätt med tredjepartsregister och avtalsöversyn, och bygg sedan ut resiliensprovning och informationsutbyte. DORA-resiliens skapas inte på en månad, men en strukturerad tre till sex månaders plan ger er en solid grund.

Fasvis implementering och proaktiv leverantörsdialog är de faktorer som skiljer framgångsrika implementationer från de som hamnar i regleringsbyråkratins fälla. Integrera DORA med er befintliga riskhantering, det är varken ett IT-projekt eller ett juridikprojekt. Det är ett organisationsprojekt med styrelsemandat.

Efterlevnad och digital resiliens – ta nästa steg med TrustView

Att förstå DORA är ett steg. Att operationalisera kraven är ett annat. TrustView ger er en strukturerad plattform för att samla riskbedömningar, tredjepartsregister, incidenthantering och avtalsöversikt på ett ställe, med tydliga arbetsflöden och ansvariga roller. Istället för att hantera DORA i separata kalkylark och e-posttrådar kan ni skapa en sammanhållen och spårbar efterlevnadsprocess.

Oavsett om ni precis påbörjat arbetet eller behöver strukturera upp en befintlig process, kan TrustView hjälpa er att bygga en åtgärdsplan för compliance som är anpassad till er organisations storlek och riskprofil. Läs mer om varför TrustView är rätt val för er, och utforska våra DORA-tjänster och utbildning för att komma igång direkt.

Vanliga frågor om DORA

När gäller DORA för vårt företag?

DORA gäller finansiella entiteter i Sverige under Finansinspektionens tillsyn, samt kritiska IKT-tredjepartsleverantörer som levererar tjänster till dessa, och tillämpas direkt sedan januari 2025.

Hur snabbt måste allvarliga incidenter rapporteras?

Allvarliga incidenter rapporteras till FI via FIDAC med initial notifikation inom 4 timmar, intermediär rapport inom 72 timmar och slutrapport inom en månad från att incidenten klassades.

Vad innebär sanktioner vid DORA-överträdelser?

Sanktioner kan uppgå till 10 miljoner euro eller 2% av global omsättning, och ledningen kan hållas personligt ansvarig med böter upp till 1 miljon euro.

Hur kan vi effektivt hantera tredjepartsrisk enligt DORA?

Skapa ett fullständigt tredjepartsregister över IKT-leverantörer, genomför regelbundna riskbedömningar och säkerställ att era avtal innehåller de obligatoriska DORA-klausulerna om revision, tillgänglighet och exitstrategi.

Kan DORA och NIS2 gälla samtidigt för vårt företag?

DORA är lex specialis och prioriteras för finansiella entiteter, men parallell tillämpning med NIS2 kan förekomma för entiteter som verkar i flera reglerade sektorer eller klassas som samhällsviktig infrastruktur på flera grunder.

Rekommendation

• Digital motståndskraft med DORA förordningen | TrustView
• För dig som är ansvarig eller VD – TrustView
• Slovenska DPA:s ingripanden: Viktiga lärdomar för efterlevnad av anställdas övervakning och hantering av juridiska risker – TrustView
• För dig som är jurist – TrustView