Mapiranje dokaza NIS2 na ISO 27001:2022 za 2026.

Problem NIS2 u 2026. nije svijest, nego dokaz

Ponedjeljak je ujutro, 08:35. Maria, nedavno imenovana CISO u brzorastućem B2B pružatelju usluga u oblaku i upravljanih usluga, priključuje se tromjesečnom sastanku upravljačkog tijela o rizicima s opsežnom analizom nedostataka za NIS2 otvorenom na prijenosnom računalu. Prvi slajd djeluje umirujuće. Politike postoje. Procjena rizika postoji. Odgovor na incidente je dokumentiran. Dobavljači su popisani. Skeniranja ranjivosti provode se svaki mjesec.

Zatim predsjednik postavlja pitanje koje mijenja tijek sastanka:

„Možemo li dokazati da su te mjere funkcionirale u prošlom tromjesečju i možemo li pokazati koje kontrole, vlasnici i zapisi prema ISO 27001:2022 podupiru svaku obvezu iz NIS2?”

Prostorija utihne.

Pravni tim zna da društvo ulazi u područje primjene NIS2 jer pruža upravljane IKT usluge i usluge u oblaku korisnicima u EU. Funkcija usklađenosti zna da Article 21 zahtijeva tehničke, operativne i organizacijske mjere upravljanja rizicima kibernetičke sigurnosti. Operacije znaju da tim zakrpava sustave, pregledava dobavljače i nadzire zapise dnevnika. No dokazi su raspršeni po sustavima za evidentiranje zahtjeva, izvozima iz SIEM-a, mapama s politikama, proračunskim tablicama, konzolama oblaka, portalima dobavljača i bilješkama sa sastanaka.

Nitko ne može brzo prikazati dokaziv lanac od NIS2 Article 21 do opsega ISO 27001:2022, rizika, kontrole, politike, vlasnika, postupka, operativnog zapisa i nalaza revizije.

To je stvarni izazov za 2026.

Mnoge organizacije više ne pitaju: „Jesmo li u području primjene NIS2?” Pitaju teže pitanje: „Možemo li dokazati da naše tehničke mjere NIS2 stvarno funkcioniraju?” Odgovor ne može biti jednokratna tablica mapiranja. Mora biti živ operativni model unutar sustava upravljanja informacijskom sigurnošću, u kojem se pravne obveze prevode u rizike, politike, kontrole, vlasnike, dokaze i kontinuirano poboljšanje.

Clarysecov model koristi ISO/IEC 27001:2022 kao okosnicu sustava upravljanja, NIS2 Article 21 kao skup regulatornih obveza, odredbe politika kao operativna pravila, Zenith Blueprint: Revizorov plan provedbe u 30 koraka kao put provedbe i Zenith Controls: Vodič za međusobno usklađivanje zahtjeva kao mapu međusobne usklađenosti za ISO 27001:2022, NIS2, DORA, GDPR, NIST CSF i sigurnosno potvrđivanje u stilu COBIT-a.

Počnite s opsegom jer dokazi za NIS2 nastaju prije kontrola

Česta pogreška u NIS2 jest izravan prelazak na MFA, zapisivanje događaja, odgovor na incidente i upravljanje ranjivostima prije potvrde opsega subjekta, opsega usluga i jurisdikcijskog opsega.

NIS2 se primjenjuje na obuhvaćene javne i privatne subjekte u reguliranim sektorima koji ispunjavaju kriterije veličine i djelatnosti, pri čemu su određene vrste subjekata obuhvaćene neovisno o veličini. Relevantne digitalne i IKT kategorije uključuju pružatelje usluga računalstva u oblaku, pružatelje usluga podatkovnih centara, pružatelje mreža za isporuku sadržaja, pružatelje usluga povjerenja, pružatelje javnih elektroničkih komunikacija, pružatelje upravljanih usluga, pružatelje upravljanih sigurnosnih usluga, internetske tržnice, internetske tražilice i platforme društvenih mreža.

Za pružatelje usluga u oblaku, SaaS platforme, MSP-ove, MSSP-ove i pružatelje digitalne infrastrukture taj posao određivanja opsega nije teorijski. Article 3 zahtijeva da države članice razlikuju ključne i važne subjekte. Article 27 zahtijeva da ENISA vodi registar za više digitalnih i IKT pružatelja, uključujući pružatelje DNS usluga, registre TLD naziva, pružatelje usluga registracije naziva domena, pružatelje usluga računalstva u oblaku, pružatelje usluga podatkovnih centara, pružatelje mreža za isporuku sadržaja, pružatelje upravljanih usluga, pružatelje upravljanih sigurnosnih usluga, internetske tržnice, internetske tražilice i platforme društvenih mreža.

ISO 27001:2022 daje odgovarajuću strukturu. Točke 4.1 do 4.4 zahtijevaju da organizacija razumije vanjska i unutarnja pitanja, zainteresirane strane, zahtjeve, sučelja i ovisnosti, a zatim definira opseg ISMS-a. NIS2 mora biti obuhvaćen ovdje, a ne ostavljen u pravnom memorandumu.

Praktičan zapis o opsegu NIS2 treba uključivati:

• Analizu pravne osobe i poslovnog nastana u EU
• Sektor i kategoriju usluge prema NIS2
• Status ključnog ili važnog subjekta, ako je potvrđen nacionalnim pravom ili određivanjem nadležnog tijela
• Relevantnost registra ENISA, gdje je primjenjivo
• Kritične usluge koje se isporučuju klijentima
• Mrežne i informacijske sustave koji podupiru te usluge
• Ovisnosti o pružateljima usluga u oblaku, podatkovnim centrima, telekomunikacijama, nadzoru sigurnosti, identitetu i softveru
• Poveznice s DORA, GDPR, ugovorima s klijentima i sektorskim obvezama
• Repozitorije dokaza, vlasnike sustava i učestalost pregleda

Ovdje treba pravilno razgraničiti i DORA. NIS2 priznaje da se, ako sektorski pravni akt EU nameće ekvivalentne obveze upravljanja rizicima kibernetičke sigurnosti ili obavješćivanja o incidentima, taj sektorski režim primjenjuje umjesto odgovarajućih odredbi NIS2. Za obuhvaćene financijske subjekte DORA je u pravilu operativni režim za kibernetičku sigurnost i izvješćivanje o IKT incidentima. DORA se primjenjuje od 17. siječnja 2025. i obuhvaća upravljanje IKT rizicima, izvješćivanje o incidentima, testiranje digitalne operativne otpornosti, rizik trećih strana u IKT-u i nadzor nad ključnim pružateljima IKT usluga trećih strana.

Fintech grupa stoga može imati različite obrade usklađenosti unutar jedne korporativne strukture. Platni subjekt može biti primarno pod DORA. MSP podružnica može biti izravno pod NIS2. Dijeljena platforma u oblaku može podupirati oboje. Zreo odgovor nisu duplicirane kontrole. To je jedan ISMS model dokaza koji može služiti za više regulatornih perspektiva.

ISO 27001:2022 kao operativni sustav usklađenosti s NIS2

NIS2 Article 21 zahtijeva odgovarajuće i razmjerne tehničke, operativne i organizacijske mjere za upravljanje rizicima za mrežne i informacijske sustave te za sprječavanje ili smanjenje utjecaja incidenata na primatelje usluga i druge usluge.

ISO 27001:2022 posebno je prikladan za operacionalizaciju tog zahtjeva jer nameće tri discipline.

Prvo, upravljanje. Točke 5.1 do 5.3 zahtijevaju predanost najvišeg rukovodstva, usklađenost sa strateškim usmjerenjem, osiguravanje resursa, komunikaciju, dodjelu odgovornosti i dokumentiranu politiku informacijske sigurnosti. To je izravno usklađeno s NIS2 Article 20, koji zahtijeva da upravljačka tijela odobre mjere upravljanja rizicima kibernetičke sigurnosti, nadziru provedbu i primaju osposobljavanje.

Drugo, obrada rizika. Točke 6.1.1 do 6.1.3 zahtijevaju ponovljiv proces procjene rizika, vlasnike rizika, vrednovanje rizika, mogućnosti obrade, odabir kontrola, Izjavu o primjenjivosti, plan obrade rizika i odobrenje preostalog rizika.

Treće, operativna kontrola. Točka 8.1 zahtijeva da organizacija planira, provodi i kontrolira ISMS procese, održava dokumentirane informacije, kontrolira promjene i upravlja eksterno pruženim procesima, proizvodima i uslugama relevantnima za ISMS.

Time se NIS2 iz pravnog kontrolnog popisa pretvara u operativni model kontrola.

Svaki redak treba imati vlasnika, izvor zapisa i metodu uzorkovanja. Ako toga nema, organizacija ima namjeru kontrole, a ne kontrolu.

Politika je mjesto na kojem NIS2 postaje operativno ponašanje

Politike se često tretiraju kao predlošci. Za NIS2 je to opasno. Regulator ili revizor neće biti uvjeren mapom s politikama ako politike ne dodjeljuju vlasništvo, ne definiraju zapise, ne povezuju se s rizicima i ne stvaraju dokaze.

Korporativna Politika pravne i regulatorne usklađenosti postavlja temelj u točki 6.2.1:

Sve pravne i regulatorne obveze moraju se mapirati na konkretne politike, kontrole i vlasnike unutar sustava upravljanja informacijskom sigurnošću (ISMS).

Ta je točka most između NIS2 i ISO 27001:2022. NIS2 Article 21 ne navodi se samo kao vanjski zahtjev. Raščlanjuje se na obveze iz politika, mapira na kontrole, dodjeljuje vlasnicima i testira dokazima.

Za manje organizacije Politika pravne i regulatorne usklađenosti za SME zadržava isti koncept u jednostavnijem obliku. Točka 5.1.1 zahtijeva:

GM mora održavati jednostavan, strukturiran Registar usklađenosti koji navodi:

Rečenica je namjerno praktična. MSP-ovima nije potrebna složena GRC implementacija za početak. Potreban im je registar usklađenosti koji obuhvaća obvezu, primjenjivost, vlasnika, politiku, dokaze i učestalost pregleda.

Obrada rizika zatim pretvara obvezu u radnju. Korporativna Politika upravljanja rizicima, točka 6.4.2 navodi:

Službenik za rizike mora osigurati da su obrade realistične, vremenski ograničene i mapirane na kontrole iz Priloga A ISO/IEC 27001.

Za MSP-ove Politika upravljanja rizicima za SME, točka 5.1.2 daje minimalno održiv zapis rizika:

Svaki unos rizika mora uključivati: opis, vjerojatnost, utjecaj, ocjenu, vlasnika i plan obrade.

Te su točke važne jer je NIS2 izričito utemeljen na riziku i razmjeran. Article 21 očekuje da mjere odražavaju stanje tehnike, relevantne standarde, trošak provedbe, izloženost riziku, veličinu, vjerojatnost i ozbiljnost incidenta, uključujući društveni i gospodarski utjecaj. Registar rizika bez vlasnika i planova obrade ne može dokazati razmjernost.

Korporativna Politika informacijske sigurnosti dovršava načelo dokaza u točki 6.6.1:

Sve implementirane kontrole moraju biti provjerljive u reviziji, podržane dokumentiranim postupcima i zadržanim dokazima o funkcioniranju.

To je razlika između postojanja NIS2 programa i postojanja NIS2 programa dokaza.

Clarysecov put od mapiranja do operativne provedbe

Zenith Blueprint vrijedan je jer odražava način razmišljanja revizora. Oni ne pitaju samo postoji li kontrola. Pitaju zašto je odabrana, gdje je dokumentirana, kako funkcionira, tko je njezin vlasnik, koji dokazi potvrđuju njezino funkcioniranje i kako je organizacija poboljšava.

U fazi upravljanja rizicima, korak 13 upućuje timove da dodaju sljedivost između rizika, kontrola i točaka:

✓ Mapirajte kontrole na rizike: U planu obrade u svojem Registru rizika naveli ste određene kontrole za svaki rizik. Svakom riziku možete dodati stupac „Referenca kontrole iz Priloga A” i navesti brojeve kontrola.

Za NIS2 to znači da registar rizika i Izjava o primjenjivosti trebaju pokazati zašto su kontrole kao što su 8.8 Upravljanje tehničkim ranjivostima, 5.19 Informacijska sigurnost u odnosima s dobavljačima i 5.24 Planiranje i priprema upravljanja incidentima primjenjive.

Korak 14 iz Zenith Blueprint izričito navodi regulatorno mapiranje:

Za svaki propis, ako je primjenjiv, možete izraditi jednostavnu tablicu mapiranja (može biti prilog izvješću) koja navodi ključne sigurnosne zahtjeve propisa i odgovarajuće kontrole/politike u vašem ISMS-u.

Time se sprječava fragmentacija. Sigurnost osobnih podataka prema GDPR, izvješćivanje o incidentima prema NIS2, testiranje IKT otpornosti prema DORA i sigurnosne obveze prema klijentima mogu se oslanjati na iste dokaze: preglede pristupa, otklanjanje ranjivosti, zapise dnevnika, testove sigurnosnih kopija, preglede dobavljača i izvješća o incidentima.

Korak 19 prelazi iz dizajna u operativnu provedbu:

Povežite svaki od ovih dokumenata s odgovarajućom kontrolom u svojem SoA ili ISMS priručniku. Ti će dokumenti služiti kao dokaz provedbe i interna referenca.

Dokumentacijski skup iz koraka 19 uključuje sigurnost krajnjih uređaja, upravljanje pristupom, autentifikaciju, polazne osnove sigurne konfiguracije, zapisivanje događaja i nadzor, upravljanje zakrpama, upravljanje ranjivostima, planiranje kapaciteta i izvješćivanje o IT operacijama. Upravo su to operativni dokumenti potrebni da tehničke mjere NIS2 budu provjerljive u reviziji.

Korak 26 objašnjava kako treba prikupljati revizijske dokaze:

Dok prikupljate dokaze, zabilježite svoje nalaze. Navedite gdje je stanje usklađeno sa zahtjevom (pozitivni nalazi), a gdje nije (moguće nesukladnosti ili opažanja).

Za NIS2 to znači uzorkovanje dokaza prije nego što ih zatraži regulator, procjenitelj klijenta ili certifikacijski revizor.

Uloga Zenith Controls u međusobnom usklađivanju zahtjeva

Zenith Controls nije zaseban okvir kontrola. To je Clarysecov vodič za međusobno usklađivanje zahtjeva, namijenjen mapiranju kontrola ISO/IEC 27001:2022 i ISO/IEC 27002:2022 na povezane kontrole, revizijska očekivanja i vanjske okvire. Pomaže timovima razumjeti kako jedna kontrola ISO 27001:2022 može poduprijeti NIS2, DORA, GDPR, NIST CSF 2.0 i sigurnosno potvrđivanje u stilu COBIT-a.

Tri kontrole ISO 27001:2022 posebno su važne za mapiranje dokaza NIS2.

Kontrola 5.1 Politike informacijske sigurnosti polazna je točka jer NIS2 Article 21 uključuje analizu rizika i politike sigurnosti informacijskih sustava. Ako se tehnička mjera NIS2 ne odražava u politici, teško je njome upravljati i dosljedno je revidirati.

Kontrola 5.36 Usklađenost s politikama, pravilima i standardima informacijske sigurnosti provjera je stvarnog stanja. Ona povezuje zahtjeve politika sa stvarnom usklađenošću s internim pravilima, standardima i vanjskim obvezama. U kontekstu NIS2, to je mjesto na kojem organizacija provjerava radi li ono što njezino mapiranje prema Article 21 kaže da radi.

Kontrola 8.8 Upravljanje tehničkim ranjivostima jedno je od najzahtjevnijih područja testiranja u 2026. Upravljanje ranjivostima izravno je relevantno za sigurnu nabavu, razvoj, održavanje, postupanje s ranjivostima i njihovu objavu. Također podupire testiranje i otklanjanje nedostataka prema DORA, odgovornost za sigurnost prema GDPR, ishode Identify i Protect prema NIST CSF te uzorkovanje u reviziji ISO 27001.

Potporni standardi mogu ojačati dizajn bez zahtjeva za dodatnim certifikacijama. ISO/IEC 27002:2022 daje smjernice za provedbu kontrola iz Priloga A. ISO/IEC 27005 podupire upravljanje rizicima informacijske sigurnosti. ISO/IEC 27017 podupire sigurnost oblaka. ISO/IEC 27018 podupire zaštitu osobnih podataka koji omogućuju identifikaciju osobe u scenarijima izvršitelja obrade u javnom oblaku. ISO 22301 podupire neprekidnost poslovanja. ISO/IEC 27035 podupire upravljanje incidentima. ISO/IEC 27036 podupire sigurnost odnosa s dobavljačima.

Cilj nisu dodatni standardi radi samih standarda. Cilj je bolji dizajn dokaza.

Praktičan primjer: izradite paket dokaza za ranjivosti prema NIS2

Razmotrite Marijinu SaaS platformu. Ona opslužuje proizvodne klijente u EU i ovisi o uslugama u oblaku, komponentama otvorenog koda, CI/CD cjevovodima i upravljanom nadzoru. Njezino izvješće o nedostacima navodi „upravljanje ranjivostima implementirano”, ali dokazi su raspršeni po skenerima, Jira, GitHubu, alatima za konfiguraciju oblaka i zahtjevima za promjenu.

Paket dokaza spreman za NIS2 može se izraditi u jednom usmjerenom sprintu.

Korak 1: Definirajte scenarij rizika

Rizik: iskoristiva ranjivost u aplikaciji izloženoj internetu, ovisnosti ili komponenti oblaka uzrokuje prekid usluge, neovlašteni pristup ili izloženost podataka klijenata.

Registar rizika treba uključivati opis, vjerojatnost, utjecaj, ocjenu, vlasnika i plan obrade. Plan obrade treba se pozivati na kontrolu ISO 27001:2022 8.8 Upravljanje tehničkim ranjivostima, kao i na povezane kontrole za popis imovine, siguran razvoj, zapisivanje događaja, kontrolu pristupa, upravljanje dobavljačima i odgovor na incidente.

Korak 2: Mapirajte rizik na NIS2 Article 21

Rizik podupire zahtjeve iz Article 21 za sigurnu nabavu, razvoj i održavanje, postupanje s ranjivostima i objavu ranjivosti, analizu rizika, postupanje s incidentima, sigurnost opskrbnog lanca i procjenu djelotvornosti kontrola.

Korak 3: Učvrstite operativna pravila u politici

Koristite postupak upravljanja ranjivostima, standard sigurnog razvoja, zahtjeve upravljanja zakrpama, politiku sigurnosnog testiranja i pravila za revizijske dokaze.

Korporativna Politika sigurnosnog testiranja i Red Team aktivnosti, točka 6.1 navodi:

Vrste testova: Program sigurnosnog testiranja mora uključivati najmanje: (a) skeniranje ranjivosti, koje se sastoji od automatiziranih tjednih ili mjesečnih skeniranja mreža i aplikacija radi identifikacije poznatih ranjivosti; (b) penetracijsko testiranje, koje se sastoji od ručnog dubinskog testiranja određenih sustava ili aplikacija koje provode kvalificirani ispitivači radi identifikacije složenih slabosti; i (c) vježbe crvenog tima, koje se sastoje od simulacija stvarnih napada temeljenih na scenarijima, uključujući socijalni inženjering i druge taktike, radi testiranja sposobnosti organizacije za otkrivanje i odgovor u cjelini.

Ta točka uspostavlja dokazivu polaznu osnovu testiranja. Također je usklađena s očekivanjem DORA za ponavljajuće, rizikom vođeno testiranje digitalne operativne otpornosti za obuhvaćene financijske subjekte.

Korak 4: Definirajte metapodatke dokaza

Politika praćenja revizije i usklađenosti za SME, točka 6.2.3 navodi:

Metapodaci (npr. tko ih je prikupio, kada i iz kojeg sustava) moraju biti dokumentirani.

Za dokaze o ranjivostima paket treba obuhvatiti:

• Naziv i konfiguraciju skenera
• Datum i vrijeme skeniranja
• Opseg imovine i izuzeća
• Kritične i visoke nalaze
• Broj tiketa i vlasnika
• Odluku o zakrpi ili ublažavanju
• Odluku o prihvaćanju rizika, gdje je primjenjivo
• Datum otklanjanja
• Skeniranje za provjeru
• Poveznicu na zapis promjene
• Vlasnika iznimke i datum isteka

Korak 5: Dodajte dokaze iz zapisivanja događaja

Politika zapisivanja događaja i nadzora za SME, točka 5.4.4 uključuje sistemske zapise dnevnika kao što su:

Sistemski zapisi dnevnika: promjene konfiguracije, administrativne radnje, instalacije softvera, aktivnosti zakrpavanja

Sam tiket za zakrpu možda ne dokazuje da je promjena provedena. Konfiguracijski zapisi dnevnika, administrativne radnje i zapisi o instalaciji softvera jačaju lanac dokaza.

Korak 6: Provedite uzorak revizije

Odaberite pet kritičnih ili visokih ranjivosti iz prethodnog tromjesečja. Za svaku stavku provjerite je li imovina bila u popisu imovine, je li skener otkrio nalaz, je li tiket otvoren unutar SLA, je li dodijeljen vlasnik, je li otklanjanje usklađeno s ozbiljnošću i mogućnošću iskorištavanja, pokazuju li zapisi dnevnika promjenu, potvrđuje li provjera zatvaranje i ima li svaka iznimka odobrenje vlasnika rizika s datumom isteka.

Taj sprint proizvodi paket dokaza o ranjivostima spreman za NIS2 i uzorak interne revizije prema ISO 27001:2022.

Sigurnost dobavljača je upravljanje ekosustavom

NIS2 Article 21 zahtijeva sigurnost opskrbnog lanca, uključujući sigurnosne aspekte odnosa s izravnim dobavljačima i pružateljima usluga. Također očekuje da organizacije razmotre ranjivosti dobavljača, kvalitetu proizvoda, prakse kibernetičke sigurnosti dobavljača i prakse sigurnog razvoja.

Tu je prva verzija Marijina izvješća o nedostacima bila najslabija. Popisivala je dobavljače, ali nije dokazivala dubinsku analizu dobavljača, ugovorne sigurnosne odredbe, nadzor ni spremnost za izlazak.

Politika sigurnosti trećih strana i dobavljača daje uporište u politici. Povezanu provedbu mogu poduprijeti Politika sigurnog razvoja, Politika podizanja svijesti i osposobljavanja o informacijskoj sigurnosti, Politika upravljanja ranjivostima i zakrpama, Politika kriptografskih kontrola, Politika kontrole pristupa i Politika rada na daljinu.

Jedinstveni registar dokaza dobavljača može poduprijeti NIS2, DORA i ISO 27001:2022.

Ova tablica sprječava duplicirane upitnike, duplicirane registre i proturječno vlasništvo nad kontrolama.

Jedan radni tok za incidente za NIS2, DORA i GDPR

NIS2 Article 23 zahtijeva da se značajni incidenti prijave bez nepotrebnog odgađanja. Uspostavlja fazni vremenski slijed: rano upozorenje u roku od 24 sata od saznanja, obavijest o incidentu u roku od 72 sata s početnom procjenom ozbiljnosti ili utjecaja i dostupnim pokazateljima kompromitacije, međuažuriranja ako se zatraže te završno izvješće najkasnije mjesec dana nakon obavijesti o incidentu.

DORA ima sličan životni ciklus za financijske subjekte: otkrivanje, klasifikaciju, zapisivanje događaja, procjenu ozbiljnosti, eskalaciju, komunikaciju s klijentima, izvješćivanje nadležnom tijelu, analizu temeljnog uzroka i otklanjanje posljedica. GDPR dodaje analizu povrede osobnih podataka, uključujući uloge voditelja obrade i izvršitelja obrade, utjecaj na ispitanike i rok od 72 sata za obavješćivanje, gdje je primjenjivo.

Ispravan dizajn nisu tri procesa za incidente. To je jedan radni tok za incidente s regulatornim granama odlučivanja.

Politika odgovora na incidente za SME, točka 5.4.1 navodi:

Sve istrage incidenata, nalazi i korektivne radnje moraju se evidentirati u registru incidenata koji održava glavni direktor.

Snažan registar incidenata treba uključivati:

Poveznica s GDPR ne smije se podcijeniti. Nadležna tijela za NIS2 mogu obavijestiti nadzorna tijela prema GDPR ako neuspjesi u upravljanju rizicima kibernetičke sigurnosti ili izvješćivanju mogu dovesti do povrede osobnih podataka. ISMS stoga treba uključiti procjenu privatnosti u trijažu incidenata, a ne je tretirati kao naknadnu misao.

Kako će revizori i regulatori testirati vaše NIS2 dokaze

Organizacija spremna za 2026. treba očekivati da se ista kontrola testira iz različitih perspektiva.

Revizor ISO 27001:2022 počet će od ISMS-a. Pitat će jesu li obveze NIS2 identificirane kao zahtjevi zainteresiranih strana, obuhvaća li opseg ISMS-a relevantne usluge i ovisnosti, procjenjuju li se i obrađuju rizici, opravdava li Izjava o primjenjivosti primjenjive kontrole i dokazuju li zapisi funkcioniranje.

Nadležno tijelo za NIS2 usmjerit će se na pravne ishode. Može pitati jesu li obuhvaćene sve mjere iz Article 21, jesu li kontrole odgovarajuće i razmjerne, je li uprava odobrila i nadzire mjere te može li izvješćivanje o incidentima ispuniti propisane rokove.

Nadzorno tijelo prema DORA, za obuhvaćene financijske subjekte, testirat će upravljanje IKT rizicima, klasifikaciju incidenata, testiranje otpornosti, rizik trećih strana, ugovorne aranžmane, rizik koncentracije i strategije izlaska.

Pregledavatelj prema GDPR testirat će štite li tehničke i organizacijske mjere osobne podatke, je li procjena povrede ugrađena u postupanje s incidentima, jesu li uloge voditelja obrade i izvršitelja obrade jasne te postoje li zapisi odgovornosti.

Procjenitelj u stilu NIST CSF 2.0 ili COBIT 2019 usmjerit će se na upravljanje, vlasništvo nad rizikom, pokazatelje uspješnosti, trenutačne i ciljne ishode, sposobnost procesa i usklađenost s apetitom za rizik organizacije.

Korporativna Politika praćenja revizije i usklađenosti, točka 3.4 obuhvaća svrhu dokaza:

Generirati dokazive dokaze i revizijski trag za podršku upitima regulatornih tijela, pravnim postupcima ili zahtjevima klijenata za pružanje potvrda.

To je operativni standard prema kojem bi NIS2 timovi trebali graditi.

Odgovornost uprave: upravljačko tijelo ne može delegirati NIS2 izvan svoje odgovornosti

NIS2 Article 20 zahtijeva da upravljačka tijela ključnih i važnih subjekata odobre mjere upravljanja rizicima kibernetičke sigurnosti, nadziru provedbu i primaju osposobljavanje. Članovi upravljačkih tijela mogu odgovarati za povrede, sukladno nacionalnim pravilima o odgovornosti.

To je usklađeno sa zahtjevima vodstva u ISO 27001:2022. Najviše rukovodstvo mora osigurati da su politika i ciljevi informacijske sigurnosti usklađeni sa strateškim usmjerenjem, integrirati zahtjeve ISMS-a u poslovne procese, osigurati resurse, komunicirati važnost, dodijeliti odgovornosti i promicati kontinuirano poboljšanje.

Upravljačkom tijelu nisu potrebni sirovi izvozi iz skenera ni potpuni zapisi dnevnika iz SIEM-a. Potrebno mu je sigurnosno potvrđivanje prikladno za donošenje odluka.

Tromjesečni NIS2 paket dokaza za upravljačko tijelo treba uključivati:

1. Promjene opsega i regulatornog statusa
2. Najvažnije rizike NIS2 i status obrade
3. Nadzornu ploču djelotvornosti kontrola iz Article 21
4. Značajne incidente, zamalo nastale događaje i odluke o izvješćivanju
5. Iznimke rizika dobavljača i oblaka
6. Nalaze interne revizije, korektivne radnje i zakašnjele dokaze

Taj paket upravi daje informacije potrebne za odobravanje mjera, osporavanje iznimaka i prihvaćanje preostalog rizika.

Clarysecov operativni model za 2026.

Operacionalizacija tehničkih mjera NIS2 pomoću ISO 27001:2022 zahtijeva jednostavan, ali discipliniran model:

• Obuhvatite NIS2, DORA, GDPR i ugovorne obveze unutar ISMS-a
• Mapirajte obveze na rizike, politike, kontrole, vlasnike i dokaze
• Koristite Izjavu o primjenjivosti kao mjerodavni izvor kontrola
• Izradite pakete dokaza za visokorizična područja Article 21
• Integrirajte izvješćivanje o incidentima u jedan regulatorni radni tok
• Tretirajte sigurnost dobavljača kao životni ciklus, a ne kao upitnik
• Provodite interne revizije korištenjem stvarnih uzoraka
• Izvješćujte upravljačka tijela o djelotvornosti kontrola
• Poboljšavajte na temelju incidenata, nalaza revizije, testova i regulatornih promjena

Za Mariju je prijelomni trenutak bio shvaćanje da joj ne treba zaseban NIS2 projekt. Trebao joj je snažniji ISMS mehanizam za dokaze.

Clarysecove politike, Zenith Blueprint i Zenith Controls osmišljeni su za zajedničko djelovanje. Politike definiraju očekivano ponašanje i zapise. Zenith Blueprint daje provedbeni i revizijski put u 30 koraka. Zenith Controls pruža mapiranje međusobne usklađenosti kako bi se NIS2, ISO 27001:2022, DORA, GDPR, NIST CSF i sigurnosno potvrđivanje u stilu COBIT-a mogli upravljati kao jedan usklađen program.

Sljedeći korak: izradite mapu dokaza NIS2 prema ISO 27001:2022

Ako vaš rad na NIS2 još uvijek živi u tablici nedostataka, 2026. je godina za njegovu operacionalizaciju.

Počnite s jednom visokorizičnom tehničkom mjerom, kao što su upravljanje ranjivostima, postupanje s incidentima ili sigurnost dobavljača. Mapirajte je na rizike, politike, kontrole iz Priloga A, vlasnike, postupke i dokaze prema ISO 27001:2022. Zatim uzorkujte zapise iz prošlog tromjesečja i postavite teško pitanje: bi li to zadovoljilo regulatora, procjenitelja klijenta i revizora ISO 27001:2022?

Clarysec vam može pomoći izgraditi taj odgovor pomoću biblioteke politika, Zenith Blueprint i Zenith Controls.

Cilj nije više dokumentacije. Cilj su dokazivi, ponovljivi dokazi da vaše tehničke mjere NIS2 stvarno funkcioniraju.