Vad är DORA?
Digital Operational Resilience Act är en EU-förordning som reglerar finanssektorns motståndskraft mot ICT-relaterade händelser. Förordningen är direktverkande i alla medlemsstater och behöver inte införlivas i svensk lag för att gälla. Regelverket bygger på fem pelare: ICT-riskhantering (Art. 5 till 15), ICT-incidenthantering (Art. 17 till 23), digital operational resilience testing (Art. 24 till 27), hantering av ICT-tredjepartsrisk (Art. 28 till 30), och informationsdelning plus oversight framework (Art. 32 till 44).
DORA gäller sedan 17 januari 2025 och har fasats in utan övergångsperiod. Till skillnad från NIS2 som beror på svensk implementationslag (Cybersäkerhetslagen, SFS 2025:1506) för att bli bindande, är DORA direktverkande och finansiella entiteter omfattas oavsett svensk lag.
Vem omfattas av DORA?
DORA listar cirka 20 typer av finansiella entiteter i Art. 2. I svensk kontext är de mest relevanta grupperna:
- Kreditinstitut, inklusive alla svenska banker under Finansinspektionens tillsyn.
- Försäkringsbolag under Solvens II, både sak och liv.
- Betaltjänstleverantörer och institut för elektroniska pengar.
- Värdepappersbolag och fondbolag (UCITS, AIF).
- Centrala motparter, centrala värdepappersförvarare och handelsplatser.
- Leverantörer av kryptotillgångstjänster (CASPs under MiCA).
- Kritiska ICT-tredjepartsleverantörer som pekas ut av europeiska tillsynsmyndigheterna (ESMA, EIOPA, EBA).
Nyckelbegrepp i DORA
| Begrepp | Innebörd |
|---|---|
| Finansiell entitet | Reglerad marknadsaktör som omfattas av DORA enligt Art. 2, exempelvis en bank eller försäkringsbolag |
| ICT-tjänst | Digital tjänst eller datatjänst som levereras löpande genom ICT-system till en eller flera användare (Art. 3(21)) |
| ICT-tredjepartsleverantör | Leverantör som tillhandahåller ICT-tjänster till finansiella entiteter |
| Kritisk ICT-tredjepartsleverantör | Leverantör som pekas ut av ESA enligt Art. 31, föremål för direkt EU-tillsyn |
| Major ICT-related incident | Incident som klassificeras som allvarlig enligt kriterier i RTS (Commission Delegated Regulation 2024/1772) |
| TLPT | Threat-Led Penetration Testing, ett tillgänglighetsfokuserat och hotbaserat penetrationstest som krävs för vissa systemviktiga entiteter |
| Incident reporting template | Harmoniserad rapporteringsmall enligt ITS (Commission Implementing Regulation) |
De fem pelarna i DORA
DORA:s struktur är pedagogiskt upplagd i fem sammanhängande delar. Alla fem kräver samordnad efterlevnad.
- Pelare 1: ICT-riskhantering (Art. 5 till 15). Ramverk, governance, identifiering, skydd, detektion, återhämtning, utbildning.
- Pelare 2: ICT-incidenthantering (Art. 17 till 23). Klassificering, rapportering, eskalering, erfarenhetsåterföring.
- Pelare 3: Digital operational resilience testing (Art. 24 till 27). Test-program, sårbarhets-scanning, red teaming, TLPT vart tredje år för systemviktiga.
- Pelare 4: Hantering av ICT-tredjepartsrisk (Art. 28 till 30). Register, kontraktsklausuler, koncentrationsbedömning, exit-strategi, oversight av kritiska leverantörer.
- Pelare 5: Informationsdelning och oversight (Art. 32 till 44). Frivillig hotinformationsdelning, direkt EU-tillsyn över kritiska ICT-leverantörer.
DORA i relation till NIS2, Cybersäkerhetslagen och AI Act
DORA är lex specialis för finanssektorn. Där DORA överlappar med NIS2 går DORA före enligt Art. 1(2) i NIS2-direktivet. Ett svenskt kreditinstitut som formellt är NIS2-omfattat via Cybersäkerhetslagen ska i första hand dokumentera ICT-riskhantering, incidentrapportering och leverantörshantering enligt DORA. NIS2-specifika krav som styrelsens personliga ansvar (Art. 20) finns dock inte i DORA och behöver därför ändå dokumenteras.
För AI Act är situationen annorlunda. AI Act är ett tematiskt regelverk som reglerar AI-systemens egenskaper. Ett svenskt finansbolag som använder AI i kreditbedömning (Bilaga III.5b) eller livförsäkringsbedömning omfattas av både DORA och AI Act samtidigt. Se även [AI Act vs DORA](/vs/dora-ai-act) för en fullständig jämförelse.
Tillsyn i Sverige: Finansinspektionens roll
Finansinspektionen är behörig myndighet för DORA för alla svenska finansiella entiteter. FI ansvarar för tolkning av DORA, tematiska granskningar, granskning av incidentrapporter och beslut om administrativa åtgärder. FI publicerade första versionen av sin DORA-vägledning under Q1 2025 och har under Q2 2026 genomfört tematiska tillsyner mot svenska storbanker och två större försäkringsbolag.
Kritiska ICT-tredjepartsleverantörer står under direkt EU-tillsyn via ESA, där EBA är lead overseer för de största molnleverantörerna. Finansinspektionen deltar i oversight forum och har nationell koordination med Riksbanken för systemvikt.
Sanktioner under DORA
Sanktioner beslutas enligt svensk lag med stöd av DORA Art. 50 och Art. 51. Finansinspektionen kan besluta om administrativa sanktionsavgifter.
| Överträdelse | Sanktion |
|---|---|
| Allvarliga brott mot ICT-riskhantering eller incidentrapportering | Administrativa sanktionsavgifter, storlek enligt svensk lag (Lagen om vissa finansiella företags och tjänsters samarbete med tillsynsmyndigheter) |
| Kritiska ICT-leverantörer som inte följer ESA:s rekommendationer | Upp till 1 procent av genomsnittlig daglig global omsättning per dag, max sex månader (Art. 35) |
| Brott mot specifika kontraktsklausuler med finansiella entiteter | Åtgärder från FI mot den finansiella entiteten, inte direkt mot leverantören |
Vad gör jag nu? Sex steg för svenska finansbolag
Planen nedan fungerar för ett svenskt finansbolag med 200 till 2 000 anställda. För mikroentiteter räcker ett enklare ramverk, för systemviktiga storbanker krävs djupare bemanning.
- Gap-analys mot Art. 5 till 44. Kartlägg nuvarande ICT-riskramverk och jämför mot DORA-kraven. Notera FI:s vägledning från Q1 2025.
- Etablera governance. Styrelsen godkänner ICT-riskstrategi. Tydlig ansvarsfördelning mellan CISO, CIO, CRO och affär.
- Bygg register över ICT-tredjepartsleverantörer. Registret är grunden för Art. 28 och ska vara maskinläsbart i rapporteringsformatet som ESA definierar.
- Etablera incidentklassificering. Implementera RTS-kriterierna för major ICT-related incident och bygg automatisk eskaleringskedja.
- Bygg och validera testprogram. Årlig sårbarhets-scan, vart tredje år avancerade tester. För systemviktiga entiteter: TLPT vart tredje år.
- Koordinera med NIS2, AI Act och GDPR. En trippel- eller kvadruppel-stack kräver samordnade dokumentationsflöden och incidentrapportering.
Exempel från svenska finansbolag
En svensk storbank med cirka 12 000 anställda har fullt separerat DORA-program på plats sedan H2 2024, med 14 heltidsekvivalenter i en programstab och delar av CIO-organisationen allokerad mot DORA-uppgifter. Banken rapporterade sju major ICT-related incidents till FI under 2025.
Ett svenskt försäkringsbolag i mellansegmentet med cirka 450 anställda gjorde gap-analys Q4 2024, implementerade ICT-riskramverket under H1 2025 och genomförde första tematiska granskningen av FI under Q1 2026. De rapporterade inga major-incidents 2025 men två betydande near-misses.
En svensk betaltjänstleverantör med cirka 120 anställda utgick från befintligt ISO 27001-ramverk och byggde DORA som påbyggnadsmodul. Största lyftet var leverantörsregister och kontraktsomförhandling.
Vanliga missuppfattningar om DORA
DORA är bara för storbankerna. Fel. DORA gäller alla finansiella entiteter i Art. 2, inklusive små betaltjänstleverantörer och fondbolag. Proportionalitet lättar kraven men tar inte bort dem.
Om vi är NIS2-omfattade har vi redan allt. Delvis fel. DORA har lex specialis-status för finans, men vissa NIS2-krav överlappar inte alls (styrelsens personliga ansvar, Art. 20 NIS2). Båda behöver dokumenteras.
Vi använder AWS/Azure så vi är skyddade. Fel logik. Finansbolaget har fortsatt fullt ansvar. Leverantören kan bli kritisk ICT-tredjepartsleverantör och få direkt tillsyn, men det avlastar inte det beställande bolaget.
DORA har en övergångsperiod. Fel. DORA gäller sedan 17 januari 2025 utan övergångsperiod. RTS och ITS har publicerats gradvis, men kärnkraven började gälla direkt.