Mapovanie dôkazov NIS2 na ISO 27001:2022 pre rok 2026

Problém NIS2 v roku 2026 nie je povedomie, ale dôkaz

Je pondelok ráno, 08:35. Maria, nedávno vymenovaná CISO rýchlo rastúceho B2B poskytovateľa cloudových a riadených služieb, sa pripája na štvrťročné zasadnutie riadiaceho orgánu o rizikách s rozsiahlym posúdením medzier voči NIS2 otvoreným na notebooku. Prvá snímka pôsobí upokojujúco. Politiky existujú. Posúdenie rizík existuje. Reakcia na incidenty je zdokumentovaná. Dodávatelia sú uvedení v zozname. Skenovanie zraniteľností prebieha každý mesiac.

Potom predseda položí otázku, ktorá zmení priebeh zasadnutia:

„Vieme preukázať, že tieto opatrenia v minulom štvrťroku skutočne fungovali, a vieme ukázať, ktoré opatrenia ISO 27001:2022, vlastníci a záznamy podporujú každú povinnosť NIS2?“

V miestnosti nastane ticho.

Právne oddelenie vie, že spoločnosť spadá do rozsahu NIS2, pretože poskytuje riadené IKT a cloudové služby zákazníkom v EÚ. Tím pre súlad vie, že Article 21 vyžaduje technické, prevádzkové a organizačné opatrenia na riadenie kybernetických rizík. Prevádzka vie, že tím záplatuje systémy, preskúmava dodávateľov a monitoruje logy. Dôkazy sú však roztrúsené v tiketovacích systémoch, exportoch zo SIEM, priečinkoch s politikami, tabuľkových prehľadoch, cloudových konzolách, dodávateľských portáloch a poznámkach zo stretnutí.

Nikto nevie rýchlo ukázať obhájiteľnú väzbu od Article 21 NIS2 k rozsahu ISO 27001:2022, riziku, opatreniu, politike, vlastníkovi, postupu, prevádzkovému záznamu a auditnému zisteniu.

To je skutočná výzva roku 2026.

Mnohé organizácie sa už nepýtajú: „Spadáme do rozsahu NIS2?“ Kladú si náročnejšiu otázku: „Vieme preukázať, že naše technické opatrenia podľa NIS2 skutočne fungujú?“ Odpoveďou nemôže byť jednorazová mapovacia tabuľka. Musí ísť o živý prevádzkový model v rámci systému manažérstva informačnej bezpečnosti, v ktorom sa zákonné povinnosti premietajú do rizík, politík, opatrení, vlastníkov, dôkazov a neustáleho zlepšovania.

Model Clarysec používa ISO/IEC 27001:2022 ako chrbticu systému manažérstva, Article 21 NIS2 ako súbor regulačných povinností, ustanovenia politík ako prevádzkové pravidlá, Zenith Blueprint: 30-krokovú cestovnú mapu audítora ako implementačnú cestu a Zenith Controls: príručku krížového súladu ako mapu krížového súladu pre ISO 27001:2022, NIS2, DORA, GDPR, NIST CSF a uistenie v štýle COBIT.

Začnite rozsahom, pretože dôkazy NIS2 sa začínajú pred opatreniami

Bežným zlyhaním pri NIS2 je prejsť priamo na MFA, logovanie, reakciu na incidenty a riadenie zraniteľností skôr, než je potvrdený rozsah subjektu, rozsah služieb a jurisdikčný rozsah.

NIS2 sa vzťahuje na zahrnuté verejné a súkromné subjekty v regulovaných sektoroch, ktoré spĺňajú kritériá veľkosti a činnosti, pričom niektoré typy subjektov sú zahrnuté bez ohľadu na veľkosť. Relevantné digitálne a IKT kategórie zahŕňajú poskytovateľov cloudových výpočtových služieb, poskytovateľov služieb dátových centier, poskytovateľov sietí na doručovanie obsahu, poskytovateľov dôveryhodných služieb, poskytovateľov verejných elektronických komunikácií, poskytovateľov riadených služieb, poskytovateľov riadených bezpečnostných služieb, online trhoviská, internetové vyhľadávače a platformy sociálnych sietí.

Pre poskytovateľov cloudu, platformy SaaS, poskytovateľov riadených služieb (MSP), poskytovateľov riadených bezpečnostných služieb (MSSP) a poskytovateľov digitálnej infraštruktúry nie je táto práca na rozsahu teoretická. Article 3 vyžaduje, aby členské štáty rozlišovali základné a dôležité subjekty. Article 27 vyžaduje, aby ENISA viedla register pre viacerých digitálnych a IKT poskytovateľov vrátane poskytovateľov služieb DNS, registrov názvov TLD, poskytovateľov služieb registrácie doménových mien, poskytovateľov cloudových výpočtových služieb, poskytovateľov služieb dátových centier, poskytovateľov sietí na doručovanie obsahu, poskytovateľov riadených služieb, poskytovateľov riadených bezpečnostných služieb, online trhovísk, internetových vyhľadávačov a platforiem sociálnych sietí.

ISO 27001:2022 poskytuje správnu štruktúru. Kapitoly 4.1 až 4.4 vyžadujú, aby organizácia porozumela externým a interným otázkam, zainteresovaným stranám, požiadavkám, rozhraniam a závislostiam a následne definovala rozsah ISMS. NIS2 musí byť zachytená tu, nie ponechaná v právnom memorande.

Praktický záznam o rozsahu NIS2 má obsahovať:

• analýzu právnickej osoby a usadenia v EÚ,
• sektor NIS2 a kategóriu služby,
• status základného alebo dôležitého subjektu, ak je potvrdený vnútroštátnym právom alebo určením orgánu,
• relevantnosť registra ENISA, ak sa uplatňuje,
• kritické služby poskytované zákazníkom,
• sieťové a informačné systémy podporujúce tieto služby,
• závislosti od cloudových služieb, dátových centier, telekomunikačných služieb, bezpečnostného monitorovania, identity a poskytovateľov softvéru,
• väzby na DORA, GDPR, zákaznícke zmluvy a odvetvovo špecifické povinnosti,
• úložiská dôkazov, vlastníkov systémov a periodicitu preskúmania.

Tu je potrebné správne oddeliť aj DORA. NIS2 uznáva, že ak odvetvovo špecifický právny akt EÚ ukladá rovnocenné povinnosti riadenia kybernetických rizík alebo oznamovania incidentov, tento odvetvovo špecifický režim sa uplatní namiesto príslušných ustanovení NIS2. Pre zahrnuté finančné subjekty je DORA spravidla rozhodujúcim režimom kybernetickej bezpečnosti a oznamovania IKT incidentov. DORA sa uplatňuje od 17. januára 2025 a pokrýva riadenie IKT rizík, oznamovanie incidentov, testovanie digitálnej prevádzkovej odolnosti, riziká tretích strán v oblasti IKT a dohľad nad kritickými externými poskytovateľmi IKT.

Fintech skupina preto môže mať v rámci jednej podnikovej štruktúry rôzne režimy súladu. Platobný subjekt môže primárne spadať pod DORA. Dcérska spoločnosť poskytujúca riadené služby môže spadať priamo pod NIS2. Zdieľaná cloudová platforma môže podporovať obe. Zrelou odpoveďou nie je duplikovanie opatrení. Je ňou jeden dôkazový model ISMS, ktorý dokáže slúžiť viacerým regulačným pohľadom.

ISO 27001:2022 ako prevádzkový systém súladu s NIS2

Article 21 NIS2 vyžaduje primerané a proporcionálne technické, prevádzkové a organizačné opatrenia na riadenie rizík pre sieťové a informačné systémy a na predchádzanie vplyvu incidentov na príjemcov služieb a iné služby alebo na jeho minimalizáciu.

ISO 27001:2022 je na uvedenie tejto požiadavky do praxe vhodná, pretože vynucuje tri disciplíny.

Po prvé, správa a riadenie. Kapitoly 5.1 až 5.3 vyžadujú záväzok vrcholového manažmentu, zosúladenie so strategickým smerovaním, zabezpečenie zdrojov, komunikáciu, priradenie zodpovedností a zdokumentovanú Politiku informačnej bezpečnosti. To priamo zodpovedá Article 20 NIS2, ktorý vyžaduje, aby riadiace orgány schvaľovali opatrenia riadenia kybernetických rizík, dohliadali na ich implementáciu a absolvovali školenie.

Po druhé, ošetrenie rizík. Kapitoly 6.1.1 až 6.1.3 vyžadujú opakovateľný proces posudzovania rizík, vlastníkov rizík, hodnotenie rizika, možnosti ošetrenia rizík, výber opatrení, Vyhlásenie o uplatniteľnosti, plán ošetrenia rizík a schválenie zostatkového rizika.

Po tretie, prevádzkové riadenie. Kapitola 8.1 vyžaduje, aby organizácia plánovala, implementovala a riadila procesy ISMS, uchovávala zdokumentované informácie, riadila zmeny a spravovala externe poskytované procesy, produkty a služby relevantné pre ISMS.

Tým sa NIS2 mení z právneho kontrolného zoznamu na prevádzkový model opatrení.

Každý riadok potrebuje vlastníka, zdroj záznamov a metódu vzorkovania. Ak chýbajú, organizácia má ambíciu zaviesť opatrenie, nie fungujúce opatrenie.

Politika je miesto, kde sa NIS2 mení na prevádzkové správanie

Politiky sa často vnímajú ako šablóny. Pri NIS2 je to nebezpečné. Regulátor ani audítor nebudú presvedčení priečinkom s politikami, ak politiky nepriraďujú vlastníctvo, nedefinujú záznamy, neprepájajú sa s rizikami a nevytvárajú dôkazy.

Podniková Politika právneho a regulačného súladu stanovuje základ v bode 6.2.1:

Všetky právne a regulačné povinnosti musia byť v rámci systému manažérstva informačnej bezpečnosti (ISMS) namapované na konkrétne politiky, opatrenia a vlastníkov.

Tento bod je mostom medzi NIS2 a ISO 27001:2022. Article 21 NIS2 nie je iba uvedený ako externá požiadavka. Rozkladá sa na povinnosti vyplývajúce z politík, mapuje sa na opatrenia, prideľuje sa vlastníkom a testuje sa prostredníctvom dôkazov.

Pre menšie organizácie zachováva Politika právneho a regulačného súladu pre MSP ten istý koncept v odľahčenej forme. Bod 5.1.1 vyžaduje:

Generálny manažér (GM) musí viesť jednoduchý, štruktúrovaný register súladu, ktorý obsahuje:

Táto veta je zámerne praktická. Malé a stredné podniky nepotrebujú na začiatok komplexnú implementáciu GRC. Potrebujú register súladu, ktorý zachytáva povinnosť, uplatniteľnosť, vlastníka, politiku, dôkaz a periodicitu preskúmania.

Ošetrenie rizík následne premieňa povinnosť na činnosť. Podniková Politika riadenia rizík, bod 6.4.2 uvádza:

Manažér rizík zabezpečí, aby boli ošetrenia realistické, časovo ohraničené a namapované na opatrenia prílohy A ISO/IEC 27001.

Pre malé a stredné podniky poskytuje Politika riadenia rizík – MSP, bod 5.1.2 minimálny životaschopný záznam rizika:

Každý záznam rizika musí obsahovať: opis, pravdepodobnosť, vplyv, skóre, vlastníka a plán ošetrenia rizika.

Tieto ustanovenia sú dôležité, pretože NIS2 je výslovne založená na riziku a proporcionalite. Article 21 očakáva, že opatrenia budú odrážať aktuálny stav techniky, relevantné normy, náklady na implementáciu, vystavenie riziku, veľkosť, pravdepodobnosť a závažnosť incidentu vrátane spoločenského a ekonomického vplyvu. Register rizík bez vlastníkov a plánov ošetrenia rizík nedokáže preukázať proporcionalitu.

Podniková Politika informačnej bezpečnosti dopĺňa princíp dôkazov v bode 6.6.1:

Všetky implementované opatrenia musia byť auditovateľné, podporené zdokumentovanými postupmi a uchovávanými dôkazmi o fungovaní.

To je rozdiel medzi tým, že organizácia má program NIS2, a tým, že má dôkazový program NIS2.

Cesta Clarysec od mapovania k prevádzke

Zenith Blueprint je hodnotný, pretože zrkadlí spôsob uvažovania audítorov. Nepýtajú sa iba na to, či opatrenie existuje. Pýtajú sa, prečo bolo vybrané, kde je zdokumentované, ako funguje, kto ho vlastní, aké dôkazy ho preukazujú a ako ho organizácia zlepšuje.

Vo fáze riadenia rizík krok 13 vedie tímy k doplneniu sledovateľnosti medzi rizikami, opatreniami a ustanoveniami:

✓ Mapujte opatrenia na riziká: V pláne ošetrenia rizika vo vašom registri rizík ste pre každé riziko uviedli určité opatrenia. Ku každému riziku môžete pridať stĺpec „Odkaz na opatrenie prílohy A“ a uviesť čísla opatrení.

Pre NIS2 to znamená, že register rizík a Vyhlásenie o uplatniteľnosti majú ukazovať, prečo sú uplatniteľné opatrenia ako 8.8 Riadenie technických zraniteľností, 5.19 Informačná bezpečnosť vo vzťahoch s dodávateľmi a 5.24 Plánovanie a príprava riadenia incidentov.

Krok 14 v Zenith Blueprint robí regulačné mapovanie explicitným:

Pre každý predpis, ak je uplatniteľný, môžete vytvoriť jednoduchú mapovaciu tabuľku (napríklad ako prílohu správy), ktorá uvedie kľúčové bezpečnostné požiadavky predpisu a zodpovedajúce opatrenia/politiky vo vašom ISMS.

Tým sa predchádza fragmentácii. Bezpečnosť osobných údajov podľa GDPR, oznamovanie incidentov podľa NIS2, testovanie odolnosti IKT podľa DORA a zákaznícke bezpečnostné záväzky sa môžu opierať o rovnaké dôkazy: preskúmania prístupových práv, nápravu zraniteľností, záznamy logovania, testy záloh, preskúmania dodávateľov a správy o incidentoch.

Krok 19 posúva organizáciu z návrhu do prevádzky:

Prepojte každý z týchto dokumentov s príslušným opatrením vo vašom SoA alebo príručke ISMS. Budú slúžiť ako dôkaz implementácie a interný referenčný materiál.

Dokumentačný súbor kroku 19 zahŕňa zabezpečenie koncových zariadení, správu prístupov, autentifikáciu, referenčné bezpečné konfigurácie, logovanie a monitorovanie, riadenie záplat, riadenie zraniteľností, kapacitné plánovanie a reportovanie prevádzky IT. Ide presne o prevádzkové dokumenty potrebné na to, aby boli technické opatrenia NIS2 auditovateľné.

Krok 26 vysvetľuje, ako sa majú zhromažďovať auditné dôkazy:

Pri zhromažďovaní dôkazov zaznamenajte svoje zistenia. Uveďte, kde veci spĺňajú požiadavku (pozitívne zistenia) a kde ju nespĺňajú (potenciálne nezhody alebo pozorovania).

Pre NIS2 to znamená vzorkovať dôkazy skôr, než si ich vyžiada regulátor, zákaznícky posudzovateľ alebo certifikačný audítor.

Úloha Zenith Controls v krížovom súlade

Zenith Controls nie je samostatný rámec opatrení. Je to príručka krížového súladu Clarysec na mapovanie opatrení ISO/IEC 27001:2022 a ISO/IEC 27002:2022 na súvisiace opatrenia, očakávania auditu a externé rámce. Pomáha tímom pochopiť, ako môže jedno opatrenie ISO 27001:2022 podporovať NIS2, DORA, GDPR, NIST CSF 2.0 a uistenie v štýle COBIT.

Tri opatrenia ISO 27001:2022 sú pre mapovanie dôkazov NIS2 osobitne dôležité.

Opatrenie 5.1 Politiky informačnej bezpečnosti je vstupným bodom, pretože Article 21 NIS2 zahŕňa analýzu rizík a politiky bezpečnosti informačných systémov. Ak technické opatrenie NIS2 nie je premietnuté do politiky, je náročné ho riadiť a konzistentne auditovať.

Opatrenie 5.36 Súlad s politikami, pravidlami a normami informačnej bezpečnosti je kontrolou reality. Spája požiadavky politík so skutočným súladom s internými pravidlami, normami a externými povinnosťami. V terminológii NIS2 je to miesto, kde sa organizácia pýta, či robí to, čo uvádza jej mapovanie Article 21.

Opatrenie 8.8 Riadenie technických zraniteľností je jednou z najnáročnejších testovacích oblastí roku 2026. Riadenie zraniteľností priamo súvisí s bezpečným obstarávaním, vývojom, údržbou, riešením zraniteľností a zverejňovaním. Podporuje aj testovanie a nápravu podľa DORA, zodpovednosť za bezpečnosť podľa GDPR, výsledky Identify a Protect v NIST CSF a vzorkovanie v audite ISO 27001.

Podporné normy môžu spresniť návrh bez toho, aby vyžadovali ďalšie certifikácie. ISO/IEC 27002:2022 poskytuje implementačné usmernenia pre opatrenia prílohy A. ISO/IEC 27005 podporuje riadenie rizík informačnej bezpečnosti. ISO/IEC 27017 podporuje bezpečnosť cloudu. ISO/IEC 27018 podporuje ochranu osobne identifikovateľných informácií v scenároch verejného cloudu, kde poskytovateľ vystupuje ako sprostredkovateľ. ISO 22301 podporuje kontinuitu činností. ISO/IEC 27035 podporuje riadenie incidentov. ISO/IEC 27036 podporuje bezpečnosť vzťahov s dodávateľmi.

Cieľom nie je viac noriem pre samotné normy. Cieľom je lepší návrh dôkazov.

Praktický príklad: vytvorte dôkazový balík zraniteľností pre NIS2

Zoberme si Mariinu platformu SaaS. Slúži výrobným zákazníkom v EÚ a závisí od cloudových služieb, open-source komponentov, CI/CD pipeline a riadeného monitorovania. Jej správa o medzerách uvádza „riadenie zraniteľností implementované“, ale dôkazy sú roztrúsené medzi skenovacími nástrojmi, Jira, GitHub, nástrojmi konfigurácie cloudu a tiketmi zmien.

Dôkazový balík pripravený na NIS2 možno vytvoriť v jednom sústredenom implementačnom bloku.

Krok 1: Definujte rizikový scenár

Riziko: zneužiteľná zraniteľnosť v aplikácii prístupnej z internetu, závislosti alebo cloudovom komponente spôsobí prerušenie služby, neoprávnený prístup alebo sprístupnenie údajov zákazníkov.

Register rizík má obsahovať opis, pravdepodobnosť, vplyv, skóre, vlastníka a plán ošetrenia rizika. Plán ošetrenia rizika má odkazovať na opatrenie ISO 27001:2022 8.8 Riadenie technických zraniteľností a na súvisiace opatrenia pre inventarizáciu aktív, bezpečný vývoj, logovanie, riadenie prístupu, riadenie dodávateľov a reakciu na incidenty.

Krok 2: Namapujte riziko na Article 21 NIS2

Riziko podporuje požiadavky Article 21 na bezpečné obstarávanie, vývoj a údržbu, riešenie a zverejňovanie zraniteľností, analýzu rizík, riešenie incidentov, bezpečnosť dodávateľského reťazca a posúdenie účinnosti opatrení.

Krok 3: Ukotvite prevádzkové pravidlá v politike

Použite postup riadenia zraniteľností, štandard bezpečného vývoja, požiadavky na riadenie záplat, politiku bezpečnostného testovania a pravidlá auditných dôkazov.

Podniková Politika bezpečnostného testovania a cvičení red teamu, bod 6.1 uvádza:

Typy testov: Program bezpečnostného testovania musí zahŕňať minimálne: (a) skenovanie zraniteľností pozostávajúce z automatizovaných týždenných alebo mesačných skenov sietí a aplikácií na identifikáciu známych zraniteľností; (b) penetračné testovanie pozostávajúce z manuálneho hĺbkového testovania konkrétnych systémov alebo aplikácií kvalifikovanými testermi na identifikáciu komplexných slabých miest; a (c) cvičenia red teamu pozostávajúce zo simulácií reálnych útokov založených na scenároch vrátane sociálneho inžinierstva a iných taktík, ktoré testujú detekčné a reakčné schopnosti organizácie ako celku.

Tento bod vytvára obhájiteľný základ testovania. Zároveň sa zhoduje s očakávaním DORA na opakované, rizikovo orientované testovanie digitálnej prevádzkovej odolnosti pre zahrnuté finančné subjekty.

Krok 4: Definujte metadáta dôkazov

Politika monitorovania auditov a súladu – MSP, bod 6.2.3 uvádza:

Metadáta (napr. kto ich zhromaždil, kedy a z ktorého systému) musia byť zdokumentované.

Pri dôkazoch o zraniteľnostiach má balík zachytávať:

• názov skenovacieho nástroja a konfiguráciu,
• dátum a čas skenu,
• rozsah aktív a výnimky,
• kritické a vysoké zistenia,
• číslo tiketu a vlastníka,
• rozhodnutie o záplate alebo zmierňujúcom opatrení,
• rozhodnutie o akceptácii rizika, ak sa uplatňuje,
• dátum nápravy,
• validačný sken,
• odkaz na záznam zmeny,
• vlastníka výnimky a dátum uplynutia platnosti.

Krok 5: Doplňte dôkazy z logovania

Politika logovania a monitorovania – MSP, bod 5.4.4 zahŕňa systémové logy, napríklad:

Systémové logy: zmeny konfigurácie, administrátorské akcie, inštalácie softvéru, aktivita záplatovania

Samotný tiket záplaty nemusí preukázať, že zmena prebehla. Konfiguračné logy, administrátorské akcie a záznamy o inštalácii softvéru posilňujú dôkazovú reťaz.

Krok 6: Vykonajte vzorkový audit

Vyberte päť kritických alebo vysokých zraniteľností z predchádzajúceho štvrťroka. Pri každej položke overte, že aktívum bolo v inventári, skener zistenie detegoval, tiket bol otvorený v rámci SLA, bol priradený vlastník, náprava zodpovedala závažnosti a zneužiteľnosti, logy preukazujú zmenu, validácia potvrdzuje uzavretie a každá výnimka má schválenie vlastníka rizika s dátumom uplynutia platnosti.

Takýto implementačný blok vytvorí dôkazový balík zraniteľností pripravený na NIS2 a vzorku vnútorného auditu ISO 27001:2022.

Bezpečnosť dodávateľov je správa a riadenie ekosystému

Article 21 NIS2 vyžaduje bezpečnosť dodávateľského reťazca vrátane bezpečnostných aspektov vzťahov s priamymi dodávateľmi a poskytovateľmi služieb. Od organizácií tiež očakáva, že budú zohľadňovať zraniteľnosti dodávateľov, kvalitu produktov, postupy kybernetickej bezpečnosti dodávateľov a praktiky bezpečného vývoja.

Práve tu bola prvá verzia Mariinej správy o medzerách najslabšia. Uvádzala dodávateľov, ale nepreukazovala previerku dodávateľov, zmluvné bezpečnostné doložky, monitorovanie ani pripravenosť na ukončenie.

Politika bezpečnosti tretích strán a dodávateľov poskytuje politické ukotvenie. Súvisiacu implementáciu môžu podporiť Politika bezpečného vývoja, Politika povedomia a školenia o informačnej bezpečnosti, Politika riadenia zraniteľností a záplat, Politika kryptografických opatrení, Politika riadenia prístupu a Politika vzdialeného prístupu.

Jeden register dôkazov dodávateľov môže podporovať NIS2, DORA a ISO 27001:2022.

Táto tabuľka predchádza duplicitným dotazníkom, duplicitným registrom a protichodnému vlastníctvu opatrení.

Jeden pracovný tok incidentov pre NIS2, DORA a GDPR

Article 23 NIS2 vyžaduje, aby sa významné incidenty oznamovali bez zbytočného odkladu. Stanovuje fázovanú časovú os: včasné varovanie do 24 hodín od zistenia, oznámenie incidentu do 72 hodín s prvotným posúdením závažnosti alebo vplyvu a dostupnými indikátormi kompromitácie, priebežné aktualizácie na vyžiadanie a záverečnú správu najneskôr do jedného mesiaca od oznámenia incidentu.

DORA má pre finančné subjekty podobný životný cyklus: detekcia, klasifikácia, logovanie, posúdenie závažnosti, eskalácia, komunikácia s klientmi, oznamovanie orgánom, analýza koreňovej príčiny a náprava. GDPR dopĺňa analýzu porušenia ochrany osobných údajov vrátane rolí prevádzkovateľa a sprostredkovateľa, vplyvu na dotknuté osoby a 72-hodinovej oznamovacej lehoty, ak sa uplatňuje.

Správny návrh neznamená tri procesy riadenia incidentov. Znamená jeden pracovný tok riadenia incidentov s rozhodovacími vetvami pre jednotlivé predpisy.

Politika reakcie na incidenty – MSP, bod 5.4.1 uvádza:

Všetky vyšetrovania incidentov, zistenia a nápravné opatrenia musia byť zaznamenané v registri incidentov vedenom generálnym manažérom.

Silný register incidentov má obsahovať:

Väzbu na GDPR netreba podceňovať. Príslušné orgány NIS2 môžu informovať dozorné orgány GDPR, ak zlyhania riadenia kybernetických rizík alebo oznamovania môžu viesť k porušeniu ochrany osobných údajov. ISMS má preto začleniť posúdenie ochrany súkromia do triáže incidentov, nie ho riešiť dodatočne.

Ako budú audítori a regulátori testovať vaše dôkazy NIS2

Organizácia pripravená na rok 2026 má očakávať, že to isté opatrenie bude testované z rôznych pohľadov.

Audítor ISO 27001:2022 začne s ISMS. Bude sa pýtať, či sú povinnosti NIS2 identifikované ako požiadavky zainteresovaných strán, či rozsah ISMS pokrýva relevantné služby a závislosti, či sú riziká posúdené a ošetrené, či Vyhlásenie o uplatniteľnosti odôvodňuje uplatniteľné opatrenia a či záznamy preukazujú fungovanie.

Príslušný orgán NIS2 sa zameria na právne výsledky. Môže sa pýtať, či sú pokryté všetky opatrenia podľa Article 21, či sú opatrenia primerané a proporcionálne, či ich manažment schválil a dohliada na ne a či oznamovanie incidentov dokáže splniť požadované lehoty.

Orgán dohľadu podľa DORA bude pri zahrnutých finančných subjektoch testovať riadenie IKT rizík, klasifikáciu incidentov, testovanie odolnosti, riziká tretích strán, zmluvné dojednania, riziko koncentrácie a stratégie ukončenia.

Posudzovateľ GDPR bude testovať, či technické a organizačné opatrenia chránia osobné údaje, či je posúdenie porušenia ochrany údajov začlenené do riešenia incidentov, či sú jasné roly prevádzkovateľa a sprostredkovateľa a či existujú záznamy preukázateľnej zodpovednosti.

Posudzovateľ v štýle NIST CSF 2.0 alebo COBIT 2019 sa zameria na správu a riadenie, vlastníctvo rizík, ukazovatele výkonnosti, aktuálne a cieľové výsledky, procesnú spôsobilosť a zosúladenie s apetítom organizácie na riziko.

Podniková Politika monitorovania auditov a súladu, bod 3.4 zachytáva účel dôkazov:

Vytvárať obhájiteľné dôkazy a auditnú stopu na podporu regulačných preverení, právnych konaní alebo požiadaviek zákazníkov na preukázanie súladu.

To je prevádzkový štandard, ku ktorému majú tímy NIS2 smerovať.

Zodpovednosť manažmentu: riadiaci orgán nemôže NIS2 delegovať mimo seba

Article 20 NIS2 vyžaduje, aby riadiace orgány základných a dôležitých subjektov schvaľovali opatrenia riadenia kybernetických rizík, dohliadali na ich implementáciu a absolvovali školenie. Členovia riadiacich orgánov môžu niesť zodpovednosť za porušenia podľa vnútroštátnych pravidiel zodpovednosti.

To je v súlade s požiadavkami ISO 27001:2022 na vedenie. Vrcholový manažment musí zabezpečiť, aby politika a ciele informačnej bezpečnosti boli zosúladené so strategickým smerovaním, aby požiadavky ISMS boli integrované do podnikových procesov, aby boli poskytnuté zdroje, komunikovaná dôležitosť, priradené zodpovednosti a podporované neustále zlepšovanie.

Riadiaci orgán nepotrebuje surové exporty zo skenerov ani úplné logy SIEM. Potrebuje uistenie vhodné na rozhodovanie.

Štvrťročný dôkazový balík NIS2 pre riadiaci orgán má obsahovať:

1. zmeny rozsahu a regulačného statusu,
2. najvýznamnejšie riziká NIS2 a stav ich ošetrenia,
3. prehľad účinnosti opatrení podľa Article 21,
4. významné incidenty, takmer vzniknuté incidenty a rozhodnutia o oznamovaní,
5. výnimky rizík dodávateľov a cloudu,
6. zistenia vnútorného auditu, nápravné opatrenia a oneskorené dôkazy.

Tento balík poskytuje manažmentu informácie potrebné na schvaľovanie opatrení, spochybňovanie výnimiek a akceptáciu zostatkového rizika.

Prevádzkový model Clarysec pre rok 2026

Uvedenie technických opatrení NIS2 do praxe s ISO 27001:2022 vyžaduje jednoduchý, ale disciplinovaný model:

• zahrnúť NIS2, DORA, GDPR a zmluvné povinnosti do rozsahu ISMS,
• mapovať povinnosti na riziká, politiky, opatrenia, vlastníkov a dôkazy,
• používať Vyhlásenie o uplatniteľnosti ako autoritatívny zdroj opatrení,
• vytvárať dôkazové balíky pre vysoko rizikové oblasti Article 21,
• integrovať oznamovanie incidentov do jedného regulačného pracovného toku,
• riadiť bezpečnosť dodávateľov ako životný cyklus, nie ako dotazník,
• vykonávať vnútorné audity na reálnych vzorkách,
• reportovať účinnosť opatrení riadiacim orgánom,
• zlepšovať sa na základe incidentov, auditných zistení, testov a regulačných zmien.

Pre Mariu nastal zlom v okamihu, keď si uvedomila, že nepotrebuje samostatný projekt NIS2. Potrebovala silnejší dôkazový mechanizmus ISMS.

Politiky Clarysec, Zenith Blueprint a Zenith Controls sú navrhnuté tak, aby spolu fungovali. Politiky definujú očakávané správanie a záznamy. Zenith Blueprint poskytuje 30-krokovú implementačnú a auditnú cestu. Zenith Controls poskytuje mapovanie krížového súladu, aby bolo možné NIS2, ISO 27001:2022, DORA, GDPR, NIST CSF a uistenie v štýle COBIT riadiť ako jeden konzistentný program.

Ďalší krok: vytvorte mapu dôkazov NIS2 na ISO 27001:2022

Ak vaša práca na NIS2 stále žije v tabuľke medzier, rok 2026 je čas uviesť ju do praxe.

Začnite jedným vysoko rizikovým technickým opatrením, napríklad riadením zraniteľností, riešením incidentov alebo bezpečnosťou dodávateľov. Namapujte ho na riziká ISO 27001:2022, politiky, opatrenia prílohy A, vlastníkov, postupy a dôkazy. Potom odoberte vzorku záznamov za minulý štvrťrok a položte si náročnú otázku: uspokojilo by to regulátora, zákazníckeho posudzovateľa a audítora ISO 27001:2022?

Clarysec vám môže pomôcť vybudovať túto odpoveď pomocou knižnice politík, Zenith Blueprint a Zenith Controls.

Cieľom nie je viac dokumentácie. Cieľom sú obhájiteľné, opakovateľné dôkazy, že vaše technické opatrenia NIS2 skutočne fungujú.