DORA-programvara kan hjälpa ett svenskt finansföretag att hålla ihop risker, IKT-tjänster, avtal, incidenter och åtgärder. Värdet ligger i att informationen går att använda när ett system slutar fungera, en leverantör ändrar sin tjänst eller Finansinspektionen begär underlag. En etikett som säger att verktyget stöder DORA visar däremot inte vilka skyldigheter det faktiskt hjälper företaget att uppfylla.
DORA-förordningen, EU 2022/2554, tillämpas sedan den 17 januari 2025. Den föreskriver inte att varje företag ska köpa en viss sorts plattform. Företaget måste kunna uppfylla sina tillämpliga skyldigheter och visa hur arbetet fungerar. Den här guiden hjälper dig att formulera krav, granska en demonstration och jämföra kostnader utan att blanda ihop programvarans funktioner med organisationens ansvar.
Börja med företagets rättsliga omfattning
Artikel 2 räknar upp vilka aktörer som omfattas och vilka undantag som finns. Banker, betalningsinstitut, värdepappersföretag och försäkringsföretag är exempel, men det är missvisande att säga att varje företag med finansiell verksamhet omfattas på samma sätt. Bland undantagen finns vissa mindre aktörer och försäkringsförmedlare som uppfyller förordningens villkor för mikro-, små eller medelstora företag.
Dokumentera därför företagets kategori, tillstånd och relevanta undantag innan en leverantör visar sin standardlösning. En koncern kan innehålla flera juridiska personer med olika skyldigheter. Verktyget bör kunna skilja dem åt samtidigt som det visar gemensamma tjänster och beroenden. En gemensam koncernlicens får inte göra det oklart vilket företag som ansvarar för en uppgift eller rapport.
Proportionalitet enligt artikel 4 innebär att hänsyn tas till storlek, riskprofil och verksamhetens art, omfattning och komplexitet. Det förenklade ramverket i artikel 16 gäller däremot bestämda kategorier, exempelvis små och icke sammanlänkade värdepappersföretag och vissa undantagna betalningsinstitut. Det är inte ett val som varje mindre företag kan göra. En leverantör bör kunna visa hur konfigurationen följer just er kategori.
IKT-leverantörer har dessutom en annan position än finansiella entiteter. Vissa leverantörer kan utses till kritiska och omfattas av ett särskilt europeiskt tillsynssystem. Det gör inte varje molntjänst till ett finansföretag med samma rapporteringsskyldigheter som kunden. För en bredare rättslig genomgång finns vår DORA-guide för finansiella entiteter.
Riskhantering ska kopplas till tjänster och beslut
Ett användbart riskregister börjar med verksamhetens funktioner och de IKT-tjänster som stödjer dem. Det ska gå att se vad ett avbrott kan påverka, vilken information som behövs och vilka leverantörer som ingår. En lista med generiska cyberhot utan koppling till verksamheten hjälper sällan ledningen att prioritera mellan två konkreta åtgärder.
För företag som omfattas av artikel 5 ska ledningsorganet definiera, godkänna och övervaka arrangemangen för IKT-riskhanteringen och ansvara för genomförandet. Programvaran bör därför kunna skilja mellan en föreslagen åtgärd, ett fattat beslut och en verifierad förbättring. En grön markering från en teknisk integration är inte samma sak som ett dokumenterat ledningsbeslut om risk och resurser.
Be leverantören visa en sammanhängande situation: en viktig betalningsfunktion är beroende av en extern tjänst som saknar tillräcklig återställningsförmåga. Vem äger risken, vilken åtgärd har beslutats och hur syns resultatet av nästa övning? En arbetsplan för IKT-riskhantering ger ett bättre demonstrationsunderlag än en rundtur bland menyer och färdiga diagram.
Informationsregistret omfattar fler avtal än de kritiska
Artikel 28 kräver ett uppdaterat informationsregister över samtliga avtalsarrangemang om användning av IKT-tjänster som tillhandahålls av tredjepartsleverantörer. Registret ska skilja mellan tjänster som stödjer kritiska eller viktiga funktioner och övriga tjänster. Det räcker därför inte att registrera de fem största leverantörerna eller de avtal som inköpsavdelningen redan betraktar som strategiska.
Kontrollera att verktyget kan koppla ihop juridisk person, avtal, tjänst, leverantör och den funktion som stöds. Samma leverantör kan leverera flera tjänster med olika betydelse. Om leverantörens namn används som enda identifierare kan ändringar i ett avtal råka påverka alla andra poster. Läs gärna vår mall för DORA:s informationsregister när ni bestämmer vilka uppgifter som behöver samlas in.
Ett särskilt program är inte i sig ett lagkrav. Ett välskött kalkylark kan vara en del av lösningen, men organisationen måste ändå klara kvalitet, uppdatering och rapporteringsformat. När antalet avtal och samband växer blir ändringshistorik och kontroller viktigare. Begär att få se hur verktyget hittar en saknad identifierare eller ett avtal som inte längre kan kopplas till rätt tjänst.
Svensk rapportering kräver en fungerande export
Finansinspektionens tekniska anvisningar beskriver rapportering i Fidac. Informationsregistret ska enligt den publicerade anvisningen lämnas som ett XBRL-CSV Reporting Package. Det är ett strukturerat paket, inte vilken komprimerad samling kalkylblad som helst. En allmän knapp för CSV-export visar därför inte att filerna kan rapporteras korrekt.
Låt leverantören demonstrera en export med representativa uppgifter och förklara hur felmeddelanden hanteras. Kontrollera också vem som underhåller formatet när myndigheternas tekniska anvisningar ändras. Ett system kan ha fungerat för en tidigare referensperiod utan att automatiskt vara rätt konfigurerat för nästa. Avtalet bör klargöra vad uppdateringar omfattar och hur snabbt relevanta ändringar införs.
För incidenter beskriver FI tre separata moduler: dora_initial, dora_intermediate och dora_final. Referenskoden från den första rapporten används för att hålla ihop senare rapporter. Verktyget bör bevara den kopplingen och skilja mellan ett sparat utkast, en exporterad fil och en faktiskt inskickad rapport. Att en rapport finns i en plattform betyder inte att FI har tagit emot den.
Incidentflödet behöver flera tidsstämplar
En IKT-incident kan upptäckas innan det står klart att den ska klassificeras som allvarlig. Systemet behöver därför kunna registrera både tidpunkten för kännedom och tidpunkten för klassificering, tillsammans med det underlag som fanns då. En enda ruta för incidentdatum gör det svårt att beräkna tidsfrister och förklara varför bedömningen senare ändrades.
FI:s incidentvägledning pekar på de tekniska standarderna för klassificering och rapportering. En automatisk regel kan hjälpa handläggaren, men resultatet behöver kunna kontrolleras och motiveras. Demonstrationen bör innehålla en incident där nya uppgifter förändrar omfattningen. Då syns om systemet sparar tidigare bedömningar eller bara skriver över dem.
Enligt artikel 5 i delegerad förordning 2025/301 ska den första anmälan lämnas så tidigt som möjligt, inom fyra timmar efter klassificering som allvarlig och senast 24 timmar efter kännedom. Om allvarlighetsklassificeringen sker först efter dessa 24 timmar gäller den särskilda grenen med anmälan inom fyra timmar efter klassificeringen. Reglerna ger inte rätt att skjuta upp en bedömning som redan kan göras.
Delrapporten ska lämnas senast 72 timmar efter den första anmälan, även om läget inte har ändrats. En uppdaterad delrapport lämnas utan onödigt dröjsmål och senast när normal verksamhet har återupptagits. Slutrapporten ska lämnas inom en månad efter delrapporten eller den senaste uppdaterade delrapporten. Om en tidsfrist inte kan hållas ska myndigheten underrättas utan onödigt dröjsmål och senast vid den aktuella fristen, med skälen till förseningen.
Programvaran får inte heller anta att alla tidsfrister flyttas till nästa arbetsdag. Artikel 5 har en möjlighet att rapportera före middag nästa arbetsdag när fristen infaller på helg eller allmän helgdag, men den gäller inte första anmälan och delrapporten för bland annat kreditinstitut, centrala motparter, handelsplatser och andra finansiella entiteter som identifierats som väsentliga eller viktiga enligt NIS2. Myndigheten kan även undanta andra betydande eller systemviktiga företag efter underrättelse. Reglerna behöver därför anpassas till företag och rapporttyp.
Leverantörsavtal behöver olika kontrollnivåer
DORA:s artikel 30 skiljer mellan grundläggande avtalskrav och ytterligare krav för tjänster som stödjer kritiska eller viktiga funktioner. Grundkraven omfattar bland annat tydliga tjänstebeskrivningar, behandlings- och lagringsplatser, skydd av data, åtkomst och återlämnande vid vissa avbrotts- eller avslutssituationer samt stöd vid incidenter. Programvaran bör hjälpa er att hitta den faktiska klausulen och dokumentera en avvikelse.
För kritiska eller viktiga funktioner tillkommer mer omfattande krav, bland annat preciserade servicenivåer, rapporteringsskyldigheter, kontinuitetsåtgärder, medverkan i relevanta tester samt åtkomst, inspektion och revision. En generell fråga om leverantören är certifierad ersätter inte granskningen. Inte heller räcker det att markera att ett standardavtal finns utan att kontrollera om det omfattar rätt tjänst och juridisk person.
Exitplanen behöver visa hur tjänsten och uppgifterna kan flyttas eller tas hem utan att kundernas tjänster bryts. Be om en demonstration där ett avtal upphör och ett alternativ ska aktiveras. Vilka beroenden följer med, vem fattar beslut och hur kontrolleras att informationen är användbar efter export? Planering i ett system kan stödja arbetet, men genomförbarheten måste prövas i verksamheten.
Testhantering är mer än att lagra rapporter
Ett verktyg för motståndskrafttester bör koppla varje upptäckt brist till en ansvarig, prioritet och verifierad åtgärd. Annars riskerar organisationen att samla många rapporter utan att veta vilka problem som fortfarande finns. För företag som omfattas av artikel 24 behöver testprogrammet följa den tillämpliga riskbaserade och proportionerliga ordningen, inklusive relevanta krav på oberoende.
Hotbildsstyrda penetrationstester, TLPT, gäller utvalda finansiella entiteter enligt artikel 26. Det är inte ett allmänt krav på varje mindre finansföretag. Grundregeln för de utvalda är minst vart tredje år, men behörig myndighet kan justera frekvensen. Artikel 16-kategorier och mikroföretag behandlas särskilt. Ett verktyg bör därför kunna skilja TLPT från andra tester och övningar.
Kontrollera även hur känsliga testresultat skyddas. En detaljerad sårbarhetsrapport bör inte automatiskt bli tillgänglig för alla som får se ledningens sammanfattning. Behörigheter, loggning och möjligheten att dela relevanta utdrag är därför praktiska köpkriterier. En sammanställning av stängda åtgärder behöver kunna följas tillbaka till bevis för att bristen faktiskt har avhjälpts.
Samordna med GDPR och NIS2 utan att blanda skyldigheterna
DORA-arbetet kan använda samma förteckning över leverantörer och system som dataskyddsarbetet, men bedömningarna är olika. En IKT-leverantör är inte automatiskt personuppgiftsbiträde. När leverantören behandlar personuppgifter för företagets räkning behöver personuppgiftsbiträdesavtalet uppfylla GDPR. DORA-klausuler och dataskyddsklausuler kan finnas i samma avtal, men den ena regeluppsättningen ersätter inte den andra.
En DORA-incident kan samtidigt vara en personuppgiftsincident som behöver bedömas för anmälan till IMY. GDPR:s artikel 33 har en egen risktröskel och tidsfrist: utan onödigt dröjsmål och om möjligt inom 72 timmar från kännedom, om det inte är osannolikt att incidenten medför risk för människors rättigheter och friheter. Alla personuppgiftsincidenter ska dokumenteras, även de som inte anmäls.
Information till berörda personer bedöms separat enligt artikel 34 och dess höga risktröskel och undantag. En rapport till FI ersätter inte denna bedömning. Systemet bör alltså kunna driva flera relaterade arbetsflöden utan att kopiera samma juridiska slutsats mellan dem. Gemensamma fakta kan återanvändas, medan mottagare, rättsliga kriterier och beslut hålls tydliga.
Även NIS2-programvara och arbetet med den svenska cybersäkerhetslagen kan ha gemensamma tekniska underlag. DORA har en särskild sektorsreglerande roll, men det krävs en bedömning av den aktuella entiteten och verksamheten. En koncern bör därför inte stänga alla andra regelspår enbart för att ett av dess företag omfattas av DORA.
Informationsdelning är en möjlighet med villkor
Artikel 45 möjliggör utbyte av information om cyberhot inom betrodda gemenskaper och under skyddande arrangemang. Det är inte en generell skyldighet att dela alla incidentuppgifter med konkurrenter. Arrangemangen ska beakta bland annat sekretess, personuppgiftsskydd och konkurrensregler. Deltagande och avslut av deltagande ska anmälas enligt artikelns villkor.
På samma sätt skiljer FI mellan obligatorisk rapportering av allvarliga IKT-incidenter och frivillig rapportering av betydande cyberhot. Programvaran bör kunna markera vilken typ av rapport det handlar om. En automatisk delningsfunktion behöver kunna begränsas så att interna personuppgifter och säkerhetskänsliga detaljer inte sprids bara för att en användare vill dela en teknisk indikator.
Jämför kostnaden för samma leverans
Det finns ingen enhetlig lagstadgad prisnivå för DORA-programvara. Begär offerter som anger samma antal juridiska personer, användare, avtal och integrationsbehov. Skilj mellan licens, införande, datamigrering, utbildning, löpande support och anpassning av rapporteringsformat. Annars kan ett lågt grundpris dölja att den funktion ni behöver kräver ett separat projekt.
En bred jämförelse av GDPR-programvara kan vara relevant om ni redan använder en gemensam plattform, men utvärdera DORA-funktionerna separat. Be att få se informationsregistret, incidentrapporternas koppling och hanteringen av kritiska funktioner. En teknisk säkerhetsprodukt kan ge värdefulla mätdata utan att samtidigt hantera avtal, juridiska bedömningar och rapportpaket.
Ta med den interna arbetstiden i kalkylen. Någon måste bedöma funktioners betydelse, granska avtalsvillkor och hålla registeruppgifter aktuella även när formulär och påminnelser automatiseras. Vår kostnadsguide för dataskyddsverktyg ger stöd för att skilja kostnadsslag, men ett generellt prisexempel bör inte behandlas som en verifierad offert för ert DORA-upplägg.
Inför verktyget med ansvariga och en prövbar leverans
Börja med att bestämma omfattning, ansvariga och vilka brister som behöver lösas först. Informationsregistret är ofta centralt, men ingen regel säger att det alltid måste föregå en akut förbättring av incidenthanteringen. Prioriteringen bör följa verksamhetens risker och faktiska skyldigheter. Koppla arbetet till er befintliga registerförteckning enligt GDPR när gemensamma uppgifter kan återanvändas.
En lämplig pilot innehåller både ett normalt avtal och ett mer komplicerat beroende. Låt sedan ansvariga genomföra en registerexport, en simulerad incident och en uppföljning av en testbrist. Syftet är att se om uppgifter går att hitta och beslut går att fatta under realistiska förhållanden. Det är en rekommenderad utvärderingsmetod, inte ett särskilt myndighetskrav på en viss pilotmodell.
Granska slutligen den nya plattformens egna risker. Var lagras informationen, vilka har administrativ åtkomst och hur fungerar export vid ett leverantörsbyte? Lagring inom EU kan vara ett relevant avtalskrav för er, men avgör inte ensam hela dataskydds- eller säkerhetsbedömningen. Rätt verktyg ska göra det lättare att hålla kontroll över arbetet även när leverantören, organisationen eller rapporteringskraven förändras.