Klockan 02.14 en lördag larmar övervakningen: API-servern i produktionsklustret svarar inte och någon har skapat ett okänt ServiceAccount med cluster-admin. Tekniskt vet du vad du ska göra. Men vem bestämmer om det här är en betydande incident? När började klockan ticka? Och vem har inloggningen till portalen där rapporten ska in?
Den här artikeln går igenom hur incidentrapportering enligt cybersäkerhetslagen fungerar i praktiken: när en incident är betydande, vad som ska in i upplysningen inom 24 timmar, incidentanmälan inom 72 timmar och slutrapporten inom en månad, och en runbook som plattformsteamet kan börja använda redan nu.
Har du frågor om ämnet? Tveka inte att höra av dig till oss!
Det här är en teknisk genomgång och inte juridisk rådgivning. Om ni är osäkra på hur kraven gäller just er, ta hjälp av en jurist. De juridiska uppgifterna är kontrollerade den 26 oktober 2026.
Av Johan Kuylenstierna, VD Agency 42 · Senast granskad 26 oktober 2026
Reglerna i korthet
Tre nivåer styr rapporteringen:
- Cybersäkerhetslagen (2025:1506), 2 kap. 5–8 §§, sätter skyldigheten och fristerna.
- Cybersäkerhetsförordningen (2025:1507), 6 §, säger att rapporterna går till CSIRT-enheten, som enligt 31 § är Försvarets radioanstalt (FRA). I praktiken tar Nationellt cybersäkerhetscenter (NCSC) vid FRA emot dem.
- MCFFS 2026:8, som gäller sedan 1 juli 2026, säger vad varje rapport ska innehålla och när en incident är betydande för de flesta sektorer. För digital infrastruktur, IKT-tjänster mellan företag och digitala leverantörer gäller i stället EU:s genomförandeförordning (EU) 2024/2690.
Föreskriften bär fortfarande MCF:s namn, men FRA förvaltar den sedan 1 juli 2026 och den gäller oförändrat.
Är det en betydande incident?
Enligt 2 kap. 5 § är en incident betydande om den har orsakat eller kan orsaka allvarlig driftsstörning eller ekonomisk skada för er, eller om den har påverkat eller kan påverka andra genom att vålla betydande skada.
MCFFS 2026:8 gör det konkret. Några av de generella kriterierna i 3 kap.:
- Ett sektorskritiskt system är otillgängligt eller nedsatt så att verksamheten bara kunnat bedrivas begränsat i mer än 12 timmar, eller personalen har fått använda alternativa arbetssätt i mer än 48 timmar.
- Information i behov av utökat skydd har blivit tillgänglig för obehöriga, förvanskats eller förstörts.
- Kostnaden för incidenten överstiger fem procent av årsomsättningen föregående räkenskapsår.
- Information som ni behandlar åt en annan juridisk person, eller åt minst 500 fysiska personer, har röjts, förvanskats eller förstörts.
Det finns även sektorsspecifika kriterier i 4 kap. och "kan orsaka"-varianter, till exempel när en betydande sårbarhet eller ett betydande cyberhot finns i era system.
Är ni molnleverantör, datacenter, MSP eller MSSP? Då gäller (EU) 2024/2690. Där räcker det till exempel att en molntjänst är helt otillgänglig i mer än 30 minuter (artikel 7). Det generella kriteriet om ekonomisk förlust ligger på 500 000 euro eller fem procent av årsomsättningen, det som är lägst (artikel 3). För plattformsteam som säljer drift eller kluster till andra är det här en betydligt lägre ribba än många tror.
När startar klockan?
Här är det värt att läsa noga:
- Lagen räknar 24 och 72 timmar från att ni har fått kännedom om incidenten.
- MCFFS 2026:8 räknar från att incidenten har identifierats som betydande.
- (EU) 2024/2690, skäl 31, beskriver kännedom som tidpunkten då ni efter en inledande bedömning med rimlig grad av säkerhet har fastställt att en betydande incident har ägt rum.
Slutsatsen för plattformsteamet är praktisk, inte juridisk: den inledande bedömningen måste gå fort och dokumenteras med tidsstämpel. "Vi tittade på det på måndagen" håller inte om larmet gick på lördagen.
Tänk på det som en fotbollsdomare. Klockan stannar inte för att ingen vill blåsa. Någon måste ha visselpipan, och alla måste veta vem.
Tidslinjen och vad som ska med
| Steg | Frist | Lagrum | Innehåll enligt MCFFS 2026:8 (urval) |
|---|---|---|---|
| Upplysning | Snarast, senast 24 h | 2 kap. 5 § lagen; 2 kap. 3 § MCFFS | Namn och organisationsnummer, om incidenten pågår, förlopp och hur den upptäcktes, misstanke om avsiktligt skadliga eller olagliga handlingar, om den kommer från en leverantör, påverkan, konsekvenser och gränsöverskridande effekter |
| Incidentanmälan | Snarast, senast 72 h (betrodda tjänster 24 h) | 2 kap. 6 § lagen; 2 kap. 4 § MCFFS | Uppdatering av upplysningen, när incidenten inträffade och upphörde, bedömd orsak, påverkan på system, angreppsindikatorer |
| Delrapport | På begäran | 2 kap. 7 § lagen | Statusuppdateringar |
| Slutrapport | Senast en månad efter anmälan | 2 kap. 8 § lagen; 2 kap. 5 § MCFFS | Slutlig bedömning av konsekvenser, grundorsak, vidtagna och planerade åtgärder |
| Lägesrapport | Om incidenten pågår efter en månad, sedan slutrapport inom en månad efter att den hanterats | 2 kap. 8 § lagen; 2 kap. 6 § MCFFS | Varför den pågår, hur länge till, fortsatt påverkan |
Rapporterna lämnas i incidentrapporteringsverktyget i NCSC:s cyberportal. Enligt NCSC skapas ett nytt incidentID för varje steg, och det behövs för att gå vidare till nästa steg. Spara det. Om portalen inte fungerar finns ett reservförfarande via cybersakerhet@ncsc.se.
Behöver ni hjälp medan incidenten pågår kan ni kontakta CERT-SE dygnet runt på 010-382 80 00 eller cert@cert.se. Det ersätter inte rapporten.
Glöm inte kunderna
Rapporten till NCSC är bara en av era mottagare. Enligt 2 kap. 9–10 §§ och 5 kap. MCFFS 2026:8 ska ni så snart det kan ske informera mottagarna av era tjänster om en betydande incident som har påverkat dem: vad som hänt, vad de behöver göra och vad som händer om de inte gör det. Samma sak gäller vid ett betydande cyberhot. Information ska inte lämnas om den kan försvåra hanteringen eller förvärra konsekvenserna.
Har incidenten även rört personuppgifter kan en anmälan till Integritetsskyddsmyndigheten (IMY) behövas enligt dataskyddsförordningen, och är ni tillverkare av en produkt som omfattas av CRA kan en aktivt utnyttjad sårbarhet dessutom trigga CRA:s rapporteringsplikt. Planera klockorna i samma rutin.
Runbooken: från larm till slutrapport
1. Förberedelser (innan något händer)
- Utse rapportansvarig och minst en ersättare, med behörighet till cyberportalen. Testa inloggningen nu, inte under incidenten.
- Skriv ner vem som får besluta att en incident är betydande. Det är ett ledningsbeslut, men plattformsteamet ska leverera underlaget.
- Gör en lista över era sektorskritiska system och vilka kluster, noder, register och pipelines som bär dem.
- Förbered mallar för upplysning, anmälan, slutrapport och kundinformation med fälten från MCFFS 2026:8.
- Kontrollera att leverantörsavtalen ger er underlag i tid. Om incidenten börjar hos en leverantör ska det framgå redan i upplysningen.
2. Timme 0–24: upptäck, bedöm, upplys
- Starta en incidentlogg med tidsstämplar direkt. Första raden: när larmet kom och när bedömningen började.
- Säkra spåren innan ni städar: Kubernetes audit-loggar, händelser, nod- och runtime-larm (till exempel Falco), ändringshistorik i Git och CI.
- Gör den inledande bedömningen mot kriterierna. Dokumentera beslutet, även om svaret är "inte betydande".
- Skicka upplysningen med en preliminär bedömning. Den behöver inte vara perfekt, den ska vara i tid.
3. Timme 24–72: förstå och anmäl
- Avgränsa: vilka kluster, namnrymder, tjänster och kunder påverkas?
- Samla angreppsindikatorer (IP-adresser, image-digests, kontonamn, hashvärden).
- Skicka incidentanmälan med uppdaterad bedömning, orsak och påverkan.
- Informera berörda kunder enligt mallen.
4. Dag 3–30: åtgärda och slutrapportera
- Gör en grundorsaksanalys utan skuldbeläggning. Människor gör fel, system ska tåla det.
- Dokumentera tekniska och organisatoriska åtgärder, till exempel strängare RBAC, nya admission-policyer, roterade hemligheter eller patchade noder.
- Skicka slutrapporten senast en månad efter anmälan, eller en lägesrapport om incidenten fortfarande pågår.
5. Efteråt
- Uppdatera riskanalysen och runbooken.
- Lägg in lärdomarna i nästa övning.
- Spara allt. Rapporteringen kan bli ett ämne vid tillsyn, och att inte rapportera enligt 2 kap. 5–9 §§ är en av de överträdelser som kan leda till ingripanden enligt 4 kap. lagen, inklusive sanktionsavgift.
En liten 42-blinkning: panik är fortfarande ingen plan. En utskriven runbook och en laddad telefon är det närmaste man kommer en handduk.
Vad plattformen måste kunna leverera
Det mesta i rapporterna går att besvara snabbt om plattformen är byggd för det:
- Tidslinje: synkroniserade klockor, centraliserade loggar och audit-loggar som sparas tillräckligt länge.
- Påverkan: övervakning som visar vilka tjänster och kunder som berörs, inte bara att en pod startar om.
- Orsak: ändringshistorik i GitOps, signerade images och SBOM så att ni vet exakt vad som kördes.
- Åtgärder: policy as code och IaC så att förbättringarna går att visa, inte bara beskriva.
Hur ni bygger bevisen i vardagen beskriver vi i Kubernetes-härdning som bevis.
Sammanfattning
- Rapporteringen styrs av 2 kap. 5–8 §§ cybersäkerhetslagen, 6 § cybersäkerhetsförordningen och MCFFS 2026:8. För moln, datacenter och MSP gäller även (EU) 2024/2690.
- Kedjan är upplysning inom 24 h, incidentanmälan inom 72 h, delrapport på begäran och slutrapport inom en månad.
- Rapporterna går till NCSC vid FRA via cyberportalen, med ett nytt incidentID per steg.
- Kunder ska informeras, och samma incident kan även kräva rapport till IMY eller enligt CRA.
Du ska göra runbooken nu om:
- ingen kan svara på vem som beslutar att en incident är betydande,
- ni inte har testat inloggningen till cyberportalen,
- era loggar inte räcker för att återskapa de första 24 timmarna.
Vanliga frågor
Vart rapporterar man en betydande incident enligt cybersäkerhetslagen?
Till CSIRT-enheten, som är FRA. I praktiken lämnas rapporterna i incidentrapporteringsverktyget i NCSC:s cyberportal.
Hur snabbt måste vi rapportera?
Upplysning senast 24 timmar och incidentanmälan senast 72 timmar efter kännedom, för betrodda tjänster 24 timmar. Slutrapporten ska in senast en månad efter anmälan.
Vad är en betydande incident?
En incident som har orsakat eller kan orsaka allvarlig driftsstörning eller ekonomisk skada, eller betydande skada för andra. MCFFS 2026:8 och, för vissa digitala tjänster, (EU) 2024/2690 anger konkreta kriterier.
Måste upplysningen vara komplett?
Nej. Den ska bygga på en preliminär bedömning. Det viktiga är att den kommer in i tid och uppdateras i incidentanmälan.
Gäller MCFFS 2026:8 fortfarande nu när FRA har tagit över?
Ja. Enligt NCSC gäller föreskrifterna oförändrat efter att föreskriftsrätten flyttade till FRA den 1 juli 2026.
Vi driftar kluster åt andra. Gäller samma kriterier för oss?
Inte nödvändigtvis. För molntjänster, datacenter och MSP/MSSP gäller kriterierna i (EU) 2024/2690, där till exempel 30 minuters total otillgänglighet för en molntjänst räcker.
Vill du ha hjälp att bygga en runbook som håller?
Vi är Sveriges go-to-specialister på Kubernetes och hjälper plattforms- och driftteam att förbereda sig inför cybersäkerhetslagen: GAP-analys, runbook, loggning och audit, härdning, GitOps-spårbarhet och evidens inför tillsyn. Vi har erfarenhet från säkerhetskritisk plattformsdrift i försvarssektorn. Kontakta oss för offert eller ett första tekniskt samtal.
Läs mer på:
- Compliance: NIS2 och CRA i plattformen
- Cybersäkerhetslagen för dig som driftar plattformen
- DevOps och DevSecOps
- Kubernetes-konsult för design, bygge och drift
- Kundcase
- Kontakta oss
Källor
Alla kontrollerade 2026-10-26.
- Cybersäkerhetslag (2025:1506), i kraft 2026-01-15. Särskilt 2 kap. 5–10 §§ och 4 kap. 1 och 10 §§. riksdagen.se
- Cybersäkerhetsförordning (2025:1507), lydelse t.o.m. SFS 2026:623. Särskilt 6 §, 18 § och 31 §. riksdagen.se
- MCFFS 2026:8, föreskrifter om incidentrapportering och informationsskyldighet för väsentliga och viktiga verksamhetsutövare, beslutad 2026-05-13, gällande från 2026-07-01. ncsc.se
- NCSC, "Rapportera en betydande incident enligt cybersäkerhetslagen (NIS2)". ncsc.se
- NCSC, föreskrifter (föreskriftsrätten hos FRA från 2026-07-01). ncsc.se
- Kommissionens genomförandeförordning (EU) 2024/2690, skäl 31 och artikel 3 och 7. eur-lex.europa.eu
- Direktiv (EU) 2022/2555 (NIS2), artikel 23. eur-lex.europa.eu
