Kartläggning av NIS2-revisionsbevis med ISO 27001:2022 för 2026

NIS2-problemet 2026 är inte medvetenhet, utan bevisbarhet

Det är måndag morgon, 08:35. Maria, nyligen utsedd CISO hos en snabbväxande leverantör av B2B-molntjänster och hanterade tjänster, ansluter till styrelsens kvartalsvisa riskmöte med en omfattande NIS2-gapanalys öppen på sin laptop. Den första bilden ser betryggande ut. Policyer finns. En riskbedömning finns. Incidenthantering är dokumenterad. Leverantörer är listade. Sårbarhetsskanningar körs varje månad.

Sedan ställer ordföranden frågan som förändrar mötet:

”Kan vi bevisa att dessa åtgärder fungerade under föregående kvartal, och kan vi visa vilka ISO 27001:2022-kontroller, ägare och registreringar som stödjer varje NIS2-skyldighet?”

Rummet tystnar.

Juridikfunktionen vet att företaget omfattas av NIS2 eftersom det levererar hanterade IKT- och molntjänster till kunder i EU. Regelefterlevnadsfunktionen vet att artikel 21 kräver tekniska, operativa och organisatoriska åtgärder för hantering av cybersäkerhetsrisker. Driften vet att teamet patchar system, granskar leverantörer och övervakar loggar. Men revisionsbevisen är utspridda över ärendehanteringssystem, SIEM-exporter, policymappar, kalkylark, molnkonsoler, leverantörsportaler och mötesanteckningar.

Ingen kan snabbt visa en försvarbar kedja från NIS2 artikel 21 till ISO 27001:2022-omfattning, risk, kontroll, policy, ägare, procedur, driftregistrering och revisionsiakttagelse.

Det är den verkliga utmaningen 2026.

Många organisationer frågar inte längre: ”Omfattas vi av NIS2?” De ställer en svårare fråga: ”Kan vi bevisa att våra tekniska NIS2-åtgärder faktiskt fungerar?” Svaret kan inte vara ett engångsark för mappning. Det måste vara en levande operativ modell i ledningssystemet för informationssäkerhet, där rättsliga skyldigheter översätts till risker, policyer, kontroller, ägare, revisionsbevis och ständig förbättring.

Clarysecs modell använder ISO/IEC 27001:2022 som ryggrad för ledningssystemet, NIS2 artikel 21 som uppsättning regulatoriska skyldigheter, policyavsnitt som operativ regelbok, Zenith Blueprint: en 30-stegs färdplan för revisorer som införandeväg och Zenith Controls: vägledningen för samordnad efterlevnad som karta för samordnad efterlevnad av ISO 27001:2022, NIS2, DORA, GDPR, NIST CSF och COBIT-baserad säkerhetsförsäkran.

Börja med omfattningen, eftersom NIS2-revisionsbevis börjar före kontrollerna

Ett vanligt NIS2-misstag är att gå direkt till MFA, loggning, incidenthantering och sårbarhetshantering innan enhetens omfattning, tjänsteomfattning och jurisdiktionella omfattning har fastställts.

NIS2 gäller berörda offentliga och privata enheter i reglerade sektorer som uppfyller kriterier för storlek och verksamhet, medan vissa typer av enheter omfattas oavsett storlek. Relevanta digitala och IKT-relaterade kategorier omfattar molntjänstleverantörer, datacentertjänstleverantörer, leverantörer av innehållsleveransnätverk, betrodda tjänsteleverantörer, leverantörer av allmänna elektroniska kommunikationstjänster, leverantörer av hanterade tjänster, leverantörer av hanterade säkerhetstjänster, digitala marknadsplatser, sökmotorer online och plattformar för sociala nätverk.

För molnleverantörer, SaaS-plattformar, MSP:er, MSSP:er och leverantörer av digital infrastruktur är detta omfattningsarbete inte teoretiskt. Artikel 3 kräver att medlemsstater skiljer mellan väsentliga och viktiga enheter. Artikel 27 kräver att ENISA upprätthåller ett register för flera digitala och IKT-leverantörer, däribland DNS-tjänsteleverantörer, TLD-namnregister, leverantörer av domännamnsregistreringstjänster, molntjänstleverantörer, datacentertjänstleverantörer, leverantörer av innehållsleveransnätverk, leverantörer av hanterade tjänster, leverantörer av hanterade säkerhetstjänster, digitala marknadsplatser, sökmotorer online och plattformar för sociala nätverk.

ISO 27001:2022 ger rätt struktur. Avsnitt 4.1 till 4.4 kräver att organisationen förstår externa och interna frågor, intressenter, krav, gränssnitt och beroenden och därefter definierar omfattningen för ledningssystemet för informationssäkerhet. NIS2 ska fångas här, inte lämnas i ett juridiskt PM.

En praktisk omfattningspost för NIS2 bör omfatta:

• Analys av juridisk person och etablering i EU
• NIS2-sektor och tjänstekategori
• Status som väsentlig eller viktig enhet, där detta har bekräftats genom nationell rätt eller myndighetsbeslut
• Relevans för ENISA-registret, där tillämpligt
• Kritiska tjänster som levereras till kunder
• Nätverks- och informationssystem som stödjer dessa tjänster
• Beroenden till moln, datacenter, telekom, säkerhetsövervakning, identitetsleverantörer och programvaruleverantörer
• Kopplingar till DORA, GDPR, kundavtal och sektorspecifika skyldigheter
• Revisionsbevisarkiv, systemägare och granskningsintervall

Det är också här DORA måste särskiljas korrekt. NIS2 erkänner att när en sektorspecifik EU-rättsakt ställer likvärdiga krav på hantering av cybersäkerhetsrisker eller incidentanmälan gäller den sektorspecifika ordningen i stället för motsvarande NIS2-bestämmelser. För berörda finansiella enheter är DORA normalt den operativa ordningen för cybersäkerhet och rapportering av IKT-incidenter. DORA gäller från den 17 januari 2025 och omfattar IKT-riskhantering, incidentrapportering, testning av digital operativ resiliens, IKT-tredjepartsrisk och tillsyn över kritiska IKT-tredjepartsleverantörer.

En fintech-koncern kan därför ha olika efterlevnadsbehandling inom samma bolagsstruktur. Betalningsenheten kan främst omfattas av DORA. MSP-dotterbolaget kan direkt omfattas av NIS2. En gemensam molnplattform kan stödja båda. Det mogna svaret är inte dubblerade kontroller. Det är en ISMS-modell för revisionsbevis som kan stödja flera regulatoriska perspektiv.

ISO 27001:2022 som operativt system för NIS2-efterlevnad

NIS2 artikel 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder för att hantera risker för nätverks- och informationssystem samt förhindra eller minimera incidentpåverkan på tjänstemottagare och andra tjänster.

ISO 27001:2022 lämpar sig väl för att operationalisera detta krav eftersom standarden tvingar fram tre discipliner.

För det första styrning. Avsnitt 5.1 till 5.3 kräver åtagande från högsta ledningen, anpassning till strategisk inriktning, resurssättning, kommunikation, tilldelning av ansvar och en dokumenterad informationssäkerhetspolicy. Detta ligger direkt i linje med NIS2 artikel 20, som kräver att ledningsorgan godkänner åtgärder för hantering av cybersäkerhetsrisker, övervakar genomförandet och får utbildning.

För det andra riskbehandling. Avsnitt 6.1.1 till 6.1.3 kräver en repeterbar riskbedömningsprocess, riskägare, riskutvärdering, behandlingsalternativ, val av kontroller, en tillämplighetsförklaring, en riskbehandlingsplan och godkännande av kvarstående risk.

För det tredje operativ styrning. Avsnitt 8.1 kräver att organisationen planerar, genomför och styr ISMS-processer, upprätthåller dokumenterad information, styr ändringar och hanterar externt tillhandahållna processer, produkter och tjänster som är relevanta för ISMS.

Detta omvandlar NIS2 från en juridisk checklista till en operativ kontrollmodell.

Varje rad behöver en ägare, en källa för registreringar och en urvalsmetod. Om dessa saknas har organisationen en kontrollambition, inte en fungerande kontroll.

Policy är där NIS2 blir operativt beteende

Policyer behandlas ofta som mallar. För NIS2 är det riskabelt. En tillsynsmyndighet eller revisor övertygas inte av en policymapp om policyerna inte tilldelar ägarskap, definierar registreringar, kopplar till risker och producerar revisionsbevis.

Den företagsövergripande Policy för rättslig och regulatorisk efterlevnad lägger grunden i avsnitt 6.2.1:

Alla rättsliga och regulatoriska skyldigheter ska mappas till specifika policyer, kontroller och ägare inom ledningssystemet för informationssäkerhet (ISMS).

Det avsnittet är bryggan mellan NIS2 och ISO 27001:2022. NIS2 artikel 21 listas inte bara som ett externt krav. Den bryts ned till policyförpliktelser, mappas till kontroller, tilldelas ägare och testas genom revisionsbevis.

För mindre organisationer behåller SME-versionen av Policy för rättslig och regulatorisk efterlevnad samma koncept i lättare form. Avsnitt 5.1.1 kräver:

VD ska upprätthålla ett enkelt, strukturerat register över regelefterlevnadskrav som listar:

Formuleringen är avsiktligt praktisk. Små och medelstora företag behöver inte ett komplext GRC-införande för att börja. De behöver ett register över regelefterlevnadskrav som fångar skyldighet, tillämplighet, ägare, policy, revisionsbevis och granskningsintervall.

Riskbehandling omvandlar därefter skyldigheten till åtgärd. Den företagsövergripande Riskhanteringspolicy, avsnitt 6.4.2 anger:

Riskansvarig ska säkerställa att behandlingar är realistiska, tidsatta och mappade mot ISO/IEC 27001 Annex A-kontroller.

För små och medelstora företag anger Riskhanteringspolicy – SME, avsnitt 5.1.2, den minsta fungerande riskposten:

Varje riskpost ska innehålla: beskrivning, sannolikhet, konsekvens, poäng, ägare och riskbehandlingsplan.

Dessa avsnitt är viktiga eftersom NIS2 uttryckligen är riskbaserat och proportionerligt. Artikel 21 förväntar sig att åtgärder återspeglar bästa tillgängliga teknik, relevanta standarder, genomförandekostnad, riskexponering, storlek samt incidentens sannolikhet och allvarlighetsgrad, inklusive samhällelig och ekonomisk påverkan. Ett riskregister utan ägare och riskbehandlingsplaner kan inte bevisa proportionalitet.

Den företagsövergripande Informationssäkerhetspolicy fullbordar bevisprincipen i avsnitt 6.6.1:

Alla införda kontroller ska vara möjliga att granska, stödjas av dokumenterade procedurer och av bevarade revisionsbevis som visar att de fungerar i drift.

Det är skillnaden mellan att ha ett NIS2-program och att ha ett NIS2-program med bevisbarhet.

Clarysecs väg från mappning till drift

Zenith Blueprint är värdefull eftersom den speglar hur revisorer tänker. De frågar inte bara om en kontroll finns. De frågar varför den valdes, var den är dokumenterad, hur den fungerar, vem som äger den, vilka revisionsbevis som styrker den och hur organisationen förbättrar den.

I riskhanteringsfasen anger steg 13 att team ska lägga till spårbarhet mellan risker, kontroller och avsnitt:

✓ Mappa kontroller till risker: I riskbehandlingsplanen i ert riskregister har ni listat vissa kontroller för varje risk. Ni kan lägga till en kolumn ”Annex A Control Reference” för varje risk och lista kontrollnumren.

För NIS2 innebär detta att riskregistret och tillämplighetsförklaringen bör visa varför kontroller som 8.8 Hantering av tekniska sårbarheter, 5.19 Informationssäkerhet i leverantörsrelationer och 5.24 Planering och förberedelse för incidenthantering är tillämpliga.

Steg 14 i Zenith Blueprint gör den regulatoriska mappningen uttrycklig:

För varje reglering, om tillämpligt, kan ni skapa en enkel mappningstabell (till exempel som bilaga i en rapport) som listar regleringens centrala säkerhetskrav och motsvarande kontroller/policyer i ert ISMS.

Detta förhindrar fragmentering. GDPR-säkerhet för personuppgifter, NIS2-incidentrapportering, DORA-testning av IKT-resiliens och kunders säkerhetsåtaganden kan alla bygga på samma revisionsbevis: åtkomstgranskningar, åtgärdande av sårbarheter, loggningsregistreringar, tester av säkerhetskopiering, leverantörsgranskningar och incidentrapporter.

Steg 19 flyttar arbetet från design till drift:

Knyt vart och ett av dessa dokument till rätt kontroll i er SoA eller ISMS-manual. De kommer att fungera som bevis på genomförande och som intern referens.

Dokumentationsuppsättningen i steg 19 omfattar slutpunktssäkerhet, åtkomsthantering, autentisering, säkra konfigurationsbaslinjer, loggning och övervakning, patchhantering, sårbarhetshantering, kapacitetsplanering och rapportering för IT-drift. Detta är exakt de operativa dokument som behövs för att göra tekniska NIS2-åtgärder granskningsbara.

Steg 26 förklarar hur revisionsbevis bör samlas in:

När ni samlar in underlag, registrera era iakttagelser. Notera var något överensstämmer med kravet (positiva iakttagelser) och var det inte gör det (möjliga avvikelser eller observationer).

För NIS2 innebär detta att revisionsbevis ska provtas innan en tillsynsmyndighet, kundgranskare eller certifieringsrevisor begär det.

Rollen för samordnad efterlevnad i Zenith Controls

Zenith Controls är inte ett separat kontrollramverk. Det är Clarysecs vägledning för samordnad efterlevnad som mappar ISO/IEC 27001:2022- och ISO/IEC 27002:2022-kontroller till relaterade kontroller, revisionsförväntningar och externa ramverk. Den hjälper team att förstå hur en ISO 27001:2022-kontroll kan stödja NIS2, DORA, GDPR, NIST CSF 2.0 och COBIT-baserad säkerhetsförsäkran.

Tre ISO 27001:2022-kontroller är särskilt viktiga för NIS2-beviskartläggning.

Kontroll 5.1 Policyer för informationssäkerhet är startpunkten eftersom NIS2 artikel 21 omfattar riskanalys och policyer för informationssystems säkerhet. Om en teknisk NIS2-åtgärd inte återspeglas i policy är den svår att styra och svår att granska konsekvent.

Kontroll 5.36 Efterlevnad av policyer, regler och standarder för informationssäkerhet är verklighetskontrollen. Den kopplar policykrav till faktisk överensstämmelse med interna regler, standarder och externa skyldigheter. I NIS2-termer är det här organisationen frågar om den gör det som dess mappning mot artikel 21 säger att den gör.

Kontroll 8.8 Hantering av tekniska sårbarheter är ett av de svåraste testområdena 2026. Sårbarhetshantering är direkt relevant för säker anskaffning, utveckling, underhåll, sårbarhetshantering och rapportering. Den stödjer också DORA-testning och åtgärdande, ansvarsskyldighet för säkerhet enligt GDPR, NIST CSF-resultat för Identify och Protect samt urval vid ISO 27001-revision.

Stödjande standarder kan skärpa utformningen utan att kräva ytterligare certifieringar. ISO/IEC 27002:2022 ger vägledning för genomförande av Annex A-kontroller. ISO/IEC 27005 stödjer informationssäkerhetsriskhantering. ISO/IEC 27017 stödjer molnsäkerhet. ISO/IEC 27018 stödjer skydd av personligt identifierbar information (PII) i scenarier där publika moln används av personuppgiftsbiträden. ISO 22301 stödjer verksamhetskontinuitet. ISO/IEC 27035 stödjer incidenthantering. ISO/IEC 27036 stödjer säkerhet i leverantörsrelationer.

Målet är inte fler standarder för deras egen skull. Målet är bättre utformning av revisionsbevis.

Praktiskt exempel: bygg ett NIS2-bevispaket för sårbarheter

Betrakta Marias SaaS-plattform. Den betjänar tillverkningskunder i EU och är beroende av molntjänster, komponenter med öppen källkod, CI/CD-pipelines och hanterad övervakning. Hennes gaprapport säger ”sårbarhetshantering införd”, men revisionsbevisen är utspridda över skannrar, Jira, GitHub, verktyg för molnkonfiguration och ändringsärenden.

Ett NIS2-anpassat bevispaket kan byggas i en fokuserad sprint.

Steg 1: Definiera riskscenariot

Risk: en exploaterbar sårbarhet i en internetexponerad applikation, ett beroende eller en molnkomponent orsakar tjänsteavbrott, obehörig åtkomst eller exponering av kunddata.

Riskregistret bör innehålla beskrivning, sannolikhet, konsekvens, poäng, ägare och riskbehandlingsplan. Riskbehandlingsplanen bör hänvisa till ISO 27001:2022-kontroll 8.8 Hantering av tekniska sårbarheter samt relaterade kontroller för tillgångsförteckning, säker utveckling, loggning, åtkomstkontroll, leverantörshantering och incidenthantering.

Steg 2: Mappa risken mot NIS2 artikel 21

Risken stödjer kraven i artikel 21 på säker anskaffning, utveckling och underhåll, sårbarhetshantering och rapportering, riskanalys, incidenthantering, säkerhet i leveranskedjan och bedömning av kontrolleffektivitet.

Steg 3: Förankra de operativa reglerna i policy

Använd en procedur för sårbarhetshantering, standard för säker utveckling, krav för patchhantering, policy för säkerhetstestning och regler för revisionsbevis.

Den företagsövergripande Policy för säkerhetstestning och Red Teaming, avsnitt 6.1 anger:

Typer av tester: Programmet för säkerhetstestning ska minst omfatta: (a) sårbarhetsskanning, bestående av automatiserade vecko- eller månadsskanningar av nätverk och applikationer för att identifiera kända sårbarheter; (b) penetrationstestning, bestående av manuell djupgående testning av specifika system eller applikationer utförd av kvalificerade testare för att identifiera komplexa svagheter; och (c) red team-övningar, bestående av scenariobaserade simuleringar av verkliga angrepp, inklusive social manipulation och andra taktiker, för att testa organisationens detekterings- och responsförmåga som helhet.

Det avsnittet skapar en försvarbar testbaslinje. Det ligger också i linje med DORA:s förväntan på återkommande, riskbaserad testning av digital operativ resiliens för berörda finansiella enheter.

Steg 4: Definiera metadata för revisionsbevis

Policy för revision och regelefterlevnadsövervakning – SME, avsnitt 6.2.3 anger:

Metadata (t.ex. vem som samlade in dem, när och från vilket system) ska dokumenteras.

För sårbarhetsbevis bör paketet fånga:

• Skannerns namn och konfiguration
• Datum och tid för skanning
• Tillgångsomfattning och undantag
• Kritiska och höga iakttagelser
• Ärendenummer och ägare
• Beslut om patch eller riskbegränsning
• Beslut om riskacceptans, där tillämpligt
• Datum för åtgärdande
• Valideringsskanning
• Länk till ändringspost
• Undantagsägare och utgångsdatum

Steg 5: Lägg till loggningsbevis

Loggnings- och övervakningspolicy – SME, avsnitt 5.4.4 omfattar systemloggar såsom:

Systemloggar: konfigurationsändringar, administrativa åtgärder, programvaruinstallationer, patchningsaktivitet

Ett patchärende ensamt kanske inte bevisar att ändringen genomfördes. Konfigurationsloggar, administrativa åtgärder och registreringar av programvaruinstallationer stärker beviskedjan.

Steg 6: Genomför en urvalsrevision

Välj fem kritiska eller höga sårbarheter från föregående kvartal. För varje post, verifiera att tillgången fanns i tillgångsförteckningen, att skannern detekterade iakttagelsen, att ett ärende öppnades inom avtalad servicenivå, att en ägare tilldelades, att åtgärdandet motsvarade allvarlighetsgrad och exploaterbarhet, att loggar visar ändringen, att validering bekräftar stängning och att eventuellt undantag har godkänts av riskägaren med ett utgångsdatum.

Den sprinten producerar ett NIS2-anpassat bevispaket för sårbarheter och ett urval för ISO 27001:2022-internrevision.

Leverantörssäkerhet är ekosystemstyrning

NIS2 artikel 21 kräver säkerhet i leveranskedjan, inklusive säkerhetsaspekter i relationer med direkta leverantörer och tjänsteleverantörer. Den förväntar sig också att organisationer beaktar leverantörssårbarheter, produktkvalitet, leverantörers cybersäkerhetspraxis och säker utvecklingspraxis.

Det var här den första versionen av Marias gaprapport var svagast. Den listade leverantörer, men den bevisade inte leverantörsgranskning, säkerhetsklausuler i avtal, övervakning eller beredskap för leverantörsavveckling.

Policy för leverantörssäkerhet och tredjepartssäkerhet ger policyförankringen. Relaterat genomförande kan stödjas av Policy för säker utveckling, Informationssäkerhetsmedvetenhets- och utbildningspolicy, Policy för sårbarhets- och patchhantering, Policy för kryptografiska kontroller, Åtkomstkontrollpolicy och Policy för distansarbete.

Ett enda leverantörsregister för revisionsbevis kan stödja NIS2, DORA och ISO 27001:2022.

Tabellen förhindrar dubbla frågeformulär, dubbla register och motsägelsefullt kontrollägarskap.

Ett incidentarbetsflöde för NIS2, DORA och GDPR

NIS2 artikel 23 kräver att betydande incidenter anmäls utan onödigt dröjsmål. Artikeln fastställer en stegvis tidslinje: tidig varning inom 24 timmar från kännedom, incidentanmälan inom 72 timmar med initial bedömning av allvarlighetsgrad eller påverkan samt tillgängliga indikatorer på kompromettering, mellanliggande uppdateringar om de begärs och en slutrapport senast en månad efter incidentanmälan.

DORA har en liknande livscykel för finansiella enheter: detektering, klassificering, loggning, bedömning av allvarlighetsgrad, eskalering, kundkommunikation, myndighetsrapportering, rotorsaksanalys och åtgärdande. GDPR lägger till analys av personuppgiftsincident, inklusive roller som personuppgiftsansvarig och personuppgiftsbiträde, påverkan på registrerade och 72-timmarsfristen för anmälan där tillämpligt.

Rätt utformning är inte tre incidentprocesser. Det är ett incidentarbetsflöde med regulatoriska beslutsgrenar.

Policy för incidenthantering – SME, avsnitt 5.4.1 anger:

Alla incidentutredningar, iakttagelser och korrigerande åtgärder ska registreras i ett incidentregister som underhålls av VD.

Ett starkt incidentregister bör innehålla:

GDPR-kopplingen ska inte underskattas. Behöriga myndigheter enligt NIS2 kan informera tillsynsmyndigheter enligt GDPR när brister i hantering av cybersäkerhetsrisker eller rapportering kan medföra en personuppgiftsincident. ISMS bör därför göra integritetsbedömning till en del av incidenttriage, inte till en efterhandsfråga.

Hur revisorer och tillsynsmyndigheter testar ert NIS2-underlag

En organisation med beredskap för 2026 bör förvänta sig att samma kontroll testas genom olika perspektiv.

En ISO 27001:2022-revisor börjar med ISMS. Revisorn frågar om NIS2-skyldigheter har identifierats som krav från intressenter, om ISMS-omfattningen täcker relevanta tjänster och beroenden, om risker bedöms och behandlas, om tillämplighetsförklaringen motiverar tillämpliga kontroller och om registreringar bevisar drift.

En behörig NIS2-myndighet fokuserar på rättsliga utfall. Den kan fråga om alla åtgärder i artikel 21 har hanterats, om kontrollerna är lämpliga och proportionerliga, om ledningen har godkänt och utövar tillsyn över åtgärderna och om incidentrapporteringen kan uppfylla föreskrivna tidsfrister.

En DORA-tillsynsmyndighet testar, för berörda finansiella enheter, IKT-riskhantering, incidentklassificering, resiliensprovning, tredjepartsrisk, avtalsarrangemang, koncentrationsrisk och exitstrategier.

En GDPR-granskare testar om tekniska och organisatoriska åtgärder skyddar personuppgifter, om bedömning av personuppgiftsincident är inbyggd i incidenthanteringen, om roller som personuppgiftsansvarig och personuppgiftsbiträde är tydliga och om registreringar för ansvarsskyldighet finns.

En granskare enligt NIST CSF 2.0 eller COBIT 2019 fokuserar på styrning, riskägarskap, prestandamått, nuläge och målläge, processförmåga och anpassning till organisationens riskaptit.

Den företagsövergripande Policy för revision och regelefterlevnadsövervakning, avsnitt 3.4 fångar syftet med revisionsbevis:

Att generera försvarbara revisionsbevis och ett revisionsspår till stöd för regulatoriska förfrågningar, rättsprocesser eller förfrågningar om säkerhetsförsäkran från kunder.

Det är den operativa standard som NIS2-team bör bygga mot.

Ledningens ansvarsskyldighet: styrelsen kan inte delegera bort NIS2

NIS2 artikel 20 kräver att ledningsorgan för väsentliga och viktiga enheter godkänner åtgärder för hantering av cybersäkerhetsrisker, utövar tillsyn över genomförandet och får utbildning. Ledamöter i ledningsorgan kan hållas ansvariga för överträdelser, med förbehåll för nationella ansvarsregler.

Detta ligger i linje med ledarskapskraven i ISO 27001:2022. Högsta ledningen ska säkerställa att informationssäkerhetspolicyn och målen ligger i linje med strategisk inriktning, integrera ISMS-krav i verksamhetsprocesser, tillhandahålla resurser, kommunicera betydelse, tilldela ansvar och främja ständig förbättring.

En styrelse behöver inte råexporter från skannrar eller fullständiga SIEM-loggar. Den behöver beslutsunderlag med säkerhetsförsäkran.

Ett kvartalsvis NIS2-underlagspaket till styrelsen bör omfatta:

1. Ändringar i omfattning och regulatorisk status
2. De största NIS2-riskerna och behandlingsstatus
3. Kontrollpanel för kontrolleffektivitet enligt artikel 21
4. Betydande incidenter, nära-händelser och rapporteringsbeslut
5. Undantag avseende leverantörs- och molnrisk
6. Internrevisionsiakttagelser, korrigerande åtgärder och försenade revisionsbevis

Detta paket ger ledningen den information som behövs för att godkänna åtgärder, ifrågasätta undantag och acceptera kvarstående risk.

Clarysecs operativa modell för 2026

Att operationalisera tekniska NIS2-åtgärder med ISO 27001:2022 kräver en enkel men disciplinerad modell:

• Omfatta NIS2, DORA, GDPR och avtalsmässiga skyldigheter i ISMS
• Mappa skyldigheter till risker, policyer, kontroller, ägare och revisionsbevis
• Använd tillämplighetsförklaringen som kontrollernas sanningskälla
• Bygg bevispaket för högriskområden i artikel 21
• Integrera incidentrapportering i ett regulatoriskt arbetsflöde
• Behandla leverantörssäkerhet som en livscykel, inte som ett frågeformulär
• Genomför internrevisioner med verkliga urval
• Rapportera kontrolleffektivitet till ledningsorgan
• Förbättra baserat på incidenter, revisionsiakttagelser, tester och regulatoriska ändringar

För Maria var vändpunkten insikten att hon inte behövde ett separat NIS2-projekt. Hon behövde en starkare ISMS-motor för revisionsbevis.

Clarysecs policyer, Zenith Blueprint och Zenith Controls är utformade för att fungera tillsammans. Policyer definierar förväntat beteende och registreringar. Zenith Blueprint ger den 30-stegiga vägen för införande och revision. Zenith Controls tillhandahåller mappningen för samordnad efterlevnad så att NIS2, ISO 27001:2022, DORA, GDPR, NIST CSF och COBIT-baserad säkerhetsförsäkran kan hanteras som ett sammanhållet program.

Nästa steg: bygg er beviskarta från NIS2 till ISO 27001:2022

Om ert NIS2-arbete fortfarande finns i ett gapkalkylark är 2026 året då det ska operationaliseras.

Börja med en teknisk högriskåtgärd, till exempel sårbarhetshantering, incidenthantering eller leverantörssäkerhet. Mappa den till ISO 27001:2022-risker, policyer, Annex A-kontroller, ägare, procedurer och revisionsbevis. Ta sedan ett urval från föregående kvartals registreringar och ställ en svår fråga: skulle detta tillfredsställa en tillsynsmyndighet, en kundgranskare och en ISO 27001:2022-revisor?

Clarysec kan hjälpa er att bygga det svaret med hjälp av policybiblioteket, Zenith Blueprint och Zenith Controls.

Målet är inte mer dokumentation. Målet är försvarbara och repeterbara revisionsbevis som visar att era tekniska NIS2-åtgärder faktiskt fungerar.