Finansiella entiteter styrs primärt av DORA eftersom regelverket fungerar som lex specialis gentemot NIS2 på de områden där de överlappar. Organisationer utanför finanssektorn faller istället under NIS2, som Sverige implementerar via nationell lagstiftning. Första steget är att kartlägga era juridiska enheter, bygga kontrollbasen mot DORA där den gäller och sedan fylla i de NIS2-krav som återstår, inklusive automatiserade larm för DORA:s fyrtimmarsgräns för incidentrapportering.
Kort sagt:
- Organisationer inom finanssektorn måste bygga en kontrollbas enligt DORA, medan andra företag endast behöver följa NIS2 om de omfattas av EU-direktivet.
- DORA kräver ett dokumenterat ICT-riskramverk, automatiserad incidentklassificering inom fyra timmar och regelbundna threat-led penetration tester var tredje år.
- NIS2:s krav på riskanalys, leverantörssäkerhet och incidentrapportering går ofta att hantera inom ramen för DORA, men kvarstår för icke-finansiella dotterbolag och fysisk säkerhet.
- Det är mest effektivt att starta med en juridisk kartläggning av enheterna, bygga kontrollbasen för DORA och sedan göra en separat gap-analys för NIS2.
- Under tiden bör organisationer automatisera incidentdetektion och testa sin klassificeringsprocess för att möta DORA:s snäva fyratimmarsgräns.
Innehållsförteckning
- Vad är NIS2? Rättslig form, målgrupp och huvudkrav
- Vad är DORA? Rättslig form, målgrupp och centrala skyldigheter
- Hur förhåller sig DORA och NIS2 till varandra? Lex specialis och överlapp
- Vilka tidsfrister gäller för incidentrapportering och testning?
- Hur hanterar ni tredjepartsleverantörer under båda regelverken?
- Vad måste styrelsen visa för att undvika sanktioner?
- Evertrusts perspektiv: konkreta nästa steg
- Varför de flesta organisationer löser detta i fel ordning
- Så kan Evertrust hjälpa er genom regelverken
- Källor
- Vanliga frågor
Vad är NIS2? Rättslig form, målgrupp och huvudkrav
NIS2 är ett EU-direktiv, vilket betyder att det inte gäller direkt utan måste omvandlas till nationell lag i varje medlemsstat. Det skapar en viss variation i hur reglerna tillämpas mellan länder, till skillnad från en förordning som gäller ordagrant överallt samtidigt. Direktiv (EU) 2022/2555 omfattar 18 sektorer, från energi och transport till hälso- och sjukvård, digital infrastruktur och offentlig förvaltning.
Tröskelvärdena avgör om en organisation räknas som väsentlig eller viktig entitet. För de flesta kategorier gäller vissa tröskelvärden för antal anställda eller årsomsättning. Ligger organisationen under den gränsen faller den oftast utanför, om inte sektorn har särskilda undantagsregler.
De huvudsakliga kraven i NIS2 handlar om:
- Ledningens ansvar för att godkänna och följa upp riskhanteringsåtgärder, med personligt ansvar vid brister.
- Obligatorisk riskanalys av nätverks- och informationssystem, inklusive fysisk säkerhet.
- Krav på leverantörssäkerhet genom hela leveranskedjan, inte bara de direkta ICT-leverantörerna.
- Incidentrapportering till nationell CSIRT-funktion eller behörig myndighet, i Sverige samordnat via MSB.
En leverantör till en väsentlig entitet kan indirekt dras in i kraven även om leverantören själv inte klassas som väsentlig eller viktig. Ett molnföretag som levererar drift till ett sjukhus möter till exempel avtalskrav som i praktiken tvingar fram samma säkerhetsnivå som om företaget själv omfattades direkt. Sveriges försenade implementering har redan lett till att EU-kommissionen inlett ett överträdelseförfarande mot Sverige, vilket gör det extra viktigt att följa hur den nationella lagstiftningen till slut landar.
Vad är DORA? Rättslig form, målgrupp och centrala skyldigheter
DORA är en förordning, inte ett direktiv, och det är den enskilt viktigaste skillnaden mellan de två regelverken. Förordning (EU) 2022/2554 gäller ordagrant i alla medlemsstater sedan den 17 januari 2025, utan mellansteg av nationell lagstiftning. Det omfattar banker, försäkringsbolag, värdepappersföretag, betalningsinstitut och en rad andra finansiella aktörer, samt vissa kritiska ICT-leverantörer som pekas ut särskilt av tillsynsmyndigheterna.
Kraven är betydligt mer detaljerade än i NIS2. Centrala skyldigheter:
- Ett dokumenterat ICT-riskramverk som styrelsen formellt måste godkänna och regelbundet se över.
- Kontinuerlig övervakning av system, med tydliga eskaleringsvägar vid avvikelser.
- Threat-led penetration testing (TLPT) minst vart tredje år för entiteter som klassificeras som betydelsefulla, enligt kraven som beskrivs på EIOPA:s sida om DORA.
- Detaljerade avtalskrav mot ICT-tredjepartsleverantörer, inklusive exitstrategier och revisionsrätt.
- Ett fullständigt register över alla ICT-kontrakt, uppdaterat och rapporterbart till tillsynsmyndigheten.
I Sverige är Finansinspektionen tillsynsmyndighet för DORA inom finanssektorn, medan de europeiska tillsynsmyndigheterna, däribland EIOPA och ESMA, tar hand om kritiska ICT-leverantörer på EU-nivå. Vill du gå djupare in i de operativa kraven finns en genomgång i Evertrusts artikel om DORA-krav.
Hur förhåller sig DORA och NIS2 till varandra? Lex specialis och överlapp
Skillnaden i rättslig form spiller över i hur de två regelverken samspelar. DORA som förordning gäller direkt och specifikt för finanssektorn, medan NIS2 som direktiv är bredare men mindre detaljerat. När båda regelverken skulle kunna tillämpas på samma organisation gäller principen lex specialis: den mer specifika lagen, DORA, tar företräde framför den mer generella, NIS2.
Det betyder i praktiken att en bank eller ett försäkringsbolag inte ska bygga två parallella kontrollsystem. Branschanalys från ISACA konstaterar att DORA redan är mer preskriptivt än NIS2 på just de områden där de överlappar, vilket gör NIS2:s krav på riskhantering, incidentrapportering och tredjepartsreglering i stort sett redundanta för finansiella entiteter som redan följer DORA fullt ut.
Men lex specialis är inte en frikort från NIS2 rakt igenom. Residualområden kvarstår, särskilt kring:
- Fysisk säkerhet för anläggningar som inte är rent finansiella (kontor, datacenter som delas med andra verksamhetsgrenar).
- Bredare leveranskedjekrav som sträcker sig bortom rena ICT-tjänster, till exempel fastighetsförvaltning eller fysisk logistik.
- Icke-finansiella dotterbolag inom samma koncern som inte omfattas av DORA:s definition av finansiell entitet.
En praktisk tumregel, som också beskrivs i jämförande analyser av DORA och NIS2, är att bygga hela kontrollbasen utifrån DORA:s krav för de enheter som omfattas, och därefter göra en separat gap-analys mot NIS2 för att fånga upp det som blir kvar. Det sparar tid jämfört med att försöka harmonisera två regelverk från grunden samtidigt.
Vilka tidsfrister gäller för incidentrapportering och testning?
De två regelverkens tidslinjer för incidentrapportering liknar varandra på ytan men skiljer sig i detalj, och den skillnaden får verkliga konsekvenser för hur ni bygger era detekteringsflöden.
- DORA: initial notis inom 4 timmar efter att en incident klassificerats som “major”, en mellanrapport inom 72 timmar och en slutrapport inom en månad.
- NIS2: en tidig varning inom 24 timmar, en fullständig anmälan inom 72 timmar och en slutrapport inom en månad.
Fyratimmarsgränsen i DORA är den skarpaste skillnaden och ställer krav på att incidentklassificeringen sker i det närmaste automatiskt. Manuella eskaleringsrutiner som fungerar för NIS2:s 24-timmarsfönster räcker sällan för DORA. Organisationer som omfattas av båda bör bygga sina SIEM- och SOAR-flöden så att klassificering och första larm triggas automatiskt, med tydligt ägarskap för vem som fattar det formella beslutet att en incident är “major”.
Proffstips: Testa er egen incidentklassificeringsprocess med en simulerad “major”-händelse och ta tid på hur lång tid det faktiskt tar från upptäckt till formellt beslut. De flesta organisationer upptäcker då att beslutsvägen, inte tekniken, är flaskhalsen.
Testkraven skiljer sig också åt. DORA specificerar TLPT i detalj, med krav på oberoende testare och återkommande cykler vart tredje år för de enheter som pekas ut. NIS2 kräver att organisationer bedömer effektiviteten i sina säkerhetsåtgärder, men utan att ange en lika strikt testmetodik. Det gör TLPT till ett rent DORA-krav som inte automatiskt uppfylls genom generella penetrationstester gjorda för NIS2-syften.
Hur hanterar ni tredjepartsleverantörer under båda regelverken?
Leverantörshantering är ett av de områden där kraven verkligen skiljer sig i detaljnivå. DORA kräver ett fullständigt register över alla ICT-tredjepartsavtal, med obligatoriska avtalsklausuler kring exitstrategier, revisionsrätt och rapporteringsskyldighet från leverantören vid incidenter. NIS2 ställer krav på säkerhet i hela leveranskedjan i en bredare mening, utan samma detaljerade avtalsmall.
Praktiskt innebär det att avtal bör harmoniseras så att de DORA-specifika klausulerna införs överallt där DORA gäller, medan bredare leveranskedjesäkerhet enligt NIS2 täcks separat för leverantörer utanför den finansiella kärnverksamheten. Fyra konkreta steg:
- Kartlägg samtliga leverantörer och klassificera vilka som stödjer kritiska eller viktiga funktioner.
- Uppdatera avtal med de leverantörer som faller under DORA med exitstrategier och revisionsrätt.
- Bygg ett register som håller kontraktsdata uppdaterat och rapporterbart till Finansinspektionen.
- Inför löpande övervakning av leverantörernas säkerhetsstatus, inte bara en engångsgranskning vid avtalstecknandet.
En molnleverantör kan hamna i korselden mellan regelverken: samma leverantör kan vara bunden av DORA-klausuler i ett avtal med en bank och samtidigt omfattas av NIS2 som leverantör av kritisk digital infrastruktur, vilket analyser av samspelet mellan regelverken pekar på som en växande komplexitet för leverantörer med flera kundsegment.
Vad måste styrelsen visa för att undvika sanktioner?
Ledningens ansvar är formellt inskrivet i båda regelverken, men DORA går längre genom att kräva att styrelsen aktivt godkänner och dokumenterar hela ICT-riskramverket, inte bara sätter en generell policy.
Sanktionerna varierar mellan nationell nivå, via tillsynsmyndigheter som Finansinspektionen och MSB, och EU-nivå för kritiska ICT-leverantörer som granskas direkt av de europeiska tillsynsmyndigheterna. Styrelsen bör kunna visa:
- Ett protokollfört beslut om godkännande av ICT-riskramverket, med datum för senaste översyn.
- En tydlig beviskedja från riskanalys till konkreta åtgärder och uppföljning.
- Regelbunden rapportering till styrelsen om incidenter, testresultat och leverantörsrisker.
Utan den beviskedjan blir det svårt att visa efterlevnad även om de tekniska kontrollerna faktiskt finns på plats.
Evertrusts perspektiv: konkreta nästa steg
Erfarenhet från GDPR- och informationssäkerhetsuppdrag visar att organisationer som lyckas bäst börjar med en juridisk-enhetskartläggning innan de rör vid en enda kontroll. Fyra steg i ordning: kartlägg juridiska enheter och vilket regelverk som gäller var, bygg kontrollbasen mot DORA där den är tillämplig, fyll NIS2-gapen separat, och lägg sedan en konkret plan för TLPT och leverantörsregister.
Varför de flesta organisationer löser detta i fel ordning
Den vanligaste missuppfattningen jag ser är att organisationer försöker bygga en enda gemensam compliance-modell för DORA och NIS2 samtidigt, som om regelverken vore utbytbara. Det är bakvänt. DORA:s detaljnivå gör att en kontrollbas byggd för NIS2 sällan täcker DORA:s krav, medan en kontrollbas byggd för DORA nästan alltid täcker det mesta av NIS2 automatiskt, tack vare lex specialis.
Det som verkligen underskattas är hur mycket av arbetet som handlar om juridisk kartläggning snarare än teknik. Många säkerhetsansvariga hoppar rakt in i verktyg och processer innan de ens har klargjort vilka juridiska enheter i koncernen som faller under vilket regelverk. Det leder till dubbelarbete och luckor som upptäcks först vid en revision.
Prioritera juridisk-enhetskartläggningen före allt annat. Bygg sedan DORA-kontrollerna där de gäller, och betrakta NIS2 som ett gap-analysarbete snarare än ett parallellt projekt. Den ordningen sparar både tid och pengar.
— Jesper
Så kan Evertrust hjälpa er genom regelverken
Det finns rådgivande partners som kan hjälpa organisationer att reda ut exakt vad DORA och NIS2 kräver av just deras juridiska struktur, och som genomför gap-analyser, DPIA, TLPT-planering och leverantörsregisterarbete, samt kan agera som interimsresurs när intern kapacitet inte räcker till under en implementeringsfas.
Det finns digitala plattformar som samlar regelefterlevnad för GDPR, ISO 27000, DORA, NIS2 och e-privacy på ett ställe, vilket gör det enklare att hålla koll på vilket krav som gäller för vilken enhet. Läs mer om vad DORA konkret innebär för er verksamhet på Evertrusts genomgång av DORA-kraven, eller se hur vi arbetar med hela vårt rådgivningsområde på sidan om vår expertis. Vill ni ha extern hjälp att reda ut ansvarsfrågor kring dataskyddsombud i samband med DORA- eller NIS2-arbetet, går det också bra att börja med vår genomgång av dataskyddsombud och intressekonflikter. Boka en workshop eller begär en offert för en gap-analys, så får ni en konkret plan för vilket regelverk som styr just er organisation.
Källor
Fördjupning finns i DORA-förordningen och NIS2-direktivet på EUR-Lex, samt Evertrusts genomgång av NIS2 2026.
- Regulation (EU) 2022/2554 (DORA) — EUR-Lex
- Digital Operational Resilience Act (DORA) — EIOPA
- Resilience and security in critical sectors: Navigating NIS2 and DORA requirements — ISACA (2025)
Vanliga frågor
Vad är skillnaden mellan NIS2 och DORA?
DORA är en EU-förordning som gäller direkt för finanssektorn, medan NIS2 är ett direktiv som kräver nationell implementering och omfattar 18 andra sektorer. Där de överlappar tar DORA företräde genom principen lex specialis.
Vilka är de centrala kraven i DORA?
DORA bygger på ett ICT-riskramverk, kontinuerlig övervakning, incidentrapportering, threat-led penetration testing (TLPT) och detaljerade krav på tredjepartsleverantörer, enligt förordningstexten.
Vilka organisationer måste följa DORA?
DORA omfattar banker, försäkringsbolag, värdepappersföretag, betalningsinstitut och andra finansiella entiteter i EU, samt vissa kritiska ICT-leverantörer som pekas ut av de europeiska tillsynsmyndigheterna.
Vad innebär EU:s DORA-förordning i praktiken?
DORA tvingar finansiella entiteter att bygga ett dokumenterat ramverk för digital operativ motståndskraft, med styrelsegodkännande, återkommande TLPT-tester och strikta krav på leverantörsavtal och register.
Behöver en organisation som redan följer DORA också uppfylla NIS2?
Ofta bara delvis. Residualkrav i NIS2 kan kvarstå för icke-finansiella dotterbolag, fysisk säkerhet och delar av leveranskedjan som ligger utanför DORA:s definition av ICT-tjänster. En gap-analys, till exempel den Evertrust erbjuder, visar exakt vilka luckor som återstår.
