Hoppa till innehåll
Cybersäkerhet & NIS2DORAFintechICT-risk12 min läsning

DORA för fintech: Operativ resiliens, ICT-risk och tredjepartshantering

DORA gör operativ motståndskraft till ett lagkrav för finansiella aktörer. Här är de fem pelarna och vad de innebär.

28 januari 2026Uppdaterad 10:00
00
DORA för fintech: Operativ resiliens, ICT-risk och tredjepartshantering
DORA bygger på fem pelare för digital operativ resiliens.Photo: Unsplash

Vad DORA innebär för fintech-bolag. Guide till ICT-risk och tredjepartsavtal.

DORA, Digital Operational Resilience Act, gäller sedan januari 2025 och flyttar fokus från om ett finansiellt bolag kan bli drabbat till hur snabbt det reser sig när det väl händer. För fintech-bolag är det här inte ett valfritt mognadssteg utan ett bindande EU-regelverk, och det träffar både de finansiella aktörerna själva och deras kritiska IT-leverantörer. Den här guiden går igenom de fem pelarna och var de blir konkreta.

Jag arbetar med operativ resiliens och ICT-risk inom cybersäkerhet och compliance, och min erfarenhet är att de flesta bolag redan gör delar av det DORA kräver, men osystematiskt och odokumenterat, vilket är just det DORA inte accepterar. Skillnaden mot tidigare är att resiliens inte längre är något ni gör för att det är klokt, utan något ni måste kunna visa att ni gör, på ett strukturerat och granskningsbart sätt. Det är ett skifte från ambition till bevisbörda.

Vad DORA vill åstadkomma

Bakgrunden till DORA är enkel att förstå. Finanssektorn har blivit djupt beroende av digital infrastruktur, och ett driftavbrott eller ett intrång hos en central aktör eller leverantör kan få spridningseffekter genom hela systemet. Tidigare reglerades cyber- och IT-risk fragmenterat, olika i olika länder och sektorer. DORA harmoniserar detta till ett gemensamt regelverk för hela EU, så att kraven på operativ motståndskraft blir desamma oavsett var i unionen en aktör verkar. För ett fintech-bolag med kunder i flera länder är den harmoniseringen faktiskt en fördel: en standard att förhålla sig till istället för många.

Pelare 1: ICT-riskhantering

Grunden är ett sammanhängande ramverk för att identifiera, skydda mot, upptäcka, hantera och återhämta sig från IT-relaterade risker. Det ska vara förankrat hos ledningen, inte delegerat helt till IT. I praktiken betyder det en dokumenterad riskprocess, klassificering av era system efter kritikalitet, och en tydlig ansvarsfördelning. Det här hänger tätt ihop med en fungerande incidentberedskap, som jag beskriver närmare i incident response-planen.

Pelare 2: Incidentrapportering

DORA inför harmoniserade krav på att klassificera och rapportera allvarliga ICT-incidenter till tillsynsmyndigheten inom bestämda tidsramar. Det förutsätter att ni på förhand vet hur ni bedömer allvarlighetsgrad, vem som beslutar om rapportering och vilka uppgifter som ska med. En incident är fel tillfälle att börja klura ut rapporteringsvägen.

Pelare 3: Test av digital motståndskraft

Bolag ska regelbundet testa sin motståndskraft, från sårbarhetsskanningar till mer avancerade övningar. För de största aktörerna tillkommer hotbildsbaserad penetrationstestning (TLPT). För de flesta fintech-bolag handlar det i praktiken om återkommande tester och att faktiskt åtgärda det som hittas, inte att producera en rapport som läggs i en pärm. Poängen med testkravet är att verifiera att den motståndskraft ni tror er ha faktiskt finns. Det är skillnad på att ha en backup och att ha bevisat att den går att återställa, och skillnad på att ha en incidentplan och att ha övat den under realistiska förhållanden. Testning är mekanismen som omvandlar antaganden till fakta, och det är just antaganden som brukar svika i en skarp situation.

Pelare 4: Hantering av tredjepartsrisk

Det här är ofta den tyngsta pelaren för fintech, eftersom så mycket bygger på molnleverantörer och externa tjänster. DORA kräver att ni för ett register över era ICT-tredjepartsleverantörer, ställer specifika krav i avtalen (exit-strategier, revisionsrätt, säkerhetsåtaganden) och bedömer koncentrationsrisk, att vara helt beroende av en enda leverantör är i sig en risk DORA vill att ni hanterar.

Här gör jag mid-vägs alltid en leverantörskartläggning: vilka tredjeparter är kritiska, vad säger avtalen idag, och var saknas exit-villkor. Den kartan är ofta en ögonöppnare. Vill ni ha den gjord ingår det i cybersäkerhetsuppdraget.

Pelare 5: Informationsdelning

Den femte pelaren uppmuntrar finansiella aktörer att frivilligt dela information om cyberhot och sårbarheter med varandra. Det är den minst betungande delen, men värd att nämna eftersom den speglar DORA:s grundtanke: resiliens byggs gemensamt i sektorn, inte enbart bakom varje bolags egen brandvägg.

Proportionalitet: kraven skalar med er storlek

En viktig nyans som lugnar många mindre fintech-bolag är att DORA bygger på proportionalitet. Kraven ska tillämpas i förhållande till verksamhetens storlek, komplexitet och riskprofil. Det betyder att ett litet betalbolag inte förväntas ha samma tunga apparat som en stor bank. De mest avancerade kraven, som hotbildsbaserad penetrationstestning, riktar sig främst mot de större och mer systemkritiska aktörerna. För ett mindre bolag handlar det om att göra det väsentliga väl: ett begripligt riskramverk, ordning på leverantörerna, en fungerande incidentprocess och regelbundna tester i rimlig omfattning. Proportionalitet är dock inte en ursäkt för att låta bli, det är en kalibrering av ambitionsnivån, inte en befrielse.

Var jag brukar börja

Börja med en gap-analys mot de fem pelarna och en kartläggning av era kritiska IT-leverantörer. För nästan alla fintech-bolag är tredjepartshanteringen den största luckan, både för att avtalen sällan innehåller de villkor DORA kräver och för att koncentrationsrisken sällan är analyserad. När den bilden finns kan resten prioriteras efter verklig risk. Jag brukar börja med att skilja på vad som är en formaliseringsfråga, saker ni redan gör men inte dokumenterat, och vad som är en verklig lucka som kräver nytt arbete. Den uppdelningen gör att DORA-arbetet sällan blir så stort som det först känns, och att resurserna går dit de behövs. Se hur jag lägger upp liknande arbete i kundcase.

Relaterat

Vill du ta det vidare?

Jag hjälper fintech-bolag att nå DORA-efterlevnad med fokus på det som faktiskt minskar risk: ICT-riskhantering och ordning på leverantörskedjan. Boka ett samtal så går vi igenom var ni står mot de fem pelarna.

DORA flyttar frågan från om ni drabbas till hur snabbt ni reser er. För fintech är tredjepartshanteringen nästan alltid den största luckan.

- Simon Axelsson

Vanliga frågor

Gäller DORA bara stora banker?
Nej. DORA omfattar ett brett spektrum av finansiella aktörer, inklusive många fintech-bolag, betaltjänster och kryptotjänsteleverantörer. Dessutom träffar regelverket kritiska IT-leverantörer till sektorn. Vissa krav, som hotbildsbaserad penetrationstestning, är dock främst riktade mot de största aktörerna.
Vad är skillnaden mellan DORA och NIS2?
NIS2 är ett bredare direktiv för cybersäkerhet i många sektorer, medan DORA är en förordning specifikt för finanssektorns operativa resiliens. För finansiella aktörer är DORA i regel det styrande regelverket, eftersom det är mer detaljerat för deras verksamhet.
Vad behöver vi göra med våra molnleverantörer?
Föra register över ICT-tredjepartsleverantörer, säkra att avtalen innehåller bland annat revisionsrätt och exit-villkor, samt analysera koncentrationsrisk. Är ni helt beroende av en enda leverantör är det en risk DORA vill att ni aktivt hanterar.

Om författaren

Simon Axelsson
Simon AxelssonIT-konsult & teknisk rådgivare

Simon Axelsson är senior IT-konsult och grundare av SIAX Technology AB. Han hjälper nordiska företag med molninfrastruktur, dataplattformar och AI-automation.

Fler artiklar av Simon