När en allvarlig IKT-incident träffar ett finansiellt företag startar klockan innan någon ens hunnit enas om vad som faktiskt hänt. Enligt EU:s förordning om digital operativ motståndskraft (DORA) har du timmar, inte dagar, på dig att skicka din första anmälan, och rapporten måste följa en fast struktur med fält du inte får lämna tomma. Team som ser incidentrapportering som något de skriver ihop i efterhand upptäcker för sent att fristen redan passerat.

DORA gör om incidentrapportering till en operativ process du kör under press. Du behöver klassificera incidenten mot fastställda kriterier, anmäla till rätt myndighet på en snäv tidslinje och följa upp med delrapport och slutrapport när bilden klarnar. Den här guiden går igenom hur DORA vill att du klassificerar och rapporterar en allvarlig IKT-relaterad incident, hur det skiljer sig från NIS2 och GDPR, och hur OptiTech håller hela kedjan på rätt spår.

Vad DORA kräver av dig

DORA är EU:s förordning om digital operativ motståndskraft (Digital Operational Resilience Act). Den gäller finansiella företag (banker, försäkringsbolag, värdepappersföretag, betaltjänstinstitut, leverantörer av kryptotillgångstjänster med flera) och de kritiska IKT-tredjepartsleverantörer de är beroende av. Förordningen samlar den operativa motståndskraften i ett ramverk: hantering av IKT-risk, incidentrapportering, motståndskraftstester, tredjepartsrisk och informationsdelning.

Incidentrapporteringen är den del med de skarpaste kanterna. När en IKT-relaterad incident passerar tröskeln från mindre till allvarlig är du skyldig din behöriga myndighet en strukturerad rapport enligt ett fastställt schema. Tröskeln är inte en bedömning du gör i stunden. Det är en uppsättning kriterier, och du måste bedöma din incident mot dem.

Vad räknas som en allvarlig IKT-relaterad incident

En IKT-relaterad incident är varje händelse som skadar säkerheten i dina nätverks- och informationssystem och har en negativ påverkan på de tjänster du levererar. De flesta incidenter är mindre och stannar internt. En allvarlig incident är en som passerar rapporteringströskeln, och det avgörs genom att väga en uppsättning klassificeringskriterier tillsammans.

Kriterierna du bedömer:

• Berörda kunder och finansiella motparter. Hur många kunder, motparter eller transaktioner incidenten rörde, och om någon av dem är kritisk. Ett litet antal kritiska kunder kan väga lika tungt som ett stort antal vanliga.
• Dataförluster. Om incidenten orsakade förlust av tillgänglighet, autenticitet, riktighet eller konfidentialitet för uppgifter. All påverkan på uppgifternas riktighet eller konfidentialitet väger tungt.
• Varaktighet och avbrottstid. Hur länge incidenten pågick och hur länge din tjänst var otillgänglig. Klockan räknar från upptäckt, inte från när du var klar med hanteringen.
• Geografisk spridning. Om påverkan korsade gränser in i andra medlemsstater, vilket höjer insatsen och kan dra in fler myndigheter.
• Ekonomisk påverkan. De direkta och indirekta kostnaderna och förlusterna, mätt i absoluta tal och i förhållande till din storlek.
• Påverkan på anseende och tjänsternas kritikalitet. Om kritiska eller viktiga funktioner påverkades och hur synlig störningen var.

Inget enskilt kriterium avgör ensamt. Du väger dem tillsammans mot de trösklar som anges i förordningen och dess tekniska standarder. Därför spelar en upprepningsbar metod större roll än någon enskild persons omdöme: samma incident ska klassificeras på samma sätt oavsett vem som har jouren.

Rapporteringens tidslinje

När en incident väl är allvarlig kör DORA en rapportering i tre steg. Varje steg har sin egen frist och sitt eget syfte, och du får inte hoppa över.

Inledande anmälan

Den första anmälan går ut kort efter att du klassificerat incidenten som allvarlig, inom timmar från det beslutet. Den är medvetet kort. Den talar om för din myndighet att en allvarlig incident har inträffat, vad du vet hittills och att en fylligare bild är på väg. Poängen är snabbhet, så att ingen väntar på en färdig grundorsaksanalys innan den skickas.

Delrapport

Delrapporten följer när du gått från upptäckt till aktiv hantering och förstår påverkan bättre. Den uppdaterar statusen, förfinar klassificeringen och beskriver vad du gör för att begränsa och återställa. Om läget ändras väsentligt skickar du uppdaterade delrapporter i stället för att bli tyst.

Slutrapport

Slutrapporten sluter cirkeln när incidenten är löst och grundorsaken är förstådd. Den redogör för vad som hände, varför, den faktiska påverkan mot klassificeringskriterierna, samt åtgärder och lärdomar. Det är rapporten som visar om ditt motståndskraftsprogram faktiskt fungerar.

Att missa någon av de här fristerna är i sig ett efterlevnadsbrott, skilt från själva incidenten. Det är det som gör tidslinjen till den svåraste delen att köra manuellt.

Vem du rapporterar till

Du rapporterar till din behöriga myndighet, vilken beror på din typ av företag och din medlemsstat. För ett svenskt finansiellt företag är det Finansinspektionen. Myndigheterna kan sedan slussa informationen vidare till de europeiska tillsynsmyndigheterna och, där det är relevant, till andra organ. Ditt jobb är att få rätt rapport till rätt myndighet inom rätt fönster, och den vidare hanteringen är deras.

Så skiljer sig DORA från NIS2 och GDPR

Finansiella företag ligger ofta under mer än ett incidentregelverk samtidigt, och det är lätt att anta att en rapport täcker allt. Det gör den inte.

• GDPR handlar om personuppgiftsincidenter. Du anmäler till tillsynsmyndigheten inom 72 timmar när personuppgifter komprometteras. Utlösaren är skada på individers uppgifter, inte operativ störning.
• NIS2 handlar om säkerheten i nätverks- och informationssystem hos väsentliga och viktiga entiteter i många sektorer. Det har sina egna steg för tidig varning och rapportering, ofta i en rytm på 24 och 72 timmar, till nationell CSIRT eller behörig myndighet.
• DORA är specifikt för finanssektorn och för IKT-relaterade incidenter. Det är mer detaljstyrt om klassificeringskriterier och den treställiga rapportstrukturen, och för finansiella företag är det den specialiserade regeln för operativ motståndskraft.

En och samma incident kan utlösa alla tre samtidigt. En ransomware-attack som tar din tjänst offline och exponerar personuppgifter kan kräva en DORA-rapport till Finansinspektionen, en GDPR-anmälan till tillsynsmyndigheten och en NIS2-rapport till nationell CSIRT, var och en på sin egen klocka. Att behandla dem som en enda rapport är precis så frister missas.

Så strukturerar OptiTech en DORA-incidentrapport

Anledningen till att incidentrapportering går fel under press är att den behandlas som fritextskrivande. Någon öppnar ett tomt dokument mitt i natten och försöker minnas vad förordningen kräver. OptiTech ersätter det tomma pappret med struktur.

När du öppnar en DORA-incident i OptiTech Console får du en rapport byggd kring klassificeringskriterierna och de obligatoriska fälten för varje rapportsteg. Du registrerar berörda kunder och motparter, datapåverkan, tidslinjen från upptäckt, den geografiska spridningen och den ekonomiska påverkan som strukturerade fält, inte som prosa du måste komma ihåg att få med. Klassificeringen beräknas från de underlagen, så att beslutet om allvarlig eller inte blir konsekvent och försvarbart.

Varje steg i rapporten (inledande, del, slut) har sina egna obligatoriska fält och sin egen frist, spårad på en synlig klocka. Rapportvalideringen kontrollerar att varje obligatoriskt fält är ifyllt innan du skickar in, så att inget lämnas tomt under tidspress. Om den inledande anmälan saknar ett underlag som myndigheten förväntar sig får du veta det av valideringen, inte av tillsynsmyndigheten.

Eftersom incidenten kopplas tillbaka till kontrollerna och bevisen i ditt bredare program är slutrapporten ingen fristående artefakt. Den knyter an till motståndskraftstesterna, tredjepartsriskerna och de kontroller som var tänkta att förhindra eller begränsa incidenten, så att dina lärdomar faktiskt matas tillbaka in i programmet.

Kom igång

Du bygger inte incidentrapportering mitt under en incident. En realistisk första omgång ser ut så här:

1. Definiera din klassificeringsmetod mot DORA-kriterierna, så att beslutet om allvarlig eller inte blir konsekvent oavsett vem som har jouren.
2. Kartlägg din behöriga myndighet och eventuella överlappande regelverk (NIS2, GDPR) innan du behöver dem.
3. Ställ upp de tre rapportstegen med deras obligatoriska fält och frister, redo att öppna med ett klick.
4. Koppla incidenter till ditt motståndskraftsprogram så att slutrapporter matar lärdomar tillbaka in i kontroller och tester.

DORA belönar de företag som behandlar incidentrapportering som en inövad operativ process, inte en stressig improvisation. Bygg strukturen en gång, så blir nästa allvarliga incident en rapport du fyller i i stället för en frist du fruktar.

Redo att köra DORA-incidentrapportering utan nattlig stress? Boka en demo och se hur OptiTech strukturerar dina rapporter, validerar de obligatoriska fälten och håller varje frist på klockan.