Cybersäkerhetslagen för dig som driftar plattformen

Sedan den 15 januari 2026 gäller cybersäkerhetslagen (2025:1506) i Sverige. Den genomför EU:s NIS2-direktiv och ersätter den äldre NIS-lagen. För dig som driftar Kubernetes, Linux och CI/CD handlar det inte om ännu en policy i en pärm. Det handlar om säkerhetsåtgärder du kan bevisa, incidentrutiner med klockan igång och leverantörskrav som landar i dina kontrakt.

Den här artikeln går igenom vad cybersäkerhetslagen betyder för dig som driftar plattformen: vilka paragrafer som faktiskt skapar arbete i teamet, vilka tidsfrister som gäller vid incidenter, vad du bör kunna visa som leverantör och en checklista att börja med.

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 du är osäker på om er verksamhet omfattas, ta hjälp av en jurist. De juridiska uppgifterna är kontrollerade den 12 oktober 2026.

Av Johan Kuylenstierna, VD Agency 42 · Senast granskad 12 oktober 2026

Lagen i korthet

Cybersäkerhetslag (2025:1506) utfärdades den 11 december 2025 och trädde i kraft den 15 januari 2026. Den genomför delvis direktiv (EU) 2022/2555 (NIS2) och upphäver lagen (2018:1174) om informationssäkerhet för samhällsviktiga och digitala tjänster.

Lagen kompletteras av cybersäkerhetsförordningen (2025:1507) (ändrad bland annat genom SFS 2026:623) och av föreskrifter. Föreskrifterna kan fortfarande heta MCFFS – Myndigheten för civilt försvars författningssamling – även efter att ansvaret flyttats till FRA och NCSC.

Tänk på lagen som brandskyddsregler för digital drift: det räcker inte att ha en brandsläckare någonstans i lokalen. Du ska kunna visa var den sitter, att folk kan använda den och att ni har övat.

Vem gör vad bland myndigheterna 2026

Rollerna har flyttats under året. Fel adressbok är vanligare än man tror.

Kort tidslinje:

• 15 januari 2026: cybersäkerhetslagen träder i kraft.
• 2 februari 2026: MCFFS 2026:1 (anmälan och identifiering) gäller.
• 1 juli 2026: cyberverksamheten från Myndigheten för civilt försvar samlas hos Nationellt cybersäkerhetscenter (NCSC) vid Försvarets radioanstalt (FRA). FRA blir gemensam kontaktpunkt och CSIRT-enhet och tar över föreskriftsrätten. Föreskrifter som fortfarande bär MCF:s namn gäller oförändrat.
• 1 oktober 2026: MCFFS 2026:11 (säkerhetsåtgärder och ledningens utbildning) träder i kraft.

FRA / NCSC är enligt förordningen gemensam kontaktpunkt (23 §) och CSIRT-enhet (31 §). Anmälningsskyldigheten enligt 2 kap. 2 § lagen går till den gemensamma kontaktpunkten. Incidentrapporteringen enligt 2 kap. 5–8 §§ går till CSIRT-enheten.

Tillsynsmyndigheter utses per sektor i förordningen 7 §. Exempel: Energimyndigheten för energi, Transportstyrelsen för transporter, Finansinspektionen för bank och finansmarknadsinfrastruktur, IVO och Läkemedelsverket inom hälso- och sjukvård. Din tillsynsmyndighet är alltså inte alltid samma som mottagaren av incidentrapporten.

Föreskrifter att känna till (översikt): MCFFS 2026:1 (anmälan/identifiering), MCFFS 2026:8 (incidentrapportering), MCFFS 2026:11 (säkerhetsåtgärder och ledningens utbildning, i kraft 1 oktober 2026) samt EU:s genomförandeförordning (EU) 2024/2690 (trösklar för bland annat DNS, moln, datacenter och MSP/MSSP). Det viktiga för plattformsteamet är att veta att de finns, vem som förvaltar dem nu och att de styr hur lagens paragrafer tolkas i praktiken.

Fem paragrafer som landar hos plattformsteamet

Jurister pratar om kapitel och paragrafer. Du pratar om kluster, pipelines och jour. Här är bryggan.

1. Säkerhetsåtgärder (2 kap. 3 §)

Ni ska vidta lämpliga och proportionella tekniska, driftsrelaterade och organisatoriska åtgärder som skyddar nätverks- och informationssystemen – och deras fysiska miljö – mot incidenter. Åtgärderna ska utgå från ett allriskperspektiv och åtminstone omfatta de tio punkterna i paragrafen, bland annat:

1. strategier för riskanalys och systemsäkerhet,
2. incidenthantering,
3. kontinuitet och krishantering,
4. säkerhet i leveranskedjan,
5. säkerhet vid förvärv, utveckling och underhåll,
6. uppföljning av att åtgärderna fungerar,
7. cyberhygien och utbildning,
8. kryptografi och vid behov kryptering,
9. personalsäkerhet, åtkomstkontroll och tillgångsförvaltning,
10. autentisering och säkrade kommunikationer vid behov.

För ett Kubernetes-team betyder det bland annat RBAC och minst privilege, nätverkspolicyer, signerade images, SBOM, sårbarhetsskanning, hemlighetshantering, patchrutiner, restore-övningar och audit-loggar som går att läsa – plus bevis. Vi beskriver hur vi arbetar med det under compliance.

2. Ledningens utbildning (2 kap. 4 §)

Personer i ledningen ska genomgå utbildning om säkerhetsåtgärderna. Det är inte "skicka en PDF till VD". Det betyder att någon måste kunna förklara tekniken uppåt på begriplig svenska: vad en privilege-escalation betyder för tjänsten, varför ett utgånget certifikat kan bli en betydande incident, och vad ni behöver för att klara 24-timmarsfristen.

Plattformsteamets jobb är översättning. Ledningen fattar besluten. AI kan sammanfatta loggar och risker, men en människa granskar och står för bedömningen.

3. Incidentrapportering (2 kap. 5–8 §§)

Vid en betydande incident gäller en kedja av rapporter. Klockan startar när ni får kännedom om incidenten. Mottagare är CSIRT-enheten (FRA), enligt förordningen 6 §. Detaljerna finns i nästa avsnitt.

4. Säkerhetsrevision och säkerhetsskanning (3 kap. 5–7 §§)

Tillsynsmyndigheten får göra regelbundna säkerhetsrevisioner av väsentliga verksamhetsutövare och, vid särskilda skäl, riktade revisioner. Den får också genomföra säkerhetsskanningar i samarbete med er.

Översatt: räkna med att någon utomstående kan be dig visa CIS-resultat, policyer, ändringshistorik och hur ni patchar. Bygg bevisen i vardagen, inte natten före revisionen.

5. Informera kunder (2 kap. 9–10 §§)

Om det är lämpligt ska ni informera mottagarna av era tjänster om en betydande incident som sannolikt påverkar tjänsten. Vid ett betydande cyberhot ska ni informera om skydds- och motåtgärder som mottagarna kan vidta – och om det är lämpligt om själva hotet.

Det kräver färdiga mallar, en namngiven avsändare och en kanal som fungerar även när chatten ligger nere.

Incidentrapportering i praktiken

En betydande incident är enligt 2 kap. 5 § en incident som har orsakat eller kan orsaka allvarlig driftsstörning för tjänsten eller ekonomisk skada för er, eller som har påverkat eller kan påverka andra genom betydande skada. Trösklar för vissa sektorer preciseras ytterligare i (EU) 2024/2690.

Tidslinje från kännedom:

Vad loggar och larm måste ge er inom det första dygnet:

• Vad hände, ungefär när, och i vilka system?
• Påverkas tillgänglighet, autenticitet, riktighet eller konfidentialitet?
• Vilka kunder eller tjänster kan vara drabbade?
• Vem beslutar att det är "betydande", och vem skickar rapporten?

Kan ni inte svara utan att ringa tre personer på semester har ni ett observabilitets- och jourproblem, inte bara ett rapporteringsproblem. Samma disciplin behövs när CRA:s rapporteringsplikt startar en parallell klocka.

En 42-blinkning: panik är aldrig en plan. En checklista är det närmaste man kommer en handduk när det brinner.

Leverantör till en NIS2-verksamhet?

Även om ni själva inte är verksamhetsutövare enligt lagen kan kraven nå er via avtal. Punkt 4 i 2 kap. 3 § handlar om säkerhet i leveranskedjan. Kunder som omfattas kommer att fråga vad ni gör med åtkomst, patchning, underhåll, incidenter och underleverantörer.

Som leverantör av plattform, drift eller IKT-tjänster bör ni kunna visa:

• hur åtkomst till kundmiljöer styrs och loggas,
• hur ändringar godkänns och spåras (GitOps, change records),
• hur ni patchar och härdar (CIS, STIG, OpenSCAP eller motsvarande),
• hur ni eskalerar och rapporterar incidenter mot avtalade tider,
• vilka underleverantörer som ingår i kedjan och hur ni följer upp dem,
• att ni kan bidra med underlag om kunden måste rapportera vidare till CSIRT.

Har ni produkter som omfattas av Cyber Resilience Act kan samma händelse sätta igång två klockor. Planera dem i samma rutin. Mer under compliance och DevOps/DevSecOps.

Checklista för plattformsteamet

1. Bestäm om ni är verksamhetsutövare – och i vilken sektor – tillsammans med juridik och ledning.
2. Anmäl er enligt 2 kap. 2 § och MCFFS 2026:1 om ni omfattas; håll uppgifterna uppdaterade (ändringar senast 14 dagar).
3. Kartlägg vilka system som bär tjänsten: kluster, CI/CD, register, DNS, identitet, backup.
4. Skriv (eller uppdatera) riskanalys och säkerhetsstrategi som speglar 2 kap. 3 § punkterna 1–10.
5. Sätt RBAC, nätverkspolicyer och hemlighetshantering så att minst privilege är standard, inte undantag.
6. Signera images, generera SBOM och skanna både i pipeline och det som redan är ute.
7. Aktivera och behåll API-server-audit och nod-/runtime-larm som går att söka i efterhand.
8. Öva restore och failover – ett oövat backupflöde räknas inte som kontinuitet.
9. Utse rapportansvarig med ersättare och behörighet att skicka till CSIRT; registrera konton i förväg.
10. Ha mallar för upplysning, anmälan, delrapport, slutrapport och kundinformation (2 kap. 9–10 §§).
11. Samla bevis löpande: skanningsresultat, ändringsloggar, utbildningsregister för ledningen, leverantörsuppföljning.
12. Kör en tabletop-övning per kvartal där klockan startar på riktigt – gärna en fredag.

Sammanfattning

• Cybersäkerhetslagen (2025:1506) gäller sedan 15 januari 2026, genomför NIS2 och ersätter 2018:1174.
• FRA/NCSC är gemensam kontaktpunkt och CSIRT sedan 1 juli 2026; tillsyn sker per sektor.
• För plattformsteamet landar arbetet framför allt i 2 kap. 3–10 §§ (åtgärder, utbildning, rapportering, kundinfo) och 3 kap. 5–7 §§ (revision och skanning).
• Incidentkedjan är 24 h → 72 h → delrapport på begäran → slutrapport inom en månad.
• Leverantörer träffas via leveranskedjekrav och avtal, även om de inte själva är verksamhetsutövare.
• Föreskrifter som MCFFS 2026:1 och MCFFS 2026:11 preciserar hur ni anmäler er och hur säkerhetsåtgärder och ledningsutbildning ska se ut.

Du ska prioritera det här nu om:

• ni omfattas – eller levererar till någon som omfattas – och saknar en övad 24-timmarsrutin,
• ni inte kan visa CIS-/policybevis utan att gräva i mejltrådar,
• ledningen inte har fått en begriplig genomgång av hur plattformen möter 2 kap. 3 §.

Vill du ha hjälp att översätta cybersäkerhetslagen till plattformsarbete?

Vi är Sveriges go-to-specialister på Kubernetes och hjälper till med härdning, DevSecOps, evidens inför tillsyn och drift i reglerade miljöer – bland annat med erfarenhet från plattformsdrift i försvarssektorn. Kontakta oss för offert eller ett första tekniskt samtal.

Läs mer på:

• Compliance: NIS2 och CRA
• DevOps och DevSecOps
• CRA:s rapporteringsplikt
• Kundcase
• Kontakta oss

Källor

Alla kontrollerade 2026-10-12.

1. Cybersäkerhetslag (2025:1506), utfärdad 2025-12-11, i kraft 2026-01-15. Särskilt 2 kap. 2–10 §§ och 3 kap. 5–7 §§ samt övergångsbestämmelserna. riksdagen.se
2. Cybersäkerhetsförordning (2025:1507), lydelse t.o.m. SFS 2026:623. Särskilt 5–7 §§, 23 § och 31 §. riksdagen.se
3. NCSC, "Det här är cybersäkerhetslagen" (i kraft 15 januari 2026; MCF → FRA/NCSC 1 juli 2026). ncsc.se
4. NCSC, föreskrifter enligt cybersäkerhetsförordningen (MCFFS 2026:1, 2026:8, 2026:11; föreskriftsrätt hos FRA från 2026-07-01). ncsc.se/sv/regler-och-foreskrifter
5. NCSC, MCFFS 2026:1 – anmälan och identifiering (gällande fr.o.m. 2026-02-02). ncsc.se
6. Direktiv (EU) 2022/2555 (NIS2). eur-lex.europa.eu
7. Kommissionens genomförandeförordning (EU) 2024/2690. eur-lex.europa.eu