Varför DORA har separat incidentpelare
Innan DORA rapporterade svenska finansbolag ICT-incidenter till Finansinspektionen via olika sektorspecifika kanaler: PSD2-incidenter, TIBER-EU-observationer, Solvens II-rapportering för försäkring. Kanalerna var fragmenterade och svåra att aggregera till sektorsövergripande analys.
DORA harmoniserar detta. Ett enda ramverk, en klassificering, en rapporteringsmall, ett tidsfönster. Finansinspektionen tar emot rapporterna och förmedlar aggregat till europeiska tillsynsmyndigheter. Det förenklar finansbolagens rapporteringsarbete men höjer samtidigt precisionskraven eftersom harmoniserade mallar innehåller fler obligatoriska fält.
Art. 17: ICT-incidenthanteringsprocess
Art. 17 kräver att finansbolaget har en dokumenterad ICT-incidenthanteringsprocess som täcker hela livscykeln: detektion, triage, klassificering, respons, återhämtning, lärande. Processen ska vara integrerad med ICT-riskhanteringsramverket enligt Art. 5 och med affärskontinuitetshantering enligt Art. 11.
Konkreta krav:
- Tidig detektion via monitoringsverktyg och SOC-funktion.
- Formaliserad triage-process med definierade kriterier.
- Klassificering enligt RTS-kriterierna (se nedan).
- Eskaleringsregler med tidskrav till ledning och styrelse.
- Rapportering till FI enligt harmoniserat tidsfönster.
- Kundkommunikation där relevant.
- Post-incident review med dokumenterade lärdomar.
Art. 18: klassificering av ICT-relaterade incidenter
Klassificering styr om en incident ska rapporteras som major ICT-related incident. Detaljreglerna finns i Commission Delegated Regulation 2024/1772 (RTS för incidentklassificering). Sju kriterier bedöms:
| Kriterium | Vad bedöms |
|---|---|
| Kunder, finansiella motparter och transaktioner påverkade | Antal eller volym, som andel av totalen eller i absoluta tal |
| Reputational impact | Mediabevakning, kundklagomål, extern rapportering |
| Varaktighet och nertid | Hur länge tjänsten varit otillgänglig eller degraderad |
| Geografisk spridning | Hur många länder påverkas |
| Dataförlust eller dataintegritetsproblem | Volym och känslighet, inklusive konfidentiellt material |
| Påverkan på kritiska tjänster | Om tjänsten stödjer kritisk eller viktig funktion |
| Ekonomisk påverkan | Direkt kostnad, indirekta kostnader, bortfallt intäkt |
Art. 19: rapportering till Finansinspektionen
Major ICT-related incidents ska rapporteras i tre steg enligt harmoniserat format (Commission Implementing Regulation 2024/2956, ITS för incidentrapportering):
| Rapport | Tidsfönster | Innehåll |
|---|---|---|
| Initial notification | Inom 4 timmar efter att incidenten klassificerats som major, senast inom 24 timmar efter detektion | Grundläggande information: datum, kort beskrivning, preliminär klassificering, pågående åtgärder |
| Intermediate report | Inom 72 timmar efter initial notification | Detaljerad analys: bakomliggande orsak preliminärt, påverkan, pågående åtgärder, förväntad återhämtning |
| Final report | Senast 1 månad efter att incidenten är löst | Fullständig analys: grundorsak, påverkan, lärdomar, förebyggande åtgärder |
Eskaleringskedja internt
Effektiv rapportering kräver en fungerande intern eskaleringskedja. För svenska finansbolag ser kedjan typiskt ut så här:
- Detektion. SOC eller monitoringsverktyg identifierar avvikelse.
- Triage (15 till 60 minuter). Incident response team klassificerar severity och aktiverar incident commander.
- Preliminär klassificering (inom 2 timmar). ICT-risk-funktion bedömer mot RTS-kriterier.
- Eskalering till ledning (inom 4 timmar). Om major: CISO, CIO, CRO, CEO, styrelseordförande informeras.
- Rapportering till FI. Inom 4 timmar efter major-klassificering.
- Kundkommunikation. Parallellt vid behov, beslutas av kommunikationsansvarig plus affärsägare.
- Post-incident review. Senast 2 veckor efter att incidenten är löst.
Art. 20: harmoniserade mallar och ITS
Harmoniserade rapporteringsmallar för initial notification, intermediate report och final report är bindande via ITS. Mallen innehåller cirka 40 obligatoriska fält beroende på rapporttyp. ESA publicerar mallarna i maskinläsbart format och Finansinspektionen tar emot rapporterna via dedikerad portal.
I praktiken: finansbolag med bra incidentrespons har automatiserade flöden som förbereder största delen av rapporten automatiskt utifrån ärendesystemet. Manuell komplettering sker typiskt på fält som bakomliggande orsaksanalys och lärdomar.
Art. 22: informationsdelning
DORA uppmuntrar frivillig informationsdelning mellan finansiella entiteter om cyberhot. Art. 22 specificerar att finansbolag får dela cyber threat intelligence med varandra, inom regleringens ramar. Svensk praxis bygger ofta på FSI-ISAC (Financial Services Information Sharing and Analysis Center) och nationella forum koordinerade via Finansinspektionen.
Art. 23: significant cyber threat notification
Art. 23 introducerar en frivillig kanal för att rapportera significant cyber threats till Finansinspektionen. Till skillnad från major ICT-related incident är detta inte en incident som realiserats, utan ett hot som bedöms ha sektorsövergripande betydelse. Exempelvis en ny zero-day sårbarhet mot en allmänt använd kärnbanksplattform. Rapportering är frivillig men värdesätts av FI för sektoranalys.
Överlapp med NIS2 och AI Act
En enda incident kan behöva rapporteras parallellt till flera tillsynsmyndigheter.
NIS2 och Cybersäkerhetslagen (SFS 2025:1506). Lex specialis innebär att DORA går före för finansbolag. I praktiken: rapportering sker enligt DORA-kanalen men vissa finansbolag får dubbla skyldigheter om de också driver verksamhet som inte täcks av DORA.
AI Act Art. 73. Om incidenten involverar ett högrisk-AI-system och utgör en allvarlig incident enligt AI Act ska parallell rapport göras till IMY och eventuellt till Finansinspektionen i dess roll som sektorsvis marknadskontrollmyndighet för finansbolag. Tidsfönstret är annorlunda (15 dagar, 48 timmar vid dödsfall).
GDPR Art. 33. Personuppgiftsincidenter rapporteras till IMY inom 72 timmar.
En ransomware-attack mot ett svenskt finansbolag med AI-kreditbedömning och personuppgifter kan kräva fyra parallella rapporter till tre olika tillsynsmyndigheter. Koordinerad incident management är avgörande för att inte missa deadlines.
Svenska exempel
En svensk storbank rapporterade sju major ICT-related incidents till FI under 2025. Den största gällde en störning i kort-processingsystemet som pågick 4 timmar och påverkade 340 000 transaktioner. Initial notification skickades inom 3 timmar, intermediate inom 48 timmar, final efter 3 veckor. Post-incident-analysen ledde till investeringar i redundant kort-processing.
Ett svenskt försäkringsbolag i mellansegmentet rapporterade inga major under 2025 men två betydande near-misses som klassificerades under tröskelvärdena. Båda near-misses föranledde frivilliga lessons learned-rapporter till FI för sektoranalys.
En svensk betaltjänstleverantör upplevde under Q3 2025 en DDoS-attack som pågick 6 timmar och påverkade över 20 procent av kundbasen. Incidenten klassificerades som major. Rapporteringen gick enligt tidsfönstren men visade brister i eskaleringskedjan som ledde till översyn av CISO-funktionens bemanning utanför kontorstid.
Vanliga fel i incidentrapportering
Finansinspektionen har identifierat återkommande brister i major-rapporter under 2026:
- Fördröjd initial notification. Klassificeringen gjordes rätt men rapporten gick iväg 6 till 8 timmar efter.
- Otydlig bakomliggande orsaksanalys i final report. Teknisk förklaring finns men inte organisatorisk root cause.
- Inkonsekvent klassificering över tid. Liknande incidenter klassificeras olika utan tydlig motivering.
- Saknad integration med NIS2-rapportering. Finansbolag som också har verksamhet utanför DORA missar ibland NIS2-rapport.
- Post-incident review som inte resulterar i konkreta åtgärder i riskregistret eller kontrollkatalogen.