ISO 27001 ger dig en stark ISMS-ryggrad, men certifieringen räcker inte som bevis för NIS2. Direktivet lägger till konkreta juridiska skyldigheter: stegvis incidentrapportering inom 24 timmar, 72 timmar och en månad, samt djupare krav på ledningsansvar och leverantörskedjan. Rekommendationen är att mappa artikel 21 och 23 mot er tillämplighetsförklaring och prioritera bevis för incidenthantering, sårbarhetshantering och leverantörssäkerhet innan ni rapporterar något till en tillsynsmyndighet.
Kort sagt:
- För att möta NIS2 krävs mer än ISO 27001-certifiering, särskilt när det gäller incidentrapportering inom 24 till 72 timmar och detaljerad leverantörsöversyn.
- Ett redan fungerande ISMS kan under vissa förutsättningar räcka, om riskbedömning, ledningsdokumentation och tillämplighetsförklaring är tillräckligt konkreta och uppdaterade.
- Praktiska bevis på att säkerhetskontroller fungerar inkluderar tidsstämplade incidentärenden, loggar, leverantörsgranskningar och ledningsgenomgångar, snarare än bara policydokument.
- Tidsfristerna för incidentrapporter och dokumentatörens ansvar är olösliga utan testade processer och tydlig dokumentation av ledningsbeslut, särskilt för större organisationer.
- En digital plattform som Trustview samlar krav, bevis och ansvar i ett system, vilket underlättar regelbunden uppföljning och dokumentation mot NIS2-kraven.
Innehållsförteckning
- Hur NIS2 och ISO 27001 relaterar till varandra
- Konkreta överlapp mellan NIS2 och ISO 27001
- Praktisk korsreferens: artikel 21 och 23 mot ISO 27001:2026
- Var ISO 27001 inte räcker mot NIS2
- Steg-för-steg: mappa och implementera NIS2 i ditt ISMS
- Vad revisorer och myndigheter förväntar sig av din SoA
- Praktiskt perspektiv: vanliga fallgropar och prioriteringar
- Trustview hjälper dig samla bevisen NIS2 kräver
- Källor
- Vanliga frågor
Hur NIS2 och ISO 27001 relaterar till varandra
NIS2 bygger inte på en ny säkerhetsfilosofi. Direktivet kräver ett riskbaserat arbetssätt som ständigt utvärderas och förbättras, vilket i praktiken är precis det ett informationssäkerhetshanteringssystem enligt ISO/IEC 27001:2022 är byggt för att leverera. Den som redan driver ett fungerande ISMS har därför en stor del av grundarbetet klart. Frågan är aldrig om ISO-strukturen är relevant, utan om den täcker allt NIS2 faktiskt frågar efter.
Standarden vilar på klausul 6.1, som styr riskbedömning och riskbehandling, och på ledningens genomgång i klausul 9.3, där organisationen regelbundet ska granska om säkerhetsarbetet fungerar. Det tredje nyckeldokumentet är tillämplighetsförklaringen, förkortad SoA (Statement of Applicability), som listar vilka kontroller i Annex A som tillämpas och varför. SoA blir den naturliga länken till NIS2, eftersom den redan kopplar krav till konkreta kontroller och ansvariga.
Det som saknas är juridiken. ISO 27001 säger ingenting om exakt vilka tidsfrister som gäller när en incident inträffar, eller vilken typ av bevis en tillsynsmyndighet förväntar sig att se. Det är Direktiv (EU) 2022/2555, alltså NIS2-direktivet, som fastställer dessa skyldigheter, och de skiljer sig mellan medlemsstaternas nationella implementering.
Tre saker avgör hur långt ett befintligt ISMS räcker:
- Om riskbedömningen redan omfattar leverantörskedjan, inte bara interna system.
- Om ledningens genomgång dokumenterar faktiska beslut, inte bara att ett möte hållits.
- Om SoA innehåller motivering för varje undantag, så att en revisor ser varför en kontroll inte tillämpas.
Ett ISMS som klarar dessa tre punkter har redan gjort större delen av arbetet mot en fungerande mappning av ISO och NIS2.
Konkreta överlapp mellan NIS2 och ISO 27001
Fyra områden återkommer i praktiskt taget alla NIS2-bedömningar, och alla fyra har en direkt motsvarighet i Annex A i ISO 27001:2022.
Incidenthantering hör till kontrollerna A.5.24 till A.5.28, som styr planering, bedömning, respons och lärande från säkerhetsincidenter. Det här är samma process NIS2 kräver, men direktivet lägger på strikta tidsramar för när myndigheten ska informeras.
Leverantörssäkerhet täcks av A.5.19 till A.5.23, som beskriver hela leverantörens livscykel: från säkerhetskrav i avtal, via granskning under samarbetet, till hur relationen avslutas säkert. NIS2:s krav på tredjepartsriskhantering går betydligt djupare än vad många organisationer historiskt dokumenterat i sina ISO-revisioner.
Kontinuitet och testning hanteras via kontroller för affärskontinuitet och tekniska sårbarhetstester, medan åtkomstkontroll och kryptering ligger i A.5.15 till A.5.18 respektive A.8.24. Sårbarhetshantering, alltså det löpande arbetet med att identifiera och åtgärda tekniska brister, är ett av de områden där tillsynsmyndigheter ofta ber om konkret bevisning.
En sak är värd att lyfta fram särskilt: NIS2 kräver inte bara att en kontroll finns, utan att organisationen kan visa att den faktiskt fungerar över tid.
Proffstips: Samla inte bara policydokument. Ett revisionsspår med tidsstämplade ärenden, från upptäckt till stängning, väger betydligt tyngre hos en tillsynsmyndighet än en policy som aldrig testats mot en verklig händelse.
Exempel på bevis som fungerar i praktiken:
- Ett urval av avslutade incidentärenden med tidsstämplar för upptäckt, eskalering och åtgärd.
- Loggar från sårbarhetsscanning som visar tid från upptäckt till patchning.
- Dokumenterade leverantörsgranskningar med datum, resultat och uppföljande åtgärder.
- Protokoll från ledningens genomgång där riskbeslut faktiskt syns, inte bara nämns.
Praktisk korsreferens: artikel 21 och 23 mot ISO 27001:2026
Artikel 21 i NIS2 listar de tekniska och organisatoriska åtgärder som väsentliga och viktiga enheter måste vidta. Artikel 23 reglerar rapporteringsskyldigheterna vid incidenter. Att mappa ISO och NIS2 handlar i grunden om att koppla varje delkrav i dessa två artiklar till en specifik kontroll i Annex A, och sedan avgöra om kontrollen räcker som den är eller behöver kompletteras med en juridisk process.
Riskhantering (artikel 21.2.a) kopplar direkt till klausul 6.1 och kontroller inom riskbedömning. Här räcker ISO-processen ofta långt, förutsatt att riskregistret uppdateras löpande och inte bara vid årsrevisionen. Beviset som krävs är ett aktuellt riskregister med daterade granskningar.
Incidenthantering (artikel 21.2.b samt artikel 23) kopplar till A.5.24 till A.5.28, men här ligger det största gapet. ISO kräver en process för hantering, medan NIS2 kräver att processen kan leverera en tidig varning inom 24 timmar, en fullständig anmälan inom 72 timmar och en slutrapport senast en månad efter händelsen. Beviset måste visa att organisationen faktiskt kan hålla dessa tider, inte bara att en rutin finns på pappret.
Driftskontinuitet och krishantering (artikel 21.2.c) motsvaras av kontinuitetsplanering och katastrofåterställning i Annex A. De flesta ISO-certifierade organisationer har redan detta på plats, men NIS2 förväntar sig regelbundna övningar med dokumenterat resultat, inte bara en plan som ligger i en pärm.
Leveranskedjans säkerhet (artikel 21.2.d) kopplar till A.5.19 till A.5.23. Det här är ofta det djupaste gapet, eftersom NIS2 explicit pekar på risker hos direkta leverantörer och deras egna underleverantörer, ett djup många ISO-revisioner aldrig granskat i detalj.
Säkerhet i nätverk och system, samt sårbarhetshantering (artikel 21.2.e och f) motsvaras av tekniska kontroller för nätverkssäkerhet och sårbarhetshantering. Kommissionens genomförandeförordning preciserar vilka händelser som räknas som väsentliga, vilket avgör om en sårbarhet måste eskaleras till en formell incidentrapport.
Kryptografi och åtkomstkontroll (artikel 21.2.h och i) kopplar till A.8.24 och A.5.15 till A.5.18. Detta är typiskt ett område där ISO-kontrollerna redan täcker kraven fullt ut.
Personalens säkerhetsmedvetenhet och grundläggande cyberhygien (artikel 21.2.g) motsvaras av utbildningskontroller i Annex A, men NIS2 lägger särskild vikt vid att ledningen personligen godkänner och följer upp utbildningsinsatserna, inte bara HR-avdelningen.
Prioriteringen ska styras av regulatorisk exponering snarare än av vad som är enklast att åtgärda. Incidenthantering, sårbarhetshantering och leverantörsgranskning är de tre områden där en tillsynsmyndighet oftast ber om detaljerad bevisning, och där konsekvenserna av bristande spårbarhet är störst. Ett konkret sätt att testa sin egen mappning är att välja fem kritiska sårbarheter från senaste kvartalet och följa hela spåret från upptäckt till godkänd åtgärd: tillgångsidentifiering, upptäckt, ärendeöppning, tilldelad ägare, åtgärd, validering och en dokumenterad godkännandeprocess för eventuella undantag.
Var ISO 27001 inte räcker mot NIS2
Tre gap återkommer oftast när organisationer försöker mappa ISO och cybersäkerhet enligt NIS2, och alla tre kräver aktiva tillägg till ett befintligt ISMS.
Det första gapet är tidsfrister för incidentrapportering. ISO kräver att incidenter hanteras, men ställer inga juridiska klockor. NIS2 gör det: en tidig varning inom 24 timmar efter att organisationen fått kännedom om incidenten, en fullständig incidentanmälan inom 72 timmar, och en slutrapport inom en månad. Att klara dessa tider kräver en process som är testad i förväg, inte improviserad när krisen är här.
Det andra gapet handlar om ledningsansvar. NIS2 lägger ett personligt ansvar på ledningen för att godkänna riskhanteringsåtgärder och för att kunna visa att de förstår och övervakar säkerhetsarbetet. Det räcker inte att ett dokument är undertecknat, myndigheten kan förvänta sig att se protokoll som visar faktiska diskussioner och beslut.
Det tredje gapet är leveranskedjans djup och sektorsspecifika krav. NIS2 tvingar organisationer att se bortom sina direkta leverantörer och bedöma risker längre bak i kedjan, samtidigt som vissa sektorer får ytterligare krav via nationell lagstiftning eller sektorsspecifika förordningar.
- Skriv en tidsstyrd process för de tre rapporteringsstegen och testa den i en simulerad övning.
- Dokumentera ledningens faktiska riskbeslut i protokoll, inte bara i en policy som signeras en gång per år.
- Utöka leverantörsbedömningen till att omfatta underleverantörer med hög kritikalitet.
Proffstips: Testa er 72-timmarsprocess innan ni behöver den. De flesta organisationer upptäcker först under en verklig incident att beslutsvägarna är oklara eller att rätt person saknar mandat att skicka anmälan.
Steg-för-steg: mappa och implementera NIS2 i ditt ISMS
Att gå från ett fungerande ISO-ramverk till en dokumenterad NIS2-efterlevnad kräver fem konkreta steg, och ordningen spelar roll.
- Kartlägg omfattning och tjänster. Identifiera vilka tjänster i organisationen som faller under NIS2, och koppla varje tjänst till relevanta artiklar, särskilt artikel 21 och 23.
- Uppdatera kravregistret mot SoA. Lägg in varje NIS2-krav som en rad i kravregistret och korsreferera det mot motsvarande kontroll i Annex A. Där en kontroll inte räcker, notera vilket tillägg som krävs.
- Tilldela ägare och skriv operativa procedurer. Varje krav behöver en namngiven ägare, inte en avdelning. Skriv konkreta rutiner för incidenthantering, sårbarhetshantering och leverantörsuppföljning som beskriver exakt vem gör vad och när.
- Genomför urvalsprov och simulera en myndighetsförfrågan. Välj ett antal ärenden slumpmässigt och testa om ni kan producera fullständig bevisning inom rimlig tid, precis som en tillsynsmyndighet skulle begära.
- Bygg ett återkommande bevispaket. Sätt ihop ett paket kvartalsvis med aktuell SoA, incidentloggar och leverantörsstatus, redo att visas för ledning eller myndighet utan improvisation.
Proffstips: Kör steg fyra som en riktig övning, inte en pappersgenomgång. Be någon utanför säkerhetsteamet formulera en myndighetsfråga och se hur lång tid det tar att ta fram svaret.
ENISA:s tekniska implementeringsvägledning ger konkreta rekommendationer för hur många av dessa operativa steg bör utformas i praktiken, särskilt kring testrutiner och tekniska kontroller. Den som vill fördjupa incidentrapporteringsprocessen specifikt hittar en detaljerad genomgång av tidsfrister och arbetsflöden värd att gå igenom innan ni skriver er egen rutin.
Vad revisorer och myndigheter förväntar sig av din SoA
Tillämplighetsförklaringen är navet i hela mappningen, men bara om den innehåller mer än en lista över kontroller. En SoA som håller för granskning ska specificera kravet, det kontrollval som gjorts, en motivering om kontrollen undantagits, en namngiven ägare, aktuell införandestatus och en länk till det bevis som visar att kontrollen faktiskt fungerar.
Konkret bevisning som brukar efterfrågas inkluderar avslutade incidentärenden, öppna och stängda sårbarhetsärenden, ändringsloggar från kritiska system, genomförda leverantörsrevisioner och rapporter från tekniska tester. En SoA utan länkade bevis är i praktiken bara en avsiktsförklaring.
| Del av SoA | Vad den ska visa |
|---|---|
| Kontrollval och motivering | Varför kontrollen tillämpas eller undantas |
| Ägare | Namngiven person, inte avdelning |
| Införandestatus | Faktiskt läge, inte planerat läge |
| Länkat bevis | Konkret ärende, logg eller rapport |
| Granskningsfrekvens | Hur ofta kontrollen omprövas |
Ett kvartalsvis bevispaket som samlar dessa element gör både internrevision och myndighetskontakt betydligt smidigare, eftersom underlaget redan finns strukturerat när frågan kommer.
Praktiskt perspektiv: vanliga fallgropar och prioriteringar
Det vanligaste misstaget är att behandla ISO-certifieringen som ett mål i sig. Certifikatet bevisar att ett system fanns vid revisionstillfället, inte att det fungerar när en verklig incident inträffar klockan tre på natten. NIS2 belönar levande bevis och testade rutiner, inte pärmar.
Om du bara har tid att göra tre saker: testa incidentrapporteringen mot klockan, gå igenom era mest kritiska leverantörer på djupet, och se till att sårbarhetsärenden faktiskt stängs inom rimlig tid. En plattform som samlar krav, ägare och bevis på samma plats gör det lättare att se var kedjan brister innan en tillsynsmyndighet gör det åt er.
— Jesper
Trustview hjälper dig samla bevisen NIS2 kräver
Att mappa artikel 21 och 23 mot Annex A är görbart med ett kalkylblad, men att hålla det levande kvartal efter kvartal är där de flesta organisationer tappar tråden. Trustview samlar tillämplighetsförklaring, riskregister, incidentlogg och leverantörsbedömningar på samma plats, så att varje krav kopplas till en ägare och ett konkret bevis istället för att ligga utspritt i separata dokument.
Plattformen stödjer flera regelverk samtidigt, inklusive GDPR, ISO 27001 och NIS2, vilket är avgörande för organisationer som redan hanterar dubbla rapporteringsplikter. Kombinationen av plattform och möjlighet till juridisk rådgivning gör att ni slipper gissa er till hur ett svenskt eller europeiskt krav ska tolkas i praktiken. Vissa plattformar är utvecklade med juridisk expertis inom svensk och europeisk lagstiftning, med fokus på tydliga ramverk och smidig administration.
Priserna för plattformen börjar från 2 500 kr per månad, och den som behöver djupare juridisk hjälp kan lägga till rådgivning som ett separat tillägg. Boka en genomgång för att se hur er befintliga ISO-mappning kan omvandlas till ett revisionsklart NIS2-bevispaket.
Källor
- Direktiv om NIS2 — ofte stillede spørgsmål | Shaping Europe’s digital future
- Directive (EU) 2022/2555 (NIS2) — EUR-Lex
- ENISA — NIS2 technical implementation guidance
- ISO — ISO/IEC 27001:2022
Vanliga frågor
Kan ISO 27001-certifiering ensam uppfylla NIS2?
Nej. ISO 27001 ger ett fungerande ISMS, men NIS2 lägger till bindande krav på incidentrapportering inom 24 timmar, 72 timmar och en månad, samt djupare leverantörsgranskning som certifikatet inte i sig bevisar.
Vilka ISO-kontroller kopplar till NIS2 artikel 21?
Artikel 21 kopplar främst till kontrollerna för riskhantering, incidenthantering, leverantörssäkerhet och kontinuitetsplanering. Varje delkrav behöver dock kompletteras med bevis på att kontrollen fungerar löpande, inte bara vid revisionstillfället.
Vad är skillnaden mellan NIS2 och det tidigare NIS-direktivet?
NIS2 breddar vilka sektorer och organisationer som omfattas, skärper tidsfristerna för incidentrapportering och lägger ett tydligare personligt ansvar på ledningen jämfört med det ursprungliga NIS-direktivet. Kraven på leveranskedjans säkerhet är också betydligt mer detaljerade i NIS2.
Vilka sanktioner riskerar organisationer vid bristande NIS2-efterlevnad?
Sanktionerna varierar mellan medlemsstaternas nationella lagstiftning, men NIS2 tillåter avgifter kopplade till organisationens omsättning för väsentliga och viktiga enheter som brister i sina skyldigheter. Den exakta nivån fastställs i varje lands egen implementering av direktivet.
Hur kan Trustview hjälpa med mappningen mellan ISO och NIS2?
Trustview samlar tillämplighetsförklaring, riskregister, incidentlogg och leverantörsbedömningar i samma plattform, vilket gör det lättare att koppla varje NIS2-krav till en ägare och ett konkret bevis. Priser för plattformen börjar från 2 500 kr per månad.
