NIS2-incidentplan: 12 Steg, 24h/72h-Frister [2026]

Den 15 januari 2026 trädde Sveriges nya cybersäkerhetslag i kraft och förvandlade NIS2 från ett EU-direktiv på papper till en operativ skyldighet för tusentals svenska organisationer. Kravet som stressar flest säkerhetschefer just nu är inte tekniskt, det är tidsstyrt: en tidig varning inom 24 timmar, en fullständig anmälan inom 72 timmar och en slutrapport inom en månad, allt räknat från den stund du blir medveten om incidenten, inte från när utredningen är klar. De flesta organisationer har en incidenthanteringsplan sedan tidigare. Väldigt få har en som klarar den klockan.

Den här guiden går igenom hur du bygger, testar och underhåller en incidenthanteringsplan som är redo för cybersäkerhetslagen och NIS2, steg för steg, med färdiga mallar, ett automatiseringsscript och ett komplett filträd du kan kopiera rakt av. Vi utgår från kraven i Artikel 23 i NIS2-direktivet och den svenska tillämpningen via MSB, PTS och Nationellt cybersäkerhetscenter (NCSC).

Bakgrunden är inte teoretisk. Under maj 2026 kapades utvecklarverktyget Nx Console via en skadlig version publicerad på npm-registret, spårad som CVE-2026-48027 med en CVSS-poäng på 9,8, och samma vecka publicerade angripare 84 skadliga versioner över 42 paket i TanStack-ekosystemet mellan klockan 19:20 och 19:26 UTC den 11 maj. Den typen av leveranskedjeattack är exakt det scenario NIS2:s krav på incidentrapportering och leverantörsriskhantering är byggt för att fånga upp tidigt, innan skadan sprider sig vidare till kundernas system. Ett svenskt team som drabbas av en liknande komprometterad byggkedja har i praktiken 24 timmar på sig att skicka den första varningen, oavsett hur komplicerad utredningen sedan blir.

Varför NIS2 kräver en annan sorts incidenthantering

Traditionell incidenthantering är sekventiell: upptäck, begränsa, utrota, återställ, lär dig. NIS2 lägger tre rapporteringsgrindar rakt ovanpå de faserna, och de bryr sig inte om var i utredningen du befinner dig. Du måste kunna skicka en tidig varning innan du ens vet hela omfattningen, och det är den delen som knäcker gamla planer.

Det här är också skälet till att så många team fastnar när de försöker skriva om sin gamla incidentplan. En plan byggd för att “lösa incidenten först, rapportera sedan” fungerar inte när lagen kräver att rapporteringsklockan startar samtidigt som utredningen. De organisationer som klarar det bäst har separerat de två spåren helt: ett tekniskt spår som jagar angriparen, och ett rapporteringsspår som matar myndigheten med det som är känt vid varje given tidpunkt, även om svaret bara är “vi vet ännu inte”.

Enligt EU-kommissionens sanktionsstruktur i Artikel 34 riskerar väsentliga verksamhetsutövare böter på upp till 10 miljoner euro eller 2 procent av global årsomsättning, det som är högst. För viktiga verksamhetsutövare är taket 7 miljoner euro eller 1,4 procent av omsättningen. Beloppen gäller per överträdelse, och en missad 72-timmarsfrist räknas som en egen överträdelse skild från själva säkerhetsincidenten.

I Sverige sker rapporteringen inte direkt till EU. Du rapporterar till Nationellt cybersäkerhetscenter, som slussar vidare till rätt tillsynsmyndighet: MSB för de flesta sektorer, Post- och telestyrelsen för digital infrastruktur och digitala tjänster, eller Finansinspektionen för finansiella aktörer. MSB driver också det nationella CSIRT:et, CERT-SE, som du kan nå på [email protected] eller 010-240 40 40 för operativt stöd under en pågående incident.

Det här skiljer sig från hur många internationella koncerner är vana att arbeta, där incidentrapportering ofta går direkt till ett centralt EU-organ. I den svenska modellen är MSB navet, och det är också MSB som är kontaktpunkten om er organisation är osäker på om, och i så fall till vem, en viss händelse ska anmälas.

Steg	Tidsfrist	Vad som ska ingå	Mottagare
Tidig varning	24 timmar	Preliminär beskrivning, upptäcktstid, misstänkt orsak, kontaktuppgifter	NCSC → MSB/PTS/FI
Incidentanmälan	72 timmar	Allvarlighetsgrad, påverkan, indikatorer på intrång (IOC), åtgärder hittills	NCSC → tillsynsmyndighet
Lägesrapport	Vid begäran, om incidenten pågår	Uppdaterad status, ny information sedan senaste rapport	Tillsynsmyndighet
Slutrapport	1 månad	Grundorsak, konsekvensanalys, vidtagna åtgärder, gränsöverskridande påverkan	NCSC → tillsynsmyndighet

Lägg märke till att lägesrapporten inte är obligatorisk i samma bemärkelse som de övriga tre, den skickas när tillsynsmyndigheten begär det eller när incidenten fortfarande pågår vid ett tidigare rapporteringstillfälle. I praktiken innebär det att ett komplicerat intrång som pågår i flera veckor kan generera fyra, fem eller fler separata inskick till myndigheten innan ärendet är slutrapporterat, snarare än de tre steg som ofta beskrivs schematiskt.

Förutsättningar: verktyg och roller du behöver innan du börjar

Du behöver inte köpa en dyr SOAR-plattform för att bygga en NIS2-redo plan, men du behöver följande på plats innan du sätter igång. Många av verktygen nedan har ni troligen redan, det som saknas i de flesta organisationer är inte tekniken utan att den kopplats ihop med en tydlig process och namngivna ansvariga.

Python 3.11 eller senare (för exempelskripten i den här guiden)
Ett centraliserat loggsystem eller SIEM, till exempel Wazuh 4.x, Elastic Security 8.x eller motsvarande
Ett ärendehanteringssystem eller minst en delad kanal i Slack, Microsoft Teams eller motsvarande för incidentkommunikation
Ett dokumentationsverktyg (Confluence, Notion, eller en enkel Git-repo med Markdown) för runbooks
Kontaktuppgifter till CERT-SE, din tillsynsmyndighet och din dataskyddsombud redo i förväg, inte googlade under en pågående kris
Mandat från ledningen att en utsedd incidentledare får fatta beslut om nedstängning av system under en aktiv incident

Räkna med 3–5 arbetsdagar utspridda över några veckor för att bygga hela planen från grunden, plus en halvdag var sjätte månad för att öva och uppdatera den. Det låter som mycket tid att avsätta, men jämför med kostnaden av att missa en rapporteringsfrist under en verklig incident: en sanktionsavgift på flera miljoner kronor, plus den tid det tar att förklara för ledningen och kunder varför processen inte fanns på plats.

Verktygslandskapet: vad nordiska säkerhetsteam faktiskt kör

Ni behöver inte standardisera på ett specifikt verktyg för att bli NIS2-redo, men det hjälper att veta vilka kategorier som täcker vilket behov. För loggning och detektion räcker det ofta med en öppen källkodslösning som Wazuh för mindre och medelstora organisationer, medan större verksamheter med högre volymer och striktare krav på lagringstid ofta väljer en kommersiell SIEM-plattform.

För själva incidentkoordineringen räcker en ärendehanteringsplattform som redan finns på plats, till exempel Jira Service Management eller Zendesk, kombinerat med en dedikerad Slack- eller Teams-kanal för realtidskommunikation. Det som avgör om verktyget fungerar är inte prislappen, utan om alla i incidentteamet faktiskt vet var de ska logga in när larmet går.

Dokumentationen, det vill säga planen själv, mallarna och runbooksen, mår bäst av att ligga någonstans versionshanterat och sökbart, oavsett om det är en Git-repo som i exemplet senare i den här guiden, eller en wiki som Confluence. Det viktiga är att den är tillgänglig även om er huvudsakliga IT-miljö är helt nedsläckt, vilket för många organisationer betyder en kopia utanför den vanliga produktionsmiljön.

Steg 1: Avgör om din organisation omfattas av cybersäkerhetslagen

Innan du bygger något, klargör om du är en väsentlig eller viktig verksamhetsutövare enligt lagen. Väsentliga sektorer inkluderar energi, transport, bank, finansmarknadsinfrastruktur, hälso- och sjukvård, dricksvatten, digital infrastruktur och offentlig förvaltning. Viktiga sektorer inkluderar bland annat post- och kurirtjänster, avfallshantering, kemikalietillverkning, livsmedel, tillverkningsindustri och digitala leverantörer som molntjänster och sociala nätverksplattformar.

Storlekskravet är i grunden medelstora och stora företag (50+ anställda eller 10 miljoner euro i omsättning), men vissa kritiska leverantörer omfattas oavsett storlek. Om du är osäker, kontakta MSB på [email protected], de svarar konkret på om just din verksamhet räknas in.

Det är också värt att kartlägga vilka av era leverantörer och underleverantörer som själva omfattas, eftersom en incident hos en av dem kan trigga rapporteringsplikt hos er om den påverkar er leverans till slutkund. Gör den kartläggningen som en enkel lista, inte ett större projekt: vilka system är kritiska för er verksamhet, och vem levererar och driftar dem.

Steg 2: Bygg ditt incidentresponsteam och rollmatris

NIS2 kräver parallella spår: du utreder samtidigt som du kommunicerar och rapporterar. Det går inte med en ensam IT-tekniker som gör allt i tur och ordning. Du behöver minst fem roller, och varje roll ska ha en utsedd ersättare eftersom incidenter sällan väntar på att rätt person är tillgänglig.

Roll	Ansvar under incident	Ersättare krävs
Incidentledare	Övergripande beslut, eskalering, mandat att stänga ner system	Ja
Teknisk utredare	Logganalys, begränsning, forensik	Ja
Juridik/regelefterlevnad	Bedöma om incidenten är “betydande”, hantera GDPR-parallell	Ja
Kommunikationsansvarig	Intern och extern kommunikation, kundkontakt	Rekommenderas
Rapportör till NCSC/MSB	Skriver och skickar de tre lagstadgade rapporterna	Ja

Sätt ihop matrisen i ett delat dokument, inte i huvudet på en enskild säkerhetschef. När den personen är på semester eller själv drabbad av incidenten ska nästa i kedjan kunna agera utan att ringa runt.

I mindre organisationer täcker samma person ofta flera roller, det är helt rimligt så länge det står tydligt utskrivet vem som gör vad. Det som inte fungerar är att improvisera rollerna första gången de faktiskt behövs, mitt i en pågående kris klockan två på natten.

Om er organisation saknar egen juridisk kompetens, knyt en extern rådgivare till teamet i förväg och lägg in kontaktuppgifterna i planen. Att behöva hitta och avtala med en advokatbyrå mitt under en pågående incident kostar värdefulla timmar av den 72-timmarsklocka ni redan jagar.

Steg 3: Definiera vad som räknas som en “betydande incident”

Inte varje säkerhetshändelse triggar rapporteringsplikten. Enligt kommissionens genomförandeförordning 2024/2690 räknas en incident som betydande om den orsakar, eller kan orsaka, allvarlig driftsstörning eller ekonomisk förlust, eller om den påverkar andra fysiska eller juridiska personer genom betydande materiell eller immateriell skada. Ett vanligt praktiskt tröskelvärde som används vid bedömningen är 100 000 euro i direkt ekonomisk förlust eller 5 procent av årsomsättningen, det lägre av de två.

Skriv ner er tröskel konkret i planen, med exempel: en ransomware-attack som krypterar produktionsservrar är nästan alltid betydande. Ett enskilt nätfiskeförsök som stoppas av spamfiltret är det nästan aldrig. Gråzonen, till exempel ett intrång utan bekräftad dataexfiltrering, ska juristen i teamet avgöra inom timmar, inte dagar.

Dokumentera även de fall ni bedömer som inte betydande, med en kort motivering. Om tillsynsmyndigheten senare frågar varför en viss händelse inte rapporterades vill ni kunna visa att bedömningen faktiskt gjordes, och inte bara glömdes bort.

Kommissionens genomförandeförordning 2024/2690 preciserar tröskelvärdena per sektor, digital infrastruktur och digitala leverantörer har delvis andra kriterier än till exempel energi eller transport. Om ni verkar i flera sektorer samtidigt, vilket är vanligt för större koncerner, kan olika delar av verksamheten behöva olika tröskelvärden i samma plan.

Steg 4: Sätt upp loggning och detektion för upptäcktsfasen

24-timmarsklockan börjar ticka när ni “blir medvetna” om incidenten, inte när ni bekräftar den. Det betyder att era detektionssystem måste larma ett människo-läst meddelande omedelbart, inte begrava händelsen i en logg som granskas veckovis. Centralisera loggar från brandväggar, EDR-agenter, autentiseringssystem och molntjänster till en plats där en analytiker kan söka över hela miljön på sekunder.

# Exempel: Wazuh-regel som taggar händelser som kräver NIS2-bedömning
# Placeras i /var/ossec/etc/rules/local_rules.xml

<group name="nis2_candidate,">
  <rule id="100201" level="12">
    <if_group>authentication_failed</if_group>
    <same_source_ip />
    <frequency>8</frequency>
    <timeframe>120</timeframe>
    <description>Möjligt brute-force-försök, kräver NIS2-triagering</description>
    <group>nis2_candidate,</group>
  </rule>
</group>

Poängen med att tagga larm redan i SIEM:et är att incidentledaren slipper leta. Allt som är märkt nis2_candidate hamnar direkt i triageringskön där juristen och den tekniska utredaren gör den första bedömningen tillsammans.

Samma princip gäller molntjänster. Om ni kör Microsoft 365, Google Workspace eller AWS, se till att säkerhetsloggarna faktiskt skickas vidare till er SIEM eller centrala logglagring, standardretentionen i många molntjänster är kort och räcker inte för en grundlig grundorsaksanalys en månad senare när slutrapporten ska skrivas.

Detektion handlar inte bara om att upptäcka intrång i den egna infrastrukturen. Bevaka även era mjukvaruberoenden: ett automatiserat larm när en sårbarhetsdatabas flaggar en komponent ni använder som aktivt utnyttjad ger er ofta ett försprång på flera dagar jämfört med att vänta tills angreppet redan syns i era egna loggar.

Steg 5: Skapa mallen för den tidiga 24-timmarsvarningen

Den tidiga varningen ska inte vara en fullständig utredningsrapport, den ska bara ge myndigheten tillräckligt för att förstå att något pågår. Håll mallen kort med fasta fält så att rapportören inte behöver formulera fritext under stress.

early_warning:
  organisation: "Exempel AB"
  org_nummer: "556XXX-XXXX"
  sektor: "digital infrastruktur"
  upptackt_tid: "2026-08-18T09:14:00+02:00"
  misstankt_typ: "ransomware / dataintrång / DDoS / leveranskedjeattack"
  paverkade_system: "produktionsdatabas, kundportal"
  preliminar_omfattning: "okänd, under utredning"
  gransoverskridande: false
  kontakt:
    namn: "Incidentledare"
    epost: "[email protected]"
    telefon: "+46 70 000 00 00"

Fyll i den här mallen även om du inte har alla svar. Fälten “preliminär omfattning” och “misstänkt typ” får absolut innehålla “okänt, under utredning”. Myndigheten förväntar sig inte färdiga svar inom 24 timmar, de förväntar sig att du har upptäckt problemet och satt igång.

Spara mallen som en fil i planen, inte bara som ett formulär i huvudet på rapportören. Under en verklig incident, klockan tre på morgonen, är det skillnaden mellan att fylla i fem fält på tio minuter och att formulera ett helt brev från noll medan klockan tickar.

Steg 6: Automatisera larmet med ett Python-script

Manuella steg glöms bort klockan tre på natten. Ett litet script som fyller i tidsstämpel, räknar ner till respektive deadline och skickar en påminnelse till incidentkanalen minskar risken att 72-timmarsfristen smiter förbi teamet mitt i utredningsarbetet.

import json
from datetime import datetime, timedelta, timezone

def skapa_tidslinje(upptackt_tid: str) -> dict:
    start = datetime.fromisoformat(upptackt_tid)
    return {
        "upptackt": start.isoformat(),
        "tidig_varning_deadline": (start + timedelta(hours=24)).isoformat(),
        "anmalan_deadline": (start + timedelta(hours=72)).isoformat(),
        "slutrapport_deadline": (start + timedelta(days=30)).isoformat(),
    }

def bedom_betydelse(ekonomisk_forlust_eur: float, arsomsattning_eur: float) -> bool:
    troskel = min(100_000, arsomsattning_eur * 0.05)
    return ekonomisk_forlust_eur >= troskel

if __name__ == "__main__":
    tidslinje = skapa_tidslinje(datetime.now(timezone.utc).isoformat())
    betydande = bedom_betydelse(ekonomisk_forlust_eur=150_000, arsomsattning_eur=40_000_000)
    print(json.dumps({"tidslinje": tidslinje, "ar_betydande": betydande}, indent=2))

Kör scriptet direkt vid triagering. Exempel på utskrift:

{
  "tidslinje": {
    "upptackt": "2026-08-18T09:14:00+00:00",
    "tidig_varning_deadline": "2026-08-19T09:14:00+00:00",
    "anmalan_deadline": "2026-08-21T09:14:00+00:00",
    "slutrapport_deadline": "2026-09-17T09:14:00+00:00"
  },
  "ar_betydande": true
}

Koppla gärna resultatet till en webhook mot Slack eller Teams så att hela teamet ser deadlinerna i incidentkanalen automatiskt, istället för att en enskild person räknar på en lapp. Ett enkelt sätt att göra det är att låta scriptet posta resultatet som ett meddelande varje gång ett nytt ärende taggas nis2_candidate, så att deadlinen syns i samma kanal där teamet redan diskuterar incidenten.

Steg 7: Contain — isolera och samla bevis utan att förstöra spår

Begränsningsfasen matar direkt in i 72-timmarsanmälan, så dokumentera varje åtgärd med tidsstämpel medan ni jobbar, inte i efterhand. Isolera drabbade system från nätverket men undvik att stänga av dem helt om det inte är absolut nödvändigt, minnesdumpar och aktiva processer försvinner vid avstängning och du förlorar bevis du behöver för grundorsaksanalysen i slutrapporten.

#!/bin/bash
# Snabb bevisinsamling innan isolering, körs som root på drabbad host
EVIDENCE_DIR="/tmp/incident-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$EVIDENCE_DIR"

ps auxww > "$EVIDENCE_DIR/processer.txt"
ss -tulpan > "$EVIDENCE_DIR/natverksanslutningar.txt"
last -F > "$EVIDENCE_DIR/inloggningar.txt"
cp /var/log/auth.log "$EVIDENCE_DIR/" 2>/dev/null
cp /var/log/syslog "$EVIDENCE_DIR/" 2>/dev/null

sha256sum "$EVIDENCE_DIR"/* > "$EVIDENCE_DIR/checksums.sha256"
echo "Bevis samlat i $EVIDENCE_DIR, isolera nätverket nu."

Checksummorna är viktiga om ärendet senare hamnar hos polis eller försäkringsbolag, de bevisar att bevismaterialet inte manipulerats efter insamlingen. Spara även en tidsstämplad logg över varje beslut som fattas under begränsningsfasen, till exempel vilka konton som spärrats och vilka system som kopplats bort från nätverket. Den loggen blir ryggraden i både 72-timmarsanmälan och slutrapporten.

Steg 8: Skicka 72-timmarsanmälan till MSB och NCSC

Till skillnad från den tidiga varningen ska den här anmälan innehålla en verklig bedömning: allvarlighetsgrad, påverkan på tjänsten, indikatorer på intrång om ni har dem, och vilka åtgärder som redan vidtagits. Skicka den via NCSC:s anmälningskanal, som slussar vidare till er tillsynsmyndighet (MSB, PTS eller Finansinspektionen beroende på sektor). Om incidenten fortfarande pågår vid 72-timmarsgränsen, skicka anmälan ändå med tydlig markering att utredningen inte är klar, och komplettera med en lägesrapport när myndigheten begär det.

Glöm inte GDPR-parallellen. Om incidenten involverar personuppgifter har ni samtidigt en separat 72-timmarsfrist mot Integritetsskyddsmyndigheten. Det är två olika rapporter till två olika mottagare, även om innehållet överlappar mycket. Bygg gärna en gemensam faktainsamling som sedan matas in i båda mallarna, det sparar tid och minskar risken att uppgifterna spretar mellan de två rapporterna.

Räkna med att tillsynsmyndigheten kan återkomma med följdfrågor efter att ni skickat in anmälan, särskilt om beskrivningen av åtgärderna är kortfattad. Ett vanligt misstag är att skriva anmälan så defensivt att den blir svårläst, en tydlig och konkret beskrivning av vad som hänt och vad ni gjort åt det uppfattas generellt bättre än en juridiskt försiktig formulering som säger lite.

Steg 9: Eradication och återställning till drift

Ta bort angriparens fotfäste helt innan ni återställer, en halvfärdig sanering är den vanligaste orsaken till att samma angripare är tillbaka inom en vecka. Rotera alla autentiseringsuppgifter som kan ha exponerats, patcha den sårbarhet som utnyttjades, och verifiera med ett nytt skanningspass innan systemen kopplas tillbaka till produktionsnätet. Återställ från en backup ni vet är ren, helst en som ligger utanför angriparens räckvidd (offline eller immutable storage).

Ha en enkel checklista för återställningen: bekräfta att sårbarheten är patchad, bekräfta att komprometterade konton är återkallade, kör en fullständig skanning av det återställda systemet, och låt minst två personer godkänna innan systemet kopplas tillbaka till produktion. Att skynda på det här steget för att “få igång driften” är en av de vanligaste orsakerna till upprepade incidenter.

Steg 10: Skriv slutrapporten inom en månad

Slutrapporten är den mest detaljerade av de tre. Den ska innehålla en fullständig beskrivning av incidenten och dess allvarlighetsgrad, grundorsaken, vilka åtgärder som vidtagits och vidtas för att förhindra upprepning, och eventuell gränsöverskridande påverkan om incidenten berörde andra EU-länder. Bygg rapporten löpande under utredningen istället för att skriva den från noll i slutet, det sparar tid och minskar risken att viktiga detaljer glöms bort.

Om utredningen fortfarande pågår när 30-dagarsgränsen närmar sig, skicka en lägesrapport med det ni har och komplettera senare. Tillsynsmyndigheten föredrar en ärlig delrapport framför en försenad slutrapport, och en väl dokumenterad delrapport visar samtidigt att ni tar processen på allvar.

Steg 11: Bygg fem scenariospecifika runbooks

En generisk plan räcker inte när klockan tickar. Bygg korta, konkreta runbooks för era mest sannolika scenarier så att teamet kan agera på minuter istället för att uppfinna processen mitt i krisen:

Ransomware och kryptering av produktionsdata
Dataintrång med misstänkt exfiltrering av person- eller kunduppgifter
Överbelastningsattack (DDoS) mot kundvänd tjänst
Leveranskedjeattack via en tredjepartskomponent eller leverantör
Insiderhot eller missbruk av privilegierad åtkomst

Varje runbook ska rymmas på en till två sidor: vem larmas, vilka första tekniska steg tas, vilken tröskel gör incidenten “betydande”, och vem skriver den tidiga varningen. Om ett dokument tar mer än fem minuter att läsa igenom mitt i en kris kommer ingen att läsa det.

Skriv runbooksen tillsammans med de personer som faktiskt kommer att använda dem, inte enbart av säkerhetschefen i ensamt majestät. En teknisk utredare som varit med och format sin egen runbook för ransomware är mer benägen att faktiskt följa den under press, jämfört med ett dokument som känns påtvingat uppifrån.

Lärdomar från verkliga leveranskedjeattacker 2026

Leveranskedjeattacker mot utvecklarverktyg har varit ett återkommande mönster under 2026, och de belyser exakt varför NIS2 lägger så stor vikt vid leverantörsriskhantering. Den 19 maj 2026 laddade angripare upp en skadlig version 18.95.0 av Nx Console, ett populärt gränssnitt för byggverktygen Nx och Lerna, till npm-registret. Sårbarheten spårades som CVE-2026-48027 med CVSS-poängen 9,8, och drabbade organisationer som förlitade sig på att paketet var säkert bara för att det kom från en etablerad källa.

Samma vecka drabbades TanStack-ekosystemet, där angripare på bara sex minuter, mellan 19:20 och 19:26 UTC den 11 maj 2026, publicerade 84 skadliga versioner spridda över 42 paket, spårat som CVE-2026-45321 med CVSS 9,6. Ett tredje exempel är installationsprogrammet för DAEMON Tools Lite, där komprometterade byggen distribuerades direkt via leverantörens egna officiella kanaler, vilket visar att även “betrodda” nedladdningskällor kan vara komprometterade.

Det gemensamma för alla tre fallen är hastigheten. Ingen av incidenterna gav organisationer dagar att reagera, det handlade om timmar från publicering till att skadlig kod kunde vara i produktion. Det är precis det scenariot er runbook för leveranskedjeattacker ska vara byggd för: snabb identifiering av vilka system som använder det komprometterade paketet, snabb isolering, och en tidig varning skickad inom 24 timmar även om ni ännu inte vet den fulla omfattningen av intrånget.

Praktiskt innebär det att teamet behöver kunna svara på frågan “använder vi det här paketet, och i så fall var” på minuter, inte dagar. Det är därför en enkel inventering av era mjukvaruberoenden, kombinerat med ett automatiserat larm när en komponent flaggas som komprometterad, är en av de mest kostnadseffektiva investeringarna ett litet säkerhetsteam kan göra inför nästa leveranskedjeattack.

Steg 12: Testa planen med tabletop-övningar

En plan som aldrig testats är en teoretisk plan. Kör en tabletop-övning där teamet går igenom ett fiktivt scenario i realtid, inklusive att faktiskt fylla i mallen för den tidiga varningen och tidsstämpla varje beslut. Många säkerhetsrådgivare rekommenderar minst två sådana övningar per år, med en större simulerad incident som involverar ledningen minst vart annat år. Justera planen efter varje övning, det är själva poängen, inte en formalitet.

Välj ett annat scenario för varje övning, till exempel ransomware ena gången och en leveranskedjeattack nästa. Om samma scenario övas om och om igen tränar teamet bara på det specifika fallet, inte på att tänka strukturerat när verkligheten avviker från manuset, vilket den nästan alltid gör.

Vanliga fallgropar när team bygger sin NIS2-plan

De flesta problem som dyker upp handlar inte om teknik utan om process och ägarskap. Här är de sex fallgroparna vi ser oftast hos svenska och nordiska team som bygger sin första NIS2-redo plan:

Väntar på fullständig bild innan den tidiga varningen skickas. Klockan börjar vid upptäckt, inte vid bekräftelse. Skicka varningen med det ni vet, komplettera senare.
En enda person äger hela processen. Utan namngivna ersättare stannar allt när nyckelpersonen är otillgänglig, vilket ofta sker just under en stor incident.
Ingen skriftlig definition av “betydande incident”. Utan tröskelvärden fastnar teamet i diskussion istället för handling när klockan redan tickar.
Planen ligger bara i ett Word-dokument på en server som blir otillgänglig under incidenten. Ha en offline-kopia, till exempel utskriven eller på en lokal disk.
Blandar ihop NIS2-anmälan med GDPR-anmälan. Det är två separata rapporter till två separata mottagare, även vid samma incident.
Ingen övning på över ett år. Roller byts, kontaktuppgifter blir inaktuella, och verktyg uppdateras. En oövad plan bryter ofta ihop på detaljer som inte längre stämmer.
Leverantörsrisker glöms bort helt. Team fokuserar ofta bara på sin egen infrastruktur och missar att en incident hos en molnleverantör eller ett komprometterat mjukvarupaket kan trigga samma rapporteringsplikt, exakt det mönster som Nx Console- och TanStack-incidenterna visade under 2026.

Felsökning: 8 vanliga problem och hur du löser dem

Även en väl genomtänkt plan stöter på friktion i praktiken. Nedan är de problem som oftast dyker upp under de första skarpa incidenterna eller under tabletop-övningar, tillsammans med den lösning som brukar fungera bäst.

Problem	Trolig orsak	Lösning
Vi vet inte om incidenten är “betydande”	Otydliga tröskelvärden i planen	Skriv konkreta exempel per scenario, låt juristen förhandsgodkänna gränsfall
24-timmarsfristen missades	Larmet nådde inte rätt person i tid	Automatisera larm till flera kanaler samtidigt, inte bara e-post
Ingen vet vem som skriver rapporten	Rollmatrisen saknar ersättare	Utse minst två personer per roll, testa i tabletop-övning
Bevis försvann vid avstängning av servern	System stängdes av innan minne och loggar samlats in	Isolera nätverksmässigt istället för att stänga av, kör insamlingsscript först
Rapport till NCSC avvisas eller efterfrågas kompletteras	Obligatoriska fält saknas eller är vaga	Använd fast mall, fyll i “okänt, under utredning” istället för att lämna fält tomma
Teamet blandar ihop NIS2- och GDPR-tidslinjer	En gemensam mall används för båda	Separata checklistor, tydligt märkta med mottagande myndighet
Kontaktuppgifter till CERT-SE eller MSB är inaktuella	Planen uppdateras inte rutinmässigt	Granska kontaktlistan vid varje halvårsvis övning
Ledningen blockerar beslut om nedstängning	Mandat är inte formellt dokumenterat	Få skriftligt mandat för incidentledaren i förväg, inte under krisen

Om ni stöter på ett problem som inte finns i listan, dokumentera det och lägg till en rad i er egen plan. Felsökningslistan ska växa efter varje verklig incident och varje övning, inte förbli statisk. Många team upptäcker sina svagaste punkter först under en skarp övning, inte under en verklig kris, vilket är precis varför tabletop-övningarna i steg tolv är så viktiga att faktiskt genomföra och inte skjuta upp.

Avancerade tips för mogna säkerhetsteam

När grundplanen sitter och ni klarat minst en tabletop-övning utan större hack, är det läge att höja ambitionsnivån. De här fem åtgärderna skiljer ett grundläggande NIS2-arbete från ett moget säkerhetsprogram:

Bygg en SBOM (Software Bill of Materials) för era kritiska system, så att ni snabbt kan avgöra om en ny leveranskedjeattack, som de som drabbat npm-paket under 2026, påverkar er miljö.
Integrera tidslinjescriptet från steg 6 direkt i ert incident-ärendesystem så att deadlines syns automatiskt på varje ärende, inte bara i en separat kanal.
Sätt upp en “krisportal” utanför er vanliga infrastruktur (till exempel ett separat molnkonto) där planen, kontaktlistor och mallar finns tillgängliga även om huvudmiljön är helt nedsläckt.
Koppla samman incidentseverity med er tröskelberäkning automatiskt, så att en SIEM-larm med hög allvarlighetsgrad direkt flaggar ärendet för NIS2-bedömning istället för att vänta på manuell triage.
Testa gränsöverskridande scenarier separat, om er organisation har verksamhet i flera EU-länder kan samma incident kräva anmälan till flera nationella myndigheter samtidigt.

Ingen av de här punkterna är obligatoriska för att klara lagens minimikrav, men de är precis det som skiljer ett team som klarar sin första riktiga incident smidigt från ett team som improviserar under press.

Så ser ett komplett NIS2-incidentprojekt ut på disk

Samla allt i en versionshanterad mapp så att hela teamet jobbar mot samma källa:

nis2-incidentplan/
├── README.md
├── kontaktlista.yaml
├── rollmatris.md
├── troskelvarden.md
├── mallar/
│   ├── tidig_varning.yaml
│   ├── anmalan_72h.md
│   └── slutrapport.md
├── runbooks/
│   ├── ransomware.md
│   ├── dataintrang.md
│   ├── ddos.md
│   ├── leveranskedja.md
│   └── insiderhot.md
├── script/
│   ├── tidslinje.py
│   └── samla_bevis.sh
└── ovningslogg/
    └── 2026-06-tabletop.md

Lägg mappen i en privat Git-repo med begränsad åtkomst, men se till att minst tre personer utanför IT-avdelningen (till exempel juridik och en i ledningsgruppen) har läsbehörighet. En plan som bara IT kan öppna hjälper inte när IT-avdelningen själv är den drabbade parten.

Skriv ett kort README i toppen av mappen som förklarar strukturen på ett par meningar, och länka till den från er interna wiki eller intranät så att den faktiskt går att hitta under stress. Uppdatera ovningslogg-mappen efter varje tabletop-övning med vad som fungerade och vad som behöver ändras, annars tenderar lärdomarna att försvinna mellan övningarna.

Med rollmatrisen, mallarna, runbooksen och automatiseringsscriptet på plats har ni täckt kärnan i vad cybersäkerhetslagen faktiskt kräver av er incidenthantering. Det som återstår är att göra planen till en vana snarare än ett dokument, genom att öva den regelbundet och uppdatera den varje gång verkligheten avviker från det ni skrev ner första gången.

Vanliga frågor om NIS2 och incidenthantering

Måste alla svenska företag följa NIS2?
Nej. Kravet gäller i huvudsak medelstora och stora organisationer inom de sektorer som räknas upp i cybersäkerhetslagen, samt vissa kritiska leverantörer oavsett storlek. Mindre företag som levererar kritiska tjänster till större omfattade organisationer kan ändå påverkas indirekt, eftersom kunderna ofta ställer motsvarande krav i sina avtal. Kontakta MSB om ni är osäkra på om ni omfattas.

Vad händer om vi missar 24-timmarsfristen?
Ni riskerar sanktionsavgift enligt Artikel 34, upp till 10 miljoner euro eller 2 procent av global omsättning för väsentliga entiteter, och 7 miljoner euro eller 1,4 procent för viktiga entiteter. I praktiken bedömer tillsynsmyndigheten också om ni agerat i god tro, hur allvarlig förseningen var och om ni ändå skickade en varning så snart det gick. En försenad men korrekt varning bedöms mildare än ingen varning alls.

Var skickar vi rapporten, till EU eller till en svensk myndighet?
Till Nationellt cybersäkerhetscenter i Sverige, som vidarebefordrar till rätt tillsynsmyndighet: MSB, PTS eller Finansinspektionen beroende på er sektor. Ni behöver alltså inte själva avgöra vilken EU-instans som ska kontaktas, den svenska kanalen sköter vidareförmedlingen, inklusive till andra medlemsstater om incidenten har gränsöverskridande påverkan.

Räknas en misslyckad phishing-attack som en betydande incident?
Vanligtvis inte, om den stoppades utan konsekvens. Men om phishingen ledde till kontokapning eller åtkomst till kritiska system kan den mycket väl vara betydande. Dokumentera bedömningen även när svaret är nej.

Kan vi återanvända vår GDPR-incidentplan för NIS2?
Delvis. Strukturen liknar varandra men tidsfrister, mottagare och innehållskrav skiljer sig. Bäst är att bygga NIS2-processen som ett parallellt spår som triggas samtidigt, inte som en ersättning. Låt samma triageringsmöte avgöra båda bedömningarna direkt, det sparar tid jämfört med att köra två separata processer efter varandra.

Hur ofta ska vi öva planen?
Minst två tabletop-övningar per år är vanlig branschpraxis, med en större övning som involverar ledningsgruppen ungefär vartannat år.

Behöver vi rapportera leverantörsincidenter, till exempel en komprometterad molntjänst vi använder?
Ja, om incidenten hos leverantören får betydande påverkan på er verksamhet. NIS2 lägger uttryckligt ansvar på er att bedöma och hantera risker i leveranskedjan, inte bara i er egen infrastruktur. Fallen med Nx Console och TanStack under 2026 är bra exempel på varför: skadan uppstod inte i er egen kod, utan i en beroende ni litade på, vilket inte gör er rapporteringsplikt mindre.

Vad är skillnaden mellan väsentlig och viktig verksamhetsutövare?
Klassificeringen styr både vilka krav som gäller och sanktionsnivån. Väsentliga entiteter (till exempel energi och finans) har högre sanktionstak, 10 miljoner euro eller 2 procent av omsättningen, medan viktiga entiteter har taket 7 miljoner euro eller 1,4 procent. Väsentliga entiteter kan även bli föremål för proaktiv tillsyn, medan viktiga entiteter i regel granskas reaktivt, till exempel efter en anmäld incident.

Vem inom organisationen bär det juridiska ansvaret om planen brister?
NIS2 lägger ett tydligt ansvar på ledningen, inte bara på säkerhetsavdelningen. Styrelsen och den verkställande ledningen ska godkänna riskhanteringsåtgärderna och kan hållas personligt ansvariga vid grov underlåtenhet, vilket är ett skäl till att incidentplanen bör vara känd och förankrad även utanför IT.

Kostar det något att rapportera till NCSC?
Nej, själva rapporteringen är kostnadsfri. Kostnaden ligger i förberedelsearbetet: att bygga planen, öva den och hålla den uppdaterad. Det är också den investeringen som avgör hur smidigt eller kaotiskt en verklig incident hanteras.

Relaterad läsning

Källor och vidare läsning: ENISA:s tekniska vägledning för NIS2, EU-kommissionens sida om NIS2 i Sverige, PTS om cybersäkerhetslagen, proposition 2025/26:28 om cybersäkerhetslagen, NCSC:s tidsplan för cybersäkerhetslagen och NIS2-direktivets Artikel 34 om sanktionsavgifter.

NIS2-incidentplan: 12 Steg, 3-5 Dagar [2026]