NIS2: styrelsens ansvar – ISO 27001-underlag

E-postmeddelandet landade i Marias inkorg kl. 08:15 en måndagsmorgon. Som CISO hos en snabbväxande europeisk leverantör av molntjänster var hon van vid brådskande meddelanden, men det här kändes annorlunda.
Finanschefen hade vidarebefordrat en kunds säkerhetsfrågeformulär till vd:n, styrelsesekreteraren och Maria. Ämnesraden var kort: ”Underlag för ledningsorganets NIS2-ansvar krävs före förnyelse.”
Kunden bad inte om ännu en rapport från penetrationstestning. De ville veta om styrelsen hade godkänt riskhanteringsåtgärder för cybersäkerhet, hur genomförandet övervakades, om ledande befattningshavare hade fått utbildning i cyberrisk, hur betydande incidenter eskalerades och hur leverantörsrisker granskades på ledningsnivå. Vd:n lade till en rad: ”Maria, vilken exponering har vi och hur visar vi vederbörlig omsorg? Styrelsen behöver detta nästa vecka.”
Det är då NIS2 blir konkret för många leverantörer inom SaaS, molntjänster, MSP, MSSP, datacenter, fintech och digital infrastruktur. Direktiv (EU) 2022/2555 behandlar inte cybersäkerhet som ett problem för en teknisk avdelning. Det gör cyberrisk till en fråga om ansvar för ledningsorganet.
NIS2 Article 20 kräver att ledningsorgan i väsentliga och viktiga entiteter godkänner riskhanteringsåtgärder för cybersäkerhet, övervakar genomförandet och genomgår utbildning. Det ger också medlemsstaterna möjlighet att fastställa ansvar vid överträdelser. Article 21 anger därefter den praktiska baslinjen: riskanalys, säkerhetspolicyer, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker anskaffning och utveckling, effektivitetsbedömning, cyberhygien, utbildning, kryptografi, HR-säkerhet, åtkomstkontroll, tillgångshantering och autentisering.
För organisationer som redan använder ISO/IEC 27001:2022 är strukturen välbekant. Skillnaden ligger i målgruppen och kraven på underlag. Frågan är inte längre bara: ”Har vi säkerhetskontroller?” Den är: ”Kan styrelsen visa att den har godkänt, förstått, finansierat, granskat, ifrågasatt och förbättrat dessa kontroller?”
Det är här ISO/IEC 27001:2022 blir ett försvarbart styrningssystem. Clarysecs metod är att använda ISO/IEC 27001:2022 som bevisstruktur, Zenith Blueprint: en revisors färdplan i 30 steg Zenith Blueprint som genomförandeväg, Clarysec-policyer som styrelseanpassade artefakter och Zenith Controls: vägledning för tvärgående regelefterlevnad Zenith Controls som mappningsvägledning mellan ramverk för NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 och revisionsförväntningar.
Varför NIS2 förändrar cybersäkerhetsdialogen på styrelsenivå
NIS2 kräver inte att styrelseledamöter blir brandväggsingenjörer. Det kräver att de styr. Den skillnaden är avgörande.
En CISO kan visa sårbarhetsrapporter, MFA-täckning, kontrollpaneler för slutpunktsskydd och poäng för säkerhetsläge i molnmiljö. Det är användbara operativa signaler, men de visar inte automatiskt ledningsorganets tillsyn. En tillsynsmyndighet, företagskund, certifieringsrevisor eller granskare från finanssektorn kommer att leta efter en kedja av styrningsunderlag:
- Organisationen har bedömt om NIS2 är tillämpligt och dokumenterat grunden.
- Styrelsen eller högsta ledningen har godkänt ramverket för riskhantering av cybersäkerhet.
- Riskaptit och toleranströsklar har definierats.
- Höga cyberrisker har eskalerats och granskats.
- Riskbehandlingsbeslut har godkänts, inklusive accepterad kvarstående risk.
- Rutiner för incidentrapportering återspeglar skyldigheter om 24 timmar, 72 timmar och slutrapport där det är tillämpligt.
- Leverantörs- och molnberoenden är kartlagda och styrda.
- Ledningens genomgång omfattar revisionsiakttagelser, incidenttrender, mätetal och förbättringsåtgärder.
- Ledande befattningshavare har fått utbildning som motsvarar deras ansvar.
- Beslut, undantag och eskaleringar är spårbara.
Det är här många äldre säkerhetsmodeller brister. Att köpa ett ”NIS2-kompatibelt” verktyg visar inte styrelsetillsyn. Att underteckna en policy och arkivera den visar inte genomförande. Att helt delegera cybersäkerhet till CISO uppfyller inte ledningsorganets tillsynsansvar.
ISO/IEC 27001:2022 löser detta problem eftersom standarden beskriver informationssäkerhet som ett strategiskt, riskbaserat ledningssystem integrerat i organisationens processer. Klausulerna om kontext, intressenter, rättsliga skyldigheter, omfattning, ledarskap, riskbedömning, riskbehandling, operativ styrning, prestandautvärdering, internrevision, ledningens genomgång och ständig förbättring skapar den struktur som en styrelse behöver för att visa vederbörlig omsorg.
Zenith Blueprint gör detta praktiskt i fasen ISMS Foundation & Leadership, steg 3:
”Klausul 5.1 handlar helt om ledarskap och åtagande. ISO 27001 kräver att högsta ledningen visar ledarskap genom att stödja ISMS, tillhandahålla resurser, främja medvetenhet, säkerställa att roller tilldelas, integrera ISMS i verksamhetsprocesser och stödja ständig förbättring.”
Det är den operativa modellen bakom NIS2 Article 20. Styrelsen behöver inte godkänna varje tekniskt ärende, men den ska godkänna styrningsmodellen, förstå väsentliga risker, säkerställa resurser och övervaka genomförandet.
Det styrelseunderlag som NIS2 faktiskt kräver
Ett vanligt misstag är att behandla NIS2-underlag som ett juridiskt PM plus en policymapp. Det räcker sällan för en seriös granskare. Styrelseansvar kräver bevis på aktiv styrning, inte passiv dokumentation.
Ett starkt NIS2-underlag för styrelsen ska koppla rättsliga skyldigheter till styrelsebeslut, kontroller och granskningscykler.
| Underlagsartefakt | Fråga om styrelsens ansvar som besvaras | ISO/IEC 27001:2022-ankare | Clarysec-källa |
|---|---|---|---|
| NIS2-tillämplighetsbedömning | Är vi väsentliga, viktiga, indirekt exponerade eller utanför omfattningen? | Klausuler 4.1 till 4.4 | Zenith Blueprint, steg 1 och steg 2 |
| ISMS-omfattning och beroendekarta | Vilka tjänster, platser, leverantörer, gränssnitt och processer styrs? | Klausuler 4.1 till 4.4 | Zenith Blueprint, ISMS Foundation-fasen |
| Cyberriskregister | Vilka är våra största cyberrisker och vem äger dem? | Klausuler 6.1.1 och 6.1.2 | Riskhanteringspolicy |
| Riskbehandlingsplan och SoA | Vilka kontroller har valts, varför och vem godkände kvarstående risk? | Klausul 6.1.3 | Zenith Blueprint, steg 13 |
| Styrelseprotokoll och beslutslogg | Har ledningen godkänt, ifrågasatt och övervakat åtgärderna? | Klausuler 5.1, 5.3, 9.3 | Policy för styrningsroller och ansvar |
| Rutin för incidenteskalering och rapportering | Kan vi uppfylla NIS2:s stegvisa rapporteringstider? | Klausuler 8.1, 9.1, incidentkontroller i bilaga A | Verktygslåda för incidenthantering och ledningens genomgång |
| Riskpanel för leverantörer | Styrs kritiska leverantörer och molnberoenden? | Klausul 8.1 och leverantörskontroller i bilaga A | Zenith Controls tvärmappning |
| Register över ledningsutbildning | Har ledningsorganets medlemmar genomgått lämplig utbildning? | Klausul 7.2 och medvetenhetskontroller | Informationssäkerhetsmedvetenhets- och utbildningspolicy |
| Resultat från internrevision och ledningens genomgång | Kontrolleras och förbättras genomförandet oberoende? | Klausuler 9.2, 9.3, 10.1 | Policy för revision och regelefterlevnadsövervakning - SME |
Styrkan i detta paket är spårbarhet. Varje artefakt besvarar en styrningsfråga och pekar på en mekanism i ISO/IEC 27001:2022. Det ger CISO, vd och styrelse en försvarbar berättelse: cybersäkerhet är inte en samling verktyg, utan ett styrt system.
Att omsätta policyer till ansvar på styrelsenivå
I inledningsscenariot kan Marias vd frestas att svara kunden med ett ISO-certifikat och några policyer. Det räcker inte för NIS2:s krav på ledningsorganets ansvar. Organisationen behöver underlag som visar att ansvar har tilldelats, beslut har dokumenterats och risker eskaleras objektivt.
Clarysec-policyer är utformade för att skapa den spårbarheten.
För mindre organisationer anger Information Security Policy-sme Informationssäkerhetspolicy - SME, klausul 4.1.1, att högsta ledningen:
”Behåller det övergripande ansvaret för informationssäkerhet.”
Den meningen är viktig. Den förhindrar ett vanligt antimönster där grundare, vd:ar eller ledningsgrupper informellt delegerar allt säkerhetsansvar till IT utan att själva utöva meningsfull tillsyn.
För större organisationer anger Riskhanteringspolicy Riskhanteringspolicy, klausul 4.1.1, att ledningen:
”Godkänner riskhanteringsramverket och definierar godtagbar riskaptit och toleranströsklar.”
Det är styrelseanpassat underlag för NIS2 Article 20. En riskaptitförklaring, toleranströsklar och en formell riskbefogenhetsmodell visar hur godkännande och eskalering fungerar i praktiken.
Samma policys klausul 5.6 tillägger:
”Riskbefogenhetsmatrisen ska tydligt definiera tröskelvärden för eskalering till högsta ledningen eller styrelsen.”
Detta är en av de viktigaste artefakterna för NIS2-styrning. Utan eskaleringströsklar ser styrelsen bara det som någon väljer att eskalera. Med trösklar flyttas hög kvarstående risk, olösta kritiska sårbarheter, betydande leverantörskoncentration, större incidenter, revisionsiakttagelser och undantag över toleransnivån automatiskt in i ledningens tillsyn.
Policy för styrningsroller och ansvar Policy för styrningsroller och ansvar förstärker beviskedjan:
”Styrning ska stödja integration med andra discipliner (t.ex. risk, juridik, IT, HR), och ISMS-beslut ska kunna spåras till sin källa (t.ex. revisionsunderlag, granskningsloggar, mötesprotokoll).”
För små och medelstora företag anger Governance Roles and Responsibilities Policy-sme Policy för styrningsroller och ansvar - SME:
”Alla betydande säkerhetsbeslut, undantag och eskaleringar måste dokumenteras och vara spårbara.”
Dessa klausuler omvandlar styrelsetillsyn från ett samtal till ett revisionsspår.
Beviskedjan enligt ISO/IEC 27001:2022 för NIS2 Article 20
En styrelse kan operationalisera NIS2 Article 20 genom en tydlig beviskedja enligt ISO/IEC 27001:2022.
Först ska kontext och omfattning fastställas. ISO/IEC 27001:2022 kräver att organisationen fastställer interna och externa frågor, intressenter, rättsliga, regulatoriska och avtalsmässiga krav, ISMS-gränser, gränssnitt, beroenden och samverkande processer. För en SaaS- eller molnleverantör bör ISMS-omfattningen uttryckligen identifiera EU-tjänster, molnmiljöer, supportverksamhet, kritiska leverantörer, reglerade kundsegment och NIS2-exponering.
Därefter ska ledarskap visas. ISO/IEC 27001:2022 kräver att högsta ledningen anpassar säkerhetsmål till strategisk inriktning, integrerar ISMS-krav i verksamhetsprocesser, tillhandahåller resurser, kommunicerar betydelsen, tilldelar ansvar och främjar ständig förbättring. För NIS2 blir detta underlag för att ledningsorganet har godkänt och övervakat riskhanteringsåtgärder för cybersäkerhet.
Därefter ska riskbedömning och riskbehandling genomföras på ett repeterbart sätt. ISO/IEC 27001:2022 kräver riskkriterier, riskidentifiering, riskägare, analys av sannolikhet och konsekvens, behandlingsalternativ, val av kontroller, jämförelse mot bilaga A, en tillämpbarhetsförklaring, en riskbehandlingsplan och godkännande av kvarstående risk.
Zenith Blueprint, riskhanteringsfasen, steg 13, gör godkännandepunkten tydlig:
”Ledningens godkännande: Riskbehandlingsbeslut och SoA bör granskas och godkännas av högsta ledningen. Ledningen bör få en genomgång av nyckelrisker och föreslagna behandlingar, risker som föreslås för acceptans samt de kontroller som planeras för genomförande.”
För NIS2 bör den genomgången inte vara en engångsinsats. Styrelsepaketet bör visa aktuella topprisker, trender, framdrift i riskbehandling, accepterad kvarstående risk, försenade åtgärder, kritisk leverantörsexponering, incidentteman och centrala effektivitetsmått.
Därefter ska verksamheten drivas och underlag bevaras. ISO/IEC 27001:2022 klausul 8.1 kräver operativ planering och styrning. Kontrollerna i bilaga A stödjer leverantörssäkerhet, molnstyrning, incidentrespons, verksamhetskontinuitet, sårbarhetshantering, säkerhetskopiering, loggning, övervakning, säker utveckling, applikationssäkerhet, arkitektur, testning, outsourcing, funktionsseparering och ändringshantering.
Slutligen ska organisationen utvärdera och förbättra. Internrevision, mätning, ledningens genomgång, korrigerande åtgärder och ständig förbättring omvandlar en kontrollkatalog till ett styrt system.
Organisationens Informationssäkerhetspolicy Informationssäkerhetspolicy bäddar in denna förväntan på ledningens genomgång:
”Ledningens genomgångsaktiviteter (enligt ISO/IEC 27001 klausul 9.3) ska genomföras minst årligen och ska omfatta:”
Värdet ligger inte bara i att ett möte hålls. Värdet ligger i att genomgången skapar underlag: indata, beslut, åtgärder, ägare, tidsfrister och uppföljning.
Audit and Compliance Monitoring Policy-sme Policy för revision och regelefterlevnadsövervakning - SME, klausul 5.4.3, sluter cirkeln:
”Revisionsiakttagelser och statusuppdateringar måste ingå i processen för ledningens genomgång av ISMS.”
Det är skillnaden mellan ”vi hade en revision” och ”ledningen granskade revisionsresultat och beslutade om åtgärdande.”
Tvärgående efterlevnadsmappning: NIS2, DORA, GDPR, NIST CSF 2.0 och COBIT 2019
NIS2 kommer sällan ensamt. En molnleverantör kan behandla personuppgifter enligt GDPR. En fintechkund kan ställa DORA-drivna leverantörskrav. En amerikansk företagskund kan begära anpassning till NIST CSF 2.0. En styrelses revisionskommitté kan använda COBIT 2019 som språk.
Svaret är inte att bygga separata efterlevnadsmappar. Svaret är att använda ISO/IEC 27001:2022 som det centrala systemet för underlag.
Zenith Controls hjälper team att konsolidera genom att mappa ISO/IEC 27002:2022 kontroll 5.4, Ledningens ansvar, över standarder, regelverk och revisionsmetoder.
I Zenith Controls klassificerar posten för ISO/IEC 27002:2022 kontroll 5.4 ”Ledningens ansvar” kontrolltypen som ”förebyggande”, kopplar den till konfidentialitet, riktighet och tillgänglighet samt placerar den under en styrningsfokuserad operativ förmåga.
Det är viktigt eftersom NIS2 Article 20 är förebyggande styrning. Ledningens godkännande och tillsyn minskar sannolikheten för att cyberrisk blir osynlig, underfinansierad eller ohanterad.
Zenith Controls kopplar även ledningens ansvar till närliggande kontroller i ISO/IEC 27002:2022: 5.1 Policyer för informationssäkerhet, 5.2 Informationssäkerhetsroller och ansvar, 5.35 Oberoende granskning av informationssäkerhet, 5.36 Efterlevnad av policyer, regler och standarder för informationssäkerhet samt 5.8 Säkerhet i projektledning. Styrelseansvar kan inte stå ensamt. Det behöver policyer, roller, oberoende granskning, efterlevnadsövervakning och integrering på projektnivå.
Den bredare korsmappningen är särskilt användbar för ledningsrapportering.
| Kravtema | NIS2 | DORA | GDPR | NIST CSF 2.0 | COBIT 2019 | Clarysecs fokus för underlag |
|---|---|---|---|---|---|---|
| Ledningens ansvar | Article 20 godkännande, tillsyn, utbildning, ansvar | Articles 5 och 6 ledningsorganets ansvar och ramverk för IKT-riskhantering | Article 5(2) ansvarsskyldighet och Article 24 ansvar | GOVERN, särskilt GV.RR, GV.RM och GV.OV | EDM03 riskoptimering | Styrelseprotokoll, rollbeskrivningar, utbildningsregister |
| Riskhanteringsåtgärder | Article 21 tekniska, operativa och organisatoriska åtgärder | Ramverk för IKT-riskhantering | Article 32 säkerhet i behandlingen | GOVERN, IDENTIFY, PROTECT | APO13 hanterad säkerhet | Riskregister, behandlingsplan, SoA |
| Incidentrapportering | Article 23 tidig varning, incidentanmälan, slutrapport | Articles 17 till 20 rapportering av större IKT-relaterade incidenter | Articles 33 och 34 anmälan av personuppgiftsincident där tillämpligt | RESPOND och RECOVER | DSS02 hanterade tjänstebegäranden och incidenter | Eskaleringsmatris, åtgärdsplaner, simuleringar |
| Leverantörsstyrning | Article 21(2)(d) säkerhet i leveranskedjan | Articles 28 till 30 IKT-tredjepartsrisk | Personuppgiftsbiträdes- och säkerhetsskyldigheter | GV.SC hantering av cybersäkerhetsrisk i leveranskedjan | APO10 hanterade leverantörer | Leverantörsregister, leverantörsgranskning, avtalskontroller |
| Effektivitet och säkerhet | Article 21(2)(f) policyer och rutiner för att bedöma effektivitet | Article 6 granskning av ramverket för IKT-riskhantering och revisionsförväntningar | Article 32(1)(d) regelbunden testning och utvärdering | GV.OV tillsyn, ID.RA riskbedömning, DE.CM kontinuerlig övervakning | MEA01 och MEA03 övervakning och regelefterlevnad | Internrevision, ledningens genomgång, korrigerande åtgärder |
DORA förtjänar särskild uppmärksamhet. NIS2 Article 4 erkänner att sektorsspecifika EU-rättsakter kan tränga undan överlappande NIS2-bestämmelser där likvärdiga riskhanteringsåtgärder för cybersäkerhet eller incidentanmälningsåtgärder gäller. DORA är nyckelexemplet för finansiella entiteter. Den gäller från den 17 januari 2025 och skapar ett enhetligt ramverk för IKT-riskhantering, incidentrapportering, resiliensprovning, tredjepartsriskhantering och tillsyn för finansiella tjänster.
En SaaS- eller molnleverantör är kanske inte direkt reglerad som en bank, men DORA kan ändå komma in via kundavtal. Finansiella entiteter måste hantera IKT-tredjepartsrisk, hålla register över avtal om IKT-tjänster, genomföra leverantörsgranskning, bedöma koncentrationsrisk, inkludera revisions- och inspektionsrättigheter, definiera rätt att säga upp avtalet och upprätthålla exitstrategier. Det innebär att leverantörer som betjänar finansiella kunder bör förvänta sig underlagsbegäranden som liknar NIS2-frågor om styrelsestyrning.
GDPR tillför ansvarsskyldighet för personuppgifter. Article 5(2) kräver att personuppgiftsansvariga ansvarar för och kan visa efterlevnad. Article 32 kräver säkerhet i behandlingen, inklusive regelbunden testning, bedömning och utvärdering av de tekniska och organisatoriska åtgärdernas effektivitet. Där personuppgifter påverkas måste incidentarbetsflöden integrera GDPR-bedömning av personuppgiftsincident med NIS2-eskalering av betydande incidenter.
NIST CSF 2.0 tillför ett ledningsvänligt språk genom funktionen GOVERN. Den betonar organisationens kontext, riskhanteringsstrategi, roller och ansvar, policy, tillsyn och hantering av risker i leveranskedjan. COBIT 2019 tillför en styrningsvokabulär som är välbekant för revisionskommittéer, särskilt genom EDM03 för riskoptimering och MEA-mål för övervakning och säkerhet.
En 90-dagars sprint för styrelseunderlag enligt NIS2
En praktisk underlagssprint kan hjälpa organisationer att komma framåt snabbt utan att skapa parallell byråkrati.
Dag 1 till 30: Fastställ ansvar
Börja med ett NIS2-ansvarsregister som dokumenterar:
- Analys av entitetsklassificering, inklusive motivering för väsentlig, viktig, indirekt exponering eller utanför omfattningen.
- Tjänster inom omfattningen, såsom SaaS, molntjänster, hanterade tjänster, datacenter, DNS, betrodda tjänster eller kommunikationsrelaterade tjänster.
- EU-medlemsstater där tjänster tillhandahålls.
- Berörda kundsektorer, särskilt finansiella tjänster, hälso- och sjukvård, transport, energi, offentlig förvaltning och digital infrastruktur.
- Tillämpliga skyldigheter, inklusive NIS2 Article 20, Article 21 och Article 23.
- Närliggande skyldigheter enligt DORA, GDPR, kundavtal och cyberförsäkring.
- Ledningsägare och frekvens för styrelserapportering.
Koppla detta till kontexten enligt ISO/IEC 27001:2022, intressenter, register över skyldigheter och ISMS-omfattning. Uppdatera därefter riskbefogenhetsmatrisen med stöd av kravet i Riskhanteringspolicy att eskaleringströsklar ska definieras för högsta ledningen eller styrelsen.
Användbara eskaleringstriggers omfattar kvarstående risk över riskaptiten, icke accepterade kritiska sårbarheter efter passerad SLA, leverantörskoncentrationsrisk, olösta höga revisionsiakttagelser, incidenter som kan utlösa NIS2-rapportering, undantag från krav på MFA, säkerhetskopiering, loggning, kryptering eller incidentrespons samt väsentliga förändringar i molnarkitekturen.
Dag 31 till 60: Godkänn riskbehandling
Använd Zenith Blueprint steg 13 för att ta fram ett beslutsunderlag till styrelsen för riskbehandlingsplanen och tillämpbarhetsförklaringen. Paketet bör omfatta:
- De 10 största cyberriskerna.
- Föreslaget behandlingsalternativ för varje risk.
- Valda kontrollgrupper.
- Kvarstående risk efter behandling.
- Risker som föreslås för acceptans.
- Nödvändiga budget- eller resursbeslut.
- Beroenden till leverantörer, juridik, HR, produkt och IT.
- Begärt ledningsbeslut.
Resultatet bör vara ett undertecknat eller protokollfört godkännande. Ett presentationsmaterial räcker inte.
Mappa även åtgärderna i NIS2 Article 21 till ISO/IEC 27001:2022-klausuler och kontroller i bilaga A. Det gör att organisationen kan visa att NIS2 hanteras genom ISMS, inte genom en frikopplad checklista.
Dag 61 till 90: Testa incidentrapportering och granska underlag
NIS2 Article 23 kräver stegvis rapportering av betydande incidenter: tidig varning inom 24 timmar, incidentanmälan inom 72 timmar, mellanliggande uppdateringar där det krävs eller begärs samt en slutrapport senast en månad efter anmälan.
Genomför en skrivbordsövning med styrelsesponsor, vd, CISO, juridik, kommunikation, kundansvar och drift. Använd ett realistiskt scenario, exempelvis en felkonfiguration i molnmiljö som exponerar kundmetadata, stör tjänstens tillgänglighet och påverkar en reglerad kund.
Testa vem som beslutar om incidenten kan vara betydande, vem som kontaktar juridisk rådgivare, vem som underrättar behöriga myndigheter eller CSIRT där det krävs, vem som godkänner kundkommunikation, hur bevismaterial bevaras, hur GDPR-skyldigheter vid personuppgiftsincident bedöms parallellt och hur styrelsen uppdateras under de första 24 timmarna.
Håll därefter en formell ledningens genomgång. Zenith Blueprint, fasen Audit, Review & Improvement, steg 28, förklarar varför:
”Ledningens genomgång är inte bara en presentation; den handlar om att fatta beslut.”
Den genomgången bör omfatta revisionsiakttagelser, framdrift i riskbehandling, incidentberedskap, leverantörsrisker, mätetal, beslut, tilldelade åtgärder och ansvariga för uppföljning.
Ledningens genomgång som faktiskt fungerar
Många genomgångar från ledningen misslyckas eftersom de är strukturerade som statusuppdateringar. En NIS2-redo ledningens genomgång bör vara ett beslutsmöte.
Agendan bör omfatta:
- Förändringar i NIS2, DORA, GDPR, avtalskrav och kundkrav.
- Förändringar i verksamhetskontext, tjänster, förvärv, leverantörer, molnarkitektur och reglerade kundsegment.
- Status för de största informationssäkerhetsriskerna och kvarstående risk jämfört med riskaptit.
- Framdrift i riskbehandlingsplanen och försenade åtgärder.
- Incidenttrender, betydande händelser, nära-händelser och rapporteringsberedskap.
- Leverantörs- och IKT-beroenderisker, inklusive koncentrations- och exitfrågor.
- Resultat från internrevisioner, externa revisioner, kundgranskningar och penetrationstester.
- Genomförande av säkerhetsmedvetenhetsutbildning och ledningsutbildning.
- Mätetal för åtkomstkontroll, sårbarhetshantering, säkerhetskopiering, loggning, övervakning, säker utveckling och kontinuitetstester.
- Beslut som krävs, inklusive riskacceptans, budget, bemanning, policyundantag, leverantörsåtgärder och kontrollförbättringar.
Ledningsutbildning är särskilt viktig. NIS2 Article 20 kräver att ledningsorganets medlemmar genomgår utbildning. Informationssäkerhetsmedvetenhets- och utbildningspolicy Informationssäkerhetsmedvetenhets- och utbildningspolicy, klausul 5.1.2.4, inkluderar uttryckligen ämnen för ledningsutbildning:
”Ledande befattningshavare (t.ex. styrning, riskacceptans, rättsliga skyldigheter)”
Ledningsutbildning i cyberfrågor bör fokusera på beslutsmandat, ansvar, eskalering, riskaptit, krisstyrning, incidentrapportering och regulatoriska skyldigheter. Den bör inte begränsas till nätfiskemedvetenhet.
Hur revisorer och kunder testar styrelsetillsyn
Olika granskare använder olika språk, men de testar samma underliggande fråga: är cybersäkerheten styrd?
Zenith Controls är värdefullt eftersom det inkluderar mappningar till revisionsmetodik. För ledningens ansvar hänvisar det till revisionsprinciper och genomförande enligt ISO/IEC 19011:2018, ISMS-revisionspraxis enligt ISO/IEC 27007:2020, ISO/IEC 27001:2022 klausul 5.1, COBIT 2019 EDM01 och EDM03, ISACA ITAF avsnitt 1401 samt NIST SP 800-53A PM-1 och PM-2. För oberoende granskning mappar det till ISO/IEC 27001:2022 klausuler 9.2 och 9.3, revisionsplanering och bevispraxis enligt ISO/IEC 27007, ISACA ITAF avsnitt 2400 och NIST:s bedömningsmetoder. För efterlevnad av policyer mappar det till ISO/IEC 27001:2022 klausuler 9.1, 9.2 och 10.1, bevisinsamling enligt ISO/IEC 19011, COBIT 2019 MEA01 och NIST:s bedömning av kontinuerlig övervakning.
| Revisorsperspektiv | Vad de frågar | Underlag de förväntar sig | Vanlig brist |
|---|---|---|---|
| ISO/IEC 27001:2022-revisor | Hur visar högsta ledningen ledarskap, godkänner riskbehandling och granskar ISMS-prestanda? | Policygodkännanden, riskregister, SoA-godkännande, protokoll från ledningens genomgång, resultat från internrevision | Ledningens genomgång finns men saknar beslut eller åtgärdsuppföljning |
| NIS2-fokuserad granskare | Har ledningsorganet godkänt cybersäkerhetsåtgärder och övervakat genomförandet? | Styrelseprotokoll, eskaleringsmatris, register över ledningsutbildning, Article 21-baslinjemappning | Säkerhetsåtgärder har endast godkänts av CISO, utan spårbarhet till styrelsen |
| NIST CSF 2.0-granskare | Är styrningsresultat, riskaptit, roller, resurser, tillsyn och risk i leveranskedjan integrerade i verksamhetens riskhantering? | Aktuella profiler och målprofiler, gapplan, ledningsrapportering, mätetal | NIST används som checklista utan styrningsägarskap |
| COBIT 2019- eller ISACA-revisor | Utvärderar, leder och övervakar styrningen hanteringen av cyberrisk? | Styrningsstadgar, riskaptit, ledningsrapportering, resultat från säkerhetsgranskning | Styrelsen får tekniska mätetal men inget sammanhang för riskbeslut |
| DORA-kund eller granskare från finanssektorn | Är IKT-risker, incidenter, resiliens och tredjepartsberoenden styrda och dokumenterade? | IKT-beroendekarta, leverantörsregister, leverantörsgranskning, revisionsrätt, incidentlivscykel | Leverantörsrisk hanteras endast genom frågeformulär, utan koncentrations- eller exitanalys |
| GDPR-revisor eller integritetsgranskare | Kan organisationen visa säkerhet och ansvarsskyldighet för behandling av personuppgifter? | Datakartor, modell för rättslig grund, process för bedömning av personuppgiftsincident, säkerhetskontroller | Integritets- och säkerhetsunderlag är separerade och inkonsekventa |
Lärdomen är enkel. Styrelseansvar visas inte enbart genom närvaro. Det visas genom informerade beslut, dokumenterade godkännanden, riskbaserad prioritering, resursallokering och uppföljning.
Vanliga fallgropar som bryter beviskedjan
De organisationer som har svårt med NIS2:s krav på ledningsorganets ansvar hamnar oftast i förutsägbara mönster.
För det första blandar de ihop teknisk drift av kontroller med styrning. MFA-täckning, SIEM-larm, EDR-driftsättning och andel lyckade säkerhetskopieringar är viktiga, men styrelsen behöver risksammanhang, behandlingsbeslut och säkerhet om att kontrollerna fungerar.
För det andra godkänner de policyer men inte riskbehandling. En undertecknad säkerhetspolicy visar inte att styrelsen har godkänt proportionerliga cybersäkerhetsåtgärder. Riskbehandlingsplanen och SoA är starkare underlag eftersom de kopplar samman risker, kontroller, kvarstående risk och ledningens godkännande.
För det tredje saknar de eskaleringströsklar. Utan en riskbefogenhetsmatris blir eskalering beroende av personer. NIS2-styrning kräver objektiva utlösare.
För det fjärde separerar de incidentrespons från regulatorisk rapportering. Rapporteringsarbetsflöden för NIS2, DORA och GDPR måste integreras före en kris.
För det femte förbiser de leverantörsstyrning. NIS2 Article 21 omfattar säkerhet i leveranskedjan och hänsyn till leverantörers sårbarheter. DORA-drivna kunder kan förvänta sig mer långtgående IKT-tredjepartsstyrning, inklusive leverantörsgranskning, revisionsrätt, koncentrationsrisk, rätt att säga upp avtalet och exitstrategier.
För det sjätte utbildar de inte ledande befattningshavare. Ledningsutbildning i cyberfrågor är inte valfri symbolik enligt NIS2. Den är en del av styrningens beviskedja.
Så ser ett bra läge ut
Efter 90 dagar bör en trovärdig NIS2-underlagsmapp för styrelsen innehålla:
- Tillämplighetsbedömning.
- ISMS-omfattning och register över skyldigheter.
- Uttalande om ledarskap och åtagande.
- Riskaptit och toleranströsklar.
- Riskbefogenhetsmatris.
- Cyberriskregister.
- Riskbehandlingsplan.
- Tillämpbarhetsförklaring.
- Styrelsens godkännandeprotokoll.
- Register över ledningsutbildning.
- Rapport från incidentrelaterad skrivbordsövning.
- Riskpanel för leverantörer.
- Internrevisionsrapport.
- Protokoll från ledningens genomgång och åtgärdsuppföljning.
Den här mappen besvarar kundens frågeformulär som Maria fick på måndagsmorgonen. Ännu viktigare är att den hjälper styrelsen att styra cyberrisk innan en incident, revision eller tillsynsmyndighet testar organisationen offentligt.
Gör NIS2-styrelseansvar till revisionsredo styrning
NIS2 har förändrat cybersäkerhetsdialogen. Ledningsorgan måste godkänna riskhanteringsåtgärder för cybersäkerhet, övervaka genomförandet och genomgå utbildning. Article 21 kräver en integrerad uppsättning tekniska, operativa och organisatoriska åtgärder. Article 23 pressar samman incidentrapportering till en stegvis tidslinje som kräver förberedelse före krisen.
ISO/IEC 27001:2022 ger dig ledningssystemet. Clarysec ger dig genomförandevägen, policyspråket, mappningarna för tvärgående regelefterlevnad och modellen för revisionsbevis.
Om din styrelse frågar: ”Vad behöver vi godkänna och hur visar vi tillsyn?”, börja med tre åtgärder:
- Använd Zenith Blueprint steg 3, steg 13 och steg 28 för att strukturera ledarskap och åtagande, godkännande av riskbehandling och ledningens genomgång.
- Använd Clarysec-policyer såsom Riskhanteringspolicy, Policy för styrningsroller och ansvar, Informationssäkerhetspolicy och motsvarigheter för små och medelstora företag för att formalisera ansvar och spårbarhet.
- Använd Zenith Controls för att mappa NIS2-styrelsetillsyn till ISO/IEC 27001:2022, ISO/IEC 27002:2022, DORA, GDPR, NIST CSF 2.0, COBIT 2019 och förväntningar enligt revisionsmetodik.
Clarysec kan hjälpa dig att bygga styrelsepaketet, uppdatera ISMS-beviskedjan, förbereda ledningens genomgång och omvandla NIS2-ansvar till en repeterbar styrningsprocess för cyberrisk som revisorer, kunder och ledande befattningshavare förstår. Ladda ned relevanta Clarysec-verktygslådor eller begär en bedömning för att omvandla styrelseansvar till revisionsredo underlag.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


