NIS2 30-dagarschecklista

Cybersäkerhetslagen (NIS2): vad som krävs i praktiken

Cybersäkerhetslagen (som genomför NIS2) gör en sak tydlig: cybersäkerhet är en verksamhetsfråga. Det räcker sällan med en policy som “finns”, eller att IT “har koll”. Ni behöver styrning, prioriteringar och bevis på genomförande, plus förmåga att agera snabbt vid incident.

Den här 30-dagarsplanen är byggd för att snabbt ge kontroll: ni vet vad som är viktigast, vad som är gjort, vad som återstår och vem som äger vad. Upplägget ligger nära hur praktiska införandeguider strukturerar tekniskt genomförande och spårbar dokumentation, till exempel i teknisk implementeringsvägledning för NIS2.

Först: snabb scope-check (1, 2 timmar)

Om ni inte redan vet om ni omfattas, börja här. Skriv ner era svar och spara som beslutsunderlag. Poängen är inte att bli “juridiskt perfekt” dag 1, utan att skapa ett tydligt spårbart beslut och en ansvarig ägare.

Besvara frågorna nedan och formulera svaret i en sida med antaganden och nästa steg.

• Utpekad tjänst/sektor: Levererar vi en tjänst i en utpekad sektor eller i ett reglerat område, eller driver vi funktioner som andra betraktar som samhällskritiska?
• Storlek och roll: Är vi medelstora/stora enligt huvudlogiken i NIS2, eller kan vi omfattas oavsett storlek på grund av roll, funktion eller typ av tjänst?
• Kundkrav via leverantörskedjan: Är vi leverantör till en aktör som omfattas, och får vi redan NIS2-liknande krav i avtal/upphandling?
• Tillsyn och rapportering: Vem är vår troliga tillsynsmyndighet, och var skulle vi rapportera incidenter? För incidentrapportering i svensk kontext kan ni jämföra med hur processen beskrivs hos incidentrapportering enligt Cybersäkerhetslagen.

Leverans (senast dag 2): En sida “Omfattas/omfattas troligen/omfattas inte (än)” med motivering, antaganden och en namngiven ansvarig för fortsatt arbete.

30-dagarschecklista: veckomål och bevismapp

Kör punkterna i ordning och låt varje aktivitet sluta i en konkret leverans. Då bygger ni en “bevismapp” som är lätt att visa för ledning, kunder och tillsyn, och lätt att uppdatera utan att börja om.

Vecka 1 (dag 1, 7): Styrning, ägarskap och lägesbild

Syfte: Få ledningen i förarsätet och skapa en gemensam bild av vad som är viktigast. Ledningsansvar och mandat är ett återkommande tema i svenska sammanfattningar av lagen, till exempel i genomgången om att företagsledningar blir ansvariga.

• Utse ansvar: Sätt en ledningsägare (verksamhet) och en operativ ägare (t.ex. IT-/säkerhetsansvarig) med tydligt mandat.
• Bestäm beslutsvägar: Definiera vad som måste upp i ledning/styrelse och vad som kan delegeras, så ni slipper ad hoc-beslut i skarpt läge.
• Identifiera “kronjuvelerna”: Lista 5, 10 mest affärskritiska tjänster/system, inklusive systemägare och viktiga beroenden.
• Sätt en enkel riskram: Välj en tydlig skala för sannolikhet/konsekvens och definiera vad ni betraktar som “oacceptabel risk”.
• Planera ledningsutbildning: Lägg ett kort återkommande format (t.ex. 45, 60 minuter) med fokus på ansvar, prioriteringar, uppföljning och incidentbeslut.

Leveranser vecka 1: (1) Beslutsanteckning med roller, mandat och mötesstruktur. (2) Kronjuvel-lista med ägare och beroenden. (3) Riskdefinition och uppföljningscadens (t.ex. månadsvis i början).

Vecka 2 (dag 8, 14): Basnivå som stoppar vardagsincidenter

Syfte: Täta vanliga hål och skapa en bevisbar lägstanivå. Fokusera på kontroller som går att verifiera med loggar, inställningar och rapporter.

• Konton & åtkomst: Säkerställ MFA för e-post, fjärråtkomst och admin. Rensa gamla konton och separera admin-konton från vanliga användarkonton.
• Patch & sårbarhet: Sätt ägare, tidsmål och en rutin för undantag, så att ni alltid kan svara på “vad är patchat, och vad är undantaget?”
• Backuper: Säkerställ skyddade backuper (t.ex. offline/immutabelt där det är möjligt) och gör minst ett restore-test på en prioriterad tjänst.
• Loggning: Bekräfta loggar för identitet, admin-händelser och kritiska system. Bestäm vem som granskar och hur ofta.
• E-postskydd: Skärp skydd mot nätfiske med praktiska åtgärder (t.ex. varningsmarkeringar, rapportknapp och riktad utbildning kopplad till era hot).

Leveranser vecka 2: (1) Underlag som visar MFA-täckning och adminprinciper. (2) Patchrutin (1 sida) och första statusrapport. (3) Backup/restore-protokoll från genomfört test. (4) Logglista: vad ni samlar, hur ni granskar och hur avvikelser eskaleras.

Vecka 3 (dag 15, 21): Leverantörer och beroenden

Syfte: Få kontroll på tredjepartsrisk utan att fastna i pappersarbete. Leverantörsåtkomster och krav på riskåtgärder återkommer i tolkningar av NIS2:s riskhanteringsåtgärder, till exempel i förklaring av riskhanteringsåtgärder (artikel 21).

• Lista kritiska leverantörer: Koppla varje “kronjuvel” till de leverantörer den beror på (moln, drift, MSP, kritiska SaaS, integrationer).
• Säkra kontaktvägar: Dokumentera teknisk jour, eskalering och vem hos er som får fatta beslut (inklusive efter kontorstid).
• Kravbild “light”: Börja med incidentkontakt, notifieringskrav, spårbarhet/loggar, återställning samt transparens kring underleverantörer.
• Spåra adminåtkomster: Ta fram vilka leverantörer som har adminåtkomst och kontrollera att åtkomsten är MFA-säkrad, loggad och helst tidsbegränsad.

Leveranser vecka 3: (1) Register över toppleverantörer (ett kalkylark räcker). (2) En sida standardfrågor/krav att återanvända i avtal och inköp. (3) Lista över externa adminåtkomster med en snabb åtgärdsplan.

Vecka 4 (dag 22, 30): Incidentrapportering som fungerar under stress

Syfte: Göra det möjligt att rapportera snabbt även när ni inte vet allt. Praktiskt innebär det en process i flera lägen och korta mallar. Innehåll som ofta efterfrågas i incidentrapportering sammanfattas tydligt i krav på innehåll vid NIS2-rapportering.

Tänk i tre lägen: (1) tidig varning (osäker information), (2) fördjupning (mer fakta), (3) slutrapport/lägesrapport (orsak och lärdomar).

• Definiera “betydande incident”: Skriv en enkel definition för er miljö med 3, 5 konkreta exempel som alla kan förstå.
• Incidentrutin på 1 sida: Roller, kontaktlista, beslutspunkter och kommunikationskanaler (inklusive hur ni jobbar om e-post/Teams ligger nere).
• Tre rapportmallar: Skapa en mall för tidig varning, en för fördjupning och en för slutrapport/lägesrapport. Håll dem korta, så de blir använda.
• 60-minuters tabletop-övning: Kör ett scenario och ta tid: när kan ni fatta rapportbeslut, hur snabbt får ni fram minsta info-paket och vilka fakta saknas (loggar, ägarskap, kontaktvägar)?

Leveranser vecka 4: (1) Incidentrutin (1 sida) och uppdaterad kontaktlista. (2) Tre rapportmallar. (3) Övningsprotokoll: vad som fungerade, vad som saknades och vad ni åtgärdar härnäst.

Minimipaket efter 30 dagar (snabb sammanfattning)

Det här är ingen extra plan, utan en sammanfattning av vad som bör finnas på plats när månaden är slut. Om ni dessutom får NIS2-krav via kunder/upphandling hjälper detta er att svara på “hur ser er basnivå ut?” utan att fastna i sektorlistor, vilket ofta lyfts i praktiska svenska genomgångar som översikter om den nya cybersäkerhetslagen.

• Styrning: Roller, mandat, mötesstruktur och plan för ledningsutbildning.
• Kronjuveler: Lista över kritiska tjänster med ägare och beroenden.
• Åtkomst: MFA på kritiska ytor, kontroll på admin och rensning av konton.
• Patch/sårbarhet: Process och första uppföljningen.
• Backuper: Skydd samt minst ett restore-test.
• Loggar: Vad som samlas, vem som granskar och hur avvikelser eskaleras.
• Leverantörer: Topplista, kontaktvägar och grundkrav.
• Incident: Definition, 1-sidesrutin, mallar och genomförd övning.

Vanliga missförstånd som sinkar arbetet

Många fastnar inte på teknik, utan på otydlighet. Därför hjälper det att avdramatisera tre vanliga stoppklossar.

1) “Vi måste veta säkert innan vi agerar eller rapporterar.”
Bygg för att kunna agera med ofullständig information. Dokumentera beslut, gör en tidig bedömning och uppdatera när ni vet mer.

2) “Det här är IT:s bord.”
IT gör mycket av jobbet, men utan ledningens prioritering, mandat och uppföljning blir det punktinsatser. Lägg därför risker och status på ledningens agenda.

3) “Vi har policyer, då är vi klara.”
I praktiken frågar man ofta efter genomförande: MFA-täckning, patchstatus, restore-test, logggranskning, leverantörskontakter och övningsprotokoll.

FAQ

Frågor och svar

Gäller Cybersäkerhetslagen (NIS2) även oss om vi inte är “en klassisk NIS2-sektor”?

Det kan den göra indirekt. Många svenska företag får krav via kunder, upphandlingar och leverantörsvillkor även om de inte är säkra på formell omfattning. Därför är en dokumenterad scope-check och ett minimipaket av kontroller ofta en bra start oavsett.

Vad är viktigast att kunna visa upp efter 30 dagar?

Fokusera på spårbarhet: beslut om ansvar och mandat, lista över kronjuveler, verifierbara skydd (t.ex. MFA och restore-test), leverantörsregister och en testad incidentrutin med mallar och övningsprotokoll. Det gör ert arbete begripligt och uppföljningsbart.

Måste vi ha ett “perfekt” incidentflöde innan vi övar?

Nej. Tvärtom brukar en kort tabletop-övning snabbt visa vilka kontaktvägar, loggar och beslutsvägar som saknas. Ni får då en konkret förbättringslista istället för en teoretisk plan.

Nästa steg: gör det enkelt att komma igång

Vill ni få en snabb, praktisk start utan att överarbeta juridik eller dokument? Advisera kan hjälpa er att göra scope-checken, prioritera åtgärderna och sätta en “bevismapp” som håller för ledning, kunder och tillsyn.

Boka en kort rådgivning där vi går igenom ert nuläge och pekar ut 5, 10 åtgärder som ger mest riskminskning på 30 dagar.