Enligt DORA ska finansiella entiteter rapportera allvarliga IKT-relaterade incidenter, så kallade major incidents, när en händelse påverkar kritiska tjänster, orsakar dataförlust, sprider sig geografiskt eller får betydande ekonomisk påverkan. Rapporteringen sker till Finansinspektionen via systemet Fidac, i tre steg: dora_initial, dora_intermediate och dora_final.
Kort sagt:
- En incident blir rapporteringspliktig när en kritisk tjänst påverkas tillsammans med minst ett annat kriterium, eller när två andra kriterier uppfylls samtidigt.
- Skicka första rapporten inom fyra timmar från klassificering och senast ett dygn efter upptäckt; uppdatera inom 72 timmar och slutrapportera inom en månad.
- Registrera rapporteringskontot med rätt behörighet, använd rapportens unika referenskod genom hela kedjan och testa filformatet i Fidac före den skarpa inlämningen.
- Dokumentera tidpunkten för upptäckt och klassificering direkt och samla in leverantörernas LEI eller EUID tidigt, så att tidsfristerna hålls och uppgifterna finns till hands.
Innehållsförteckning
- Klassificering och materialitetskriterier: när blir en händelse “major”?
- Tidsfrister och vilka uppgifter som krävs i initial, intermediate och final rapport
- Hur rapporteringen till Finansinspektionen genomförs tekniskt
- Praktisk intern process och checklista för compliance-teamet
- Praktisk rådgivning: juridiska och processmässiga nyckelråd
- Kort perspektiv: varför en robust rapporteringsprocess är strategisk
- Hur vi kan hjälpa till med er DORA-rapportering
- Vanliga frågor
- Källor
Klassificering och materialitetskriterier: när blir en händelse “major”?
Innan en rapport kan skickas måste vi avgöra om händelsen faller under DORA:s definition av en major incident. Kommissionens delegerade förordning 2024/1772 specificerar de kriterier och materialitetströsklar som styr klassificeringen, och de flesta team gör bedömningen utifrån en kombination av följande faktorer:
- Påverkan på klienter och finansiella motparter, räknat i antal eller andel berörda.
- Ryktesmässig påverkan, exempelvis mediebevakning eller klagomål från kunder.
- Varaktighet och driftstopp, det vill säga hur länge tjänsten var otillgänglig.
- Geografisk spridning, om incidenten påverkar flera medlemsstater.
- Dataförluster, inklusive integritet, tillgänglighet och konfidentialitet.
- Kritiska tjänster som påverkas, kopplat till verksamhetens kärnfunktioner.
- Ekonomisk påverkan, mätt i direkta och indirekta kostnader.
Kombinationsregeln är central: en incident klassas som major antingen när en kritisk tjänst påverkas tillsammans med minst ett annat kriterium, eller när två andra kriterier uppfylls samtidigt utan att en kritisk tjänst är inblandad. Återkommande incidenter som var för sig inte är rapporteringspliktiga kan ändå tillsammans peka på systematiska brister, och ESAs operativa instruktioner förtydligar att sådana mönster bör bedömas kollektivt snarare än isolerat. För team som är osäkra på om en enhet omfattas av regelverket över huvud taget finns en genomgång av vilka som omfattas av DORA att utgå från innan klassificeringsarbetet påbörjas.
Tidsfrister och vilka uppgifter som krävs i initial, intermediate och final rapport
När en händelse har klassats som major incident styr klockan resten av processen. Tidsfristerna är strikta och varje steg kräver olika typ av dokumentation:
- Initial rapport: skickas inom 4 timmar efter klassificering och senast 24 timmar efter att incidenten upptäcktes. Här ingår grundläggande identifiering av entiteten, en intern incidentreferens och en första beskrivning av vilka tjänster som påverkas.
- Intermediate rapport: lämnas inom 72 timmar och uppdaterar statusen, inklusive varaktighet, uppskattad kontra faktisk påverkan och information om eventuella tredjeparter, som LEI eller EUID.
- Final rapport: skickas inom en månad och sammanfattar grundorsak, åtgärder och den slutgiltiga bedömningen av konsekvenserna.
Det praktiska arbetet underlättas avsevärt av att vi dokumenterar upptäcktstidpunkt och klassificeringstidpunkt så fort som möjligt, eftersom dessa tidsstämplar avgör om fristerna hålls. Spara även underlag för varje uppdatering, så att ändringar mellan rapportstegen går att motivera i efterhand.
Hur rapporteringen till Finansinspektionen genomförs tekniskt
Själva inlämningen sker i Finansinspektionens rapporteringsportal, och innan en rapport kan skickas måste kontot ha rätt behörighet. Processen ser i korthet ut så här:
- Registrera organisationen i Rapporteringsportalen och tilldela behörigheten “DORA incident och cyberhot” till de personer som ska rapportera.
- Skicka in dora_initial för att generera en unik referenskod, som sedan måste användas i både dora_intermediate och dora_final för att binda samman hela incidentförloppet.
- Ladda upp informationsregistret som ett XBRL-CSV-paket, med fält som refPeriod och baseCurrency samt tillhörande parameters.csv enligt EBA:s rapporteringsramverk.
- Kör en testrapport i Fidac innan skarp inlämning, eftersom felaktiga filformat eller saknade obligatoriska fält är de vanligaste orsakerna till avvisade rapporter.
Proffstips: Testa alltid XBRL-CSV-paketet mot FI:s tekniska scheman innan den skarpa inlämningen, så undviker ni att en hel rapportkedja fastnar på ett formatfel i sista minuten.
Om en incident senare visar sig vara mindre allvarlig än först bedömt finns en särskild omklassificeringskod i Fidac, major_incident_reclassification_as_non-major, som bevarar spårbarheten i stället för att posten tas bort. Den som vill fördjupa sig i de första stegen och vanliga fallgropar kan läsa mer i vår genomgång av DORA-rapportering från dag ett.
Praktisk intern process och checklista för compliance-teamet
En fungerande rapporteringsprocess bygger på tydligt fördelat ansvar innan en incident ens inträffar. Vi rekommenderar följande struktur:
- Utse vem som klassificerar incidenten, vanligen en säkerhetsansvarig, och vem som har mandat att skicka in rapporterna till Fidac.
- Koordinera tidigt med leverantörer för att samla in LEI eller EUID och annan tredjepartsinformation som krävs för fält 2.8.
- Följ kedjan upptäckt, triage, initial rapport, löpande dokumentation, intermediate rapport och slutligen final rapport, med omklassificering som en möjlig gren längs vägen.
- Öva processen regelbundet genom testrapportering i Fidac, så att både roller och tekniska steg sitter när en verklig incident inträffar.
Den som vill bygga ett mer heltäckande program för leverantörsledet, inklusive hur tredjepartsinformation samlas in löpande snarare än under tidspress, hittar en fördjupning i tredjepartsrisker i GRC.
Praktisk rådgivning: juridiska och processmässiga nyckelråd
Vi ser ofta att de organisationer som hanterar DORA-rapportering bäst är de som omsätter regelverket till egna, standardiserade operativa instruktioner som speglar ESAs operativa instruktioner och uppdateras varje gång myndigheterna publicerar nya tolkningar. Vår erfarenhet från rådgivningsuppdrag visar att tredjepartsspårning ofta är den svagaste länken, särskilt insamlingen av LEI och EUID till fält 2.8.
Konkret kan vi bistå med:
- Mallar för fältutfyllnad som minskar risken för felaktiga eller ofullständiga rapporter.
- Stöd vid testrapportering i Fidac för att verifiera att processen håller inför en skarp incident.
- Utbildning av incident- och complianceteam i klassificering och tidsfrister.
- Implementering av Trustview som stöd för att dokumentera och spåra incidenter över tid.
Kort perspektiv: varför en robust rapporteringsprocess är strategisk
En DORA-rapport är inte bara en administrativ pliktövning. Korrekt och snabb rapportering minskar risken för att en incident sprider sig till andra aktörer i en gränsöverskridande kedja, och Finansinspektionen pekar på att process- och systemfel dominerar bland de incidenter som faktiskt rapporteras in. Bättre data ger dessutom en bättre dialog med tillsynen.
— Jesper
Hur vi kan hjälpa till med er DORA-rapportering
Vi erbjuder incidentrådgivning, interimstöd som compliance officer och en digital plattform för den organisation som vill bygga en process som håller när klockan väl börjar ticka. Vårt arbete handlar om att göra klassificering, fältutfyllnad och tredjepartsspårning hanterbart i praktiken, inte bara på pappret.
- Boka en genomgång av er nuvarande incidentprocess och få konkreta förbättringsförslag.
- Få tillgång till mallar och checklistor anpassade efter er organisations struktur.
- Använd en digital plattform som stöd för dokumentation och spårbarhet över tid.
Hör av dig via vår sida för rådgivning och konsulttjänster för att boka ett första samtal.
Vanliga frågor
För vilka gäller DORA?
DORA gäller för de flesta finansiella entiteter inom EU, inklusive banker, försäkringsbolag, värdepappersbolag och vissa tredjepartsleverantörer av IKT-tjänster. Vissa aktörer, som kreditinstitut utan insättningsverksamhet, kan vara undantagna enligt Finansinspektionens beslutspromemoria. En fullständig genomgång av vilka som omfattas finns i vår artikel om DORA-krav.
Vad räknas som en incident?
En IKT-relaterad incident är en händelse som påverkar tillgänglighet, konfidentialitet, integritet eller äkthet för data och tjänster. Den blir rapporteringspliktig, det vill säga en major incident, först när den uppfyller materialitetskriterierna i Delegated Regulation 2024/1772, till exempel genom påverkan på kritiska tjänster eller betydande ekonomisk skada.
Hur rapporterar jag en incident till FI?
Rapporteringen sker digitalt i Fidac genom modulerna dora_initial, dora_intermediate och dora_final, som alla länkas samman via en unik referenskod. Kontot måste först registreras i Rapporteringsportalen med rätt behörighet innan inlämning är möjlig.
Vad är en betydande incident enligt NIS2?
Definitionen av en betydande incident skiljer sig mellan regelverk, men inom DORA är det materialitetskriterierna i den delegerade förordningen som avgör klassificeringen för finansiella entiteter. För organisationer som omfattas av både DORA och NIS2 bör bedömningen göras utifrån respektive regelverks egna trösklar snarare än en gemensam definition.
När ska informationsregistret lämnas in?
Informationsregistret ska lämnas in årligen, senast den 28 februari, via Fidac i format XBRL-CSV enligt Finansinspektionens krav. Rapporteringen görs antingen på grupp- eller entitetsnivå, aldrig båda samtidigt.
