Säkerhetsåtgärder, cybersäkerhetslagen & MCFFS 2026:11

Den här sidan går igenom de tio säkerhetsåtgärderna i cybersäkerhetslagen, sorterade så att de går att arbeta med. Vill du läsa om lagen i stort, vem som omfattas, tillsyn, sanktioner, finns cybersäkerhetslagen och NIS2.

Lagen räknar upp tio åtgärder utan inbördes ordning. Föreskriften sorterar dem på ett helt annat sätt, i organisatoriska, tekniska och fysiska, och kopplar aldrig tillbaka till lagens punkter. Tabellen nedan gör den kopplingen.

Sista kolumnen är min egen sortering. Den finns för att tio åtgärder utan ordning är svåra att arbeta med, och för att ingen av de två officiella indelningarna ger en ingång som en ledningsgrupp känner igen. Fyra teman räcker:

Styrande är det som ska beslutas och dokumenteras. Policys, riskhantering, kryptografi, åtkomstregler. Ledningens bord.

Värdekedjan är det som kommer utifrån. Leverantörer, förvärv, utveckling, underhåll. Det ni inte gör själva men ändå svarar för.

Personal och miljö är det som ska skyddas fysiskt. Människorna och lokalerna.

Incidenter är det som ska hanteras när något ändå går fel. Incidenthantering, kontinuitet, kris.

Och så ett femte som inte kommer ur lagen alls. Se sista raden.

Notera sista raden. Segmentering, logganalys, robust tid och intrångsskydd har ingen egen punkt bland lagens tio. De är teknisk drift, och den nivån uppstår först när föreskriften ska säga hur kraven uppfylls. Det är där det femte temat föds.

Observera också att sambandet går åt båda håll. Flera paragrafer bidrar till samma lagkrav, och samma paragraf kan bidra till flera. Därför behövs en mappning och inte bara en innehållsförteckning.

MCFFS 2026:11 kapitel 3, 19 paragrafer. Det här är styrningen: hur ni leder arbetet, vem som ansvarar för vad och hur ni vet om det fungerar.

Systematiskt och riskbaserat arbete, 3 kap. 1–3 §§

Föreskriften kräver ett systematiskt och riskbaserat cybersäkerhetsarbete utifrån ett allriskperspektiv, integrerat med hur ni redan leder organisationen.

Allriskansatsen tar hänsyn till alla risker i en given kontext. Vem står i centrum — måsen, viggen eller kraftledningen? Vad händer när planet kör in i ledningen?

I cybersäkerhet skyddas systemen mot stöld, brand, systemfel och mänskliga misstag, allt som kan störa en samhällsviktig tjänsts funktion. Er affärsmodell är kontexten, och det är cyberriskerna mot den affären som ska analyseras.

Så gör du en riskanalys

Roller och ansvar, 3 kap. 4–8 §§

Tre roller är obligatoriska: samordnare, informationsägare och systemägare. All informationsbehandling ska ha en informationsägare och alla system en systemägare.

Ledningen ska godkänna och övervaka genomförandet, och ska informeras om nivån på cybersäkerheten vid behov men minst en gång per år.

Det här är en nationell konstruktion. EU:s genomförandeförordning kräver funktionell ansvarsfördelning men inte namngivna roller. Har ni globala styrdokument behöver de kompletteras.

Personalsäkerhet, 3 kap. 9 §

All personal, inklusive inhyrd, ska kontrolleras vid rekrytering och vid förändrad åtkomst. Ni ska också fastställa vilka utbildningar och övningar som ska genomföras före och under anställningen.

Målet är att minska risken genom att alla bidrar. Bara pålitlig personal ska se känslig information, och alla ska förstå varför.

För er i ledningen är det här bekant. Men ni ska forma en säkerhetskultur där säkerhet är allas angelägenhet — den kultur som finns i flyget.

Omvärldsbevakning, 3 kap. 10 §

Ny i förhållande till tidigare svensk reglering. Ni ska inhämta information från era hård- och mjukvaruleverantörer och från NCSC vid FRA, och ansluta er till automatiska notifieringar av tekniska sårbarheter, ANTS, om det inte är uppenbart obehövligt.

Informationsklassning och riskhantering, 3 kap. 11–13 §§

Informationen ska värderas utifrån behov av skydd för konfidentialitet, riktighet och tillgänglighet. Ni ska fastställa antalet nivåer och kriterierna.

Riskerna ska identifieras, analyseras och värderas, och ni ska fastställa kriterier för riskacceptans. Valda åtgärder dokumenteras i en åtgärdsplan med ansvarig roll och tidpunkt.

Kontinuitet, incidenter och kris, 3 kap. 14–18 §§

Ni ska på förhand fastställa acceptabla tider för otillgänglighet och bristande funktionalitet, och en prioriteringsordning för återställning.

I flygexemplet ligger fokus inte på flygplanet utan på att 250 passagerare ska från A till B. Precis som jag har en checklista för motorstopp har flygbolaget en plan för hotell, mat och transport.

Incidenter ska kunna identifieras, anmälas, analyseras och begränsas — och återställningen ska följa prioriteringsordningen. Jag kan fortfarande motorstopp efter start utantill, för att det är övat.

Uppföljning, 3 kap. 19 §

Säkerhetsåtgärderna ska följas upp och utvärderas. För sektorskritiska system minst en gång per år.

Hur ska ledningen kunna ta ansvar för cybersäkerheten utan att veta om åtgärderna fungerar?

Om internrevision och ISO 27001 kapitel 9

MCFFS 2026:11 kapitel 4, 31 paragrafer. Det största kapitlet, större än de andra tillsammans.

Leveranskedjan, 4 kap. 1–4 §§

När ledningsgruppen kliver ombord på ett flygplan på Arlanda förutsätter ni att allt är säkert — planet från en tillverkare, motorerna från en annan.

Säkerhet i leveranskedjan är samma sak. Leverantörerna ska ha cybersäkra tjänster och ni ska ha cybersäkra integrationer mot dem.

Kraven löser ni genom avtal och uppföljning. I avtalet behöver det finnas krav ni kan verifiera, och villkor som reglerar vem som bär kostnaden om leverantören brister.

Viktigt om befintliga avtal: ni ska identifiera och hantera behovet av att komplettera avtal som ingåtts före den 1 oktober 2026 med krav på cybersäkerhet.

Utveckling, underhåll och avveckling, 4 kap. 5–7 §§

Säkerhet i utveckling är en självklarhet inom flyg, järnväg, fordon och medicinteknik. Där finns standarder som oftast grundar sig på IEC 61508.

Säker utveckling — safety och security by design — bygger in säkerheten i arbetet, genom hela systemets livscykel.

Innan ett system driftsätts första gången ska ni säkerställa dokumentation, genomförda säkerhetstester, tillräckliga resurser och att identifierade behov av säkerhetsåtgärder är omhändertagna.

Safety och security by design

Dokumentation och tillgångshantering, 4 kap. 8–10 §§

En IT-tillgång är förenklat hårdvara, mjukvara eller information. Tillgångshantering är att säkerställa att de registreras, används, underhålls och uppgraderas rätt.

För mig som pilot är det enkelt: viss information är hemlig, exempelvis flygplanets prestanda. Den kvitteras ut när jag börjar, används i arbetet, rättas vid ändringar och lämnas in när jag slutar.

Föreskriften kräver uppdaterad dokumentation över arkitekturen, en förteckning över den digitala miljön, och driftdokumentation per system. Ni ska också fastställa vilka system som är sektorskritiska.

Segmentering, 4 kap. 11–13 §§

Produktionsmiljön ska delas in i segment, och bara godkända informationsflöden ska tillåtas till och från dem.

Utveckling, test och utbildning som kan påverka säkerheten i it-segmentet ska bedrivas i en avskild miljö. För ot-segmentet är det en behovsbedömning.

Behörighet och autentisering, 4 kap. 14–19 §§

Flerfaktorsautentisering krävs för åtkomst till system i it-segment som behandlar information med behov av utökat skydd, för systemadministrativ åtkomst till både it- och ot-segment, och för åtkomst till den digitala miljön via externt nätverk.

Autentiseringsuppgifter från produktionsmiljön får inte användas i utvecklings-, test- eller utbildningsmiljö.

Vi är vana vid att få kvitto från banken direkt efter ett köp. Mycket sådan kommunikation är nödvändig för att samhällsviktiga funktioner ska fungera.

Övervakning och loggning, 4 kap. 20–23 §§

Relevanta säkerhetshändelser ska loggas, och obehörig åtkomst samt försök därtill ska alltid loggas. Loggarna ska skyddas och analyseras.

Tiden ska vara robust och korrekt och översättningsbar till UTC (SP), så att loggar går att jämföra vid incidenter som berör flera organisationer.

Kryptering, 4 kap. 24–26 §§

Kryptering gör information svårläslig för alla som inte ska kunna läsa den. Att läcka information oavsiktligt skadar kundförtroende och affärer.

Föreskriften kräver att ni identifierar och hanterar behovet av kryptering i den digitala miljön. Hårt krav gäller för säkerhetsloggar och autentiseringsuppgifter vid överföring, och för information med behov av utökat skydd när den lämnar miljön.

DNSSEC ska användas för era registrerade domännamn om det inte är uppenbart obehövligt.

Tester, säkerhetskopiering och uppdateringar, 4 kap. 27–31 §§

Säkerhetstester ska kontrollera att systemen är uppdaterade, att publicerade sårbarheter är omhändertagna och att konfigurationerna är införda.

Informationen ska kunna återställas inom de fastställda acceptabla tiderna. Minst en säkerhetskopia bör ligga på hårdvara separerad från källsystemet.

Säkerhetsuppdateringar i it-segment ska genomföras skyndsamt. Allmänna råd anger att arbetet bör påbörjas inom 72 timmar från att skyddet blivit tillgängligt.

MCFFS 2026:11 kapitel 5.

Noaks datahall skyddar miljön för era tjänster. Systemen ska skyddas mot fysiska hot: tillträdesbegränsning, bevakning och larm, samt skydd mot brand, vattenskador och skadliga nivåer av luftfuktighet och temperatur.

Försörjningssystemen ska ha tillräcklig funktionalitet, el, kyla, värme, ventilation och externa kommunikationsnät. Naturhändelser som skogsbrand eller översvämning hör hit.

Med det skapar ni kontinuitet och minskar skadekostnaderna. Kunder och intäkter säkras.

Föreskriften gäller från den 1 oktober 2026.

Utgå från de hårda kraven. Gå igenom föreskriften och sortera paragraferna i de två styrkegraderna. De hårda är minimum.

Inventera avtalen. Avtal ingångna före den 1 oktober 2026 ska prövas mot behovet av kompletterande cybersäkerhetskrav.

Utse rollerna. Samordnare, informationsägare och systemägare. Utan dem faller flera andra krav.

Dokumentera behovsbedömningarna. Även de ni landar i att inte införa något.

Kontrollera om ni är undantagna. Bedriver ni uteslutande verksamhet inom de fem PTS-sektorerna gäller bara ledningens utbildning.

Bedriver ni blandad verksamhet kan båda gälla, var och en för sin del. Hur ni än gör så är Ensions process för safety & security by design ett sätt att följa reglerna

Behöver ni hjälp att gå från lagtext till en prioriterad åtgärdsplan? Jag arbetar som säkerhetsexpert med kravanalys och säkerhetsarkitektur. Hör av dig.