NIS2 och DORA i praktiken: Så säkrar du leverantörskedjor och incidentrapportering

Vägen från regelbörda till robust verksamhetsskydd

NIS2 och DORA behöver inte hanteras som två separata regelprojekt som främst producerar dokumentation. Rätt tillämpade fungerar regelverken som en praktisk manual för att förstå verksamhetens kritiska beroenden, minska sårbarheter och agera snabbare när något går fel. I Sverige trädde cybersäkerhetslagen, som genomför NIS2, i kraft den 15 januari 2026. DORA började tillämpas inom finanssektorn den 17 januari 2025 och omfattar både finansiella entiteter och relevanta ICT-leverantörer. Digital Operational Resilience Act (DORA) kopplar därmed digital motståndskraft direkt till finansiell stabilitet och kontinuitet.

För ledningsgrupper är den centrala frågan inte hur många styrdokument som finns, utan om organisationen kan upptäcka, förstå och begränsa en störning innan den får affärsmässiga eller samhälleliga konsekvenser. Finns en aktuell bild av kritiska tjänster och leverantörer? Är ansvar och beslutsmandat tydliga under en incident? Kan en molnleverantör, driftpartner eller programvaruleverantör snabbt lämna relevant information? De organisationer som prioriterar systemhygien, fungerande reservrutiner och återkommande riskrevidering bygger ett skydd som fungerar även när förutsättningarna förändras.

Skärningspunkten mellan NIS2 och DORA

NIS2 är ett direktiv med bred räckvidd. Det omfattar samhällsviktiga och digitala sektorer som bland annat energi, vård, transport, vattenförsörjning och digital infrastruktur. I Sverige organiseras de berörda verksamheterna inom 18 sektorer och relaterade delsektorer. DORA är däremot en direkt tillämplig EU-förordning med fokus på finanssektorns digitala operativa motståndskraft. Banker, försäkringsföretag, investeringsföretag och andra finansiella entiteter ska kunna stå emot, hantera och återhämta sig från ICT-relaterade störningar. Kraven omfattar även centrala ICT-tredjepartsleverantörer.

Skillnaden i juridisk form och målgrupp får praktiska följder. NIS2 genomförs genom nationell lagstiftning och ställer krav på riskhantering, säkerhetsåtgärder, ledningsansvar, utbildning och incidentrapportering. DORA går djupare inom finanssektorn genom detaljerade krav på ICT-riskhantering, motståndskraftstester, rapportering och styrning av utkontrakterade tjänster. Gemensamt är däremot principerna om proportionalitet, dokumenterad riskbedömning, tydligt styrelse- och ledningsansvar samt kontinuerlig uppföljning. Efterlevnad är alltså inte en engångskontroll, utan en återkommande styrprocess.

Dubbelarbete uppstår när varje regelverk får en egen riskmodell, leverantörsdatabas, incidentprocess och utbildningsplan. En bättre modell är att etablera ett gemensamt kontrollramverk med separata tillägg där kraven skiljer sig. Samma register över kritiska system kan exempelvis användas som grund för både NIS2:s riskarbete och DORA:s register över ICT-avtal. Skillnader i rapporteringskanaler, tröskelvärden och myndighetsdialog måste däremot dokumenteras tydligt, så att en gemensam struktur inte leder till felaktig rapportering.

Kartläggning och kravställning i leverantörskedjan

Leverantörsrisk börjar inte med ett frågeformulär. Den börjar med en karta över verksamhetens viktigaste flöden. Identifiera vilka tjänster som krävs för att ta emot order, behandla betalningar, leverera vård, styra produktion, kommunicera med kunder eller uppfylla regulatoriska krav. Koppla sedan varje flöde till system, data, tekniska plattformar och externa leverantörer. På så sätt blir det möjligt att se skillnaden mellan en leverantör som är administrativt viktig och en leverantör vars avbrott omedelbart stoppar en kritisk funktion.

För finansiella entiteter kräver DORA bland annat en aktuell strategi för ICT-tredjepartsrisk, register över avtal och särskild styrning av tjänster som stödjer kritiska eller viktiga funktioner. Innan ett avtal ingås behöver organisationen bedöma tjänstens kritikalitet, leverantörens lämplighet, informationssäkerhetsnivå, tillsynsförhållanden, intressekonflikter och möjligheten att avsluta eller ersätta tjänsten. NIS2 kräver på motsvarande sätt att leverantörsrisker hanteras som en del av den övergripande cybersäkerheten, inte som en fråga som kan lämnas över till inköp.

Avtalen måste översätta säkerhetskraven till verifierbara åtaganden. Det bör framgå vilka incidenter som ska rapporteras, inom vilken tid och genom vilken kanal. Avtalet bör även reglera åtkomstloggar, sårbarhetshantering, patchning, underleverantörer, datalokalisering, revisionsrätt, säkerhetstester och stöd vid återställning. För kritiska tjänster behövs dessutom en realistisk exit- och övergångsplan. En klausul om att leverantören ska upprätthålla ”hög säkerhet” ger begränsad praktisk nytta om det inte går att kontrollera vad kravet innebär eller vilka åtgärder som gäller vid bristande prestation.

• Bedöm leverantören utifrån påverkan på kritiska affärsflöden, inte enbart inköpsvärde.
• Dokumentera beroenden till molnplattformar, underleverantörer, identitetstjänster och gemensamma tekniska komponenter.
• Kontrollera säkerhetsförmåga genom relevanta underlag, exempelvis revisioner, certifieringar, externa bedömningar och riktade intervjuer.
• Definiera mätbara SLA-krav för tillgänglighet, incidentkommunikation, återställning och sårbarhetsåtgärder.
• Testa exitstrategier och säkerställ att data, konfigurationer och kompetens kan flyttas vid ett allvarligt leverantörsproblem.
• Följ upp leverantörer löpande, särskilt efter större förändringar, nya underleverantörer eller bekräftade sårbarheter.

Prioriteringen bör vara dynamisk. En leverantör som bedömdes som låg risk för två år sedan kan ha blivit central efter en migrering till en ny plattform eller en förändrad affärsprocess. Riskbedömningen behöver därför kopplas till förändringshantering, inköp och arkitekturstyrning. Det är också viktigt att skilja mellan formell certifiering och faktisk förmåga. ISO 27001 eller motsvarande kontrollunderlag kan vara värdefullt, men ersätter inte en bedömning av den specifika tjänstens återställningstid, tekniska beroenden och koncentrationsrisk.

Att bygga en effektiv process för incidentrapportering

Incidentrapportering fungerar bara när den börjar internt långt innan en myndighetsrapport ska skickas. Under DORA används en rapporteringsmodell med initial anmälan, mellanrapport och slutrapport för allvarliga ICT-relaterade incidenter. Den initiala varningen ska i praktiken kunna lämnas inom 24 timmar från det att organisationen blivit medveten om en allvarlig incident, medan en fördjupad rapport ska följa inom 72 timmar enligt de relevanta rapporteringskraven och tillämpningsanvisningarna. Exakta trösklar, formulär och kanaler måste alltid kontrolleras mot aktuell sektorspecifik vägledning och behörig myndighet.

Under NIS2 ska incidenter som orsakar eller kan orsaka betydande störning hanteras och rapporteras enligt den nationella regleringen. För svenska organisationer innebär det att ansvarig tillsynsmyndighet och nationella kontaktvägar måste vara kända i förväg. DORA-rapporter till Finansinspektionen har hanterats genom Fidac, där rapporteringen är uppdelad i bland annat incidenter och cyberhot. Tekniska format kan utvecklas över tid, vilket gör det olämpligt att bygga processen kring en enda statisk mall. Technical guideline for Incident Reporting från ENISA kan användas som stöd för att skapa en konsekvent struktur för händelsebeskrivning, påverkan, åtgärder och uppföljning.

En snabb process kräver en tydlig eskaleringskedja. Säkerhetsövervakning och servicedesk behöver veta när en avvikelse ska föras vidare till incidentledare. Incidentledaren behöver kunna kalla in IT-drift, juridik, kommunikation, dataskydd, verksamhetsansvarig och leverantörsansvarig utan att invänta flera godkännanden. Ledningen ska få beslutsunderlag om påverkan, alternativ, risk för spridning och sannolik återställning, inte enbart tekniska loggar. Samtidigt måste rapporteringen bygga på verifierade fakta och tydligt skilja mellan vad som är känt, vad som är sannolikt och vad som ännu utreds.

1. Upptäck och registrera händelsen med tidpunkt, berörda system, första indikatorer och ansvarig incidentledare.
2. Gör en snabb klassificering utifrån påverkan på konfidentialitet, riktighet, tillgänglighet, säkerhet och kritiska affärsflöden.
3. Eskalerа till rätt funktioner och aktivera krisorganisationen när tröskeln för allvarlig incident nås.
4. Skicka en tidig rapport med tillgängliga fakta, även om utredningen fortfarande pågår.
5. Komplettera med teknisk analys, orsaker, konsekvenser, vidtagna åtgärder och kvarstående risker.
6. Avsluta med en slutrapport, lärdomsanalys och verifierade förbättringsåtgärder med ansvarig och förfallodatum.

Dokumentationen måste kunna fungera för flera mottagare samtidigt. Tillsynsmyndigheten behöver en begriplig redogörelse för händelseförlopp, påverkan och hantering. Ledningen behöver förstå affärsrisken och besluten. Den tekniska organisationen behöver tillräckligt detaljerade data för rotorsaksanalys och återställning. Därför bör mallar, tidsstämplar, rapporterings-ID:n, kontaktlistor och beslutspunkter vara förberedda och testade. Incidentövningar bör omfatta hela rapporteringskedjan, inklusive kontakten med leverantörer och myndigheter.

Kultur och operativ beredskap i hela organisationen

Cybersäkerhet blir affärskritisk när ledningen behandlar den som en del av verksamhetsstyrningen, inte som en isolerad IT-fråga. Styrelse och ledningsgrupp behöver förstå vilka tjänster som är mest kritiska, vilken återställningsförmåga som krävs och vilka risker som accepteras. Det innebär också att investeringar i identitetshantering, säkerhetskopiering, loggning, sårbarhetshantering och återställning ska kunna kopplas till konkret riskreduktion. Under cybersäkerhetslagen omfattar skyldigheterna bland annat systematiskt säkerhetsarbete, lämpliga skyddsåtgärder och utbildning av ledning och personal.

Regelbundna övningar är den snabbaste vägen från dokumenterad beredskap till faktisk handlingsförmåga. Ett scenario kan exempelvis börja med en komprometterad leverantör, fortsätta med otillgängliga system och sluta med krav på tidig myndighetsrapportering. Övningen bör inte bara testa teknik, utan även beslutsmandat, kommunikation, juridiska bedömningar och prioritering mellan verksamhetens olika delar. Efteråt ska varje identifierad brist få en ägare, en tidsplan och en kontrollpunkt. ENISA:s vägledning från 2025 om att koppla NIS2-krav till cybersäkerhetsroller och kompetenser kan användas för att tydliggöra ansvar för exempelvis CISO, incidenthanterare och juridik- och compliancefunktion.

• Utse en tydlig incidentledare och ersättare för varje kritiskt verksamhetsområde.
• Definiera vem som får besluta om isolering, driftstopp, återställning och extern kommunikation.
• Genomför scenariobaserade övningar minst återkommande och inkludera kritiska leverantörer där det är möjligt.
• Bygg kompetens genom korta, rollanpassade utbildningar för ledning, tekniker, inköp och verksamhetsägare.
• Följ upp mätetal som upptäcktstid, eskaleringstid, återställningstid, patchningsgrad och genomförda förbättringsåtgärder.

En mogen säkerhetskultur handlar inte om att undvika alla incidenter. Den handlar om att upptäcka avvikelser tidigt, begränsa skadan, kommunicera korrekt och återgå till kontrollerad drift. När ansvar, kompetens och teknik utvecklas tillsammans blir regelkraven en del av den dagliga styrningen. Det minskar risken för att organisationen först upptäcker sina svagheter under en verklig kris.

Stärk organisationens resiliens för morgondagens krav

Det som skapar faktisk motståndskraft är sällan ytterligare ett fristående policydokument. Störst effekt uppstår när kritiska tjänster är kartlagda, leverantörsberoenden är synliga, säkerhetskrav finns i avtalen och incidentprocessen är övad. NIS2 och DORA ger en gemensam riktning, men värdet uppstår först när kraven kopplas till arkitektur, inköp, drift, riskstyrning och ledningens beslut.

Börja med tre konkreta steg. Fastställ vilka verksamhetsflöden som inte får stanna, koppla dem till system och leverantörer och rangordna de största återställningsriskerna. Därefter bör incidentprocessen testas mot 24- och 72-timmarskraven, med tydliga interna eskaleringar och färdiga rapporteringsunderlag. Slutligen bör ledningen besluta om en prioriterad åtgärdsplan med finansiering, ansvar och uppföljning. Då blir efterlevnad inte en reaktiv kontrollpunkt, utan en naturlig del av hur organisationen skyddar intäkter, förtroende och kontinuitet.