Cybersäkerhetslagens syfte är att uppnå en hög nivå av cybersäkerhet i samhället, 1 kap. 1 §.

Enssion har tagit fram ett whitepaper för hur du i sju punkter efterlever lagen:

1. Utbilda ledningen i cybersäkerhet
2. Identifiera system som är eller kan påverka samhällsviktiga tjänster
3. Analysera risker för att hitta var det behövs säkerhetsåtgärder
4. Starta en förbättringsprocess, en säkerhetsplan
5. Skapa rutiner för att rapportera incidenter

Kontkta Ension så översänder vi ett whitepaper för hur du gör.

NIS2-direktivet är den uppdaterade versionen av det ursprungliga NIS-direktivet, Europeiska unionens första cybersäkerhetsförordning. NIS2 är utformat för att täppa till tidigare luckor och säkerställa konsekvent implementering i alla EU-medlemsstater, och utökar avsevärt omfattningen av cybersäkerhetsefterlevnaden.

NIS2-direktivet introducerar en harmoniserad uppsättning av cybersäkerhetskrav inom EU. Det innebär striktare regler för incidentrapportering, genomför ansvar på ledningsnivå och fastställer påföljder för bristande efterlevnad. Viktiga funktioner inkluderar:

• Obligatoriska riskbedömningar och implementering av säkerhetsåtgärder
• Tydliga ansvar för verkställande ledning
• Obligatorisk cybersäkerhetsutbildning och löpande riskhantering
• Ett samordnat EU-omfattande ramverk för sårbarhets- och hotdelning

Till skillnad från tekniska standarder fokuserar NIS2 på bästa praxis och styrningsprinciper snarare än att föreskriva specifika teknologier.

En av de viktigaste förändringarna i NIS2 är det utökade tillämpningsområdet. NIS1 fokuserade främst på kritiska infrastruktursektorer, men NIS2 breddade detta till att omfatta fler enheter. Denna förändring återspeglar sammankopplingarna mellan olika sektorer.

Genom att utöka täckningen eliminerar NIS2 svaga länkar orsakade av organisationer som tidigare var undantagna. Med betydligt fler organisationer som nu måste följa robusta cybersäkerhetsstandarder, förbättras den övergripande motståndskraften hos EU:s digitala infrastruktur avsevärt.

NIS1 riktade sig i första hand till operatörer av samhällsviktiga tjänster (OES) inom kritiska sektorer som energi, transport, vatten, bankverksamhet, infrastrukturer för finansmarknader, hälsa och digital infrastruktur. Dessutom omfattade det vissa leverantörer av digitala tjänster (DSP), såsom online-marknadsplatser, online-sökmotorer och molntjänster.

NIS2 utökar betydligt omfattningen av täckningen till att inkludera ett bredare spektrum av sektorer och enheter. Denna utvidgning erkänner den ökande sammankopplingen och digitaliseringen av olika branscher. En detaljerad lista över organisationer som måste följa de regler som anges i NIS2 finns nedan.

Övergången från NIS1 till NIS2 innebar flera betydande förändringar när det gäller de organisationer som omfattas av direktivet. Dessa förändringar speglar det föränderliga cyberhotlandskapet och behovet av ett mer omfattande tillvägagångssätt för cybersäkerhet i EU:s medlemsstater.

Med NIS2 ökar ledningens ansvar och ansvarsskyldighet. Genom detta lyfter NIS2 cybersäkerhet och cyberresiliens till den verkställande nivån och ökar integrationen i den grundläggande bolagsstyrningen.

Denna starkare betoning på ledningens ansvar innebär att organisationernas ledningsgrupper blir mer fullt involverade i och ansvariga för cybersäkerhetsstyrning. Detta inkluderar att övervaka implementeringen av säkerhetsåtgärder och säkerställa efterlevnad av direktivet.

Under NIS1 upplevdes krav för incidentrapportering av många som tvetydiga och inkonsekventa i EU:s medlemsstater. NIS2 syftade till att standardisera och effektivisera dessa krav, vilket gjorde dem mer precisa och konsekventa.

Till exempel, under NIS2 måste organisationer rapportera betydande incidenter till relevanta nationella myndigheter inom en specifik tidsram, vilket säkerställer snabba och effektiva åtgärder. Dessutom betonar NIS2 vikten av informationsdelning mellan EU:s medlemsstater och med EU:s cybersäkerhetsbyrå (ENISA). Detta samarbete underlättar snabb spridning av hotinformation och möjliggör en mer koordinerad respons på gränsöverskridande cyberhot.

Med NIS2 spelar tid en avgörande roll i responsen på attacker. Till skillnad från NIS1, som tillät mer skönsmässighet gällande rapporteringstidslinjer, fastställer det nya direktivet att cyberincidenter måste rapporteras till de behöriga myndigheterna inom 24 timmar. Därefter krävs följande:

• Uppdateringar inom 72 timmar;
• En slutgiltig incidenthanteringsrapport inom en månad.

Denna nya struktur är utformad för att säkerställa en mer aktuell och effektiv incidenthantering, vilket minimerar potentiella skador.

NIS2 föreskriver striktare riskhanteringsåtgärder jämfört med NIS1. Enligt NIS2 måste organisationer implementera omfattande cybersäkerhetspolicyer och -procedurer som är anpassade till deras specifika riskprofiler. Det kräver också att dessa riskhanteringsåtgärder är proportionerliga i förhållande till de faktiska risker som organisationen står inför. Detta är avsett att säkerställa att organisationer implementerar de säkerhetskontroller som är lämpliga för deras specifika profil och att de har förmågan att skala för att möta framtida krav.

Cybersäkerhetslagen ska göra samhället motståndskraftigt mot cyberhot. Samhällsviktiga tjänster alltid fungerar. Lagen kräver att ni bidrar med er del. Er verksamhet ska vara cybersäker, lika självklart som luftvärdiga flygplan.

Syftet med cybersäkerhetslagen (CSL) är att uppnå en hög nivå av cybersäkerhet i samhället. Idag är vi för sårbara, det visar en analys av vård och energi. För dig är lagen rätt använd steget mot affärsdriven säkerhet. Denna säkerhet bygger på att ni säkrar er affärsmodell och affärsdrivna arkitektur. Ledningens ansvar i NIS2 är tydligt: Cybersäkerhetslagen kan innebära betydande sanktionsavgifter och ledningsförbud. Här hittar du NIS2 checklista för er ledningsgrupp

Cybersäkerhetslagen / NIS2 är en strategisk möjlighet. Lagen ska säkerställa samhällsviktiga tjänsters funktion. För er skapar cybersäkerhetslagen fokus på att leverera era tjänster, affärsdriven säkerhet. För er innebär lagen:

• Ledningen ansvarar för säkerhetsåtgärder
• Incidenthantering & rapportering.
• Säker utveckling och leveranskedja. 

Cybersäkerhetslagen / NIS2 innebär inget alternativ. Noncompliance finns inte. Så bli en vinnare, investera i  digital resiliens och operativ motståndskraft.

Den här artikeln vänder sig till chefer och ledare som direkt eller indirekt levererar samhällsviktiga tjänster.  Syftet är att du ska förstå kraven i cybersäkerhetslagen.

Innan ni påbörjar arbetet tar ni reda på om ni träffas ni av cybersäkerhetslagen? Gör ni det ska du fortsätta läsa.

Sedan presenterar jag"Fem steg för efterlevnad av lagen", en process för efterlevnad av cybersäkerhetslagen.

Processens första steg "Utbilda ledningen i säkerhetsåtg" finns eftersom ni i ledningen är skyldiga att utbilda er i just dessa säkerhetsåtgärder. I "Säkerhetsåtgärder, lednings kunskap" beskrivs kortfattat åtgärderna.

Misslyckas ni riskerar ni NIS2 sanktionsavgifter.

Första frågan ni ställer er, omfattar cybersäkerhetslagen oss? Ension har förenklat det till tre frågor ett flöde: Träffas du oberoende av storlek? Är du aktiv i en sektor enligt Bilaga I eller Bilaga II? Är du stor nog för att träffas? Om ni träffas, registrera er på MCF anmälningsportal. .

Normalt omfattas inte små företag. Indirekt kan dock de ändå behöva anpassa verksamheten då de som träffas kan behöva ställa krav på sina underleverantörer.

EU regler är en pyramid: NIS2 är lagen, genomförande-förordningen detaljerade regler och  ENISA vägledning en guide som klargör reglerna. Ett exemplel:

NIS2 kräver ”användning av flerfaktorautentisering”. Genomförandeförordning anger att användare flerfaktor-autentiseras i enlighet med [risk-]klassificeringen av den tillgång som ska nås”. Vägledningen utvecklar i att fler-faktorautentisering bör tillämpas på internetexponerade system, efterlevnad visas genom konfigurationsloggar.

Vägledningen kopplar även ENISA:s förväntningar mot internationella standarder, såsom ISO/IEC 27001.

Sverige har en annan struktur på regelverken än EU. Det startar med en Cybersäkerhetslag (2025:1506), fastställd av riksdagen. Därefter kommer Cybersäkerhetsförordning (2025:1507) som regeringen fastställer. Längst ner i de bindande reglerna kommer föreskrifterna som en myndighet fastställer.

Cybersäkerhetslagen och förordningen är på plats, och lagen gäller sedan den 15 januari 2026. Nu är även föreskrifterna om säkerhetsåtgärder och utbildning, MCFFS 2026:11, på plats och träder i kraft 1 oktober. Vägledning väntas vid årsskiftet.

I remissförslaget blev reglerna hårdare, mer detaljerade och kostnadsdrivande. Kravet på flerfaktorsautentisering formulerades som att det skulle gälla vid åtkomst till system som behandlar information som vid informationsklassning bedömts ha behov av utökat skydd. I en OT-miljö kan ett sådant krav sänka säkerheten i stället för att höja den, eftersom generell MFA i ett kontrollrum fördröjer det ingripande som ska rädda situationen.

Det påpekade jag i remissvaret. I den beslutade föreskriften gäller kravet bara it-segment, plus systemadministrativ åtkomst och åtkomst via externt nätverk. OT-invändningen gick fram.

Samma sak hände med kravet på fysiskt åtskilda sektioner för redundanta system, som är struket, och med kravet på obligatorisk sårbarhetsrapportering, som blev ett allmänt råd.

NIS2-direktivets bilaga 1 och 2 definierar de sektorer som omfattas av cybersäkerhetslagen.

NIS2 bilaga I definierar högkritiska sektorer. En högkritisk verksamhetsutövare kan vara Väsentlig eller Viktig beroende på årsomsättningen och storleken på företaget.

NIS2 Bilaga 2 definierar andra kritiska sektorer som omfattas av cybersäkerhetslagen.

Om ni träffas ska ni i ledningen säkra att följande. genomförs:

1. Utbilda ledningen i cybersäkerhet
2. Hitta system påverkande samhällsviktiga tjänster
3. Led genom policys
4. Starta en förbättringsprocess, en säkerhetsplan
5. Rutiner för att rapportera incidenter

Lagens krav gäller hela verksamheten, men punkt 3 avgränsar med en riskanalys vilka system som omfattas.

Cybersäkerhetslagen kräver att din affärsmodells tjänster är cybersäkra. Affärsmodellen ska klara sig i cyberspace mot cyberangrepp. Om du skapar värde för dig, dina kunder och dina partners trots angrepp från cyberspace blir du starkare. En operativ motståndskraft skapas.

Cyberattacker inriktas på att se till att din verksamhet och samhället skadas. Detta görs genom att komma åt, ändra eller förstöra information.

Cyberattacken är ett skott mitt i hjärtat på affärsmodellen. Affärsmodellen är bra att utgå ifrån för att klara lagen.

Ledningen är ansvarig för cybersäkerhet, ledningsförbud är möjligt. För att kunna axla det ansvaret behöver ni i ledningen kompetens för att kunna godkänna och övervaka genomförandet av säkerhetsåtgärderna. Därför finns ett krav i cybersäkerhetslagen på att ledningen ska genomgå en utbildning om säkerhetsåtgärder.

Cybersäkerhetslagen

Utbildningen av ledningen i säkerhetsåtgärder ger er kompetens att följa cybersäkerhetslagen. Ni levererar en säker intäkt och ett högt kundförtroende. Det blir bättre strategiska beslut och bättre riskhantering som skyddar intäkter och varumärke. Ni får även förmågan att skapa den proaktiva säkerhetskultur som krävs för att bygga en rubust organisation.

Verksamhetens sammanhang, kontext, är grunden för säkerhet. Det är i affärsmodellen ni hittar era tjänster och i kontexten kan bedöma vilka som är samhällsviktiga:

Ett flygplan som används för att flyga har ett annat sammanhang och andra risker än när det används som hotell.

En kontextanalys ger er en kunskap om hoten mot er affärsmodell och ert erbjudande grunden för förbättring.

I cybersäkerhetslagens säkerhetsåtgärder finns krav på sex policys. Med dessa styr ni med riktlinjer säkerheten.

Ni i ledningen ska fokusera på den övergripande säkerhetspolicyn. Kontextanalysen är tillräcklig för att ta fram denna. En smart skriven policy driver innovation kring säkra tjänster och effektiva processer.

Policyn kan även skapa den säkerhetskultur som fokuserar på affärsnytta och affärsdriven säkerhet.

Nu ska affärsdriven säkerhet levereras. Gör det inte i ett jätteprojekt utan ett kontinuerligt förbättringsarbete.

Ni ska leverera en säker intäkt och ett högt kundförtroende, att affärsmodellen levererar. 

Metoden är att hitta och prioritera säkerhetsåtgärder och iterativt införa dem. Stödet är ett kontinuerligt förbättringsarbete där internrevisioner styr de kontinuerliga förbättringarna. Affärsdriven säkerhet. 

Cybersäkerhetslagen inför ett strikt rapporteringssystem i tre steg av betydande incidenter: Tidig varning inom 24 timmar, incidentanmälan inom 72 timmar och slutrapport inom 1 månad.

Är detta lagens nedsida? Kanske inte! Genom att snabbt upptäcka incidenter, kan ni snabbt sätta in incident- och kontinuitetshantering vilket kapar kostnader för er och gör att kundernas förtroende behålls. Snabbhet och transparens bygger kundlojalitet i kris.

Ni i ledningen ska se till att rutiner finns implementerade, tillsammans med säkerhetsåtgärder för att hantera incidenter. Effektivt genom samordning med andra lagar. Läs hos MSB:hantera och rapportera it-incidenter och cyberangrepp.

Tillsynsmyndigheten utför tillsyn. Väsentliga entiteter står under proaktivt tillsyn, viktiga entiteter vid befogad anledning. Säkerhetsrevisioner och säkerhetsskanningar kan ske.

För tillsynen ska ni leverera information som visar att ni följer lagen. Det kan kännas byråkratiskt. Men, om ni dokumenterar under säkerhetsarbetet så blir det både ett verktyg för analys och bevis av säkerhet.

Ni i ledningen måste skapa effektiva rutiner för analys och dokumentation. Ension visar på denna site hur du skapar affärsdriven säkerhet, med AI och modell.

Om ni inte följer cybersäkerhetslagen så riskerar ni ekonomiska sanktioner. Sanktionsavgifter NIS2:

• Väsentliga enheter: Max 10 miljoner EUR eller 2 % av global omsättning, beroende på vilket som är högst.
• Viktiga enheter: Max 7 miljoner EUR eller 1,4 % av global omsättning, beroende på vilket som är högst. 

Ni ska vidta lämpliga och proportionella åtgärder mot de risker som hotar era nätverks- och informationssystem. Cybersäkerhetslagen räknar upp tio områden som minst ska ingå:

1. Strategi riskanalys och cybersäkerhet
2. Incidenthantering
3. Kontinuitetshantering och krishantering,
4. Säkerhet i leveranskedjan
5. Säkerhet vid förvärv, utveckling och underhåll
6. Strategi för att mäta effektivitet i säkerhet
7. Praxis för cyberhygien och utbildning
8. Strategi för kryptografi och kryptering
9. Personalsäkerhet, och hantering av tillgångar
10. Autentisering, säker kommunikation

Redan den första säkerhetsåtgärden i listan kräver en strategi för riskanalys. Riskanalysen används sedan för att bedöma vilka av de övriga som är lämpliga och proportionella för just er.

Det är de här tio ledningen ska utbildas i enligt 2 kap. 4 §.

Säkerhetsåtgärderna i detalj, med de fyra temana vad varje säkerhetsåtgärd innebär. Här beskrivs hur de förhåller sig till genomförandeförordningens tretton riskhanteringsåtgärder.

MCFFS 2026:11 paragraf för paragraf, de svenska föreskrifterna som gäller från 1 oktober 2026, och var i dem varje säkerhetsåtgärd återfinns.

De tio säkerhetsåtgärderna är krav på vad som ska uppnås. Ensions process för safety och security by design är ett sätt att uppfylla dem processuellt, i sex steg från kontext till bevisad säkerhet, spårbart mot lagen, genomförandeförordningen, MCFFS 2026:11, ISO 27001 och IEC 61508.

Säker utveckling bygger in säkerheten i arbetet, genom hela systemets livscykel. Det är en självklarhet inom flyg, järnväg, fordon och medicinteknik. Tänk på det: du ska flyga.

Cybersäkerhetskollen är ett verktyg från MSB som hjälper organisationer att mäta säkerhetsåtgärder.

Verktyget består av fyra delar: Infosäkkollen, It-säkkollen, Ot-säkkollen och Leveranskedjekollen.

Resultaten används för att skapa en nationell lägesbild. Deltagande organisationer bidrar till ett säkrare Sverige och kan få företräde till MSB:s rådgivning.

Krav på säkerhet kräver expertis. Ulf är expert på cybersäkerhetslagen och safety by design. Han har arbetat med säkerhet i utveckling och operativt, som expert och ledare.

För Ulf är cybersäkerhet som annan säkerhet: det gäller att uppnå safety, en säker funktion, inte bara security, säkerhetsskydd. Flygplan som står stilla på marken är det säkraste som finns, men saknar funktion.

Att möta kraven i NIS2 / Cybersäkerhetslagen kräver mer än traditionell IT-säkerhet. NIS2 kräver spårbarhet, systematisk riskkontroll och bevisad säkerhet.

Security by Design applicerar ingenjörskonst på digitala system. Hot- och felmodellering via t ex HAZID/HAZOP skapar en säker systemarkitektur med säkerhetskraven i grundkonstruktionen, precis som inom flygindustrin. Du går inte ombord på ett flygplan som inte är bevisat säkert. Som CTO / CIO ska du vara lika kaxig.

Denna guide presenterar Safety & Security by Design och DevSecOps integreras med cybersäkerhetslagens krav i utvecklingsprocessen. I sex steg omvandlar du säkerhet från en kostnad till en konkurrensfördel. Affärsdriven cybersäkerhet som skyddar kärnan i er affärsmodell med robusta system och regelefterlevnad.

För en CTO/CIO innebär guiden ett sätt att minimera risk och leverera bevisad säkerhet. Detta stärker både kundrelationer och marknadsposition. Jag berättar här hur du gör, med min erfarenhet som ingenjör, pilot och utveckling från signalsystem för järnväg.

Processen för Safety & security by design är spårbar mot NIS2, NIS2 genomförandeförordning, ISO27001 samt IEC 61508. Det har jag fixat åt er.

Pilotens kommentar: Från Luftvärdighet till Cybervärdighet

Som pilot lär man sig snabbt att säkerhet inte är något man lägger till i efterhand. Ingen kliver ombord när teknikerna står och tejpar fast reservmotorn precis innan start. Ett flygplans luftvärdighet bygger på att varje system är designat för att fungera säkert, redan på ritbordet. I den digitala världen har vi  cybervärdighet. Idag ser vi att alltför många organisationer lappar och lagar system i efterhand. Inbyggd säkerhet saknas. Genom att tillämpa Safety & Security by Design skapar vi cybervärdiga organisationer och system. Piloten är nöjd

Vi använder ordet säkerhet på svenskan. Men det är viktigt att skilja på safety och security:

• Safety handlar om att skydda människa och miljö från systemfel.
• Security handlar om att skydda systemet från angrepp utifrån.

Cybervärdighet, vad NIS2 kräver, kräver båda. Felen som uppträder kan vara av två olika typer.

• Systematiska fel: Beror på "fel i tanken" (programvara/design) och förhindras genom bra processer.
• Hårdvarufel: Beror på "fysiskt slitage" (hårdvara) och hanteras genom redundant design och beräkningar.

För cybersäkerhet krävs båda, då blir din organisation cybervärdig. Inom IT kan förmågan att identifiera systematiska fel variera. Är kafka säkert eller kafka?

Säkerhet genom design är en proaktiv metod som integrerar säkerhetsaktiviteter i hela designprocessen.  Istället för att i efterhand sätta in skyddsåtgärder, fokuserar metoden på att minimera risker genom att förutse, upptäcka och hantera risker innan de inträffar.

En preliminär riskanalys identifierar vad som behöver skyddas. Sedan görs en riskanalys mot system och organisation så att säkerhetsfunktioner och säkerhetskrav kan tas fram. Efter att alla krav implementerats och verifierats levereras säkra system

Cybersäkerhetslagen kräver att din affärsmodells tjänster är cybersäkra. Affärsmodellen ska klara sig i cyberspace. Om du skapar värde trots angrepp från cyberspace blir du starkare, du har en  resilient affär.

Detta kräver säkerhet vid förvärv, utveckling och underhåll av system och organisation. Med safety och Security by Design får du dina tjänster att leverera, till kunder och dig.

Cyberattacken är ett skott mitt i hjärtat på affärsmodellen. Affärsmodellen är bra att utgå ifrån för att klara lagen.

Bevakning kravställs i NIS2 med genomförandeförordning, cybersäkerhetslagen med MCFFS 2026:11 , CRA, GDPR och AI-förordningen. Det som skiljer dem är området de är skrivna för och vad de ska skydda.

Samhället sätter upp och har satt upp regelverk för att skydda oss mot alla dessa hot. Andra exempel än cybersäkerhetslagen säkerhetsskyddslagen, Digital Operational Resilience Act (DORA) och luftfartslagen.

Cybersäkerhetslagen ställer krav på säkerhet vid förvärv, utveckling och underhåll. Safety och Security By Design är ett sätt att implementera dessa krav. En stor del av Cybersäkerhetslagen kan implementeras på detta sätt.

Både beställare och leverantörer har internationella standarder att luta sig mot. För cybersäkerhet ISO 27001 och IEC 62443, för säkerhetskritiska system IEC 61508. IEC 61508 är en moderstandard som specialiserats per bransch: ISO 26262) för fordon, 61511 för processindustri och EN 50128  för järnväg.

ISO 27001 hanterar security, att stänga ute hot. IEC 61508 hanterar safety, att systemet fungerar. Det du vill uppnå med security är safety, och det är inte ISO 27001 särskilt inriktad på.

IEC 61508 beskriver safety by design, hur du ser till att systemet alltid fungerar. ISO 27002 ställer krav på säker utvecklingslivscykel, säkerhetskrav för applikationer, säker arkitektur och säker kodning.

För utveckling följer den här siten strukturen i IEC 61508 tillsammans med ISO 15288.

DevSecOps är mindre definierat än SAFe. Detta gör en analys relaterat ISO 27001 svår. Här bredvid ser du var kapitlen i ISO 27001 ligger relaterat DevOps. IEC 61508 täcker alla faser i systemutveckling.

DevSecOps syftar till att utveckla och drifta säkra IT-system. ISO 27001 syftar till informationssäkerhet och  ISO 615008 syftar till funktionell säkerhet. I den här artikeln beskriv hur du bedriver säker utveckling

Vad blir resultatet? En exakt, funktionell kravspecifikation som sömlöst kan integreras i er DevSecOps-pipeline. Utan en gedigen arkitektur i botten blir DevSecOps bara kosmetika. Med vår metod skapar ni förutsättningarna för Continuous Compliance (kontinuerlig efterlevnad), där automatiserade säkerhetsverktyg i realtid kan bevisa att er kod och era underleverantörer (via SBOM) strikt följer uppsatta lagkrav innan något driftsätts.

Många plattformar säljer DevSecOps som en mjukvara, men det är en metod. DevSecOps och "shift left" är i praktiken DevOps kombinerat med rigorösa standarder som ISO 27000 (informationssäkerhet) och IEC 61508 (funktionell säkerhet). Genom att integrera kraven från Cybersäkerhetslagen i utvecklingsprocessens alla faser, från planering till driftsättning och övervakning, syftar DevSecOps till att automatiskt utveckla och drifta bevisat säkra IT-system.

Processen här för safety och security by design grundar sig på ISO 27001, ISO 27005, IEC 61508 och ISO 15288. Syftet är att definiera och sätta krav mot aktiviteter i processen för säker systemdesign. 

Säkerhet genom design skapar säkerhet vid ritbordet istället för efter att problem uppstått, bevisat säkra system. Processen för Security by Design har sex steg:

1. Kontext för system och organisation
2. Preliminär riskanalys, identifiera kritiska system
3. Policy för system och organisation
4. Riskanalys system och organisation
5. Säkerhetsfunktioner med säkerhetskrav
6. Bevisa säkerhet genom dokumentation och test.

Enligt Artikel 21 ska verksamheter som träffas av NIS2 implementera tekniska, driftrelaterade och organisatoriska åtgärder utifrån ett allriskperspektiv. Åtgärder ska dessutom vara proportionerliga i förhållande till verksamhetens riskexponering. I modellform kan du beskriva lagen enligt nedan.

Problemet är att lagtexten säger vad som ska uppnås, inte vad ni ska göra på måndag. Och mellan lagen och måndagen ligger fyra regelverk till: MCFFS 2026:11 med ISO 27001 och 27002 samt genomförandeförordningen.

Ska du lyckas med safety & security by design krävs även IEC 61508. Ingen av dem hänvisar till de andra. MCFFS 2026:11 har 31 paragrafer om säkerhetsåtgärder utan en enda koppling till vilken av lagens tio åtgärder de genomför. Det löser Ension åt dig.

Inget av regelverken kräver IEC 61508 uttryckligen. Men både genomförandeförordningen och MCFFS 2026:11 kräver att etablerade metoder för säker utveckling följs, utan att säga vilka. För säkerhetskritiska system är IEC 61508 svaret, med sektorsstandarder som EN 50128 för järnväg och ISO 26262 för fordon. Lagstiftaren har lämnat frågan till branschen. Jag har valt IEC 61508 för att det är en moderstandard gjord för att specialisera.

För industriella styrsystem är motsvarigheten IEC 62443, som tar in cybersäkerhet i den värld 61508 byggde för funktionssäkerhet. MCFFS 2026:11 skiljer genomgående på it-segment och ot-segment men säger inget om vilka metoder som gäller för OT, där är 62443 svaret branschen redan gett.

Processen följer i huvudsak logiken i 62443-3-2: översiktlig riskbedömning, partitionering, detaljerad bedömning per del, sedan krav. Den tekniska detaljstyrningen saknas, zoner och conduits som modellobjekt, och Security Levels som styr kravmängden per zon. För en ren OT-implementation behöver processen kompletteras där.

Hur säkerställer Ension då att processen möter kraven i NIS2, dess genomförandeförordningar, ISO 27001/27002 samt IEC 61508? Svaret är krav som hänger ihop åt båda håll: varje aktivitet i processen har ett krav på sig, och varje krav pekar på sin punkt i regelverken.

Här i bilden visas hur andra steget, preliminär riskanalys, spåras mot ur regelverken framanalyserade krav. Kraven, de lila rutorna, spåras sedan mot MCFFS 2026:11, standarder, NIS2 genomförandeförordning, cybersäkerhetslag och till slut NIS2, gröna och gråa rutor.

Processen är nedbruten i ett femtiotal aktiviteter. Bakom dem ligger flera hundra spårbara krav, var och en kopplad till sin punkt i NIS2, genomförandeförordningen, MCFFS 2026:11, ISO 27001, ISO 27002 eller IEC 61508.

Ensions spårbarhet innebär en obruten röd tråd från lag till process. Om du följer processen beskriven på denna site får du även en spårbarhet i resultaten: en modell i Archimate som bevisar din efterlevnad av NIS2.

1. Alla dina säkerhetskrav och åtgärder går att spåra till ett lagkrav.
2. Luckorna mot lagen syns.Ett lagkrav utan spår är ett gap.
3. Beviset blir en biprodukt. Arbetar ni modellbaserat enligt beskrivningarna här genereras säkerhetsbeviset ur modellen i stället för att skrivas ihop i efterhand. Spårbarheten är något som redan finns.

Första steget i Security by Design är att ta reda på vad som måste ha säker design. I detta tar du först reda på om du träffas av cybersäkerhetslagen. Grunden är ditt erbjudande. Detta är din kontext för cybersäkerhet.

I affärsmodellen kan du se vilka värden / tjänster som ditt företag erbjuder kunder och partners. Du kan även se hur dina partners nyttjar dem för att ni tillsammans ska leverera värden / tjänster till kunden.

Den preliminära faro och riskanalysen skapar grunden för analys av om du träffas av cybersäkerhetslagen. Dessutom skapar preliminära riskanalysen tillsammans med övriga kontextanalysen grunden för säkerhetspolicy.

Indata till preliminära riskanalysen är affärsmodellen, värdekedjor, verksamhets och systemarkitektur. Resultatet av riskanalysen är prioriterade risker syftande till att skapa en säkerhetspolicy för effektiv riskhantering.

Strategier för säkerhet krävs i cybersäkerhetslagen med detaljerade krav i NIS2 genomförandeförordning.

I termer av ISO 27001 är det en säkerhetspolicy som krävs. Det som gjorts i genomförandeförordningen är att formulera om skrivningarna i ISO 27001. Dessutom har man rört ihop ISO 27001 och ISO 27002

Här är en process för att ta fram en säkerhetspolicy som följer cybersäkerhetslagen, ISO 27000 och IEC 61508.

Systemriskanalys skapar grunden för sätta krav mot säkerhetsåtgärder i säkerhetssystemet, säkerhetskrav.

Systemriskanalys tar arkitekturarbetet med system och organisation som innput. Resultatet är prioriterade riskbedömningar som ska ligga till grund för arbetet med att hitta säkerhetsåtgärder och att sätta de säkerhetskrav som är nödvändiga.

Säkerhetskrav är de regler och åtgärder som skyddar människor, egendom och information från skada.

Utgå från de farliga händelserna. För varje händelse bestämmer du säkerhetsfunktionen som ska hantera den och specificerar den med funktionella säkerhetskrav. Därefter härleder du kraven på det tekniska systemet, och verifierar att de är korrekta.

Arbetet görs i två steg: först logisk arkitektur, sedan teknisk. Genomförandeförordningen kräver analys av säkerhetskrav i båda.

Bevisat säkra system är en självklarhet i väldigt många branscher.  Bara byråkrati säger du, men säger du det när du ska kliva ombord på flygplanet nästa gång?

Bevis av säkerhet innebär att man visar att system och organisation är säker genom att sammanställa i designarbetet  producerad dokumentation. Har du som jag arbetat modellbaserat är det enkelt. Säkerhetsbevis genereras automatiskt ur modellen. Lätt om en plätt.

Säkerhet är inte ett jätteprojekt utan ett kontinuerligt förbättringsarbete. Detta gäller även Safety By Design. Med kunskapen förbättrar du stegvis din designprocess.

Med kontinuerliga internrevisioner startar du högst upp i organisationen och lär dig krypa innan du kan gå. Här beskrivs hur du efter egen ambition i kontinuerliga förbättringscykler skapar bevisad säkerhet.

Denna sida har finansierats med bidrag från MSB och NCC-SE