Preslikava dokazil NIS2 na ISO 27001:2022 za leto 2026

Izziv NIS2 v letu 2026 ni ozaveščenost, temveč dokazljivost

Ponedeljek je, 08:35. Maria, nedavno imenovana vodja informacijske varnosti (CISO) pri hitro rastočem ponudniku B2B storitev v oblaku in ponudniku upravljanih storitev, se pridruži četrtletnemu sestanku organa upravljanja o tveganjih. Na prenosniku ima odprto obsežno oceno vrzeli NIS2. Prvi diapozitiv je videti pomirjujoč. Politike obstajajo. Ocena tveganja obstaja. Odziv na incidente je dokumentiran. Dobavitelji so navedeni. Skeniranje ranljivosti se izvaja vsak mesec.

Nato predsednik postavi vprašanje, ki spremeni potek sestanka:

»Ali lahko dokažemo, da so ti ukrepi v prejšnjem četrtletju delovali, in ali lahko pokažemo, katere kontrole ISO 27001:2022, lastniki in evidence podpirajo vsako obveznost NIS2?«

V prostoru zavlada tišina.

Pravna služba ve, da podjetje spada na področje uporabe NIS2, ker strankam v EU zagotavlja upravljane storitve IKT in storitve v oblaku. Funkcija skladnosti ve, da Article 21 zahteva tehnične, operativne in organizacijske ukrepe za obvladovanje tveganj kibernetske varnosti. Operativa ve, da ekipa namešča popravke, pregleduje dobavitelje in spremlja dnevnike. Toda dokazila so razpršena po sistemih za upravljanje tiketov, izvozih iz SIEM, mapah s politikami, preglednicah, konzolah v oblaku, portalih dobaviteljev in zapiskih s sestankov.

Nihče ne more hitro pokazati zagovorljive verige od NIS2 Article 21 do obsega ISO 27001:2022, tveganja, kontrole, politike, lastnika, postopka, operativnega zapisa in ugotovitve presoje.

To je dejanski izziv leta 2026.

Številne organizacije se ne sprašujejo več: »Ali smo v obsegu NIS2?« Zastavljajo težje vprašanje: »Ali lahko dokažemo, da naši tehnični ukrepi NIS2 dejansko delujejo?« Odgovor ne sme biti enkratna preglednica preslikav. Biti mora živ operativni model znotraj sistema upravljanja informacijske varnosti, v katerem se zakonske obveznosti prevedejo v tveganja, politike, kontrole, lastnike, dokazila in nenehno izboljševanje.

Model Clarysec uporablja ISO/IEC 27001:2022 kot hrbtenico sistema upravljanja, NIS2 Article 21 kot nabor regulativnih obveznosti, klavzule politik kot operativni pravilnik, Zenith Blueprint: 30-koračni načrt presojevalca kot izvedbeno pot in Zenith Controls: vodnik za navzkrižno skladnost kot preslikavo navzkrižne skladnosti za ISO 27001:2022, NIS2, DORA, GDPR, NIST CSF in zagotavljanje zaupanja v slogu COBIT.

Začnite z obsegom, ker se dokazila NIS2 začnejo pred kontrolami

Pogosta napaka pri NIS2 je, da organizacije neposredno preidejo na večfaktorsko avtentikacijo (MFA), beleženje, odziv na incidente in upravljanje ranljivosti, preden potrdijo obseg subjekta, obseg storitev in jurisdikcijski obseg.

NIS2 se uporablja za zajete javne in zasebne subjekte v reguliranih sektorjih, ki izpolnjujejo merila glede velikosti in dejavnosti, pri čemer so nekatere vrste subjektov zajete ne glede na velikost. Ustrezne digitalne in IKT kategorije vključujejo ponudnike storitev računalništva v oblaku, ponudnike storitev podatkovnih centrov, ponudnike omrežij za dostavo vsebin, ponudnike storitev zaupanja, ponudnike javnih elektronskih komunikacij, ponudnike upravljanih storitev, ponudnike upravljanih varnostnih storitev, spletne tržnice, spletne iskalnike in platforme družbenih omrežij.

Za ponudnike storitev v oblaku, platforme SaaS, ponudnike upravljanih storitev, ponudnike upravljanih varnostnih storitev in ponudnike digitalne infrastrukture to določanje obsega ni teoretično. Article 3 zahteva, da države članice razlikujejo med bistvenimi in pomembnimi subjekti. Article 27 zahteva, da ENISA vodi register za več digitalnih in IKT ponudnikov, vključno s ponudniki storitev DNS, registri imen TLD, ponudniki storitev registracije domenskih imen, ponudniki storitev računalništva v oblaku, ponudniki storitev podatkovnih centrov, ponudniki omrežij za dostavo vsebin, ponudniki upravljanih storitev, ponudniki upravljanih varnostnih storitev, spletnimi tržnicami, spletnimi iskalniki in platformami družbenih omrežij.

ISO 27001:2022 zagotavlja ustrezno strukturo. Klavzule 4.1 do 4.4 zahtevajo, da organizacija razume zunanje in notranje dejavnike, zainteresirane strani, zahteve, vmesnike in odvisnosti, nato pa opredeli obseg ISMS. NIS2 mora biti zajet tukaj, ne pa puščen v pravnem memorandumu.

Praktičen zapis o obsegu NIS2 mora vključevati:

• analizo pravne osebe in poslovne enote v EU;
• sektor NIS2 in kategorijo storitve;
• status bistvenega ali pomembnega subjekta, kadar je potrjen z nacionalno zakonodajo ali imenovanjem pristojnega organa;
• relevantnost registra ENISA, kadar je to primerno;
• kritične storitve, zagotovljene strankam;
• omrežne in informacijske sisteme, ki podpirajo te storitve;
• odvisnosti od ponudnikov oblaka, podatkovnih centrov, telekomunikacij, varnostnega spremljanja, identitetnih storitev in programske opreme;
• povezave z DORA, GDPR, pogodbami s strankami in sektorsko specifičnimi obveznostmi;
• repozitorije dokazil, lastnike sistemov in pogostost pregledov.

Tu je treba pravilno razmejiti tudi DORA. NIS2 priznava, da se, kadar sektorski pravni akt EU nalaga enakovredne obveznosti obvladovanja tveganj kibernetske varnosti ali obveščanja o incidentih, namesto ustreznih določb NIS2 uporablja ta sektorski režim. Za zajete finančne subjekte je DORA praviloma operativni režim za kibernetsko varnost in poročanje o incidentih IKT. DORA se uporablja od 17. januarja 2025 in zajema upravljanje tveganj IKT, poročanje o incidentih, testiranje digitalne operativne odpornosti, tveganje tretjih oseb na področju IKT in nadzor nad kritičnimi IKT ponudniki tretjih oseb.

Finančnotehnološka skupina ima zato lahko znotraj ene korporativne strukture različne obravnave skladnosti. Plačilni subjekt je lahko primarno pod DORA. Odvisna družba ponudnika upravljanih storitev je lahko neposredno pod NIS2. Skupna platforma v oblaku lahko podpira oboje. Zrel odgovor niso podvojene kontrole. Zrel odgovor je en model dokazil ISMS, ki lahko podpira več regulativnih pogledov.

ISO 27001:2022 kot operativni sistem skladnosti z NIS2

NIS2 Article 21 zahteva ustrezne in sorazmerne tehnične, operativne in organizacijske ukrepe za obvladovanje tveganj za omrežne in informacijske sisteme ter za preprečevanje ali zmanjšanje vpliva incidentov na prejemnike storitev in druge storitve.

ISO 27001:2022 je za operacionalizacijo te zahteve zelo primeren, ker uveljavlja tri discipline.

Prvič, upravljanje. Klavzule 5.1 do 5.3 zahtevajo zavezanost najvišjega vodstva, uskladitev s strateško usmeritvijo, zagotavljanje virov, komuniciranje, dodelitev odgovornosti in dokumentirano politiko informacijske varnosti. To se neposredno ujema z NIS2 Article 20, ki zahteva, da organi upravljanja odobrijo ukrepe za obvladovanje tveganj kibernetske varnosti, nadzirajo izvajanje in se usposabljajo.

Drugič, obravnava tveganj. Klavzule 6.1.1 do 6.1.3 zahtevajo ponovljiv proces ocenjevanja tveganj, lastnike tveganj, vrednotenje tveganj, možnosti obravnave tveganj, izbiro kontrol, izjavo o uporabnosti, načrt obravnave tveganj in odobritev preostalega tveganja.

Tretjič, operativni nadzor. Klavzula 8.1 zahteva, da organizacija načrtuje, izvaja in nadzoruje procese ISMS, vzdržuje dokumentirane informacije, obvladuje spremembe ter upravlja zunanje zagotovljene procese, produkte in storitve, relevantne za ISMS.

S tem se NIS2 iz pravnega kontrolnega seznama pretvori v operativni model kontrol.

Vsaka vrstica potrebuje lastnika, vir zapisov in metodo vzorčenja. Če ti elementi manjkajo, ima organizacija namen vzpostaviti kontrolo, ne pa delujoče kontrole.

Politika je mesto, kjer NIS2 postane operativno ravnanje

Politike se pogosto obravnavajo kot predloge. Pri NIS2 je to nevarno. Regulatorja ali presojevalca mapa politik ne bo prepričala, če politike ne dodeljujejo lastništva, ne opredeljujejo zapisov, se ne povezujejo s tveganji in ne ustvarjajo dokazil.

Korporativna Politika pravne in regulativne skladnosti postavlja temelj v klavzuli 6.2.1:

Vse zakonske in regulativne obveznosti morajo biti preslikane na posebne politike, kontrole in lastnike znotraj sistema upravljanja informacijske varnosti (ISMS).

Ta klavzula je most med NIS2 in ISO 27001:2022. NIS2 Article 21 ni zgolj naveden kot zunanja zahteva. Razčlenjen je na obveznosti iz politik, preslikan na kontrole, dodeljen lastnikom in preverjen z dokazili.

Za manjše organizacije Politika pravne in regulativne skladnosti za MSP isti koncept ohranja lahek. Klavzula 5.1.1 zahteva:

Generalni direktor mora vzdrževati preprosto, strukturirano evidenco skladnosti, ki navaja:

Stavek je namenoma praktičen. MSP za začetek ne potrebujejo zapletene implementacije GRC. Potrebujejo evidenco skladnosti, ki zajema obveznost, uporabnost, lastnika, politiko, dokazila in pogostost pregledov.

Obravnava tveganja nato obveznost pretvori v ukrepanje. Korporativna Politika upravljanja tveganj, klavzula 6.4.2 določa:

Pooblaščenec za tveganja mora zagotoviti, da so obravnave realistične, časovno omejene in preslikane na kontrole ISO/IEC 27001 Priloga A.

Za MSP Politika upravljanja tveganj za MSP, klavzula 5.1.2, podaja minimalno izvedljiv zapis tveganja:

Vsak vnos tveganja mora vključevati: opis, verjetnost, vpliv, oceno, lastnika in načrt obravnave tveganja.

Te klavzule so pomembne, ker je NIS2 izrecno utemeljen na tveganju in sorazmernosti. Article 21 pričakuje, da ukrepi odražajo stanje tehnike, relevantne standarde, stroške izvedbe, izpostavljenost tveganju, velikost, verjetnost in resnost incidenta, vključno z družbenim in gospodarskim vplivom. Register tveganj brez lastnikov in načrtov obravnave tveganj ne more dokazati sorazmernosti.

Korporativna Politika informacijske varnosti v klavzuli 6.6.1 dopolnjuje načelo dokazil:

Vse implementirane kontrole morajo biti preverljive, podprte z dokumentiranimi postopki in ohranjenimi dokazili o delovanju.

To je razlika med programom NIS2 in programom dokazil NIS2.

Pot Clarysec od preslikave do delovanja

Zenith Blueprint je dragocen, ker odraža način razmišljanja presojevalcev. Ti ne vprašajo le, ali kontrola obstaja. Vprašajo, zakaj je bila izbrana, kje je dokumentirana, kako deluje, kdo je njen lastnik, katera dokazila jo dokazujejo in kako jo organizacija izboljšuje.

V fazi upravljanja tveganj 13. korak ekipam nalaga, naj dodajo sledljivost med tveganji, kontrolami in klavzulami:

✓ Preslikajte kontrole na tveganja: v načrtu obravnave tveganj v vašem registru tveganj ste za vsako tveganje navedli določene kontrole. Vsakemu tveganju lahko dodate stolpec »Sklic na kontrolo iz Priloge A« in navedete številke kontrol.

Za NIS2 to pomeni, da morata register tveganj in izjava o uporabnosti pokazati, zakaj so kontrole, kot so 8.8 upravljanje tehničnih ranljivosti, 5.19 informacijska varnost v odnosih z dobavitelji in 5.24 načrtovanje in priprava upravljanja incidentov, uporabne.

14. korak v Zenith Blueprint regulativno preslikavo naredi izrecno:

Za vsak predpis, če je uporaben, lahko ustvarite preprosto tabelo preslikav (lahko kot prilogo poročilu), ki navaja ključne varnostne zahteve predpisa in ustrezne kontrole/politike v vašem ISMS.

To preprečuje razdrobljenost. Varnost osebnih podatkov po GDPR, poročanje o incidentih po NIS2, testiranje odpornosti IKT po DORA in varnostne zaveze strankam se lahko vsi opirajo na ista dokazila: preglede pravic dostopa, odpravo ranljivosti, zapise beleženja, teste varnostnih kopij, preglede dobaviteljev in poročila o incidentih.

19. korak preide od zasnove k delovanju:

Vsak od teh dokumentov povežite z ustrezno kontrolo v svoji izjavi o uporabnosti ali priročniku ISMS. Ti dokumenti bodo služili kot dokazilo o implementaciji in interna referenca.

Dokumentacijski nabor iz 19. koraka vključuje varnost končnih naprav, upravljanje dostopa, avtentikacijo, varne osnovne konfiguracije, beleženje in spremljanje, upravljanje popravkov, upravljanje ranljivosti, načrtovanje zmogljivosti in poročanje o IT operacijah. To so natanko operativni dokumenti, potrebni za to, da tehnični ukrepi NIS2 postanejo primerni za presojo.

26. korak pojasnjuje, kako je treba zbirati revizijske dokaze:

Ko zbirate dokazila, zabeležite svoje ugotovitve. Zapišite, kje so zadeve skladne z zahtevo (pozitivne ugotovitve) in kje niso (morebitne neskladnosti ali opažanja).

Za NIS2 to pomeni vzorčenje dokazil, preden jih zahteva regulator, ocenjevalec stranke ali certifikacijski presojevalec.

Vloga Zenith Controls pri navzkrižni skladnosti

Zenith Controls ni ločen okvir kontrol. Je Clarysecov vodnik za navzkrižno skladnost pri preslikavi kontrol ISO/IEC 27001:2022 in ISO/IEC 27002:2022 na povezane kontrole, revizijska pričakovanja in zunanje okvire. Ekipam pomaga razumeti, kako lahko ena kontrola ISO 27001:2022 podpira NIS2, DORA, GDPR, NIST CSF 2.0 in zagotavljanje zaupanja v slogu COBIT.

Tri kontrole ISO 27001:2022 so posebej pomembne za preslikavo dokazil NIS2.

Kontrola 5.1 politike informacijske varnosti je vstopna točka, ker NIS2 Article 21 vključuje analizo tveganj in politike varnosti informacijskih sistemov. Če tehnični ukrep NIS2 ni odražen v politiki, ga je težko upravljati in dosledno presojati.

Kontrola 5.36 skladnost s politikami, pravili in standardi informacijske varnosti je preverjanje dejanskega stanja. Zahteve politik povezuje z dejansko skladnostjo z internimi pravili, standardi in zunanjimi obveznostmi. V smislu NIS2 je to mesto, kjer organizacija vpraša, ali dejansko izvaja to, kar njena preslikava Article 21 navaja.

Kontrola 8.8 upravljanje tehničnih ranljivosti je eno najzahtevnejših področij preverjanja v letu 2026. Upravljanje ranljivosti je neposredno relevantno za varno nabavo, razvoj, vzdrževanje, obravnavo ranljivosti in razkritje. Podpira tudi testiranje in odpravo pomanjkljivosti po DORA, odgovornost za varnost po GDPR, izide NIST CSF Identify in Protect ter revizijsko vzorčenje ISO 27001.

Podporni standardi lahko izostrijo zasnovo brez zahteve po dodatnih certifikacijah. ISO/IEC 27002:2022 zagotavlja smernice za implementacijo kontrol iz Priloge A. ISO/IEC 27005 podpira upravljanje tveganj informacijske varnosti. ISO/IEC 27017 podpira varnost oblaka. ISO/IEC 27018 podpira varstvo osebno določljivih informacij v scenarijih javnega oblaka, kjer nastopa obdelovalec. ISO 22301 podpira neprekinjeno poslovanje. ISO/IEC 27035 podpira upravljanje incidentov. ISO/IEC 27036 podpira varnost odnosov z dobavitelji.

Cilj niso dodatni standardi sami po sebi. Cilj je boljša zasnova dokazil.

Praktičen primer: izdelajte paket dokazil NIS2 za ranljivosti

Vzemimo Mariino platformo SaaS. Služi proizvodnim strankam v EU in je odvisna od storitev v oblaku, odprtokodnih komponent, cevovodov CI/CD in upravljanega spremljanja. Njeno poročilo o vrzelih navaja »upravljanje ranljivosti implementirano«, vendar so dokazila razpršena po orodjih za skeniranje, Jira, GitHub, orodjih za konfiguracijo oblaka in zahtevkih za spremembe.

Paket dokazil, pripravljen za NIS2, je mogoče zgraditi v eni osredotočeni iteraciji.

1. korak: opredelite scenarij tveganja

Tveganje: izkoristljiva ranljivost v aplikaciji, dostopni iz interneta, odvisnosti ali komponenti v oblaku povzroči motnjo storitve, nepooblaščen dostop ali izpostavitev podatkov strank.

Register tveganj mora vključevati opis, verjetnost, vpliv, oceno, lastnika in načrt obravnave tveganja. Načrt obravnave tveganja se mora sklicevati na kontrolo ISO 27001:2022 8.8 upravljanje tehničnih ranljivosti ter na povezane kontrole za inventar sredstev, varen razvoj, beleženje, nadzor dostopa, upravljanje dobaviteljev in odziv na incidente.

2. korak: preslikajte tveganje na NIS2 Article 21

Tveganje podpira zahteve Article 21 za varno nabavo, razvoj in vzdrževanje, obravnavo in razkritje ranljivosti, analizo tveganj, obravnavanje incidentov, varnost dobavne verige in oceno učinkovitosti kontrol.

3. korak: zasidrajte operativna pravila v politiki

Uporabite postopek upravljanja ranljivosti, standard varnega razvoja, zahteve za upravljanje popravkov, politiko varnostnega testiranja in pravila za revizijske dokaze.

Korporativna Politika varnostnega testiranja in vaj Red Team, klavzula 6.1, določa:

Vrste testov: program varnostnega testiranja mora najmanj vključevati: (a) skeniranje ranljivosti, ki obsega avtomatizirana tedenska ali mesečna skeniranja omrežij in aplikacij za identifikacijo znanih ranljivosti; (b) penetracijsko testiranje, ki obsega ročno poglobljeno testiranje določenih sistemov ali aplikacij, ki ga izvajajo usposobljeni preizkuševalci za identifikacijo kompleksnih slabosti; in (c) vaje red team, ki obsegajo simulacije dejanskih napadov na podlagi scenarijev, vključno s socialnim inženiringom in drugimi taktikami, za celovito preverjanje zmožnosti organizacije za zaznavanje in odzivanje.

Ta klavzula vzpostavlja zagovorljivo izhodišče testiranja. Ujema se tudi s pričakovanjem DORA glede ponavljajočega se, na tveganjih utemeljenega testiranja digitalne operativne odpornosti za zajete finančne subjekte.

4. korak: opredelite metapodatke dokazil

Politika spremljanja presoj in skladnosti za MSP, klavzula 6.2.3, določa:

Metapodatki (npr. kdo jih je zbral, kdaj in iz katerega sistema) morajo biti dokumentirani.

Za dokazila o ranljivostih mora paket zajemati:

• ime in konfiguracijo orodja za skeniranje;
• datum in čas skeniranja;
• obseg sredstev in izključitve;
• kritične in visoke ugotovitve;
• številko tiketa in lastnika;
• odločitev o popravku ali ublažitvi;
• odločitev o sprejemu tveganja, kadar je uporabno;
• datum odprave;
• potrditveno skeniranje;
• povezavo do zapisa o spremembi;
• lastnika izjeme in datum poteka.

5. korak: dodajte dokazila iz beleženja

Politika beleženja in spremljanja za MSP, klavzula 5.4.4, vključuje sistemske dnevnike, kot so:

Sistemski dnevniki: spremembe konfiguracije, administratorska dejanja, namestitve programske opreme, dejavnosti nameščanja popravkov

Samo zahtevek za popravek morda ne dokazuje, da je bila sprememba izvedena. Konfiguracijski dnevniki, administratorska dejanja in zapisi o namestitvi programske opreme okrepijo dokazno verigo.

6. korak: izvedite vzorčno presojo

Iz prejšnjega četrtletja izberite pet kritičnih ali visokih ranljivosti. Za vsako postavko preverite, da je bilo sredstvo v inventarju, da je orodje za skeniranje zaznalo ugotovitev, da je bil tiket odprt v okviru SLA, da je bil dodeljen lastnik, da je odprava ustrezala resnosti in izkoristljivosti, da dnevniki kažejo spremembo, da validacija potrjuje zaprtje in da ima vsaka izjema odobritev lastnika tveganja z datumom poteka.

Ta iteracija ustvari paket dokazil za ranljivosti, pripravljen za NIS2, in vzorec notranje presoje ISO 27001:2022.

Varnost dobaviteljev je upravljanje ekosistema

NIS2 Article 21 zahteva varnost dobavne verige, vključno z varnostnimi vidiki odnosov z neposrednimi dobavitelji in ponudniki storitev. Od organizacij pričakuje tudi upoštevanje ranljivosti dobaviteljev, kakovosti produktov, praks kibernetske varnosti dobaviteljev in praks varnega razvoja.

Tu je bila prva različica Mariinega poročila o vrzelih najšibkejša. Dobavitelje je sicer navajala, ni pa dokazovala skrbnega pregleda, pogodbenih varnostnih klavzul, spremljanja ali pripravljenosti na izstop.

Politika varnosti tretjih oseb in dobaviteljev zagotavlja sidro politike. Povezano implementacijo lahko podprejo Politika varnega razvoja, Politika ozaveščanja in usposabljanja za informacijsko varnost, Politika upravljanja ranljivosti in popravkov, Politika kriptografskih kontrol, Politika nadzora dostopa in Politika oddaljenega dostopa.

Ena evidenca dokazil dobaviteljev lahko podpira NIS2, DORA in ISO 27001:2022.

Ta tabela preprečuje podvojene vprašalnike, podvojene evidence in nasprotujoče si lastništvo kontrol.

En delovni tok za incidente za NIS2, DORA in GDPR

NIS2 Article 23 zahteva, da se pomembni incidenti prijavijo brez nepotrebnega odlašanja. Določa večstopenjsko časovnico: zgodnje opozorilo v 24 urah od seznanitve, obvestilo o incidentu v 72 urah z začetno oceno resnosti ali vpliva ter razpoložljivimi kazalniki kompromitacije, vmesne posodobitve, če so zahtevane, in končno poročilo najpozneje en mesec po obvestilu o incidentu.

DORA ima podoben življenjski cikel za finančne subjekte: zaznavanje, razvrščanje, beleženje, oceno resnosti, eskalacijo, komunikacijo s strankami, poročanje organom, analizo temeljnega vzroka in odpravo. GDPR dodaja analizo kršitve varnosti osebnih podatkov, vključno z vlogami upravljavca in obdelovalca, vplivom na posameznike, na katere se nanašajo podatki, in 72-urnim rokom obveščanja, kadar je to primerno.

Pravilna zasnova niso trije procesi za incidente. Pravilna zasnova je en delovni tok za incidente z regulativnimi odločitvenimi vejami.

Politika odzivanja na incidente za MSP, klavzula 5.4.1, določa:

Vse preiskave incidentov, ugotovitve in korektivni ukrepi morajo biti evidentirani v registru incidentov, ki ga vzdržuje generalni direktor.

Močan register incidentov mora vključevati:

Povezave z GDPR ne smemo podcenjevati. Pristojni organi NIS2 lahko obvestijo nadzorne organe GDPR, kadar lahko pomanjkljivosti pri obvladovanju tveganj kibernetske varnosti ali poročanju povzročijo kršitev varnosti osebnih podatkov. ISMS mora zato presojo zasebnosti vključiti v triažo incidentov, ne kot naknadno misel.

Kako bodo presojevalci in regulatorji preverjali vaša dokazila NIS2

Organizacija, pripravljena na leto 2026, mora pričakovati, da se ista kontrola preverja skozi različne poglede.

Presojevalec ISO 27001:2022 bo začel pri ISMS. Vprašal bo, ali so obveznosti NIS2 identificirane kot zahteve zainteresiranih strani, ali obseg ISMS zajema relevantne storitve in odvisnosti, ali so tveganja ocenjena in obravnavana, ali izjava o uporabnosti utemeljuje uporabne kontrole in ali zapisi dokazujejo delovanje.

Pristojni organ NIS2 se bo osredotočil na pravne učinke. Lahko vpraša, ali so obravnavani vsi ukrepi iz Article 21, ali so kontrole ustrezne in sorazmerne, ali je vodstvo ukrepe odobrilo in jih nadzira ter ali lahko poročanje o incidentih doseže zahtevane roke.

Nadzorni organ DORA bo za zajete finančne subjekte preverjal upravljanje tveganj IKT, razvrščanje incidentov, testiranje odpornosti, tveganje tretjih oseb, pogodbene ureditve, tveganje koncentracije in izstopne strategije.

Pregled po GDPR bo preverjal, ali tehnični in organizacijski ukrepi varujejo osebne podatke, ali je presoja kršitve vgrajena v obravnavanje incidentov, ali so vloge upravljavca in obdelovalca jasne ter ali obstajajo zapisi o odgovornosti.

Ocenjevalec v slogu NIST CSF 2.0 ali COBIT 2019 se bo osredotočil na upravljanje, lastništvo tveganj, kazalnike uspešnosti, trenutne in ciljne izide, zmožnost procesov in uskladitev z apetitom organizacije po tveganju.

Korporativna Politika spremljanja presoj in skladnosti, klavzula 3.4, zajema namen dokazil:

Ustvarjati zagovorljiva dokazila in revizijsko sled v podporo regulativnim poizvedbam, pravnim postopkom ali zahtevam strank za zagotavljanje zaupanja.

To je operativni standard, h kateremu morajo stremeti ekipe NIS2.

Odgovornost vodstva: organ upravljanja odgovornosti za NIS2 ne more prenesti drugam

NIS2 Article 20 zahteva, da organi upravljanja bistvenih in pomembnih subjektov odobrijo ukrepe za obvladovanje tveganj kibernetske varnosti, nadzirajo njihovo izvajanje in se usposabljajo. Člani organov upravljanja so lahko odgovorni za kršitve v skladu z nacionalnimi pravili o odgovornosti.

To je usklajeno z zahtevami ISO 27001:2022 glede vodenja. Najvišje vodstvo mora zagotoviti, da so politika in cilji informacijske varnosti usklajeni s strateško usmeritvijo, da se zahteve ISMS vključijo v poslovne procese, da so zagotovljeni viri, da se komunicira pomen, da so dodeljene odgovornosti in da se spodbuja nenehno izboljševanje.

Organ upravljanja ne potrebuje surovih izvozov iz orodij za skeniranje ali celotnih dnevnikov SIEM. Potrebuje zagotovilo, primerno za odločanje.

Četrtletni paket dokazil NIS2 za organ upravljanja mora vključevati:

1. spremembe obsega in regulativnega statusa;
2. najpomembnejša tveganja NIS2 in status obravnave;
3. nadzorno ploščo učinkovitosti kontrol Article 21;
4. pomembne incidente, skorajšnje incidente in odločitve o poročanju;
5. izjeme pri tveganjih dobaviteljev in oblaka;
6. ugotovitve notranjih presoj, korektivne ukrepe in zapadla dokazila.

Ta paket vodstvu daje informacije, potrebne za odobritev ukrepov, izpodbijanje izjem in sprejem preostalega tveganja.

Operativni model Clarysec za leto 2026

Operacionalizacija tehničnih ukrepov NIS2 z ISO 27001:2022 zahteva preprost, vendar discipliniran model:

• umestite NIS2, DORA, GDPR in pogodbene obveznosti v ISMS;
• preslikajte obveznosti na tveganja, politike, kontrole, lastnike in dokazila;
• uporabite izjavo o uporabnosti kot vir resnice za kontrole;
• zgradite pakete dokazil za visoko tvegana področja Article 21;
• vključite poročanje o incidentih v enoten regulativni delovni tok;
• obravnavajte varnost dobaviteljev kot življenjski cikel, ne kot vprašalnik;
• izvajajte notranje presoje z dejanskimi vzorci;
• poročajte učinkovitost kontrol organom upravljanja;
• izboljšujte na podlagi incidentov, ugotovitev presoj, testov in regulativnih sprememb.

Za Mario je bil prelomni trenutek spoznanje, da ne potrebuje ločenega projekta NIS2. Potrebovala je močnejši mehanizem dokazil ISMS.

Politike Clarysec, Zenith Blueprint in Zenith Controls so zasnovani tako, da delujejo skupaj. Politike opredeljujejo pričakovano ravnanje in zapise. Zenith Blueprint podaja 30-koračno pot implementacije in presoje. Zenith Controls zagotavlja preslikavo navzkrižne skladnosti, da je mogoče NIS2, ISO 27001:2022, DORA, GDPR, NIST CSF in zagotavljanje zaupanja v slogu COBIT upravljati kot en skladen program.

Naslednji korak: zgradite svojo mapo dokazil NIS2–ISO 27001:2022

Če vaše delo na NIS2 še vedno živi v preglednici vrzeli, je leto 2026 leto, ko ga morate operacionalizirati.

Začnite z enim visoko tveganim tehničnim ukrepom, kot so upravljanje ranljivosti, obravnavanje incidentov ali varnost dobaviteljev. Preslikajte ga na tveganja ISO 27001:2022, politike, kontrole iz Priloge A, lastnike, postopke in dokazila. Nato vzorčite zapise iz prejšnjega četrtletja in postavite zahtevno vprašanje: ali bi to zadovoljilo regulatorja, ocenjevalca stranke in presojevalca ISO 27001:2022?

Clarysec vam lahko pomaga zgraditi ta odgovor z uporabo knjižnice politik, Zenith Blueprint in Zenith Controls.

Cilj ni več dokumentacije. Cilj so zagovorljiva, ponovljiva dokazila, da vaši tehnični ukrepi NIS2 dejansko delujejo.