När och hur ni rapporterar
NIS2 och DORA har olika rapporteringskedjor och olika trösklar för "betydande" incident. Den här playbooken visar tre Mythos-typiska scenarier och mappar dem mot 24 h-/72 h-/1 mån-deadlines i NIS2 art. 23 och 4 h-/72 h-/1 mån i DORA art. 19. Använd som första-pass-stöd vid larm — slutgiltig klassificering och rapporteringsbeslut tas av incident-koordinator i samråd med jurist.
Tidsaxel · NIS2 art. 23 (Cybersäkerhetslagen)
Trestegsrapportering vid betydande incident enligt NIS2-direktivet. Implementeras i Sverige genom Cybersäkerhetslagen; sektorsmyndighet beror på er sektor.
Tidig varning
Första signalen om en betydande incident är på väg eller har inträffat. Räcker att indikera misstanke om malign orsak och eventuell gränsöverskridande påverkan.
Indikator på malign orsak; antagande om gränsöverskridande påverkan; förslag på första klassificering. Ingen krav på fullständig analys vid 24-h-punkten.
Incidentanmälan
Konkret bedömning av allvar, verkan, IoC:er och korsreferens till tidigare 24 h-varning.
Bedömning av allvar och verkan, indikatorer på kompromiss (IoC:er), åtgärder vidtagna eller planerade, statushet på systemen.
Slutrapport
Detaljerad rapport med root-cause, åtgärder, lessons learned, gränsöverskridande effekter.
Detaljerad beskrivning av incidenten, root-cause-analys, vidtagna åtgärder, eventuella effekter över medlemsstatsgränser, lärdomar och förändrade kontroller.
Tidsaxel · DORA art. 19 (Finansiell sektor)
Gäller ICT-relaterade incidenter klassificerade som betydande enligt DORA. Trösklarna är skarpare än NIS2 — initial anmälan inom 4 h efter klassificering.
Initial anmälan
Inom 24 h efter detektion ska klassificeringen vara klar; därefter 4 h till FI. För kombinerad NIS2+DORA-incident: rapportera båda — DORA går till FI, NIS2 till sektorsmyndigheten.
Klassificeringskriterier, antal påverkade kunder, finansiell påverkan, geografisk spridning, kritiska funktioner som drabbats. Tröskelvärden specificeras i DORA RTS — verifiera mot aktuell version.
Mellanrapport
Statusuppdatering med korrigeringar och progress mot återställning. Ny information som påverkar klassificering eller åtgärder.
Slutrapport
Detaljerad slutlig analys, root-cause, åtgärder och åtaganden för förbättring. Underlag för FI:s tillsyn och eventuella sanktioner.
Mythos-typiska scenarier
Tre incidentbilder som rapporten lyfter fram som realistiska under 6–12-månadersfönstret. Klicka på rapporteringskrav i tabellen för länk till relevant artikel.
1. Komprometterad coding-agent läcker hemligheter
| Ramverk | Trigger | Deadline | Rapport |
|---|---|---|---|
| NIS2 art. 23 | Misstanke om läcka av betydande omfång | 24 h | Tidig varning till CERT-SE |
| NIS2 art. 23 | Bekräftad kompromiss | 72 h | Incidentanmälan |
| DORA art. 19 | FI-omfattad entitet, kund-API påverkat | 4 h efter klass. | Initial anmälan till FI |
| GDPR art. 33 | Persondata bland läckta hemligheter | 72 h | Anmälan till IMY |
| DORA art. 28 | Agent-leverantör är ICT-tredjepart | Löpande | Uppdatera ICT-tredjepartsregister |
Förebyggande åtgärder: Skydda dina agenter, Härda miljön.
2. AI-driven exploit-våg utnyttjar nyligen patchad CVE
| Ramverk | Trigger | Deadline | Rapport |
|---|---|---|---|
| NIS2 art. 23 | Försök eller framgångsrik kompromiss på betydande system | 24 h | Tidig varning till CERT-SE/sektorsmyndighet |
| NIS2 art. 23 | Klassad som "betydande" enligt sektorkriterier | 72 h | Incidentanmälan |
| DORA art. 19 | Finansiell entitet, kritisk funktion påverkad | 4 h efter klass. | Initial till FI |
| NIS2 art. 23 | Bara försök, ingen kompromiss | — | Inget rapporteringskrav (men logga; kan bli "betydande cyberhot") |
Förebyggande åtgärder: Kontinuerlig patching, Deception-kapacitet, Automatiserad IR.
3. MCP-server-leverantörs supply-chain-uppdatering är komprometterad
| Ramverk | Trigger | Deadline | Rapport |
|---|---|---|---|
| NIS2 art. 23 | Bakdörr aktiv, exfiltration osäker | 24 h efter upptäckt | Tidig varning |
| DORA art. 19 + 28 | FI-entitet, ICT-tredjepartsproblem | 4 h efter klass. | Initial till FI; uppdatera tredjepartsregister |
| DORA art. 28(8) | Beslut om exit/byte av leverantör | Löpande | Genomför exit-strategi enligt avtal |
| NIS2 art. 21(2)(d) | Leveranskedjan exponerad | N/A | Uppdatera leverantörsbedömning |
Förebyggande åtgärder: Skydda dina agenter, Inventera & reducera attackytan.
Vart ringer ni
Beroende på sektor och vilken förordning som triggas. Vid tvekan: börja med CERT-SE och er sektorsmyndighet.
CERT-SE (CSIRT)
Nationell CSIRT. Förstavalet vid 24 h-varning för NIS2-omfattade entiteter.
Finansinspektionen
Tillsynsmyndighet under DORA. Mottar betydande ICT-incidenter inom finansiell sektor.
PTS
Sektorsmyndighet för digital infrastruktur (telekom, datacenter). Tar emot NIS2-rapporter inom sektorn.
FRA
Tekniskt stöd vid större incidenter, särskilt vid statliga aktörer eller försvarsrelaterad verksamhet.
Generera konceptrapport
Webformulär som skapar nedladdningsbar JSON + HTML — inget skickas till server. Använd som koncept-rapport innan ni granskar internt och skickar till relevant myndighet.
Måste verifieras innan ni faktiskt rapporterar
Sidan är planeringsstöd, inte regulatorisk vägledning. Innan en faktisk anmälan skickas:
- Tröskelvärden för "betydande incident" regleras i delegerade RTS (NIS2 art. 23(11), DORA art. 19(7)). Verifiera mot aktuell version.
- Kanalen kan ändras — Loopia-listan här är generell. Sektorspecifik kanal anges i Cybersäkerhetslagens tillämpningsföreskrifter.
- Sektorsklassificering (väsentlig vs viktig entitet) påverkar både trösklar och deadline-tolkning. Be jurist verifiera er klassning.
- Kombinerade incident där både NIS2- och DORA-rapportering aktualiseras kräver dubbel anmälan — undvik att en kanal "äter" den andra.
- Persondata (GDPR art. 33) har egen 72 h-deadline till IMY — börjar löpa när organisationen blir medveten om överträdelsen.