NIS2 bizonyítéktérképezés ISO 27001:2022 alapján 2026-ra

A 2026-os NIS2-probléma nem a tudatosság, hanem a bizonyíthatóság

Hétfő reggel van, 08:35. Maria, egy gyorsan növekvő B2B felhő- és menedzselt szolgáltatásokat nyújtó vállalat nemrég kinevezett információbiztonsági vezetője (CISO), csatlakozik a negyedéves igazgatósági kockázati értekezlethez, miközben a laptopján egy terjedelmes NIS2 hiányosságelemzés van megnyitva. Az első dia megnyugtatónak tűnik. Vannak szabályzatok. Van kockázatértékelés. Az incidensreagálás dokumentált. A beszállítók szerepelnek a listában. A sérülékenységvizsgálatok havonta lefutnak.

Ekkor az elnök felteszi a kérdést, amely megváltoztatja az értekezlet menetét:

„Bizonyítani tudjuk, hogy ezek az intézkedések az előző negyedévben ténylegesen működtek, és meg tudjuk mutatni, hogy mely ISO 27001:2022 kontrollok, felelősök és nyilvántartások támogatják az egyes NIS2-kötelezettségeket?”

A teremben csend lesz.

A jogi terület tudja, hogy a vállalat a NIS2 hatálya alá tartozik, mert menedzselt IKT- és felhőszolgáltatásokat nyújt EU-s ügyfeleknek. A megfelelőségi terület tudja, hogy az Article 21 technikai, működési és szervezeti kiberbiztonsági kockázatkezelési intézkedéseket ír elő. Az üzemeltetés tudja, hogy a csapat javításokat telepít, beszállítókat vizsgál felül és naplókat figyel. A bizonyítékok azonban szétszórva találhatók jegykezelő rendszerekben, SIEM-exportokban, szabályzatmappákban, táblázatokban, felhőkonzolokban, beszállítói portálokon és értekezleti feljegyzésekben.

Senki sem tud gyorsan bemutatni egy igazolható láncot a NIS2 Article 21 követelményeitől az ISO 27001:2022 hatályig, kockázatig, kontrollig, szabályzatig, felelősig, eljárásig, működési nyilvántartásig és auditmegállapításig.

Ez a valódi 2026-os kihívás.

Sok szervezet már nem azt kérdezi: „A NIS2 hatálya alá tartozunk?” Hanem egy nehezebb kérdést tesz fel: „Bizonyítani tudjuk, hogy a NIS2 szerinti technikai intézkedéseink ténylegesen működnek?” A válasz nem lehet egy egyszeri megfeleltetési táblázat. Élő működési modellnek kell lennie az információbiztonsági irányítási rendszerben (IBIR), ahol a jogi kötelezettségek kockázatokká, szabályzatokká, kontrollokká, felelősökké, bizonyítékokká és folyamatos fejlesztéssé alakulnak.

A Clarysec modellje az ISO/IEC 27001:2022 szabványt használja az irányítási rendszer gerinceként, a NIS2 Article 21 követelményeit szabályozói kötelezettségkészletként, a szabályzati pontokat működési szabálykönyvként, a Zenith Blueprint: egy auditor 30 lépéses ütemterve megoldást bevezetési útvonalként, a Zenith Controls: keresztmegfelelési útmutató megoldást pedig keresztmegfelelési térképként az ISO 27001:2022, NIS2, DORA, GDPR, NIST CSF és COBIT-szerű bizonyosság között.

A hatállyal kell kezdeni, mert a NIS2-bizonyíték a kontrollok előtt kezdődik

Gyakori NIS2-hiba, hogy a szervezetek közvetlenül az MFA, a naplózás, az incidensreagálás és a sérülékenységkezelés témáira ugranak, mielőtt megerősítenék a szervezeti hatályt, a szolgáltatási hatályt és a joghatósági hatályt.

A NIS2 a szabályozott ágazatokban működő, méret- és tevékenységi kritériumoknak megfelelő, érintett köz- és magánszervezetekre alkalmazandó; bizonyos szervezettípusok pedig mérettől függetlenül a hatálya alá tartoznak. A releváns digitális és IKT-kategóriák közé tartoznak a felhőszolgáltatók, adatközpont-szolgáltatók, tartalomkézbesítő hálózati szolgáltatók, bizalmi szolgáltatók, nyilvános elektronikus hírközlési szolgáltatók, menedzselt szolgáltatók, menedzselt biztonsági szolgáltatók, online piacterek, online keresőmotorok és közösségi hálózati platformok.

Felhőszolgáltatók, SaaS-platformok, MSP-k, MSSP-k és digitális infrastruktúra-szolgáltatók esetében ez a hatálymeghatározás nem elméleti gyakorlat. Az Article 3 előírja a tagállamok számára, hogy különböztessék meg az alapvető és fontos szervezeteket. Az Article 27 előírja az ENISA számára, hogy több digitális és IKT-szolgáltatóról nyilvántartást vezessen, ideértve a DNS-szolgáltatókat, TLD névnyilvántartókat, domainnév-regisztrációs szolgáltatókat, felhőszolgáltatókat, adatközpont-szolgáltatókat, tartalomkézbesítő hálózati szolgáltatókat, menedzselt szolgáltatókat, menedzselt biztonsági szolgáltatókat, online piactereket, online keresőmotorokat és közösségi hálózati platformokat.

Az ISO 27001:2022 megfelelő struktúrát ad. A 4.1–4.4 pontok előírják, hogy a szervezet értse meg a külső és belső tényezőket, az érdekelt feleket, a követelményeket, az interfészeket és a függőségeket, majd határozza meg az IBIR alkalmazási területét. A NIS2-t itt kell rögzíteni, nem szabad egy jogi feljegyzésben hagyni.

Egy gyakorlati NIS2 hatálymeghatározási nyilvántartásnak tartalmaznia kell:

• Jogi személy és EU-s letelepedés elemzése
• NIS2 ágazat és szolgáltatási kategória
• Alapvető vagy fontos szervezeti státusz, ahol azt a nemzeti jog vagy hatósági kijelölés megerősíti
• ENISA-nyilvántartási relevancia, ahol alkalmazandó
• Ügyfeleknek nyújtott kritikus szolgáltatások
• Az ezeket a szolgáltatásokat támogató hálózati és információs rendszerek
• Függőségek felhő-, adatközpont-, telekommunikációs, biztonsági monitoring-, identitás- és szoftverszolgáltatóktól
• Kapcsolódások a DORA, GDPR, ügyfélszerződések és ágazatspecifikus kötelezettségek felé
• Bizonyítéktárak, rendszerfelelősök és felülvizsgálati ütemezés

Itt kell helyesen elkülöníteni a DORA követelményeit is. A NIS2 elismeri, hogy amennyiben egy ágazatspecifikus uniós jogi aktus egyenértékű kiberbiztonsági kockázatkezelési vagy incidensbejelentési kötelezettségeket ír elő, az adott ágazatspecifikus szabályozás alkalmazandó a megfelelő NIS2-rendelkezések helyett. Az érintett pénzügyi szervezetek esetében általában a DORA az irányadó kiberbiztonsági és IKT-incidensjelentési rendszer. A DORA 2025. január 17-től alkalmazandó, és kiterjed az IKT-kockázatkezelésre, az incidensjelentésre, a digitális operatív reziliencia tesztelésére, az IKT harmadik féllel kapcsolatos kockázatra és a kritikus IKT harmadik fél szolgáltatók felügyeletére.

Egy fintech csoporton belül ezért eltérő megfelelőségi kezelések jelenhetnek meg ugyanazon vállalati struktúrán belül. A fizetési szervezet elsődlegesen a DORA hatálya alá tartozhat. Az MSP leányvállalat közvetlenül a NIS2 hatálya alá eshet. Egy közös felhőplatform mindkettőt támogathatja. Az érett válasz nem a kontrollok megkettőzése. Hanem egyetlen IBIR bizonyítékmodell, amely több szabályozói nézőpontot is képes kiszolgálni.

Az ISO 27001:2022 mint a NIS2-megfelelés működési rendszere

A NIS2 Article 21 megfelelő és arányos technikai, működési és szervezeti intézkedéseket ír elő a hálózati és információs rendszereket érintő kockázatok kezelésére, valamint az incidensek szolgáltatásigénybe vevőkre és más szolgáltatásokra gyakorolt hatásának megelőzésére vagy minimalizálására.

Az ISO 27001:2022 jól alkalmas e követelmény működésbe ültetésére, mert három fegyelmet kényszerít ki.

Először: irányítás. Az 5.1–5.3 pontok előírják a felső vezetés elkötelezettségét, a stratégiai iránnyal való összhangot, az erőforrás-biztosítást, a kommunikációt, a felelősségek kijelölését és a dokumentált információbiztonsági szabályzatot. Ez közvetlenül összhangban áll a NIS2 Article 20 követelményével, amely szerint a vezető testületeknek jóvá kell hagyniuk a kiberbiztonsági kockázatkezelési intézkedéseket, felügyelniük kell azok végrehajtását, és képzésben kell részesülniük.

Másodszor: kockázatkezelés. A 6.1.1–6.1.3 pontok ismételhető kockázatértékelési folyamatot, kockázattulajdonosokat, kockázatértékelést, kezelési opciókat, kontrollkiválasztást, alkalmazhatósági nyilatkozatot, kockázatkezelési tervet és maradványkockázat-jóváhagyást írnak elő.

Harmadszor: operatív kontroll. A 8.1 pont előírja, hogy a szervezet tervezze meg, vezesse be és szabályozza az IBIR-folyamatokat, tartsa fenn a dokumentált információkat, szabályozza a változásokat, és kezelje az IBIR szempontjából releváns, külső fél által biztosított folyamatokat, termékeket és szolgáltatásokat.

Ez a NIS2-t jogi ellenőrzőlistából kontrollalapú működési modellé alakítja.

Minden sorhoz felelős, nyilvántartási forrás és mintavételi módszer szükséges. Ha ezek hiányoznak, a szervezetnek kontrolltörekvése van, nem kontrollja.

A szabályzat az a pont, ahol a NIS2 működési magatartássá válik

A szabályzatokat gyakran sablonként kezelik. A NIS2 esetében ez veszélyes. Egy szabályozó hatóságot vagy auditort nem fog meggyőzni egy szabályzatmappa, ha a szabályzatok nem jelölnek ki felelősséget, nem határoznak meg nyilvántartásokat, nem kapcsolódnak kockázatokhoz és nem állítanak elő bizonyítékot.

A vállalati Jogi és szabályozói megfelelőségi szabályzat a 6.2.1 pontban teremti meg az alapot:

Minden jogi és szabályozói kötelezettséget konkrét szabályzatokhoz, kontrollokhoz és felelősökhöz kell rendelni az információbiztonsági irányítási rendszerben (IBIR).

Ez a pont teremti meg a hidat a NIS2 és az ISO 27001:2022 között. A NIS2 Article 21 nem egyszerűen külső követelményként szerepel. Szabályzati kötelezettségekre kell bontani, kontrollokhoz kell rendelni, felelősökhöz kell kiosztani, és bizonyítékokon keresztül kell tesztelni.

Kisebb szervezeteknél a KKV-k számára készült Jogi és szabályozói megfelelőségi szabályzat ugyanezt a koncepciót tartja könnyen kezelhető formában. Az 5.1.1 pont előírja:

Az ügyvezetőnek egyszerű, strukturált megfelelőségi nyilvántartást kell fenntartania, amely tartalmazza:

A mondat szándékosan gyakorlatias. A KKV-knak a kezdéshez nincs szükségük összetett GRC-bevezetésre. Olyan megfelelőségi nyilvántartásra van szükségük, amely rögzíti a kötelezettséget, az alkalmazhatóságot, a felelőst, a szabályzatot, a bizonyítékot és a felülvizsgálati ütemezést.

A kockázatkezelés ezt követően cselekvéssé alakítja a kötelezettséget. A vállalati Kockázatkezelési szabályzat 6.4.2 pontja kimondja:

A kockázatkezelési felelősnek biztosítania kell, hogy a kezelések reálisak, határidőhöz kötöttek legyenek, és az ISO/IEC 27001 A mellékletének kontrolljaihoz legyenek rendelve.

KKV-k esetében a Kockázatkezelési szabályzat – KKV 5.1.2 pontja adja meg a minimálisan szükséges kockázati nyilvántartást:

Minden kockázati bejegyzésnek tartalmaznia kell: leírás, valószínűség, hatás, pontszám, felelős és kockázatkezelési terv.

Ezek a pontok azért fontosak, mert a NIS2 kifejezetten kockázatalapú és arányos. Az Article 21 elvárja, hogy az intézkedések tükrözzék a technika állását, a releváns szabványokat, a bevezetési költséget, a kockázati kitettséget, a méretet, az incidens bekövetkezési valószínűségét és súlyosságát, beleértve a társadalmi és gazdasági hatást is. A felelősök és kezelési tervek nélküli kockázati nyilvántartás nem tudja bizonyítani az arányosságot.

A vállalati Információbiztonsági szabályzat a 6.6.1 pontban egészíti ki a bizonyítékelvet:

Minden bevezetett kontrollnak auditálhatónak kell lennie, dokumentált eljárásokkal és a működés megőrzött bizonyítékaival alátámasztva.

Ez a különbség a NIS2-program és a NIS2-bizonyítékprogram között.

A Clarysec útja a térképezéstől a működésig

A Zenith Blueprint azért értékes, mert azt tükrözi, ahogyan az auditorok gondolkodnak. Nem csak azt kérdezik, hogy létezik-e egy kontroll. Azt is kérdezik, miért választották ki, hol dokumentálták, hogyan működik, ki a felelőse, milyen bizonyíték igazolja, és hogyan fejleszti tovább a szervezet.

A kockázatkezelési fázisban a 13. lépés arra utasítja a csapatokat, hogy teremtsenek visszakövethetőséget a kockázatok, kontrollok és pontok között:

✓ Rendeld a kontrollokat a kockázatokhoz: a kockázati nyilvántartás kezelési tervében minden kockázathoz megadtál bizonyos kontrollokat. Minden kockázathoz hozzáadhatsz egy „A melléklet szerinti kontrollhivatkozás” oszlopot, és felsorolhatod a kontrollszámokat.

A NIS2 esetében ez azt jelenti, hogy a kockázati nyilvántartásnak és az alkalmazhatósági nyilatkozatnak meg kell mutatnia, miért alkalmazandók például a 8.8 technikai sérülékenységek kezelése, az 5.19 információbiztonság a beszállítói kapcsolatokban és az 5.24 incidenskezelési tervezés és felkészülés kontrollok.

A Zenith Blueprint 14. lépése egyértelművé teszi a szabályozói megfeleltetést:

Minden szabályozás esetében, ahol alkalmazandó, létrehozhatsz egy egyszerű megfeleltetési táblázatot — akár egy jelentés mellékleteként —, amely felsorolja a szabályozás fő biztonsági követelményeit és az ezeknek megfelelő kontrollokat/szabályzatokat az IBIR-ben.

Ez megakadályozza a széttöredezést. A GDPR szerinti személyesadat-biztonság, a NIS2 szerinti incidensjelentés, a DORA szerinti IKT-reziliencia tesztelése és az ügyfélbiztonsági vállalások mind ugyanarra a bizonyítékra támaszkodhatnak: hozzáférés-felülvizsgálatokra, sérülékenységek javítására, naplózási nyilvántartásokra, biztonságimentés-tesztekre, beszállítói felülvizsgálatokra és incidensjelentésekre.

A 19. lépés a tervezéstől a működésig visz:

Kapcsold ezeket a dokumentumokat a megfelelő kontrollhoz az SoA-ban vagy az IBIR-kézikönyvben. Ezek a bevezetés bizonyítékaként és belső hivatkozásként szolgálnak majd.

A 19. lépés dokumentációs készlete magában foglalja a végpontbiztonságot, a hozzáféréskezelést, a hitelesítést, a biztonságos konfigurációs alapokat, a naplózást és monitoringot, a javításkezelést, a sérülékenységkezelést, a kapacitástervezést és az IT-üzemeltetési jelentéstételt. Pontosan ezek azok a működési dokumentumok, amelyek szükségesek ahhoz, hogy a NIS2 technikai intézkedései auditálhatóvá váljanak.

A 26. lépés elmagyarázza, hogyan kell az auditbizonyítékok gyűjtését végezni:

A bizonyítékok gyűjtése során rögzítsd a megállapításaidat. Jegyezd fel, hol felelnek meg a tények a követelménynek — pozitív megállapítások —, és hol nem — lehetséges nemmegfelelőségek vagy észrevételek.

A NIS2 esetében ez azt jelenti, hogy a bizonyítékokat még azelőtt mintavételezni kell, hogy egy szabályozó hatóság, ügyfélértékelő vagy tanúsító auditor kérné azokat.

A Zenith Controls keresztmegfelelési szerepe

A Zenith Controls nem különálló kontrollkeretrendszer. Ez a Clarysec keresztmegfelelési útmutatója az ISO/IEC 27001:2022 és ISO/IEC 27002:2022 kontrollok kapcsolódó kontrollokhoz, auditelvárásokhoz és külső keretrendszerekhez való térképezéséhez. Segít a csapatoknak megérteni, hogyan támogathat egyetlen ISO 27001:2022 kontroll NIS2, DORA, GDPR, NIST CSF 2.0 és COBIT-szerű bizonyosságot.

Három ISO 27001:2022 kontroll különösen fontos a NIS2 bizonyítéktérképezése szempontjából.

Az 5.1 kontroll, az Információbiztonsági szabályzatok a belépési pont, mert a NIS2 Article 21 kockázatelemzést és információsrendszer-biztonsági szabályzatokat is magában foglal. Ha egy NIS2 technikai intézkedés nem jelenik meg szabályzatban, nehéz irányítani és következetesen auditálni.

Az 5.36 kontroll, a Megfelelés az információbiztonsági szabályzatoknak, szabályoknak és szabványoknak a valóságpróba. Összekapcsolja a szabályzati követelményeket a belső szabályoknak, szabványoknak és külső kötelezettségeknek való tényleges megfeleléssel. NIS2-terminológiával ez az a pont, ahol a szervezet megkérdezi, hogy valóban azt teszi-e, amit az Article 21 szerinti térképezése állít.

A 8.8 kontroll, a Technikai sérülékenységek kezelése, 2026 egyik legnehezebb tesztterülete. A sérülékenységkezelés közvetlenül releváns a biztonságos beszerzés, fejlesztés, karbantartás, sérülékenységkezelés és bejelentés szempontjából. Támogatja továbbá a DORA szerinti tesztelést és korrekciós intézkedéseket, a GDPR szerinti biztonsági elszámoltathatóságot, a NIST CSF Identify és Protect eredményeit, valamint az ISO 27001 auditmintavételt.

A támogató szabványok további tanúsítások nélkül is pontosíthatják a tervezést. Az ISO/IEC 27002:2022 bevezetési iránymutatást ad az A melléklet szerinti kontrollokhoz. Az ISO/IEC 27005 támogatja az információbiztonsági kockázatkezelést. Az ISO/IEC 27017 támogatja a felhőbiztonságot. Az ISO/IEC 27018 támogatja a személyazonosításra alkalmas információk védelmét nyilvános felhőben adatfeldolgozói helyzetekben. Az ISO 22301 támogatja az üzletmenet-folytonosságot. Az ISO/IEC 27035 támogatja az incidenskezelést. Az ISO/IEC 27036 támogatja a beszállítói kapcsolatok biztonságát.

A cél nem az, hogy önmagukért több szabványt alkalmazzunk. A cél a jobb bizonyítéktervezés.

Gyakorlati példa: NIS2 sérülékenységi bizonyítékcsomag kialakítása

Vegyük Maria SaaS-platformját. EU-s gyártóipari ügyfeleket szolgál ki, és felhőszolgáltatásoktól, nyílt forráskódú komponensektől, CI/CD-folyamatláncoktól és menedzselt monitoringszolgáltatástól függ. A hiányosságelemzési jelentése azt állítja: „a sérülékenységkezelés bevezetve”, de a bizonyítékok szétszórva találhatók vizsgálati eszközökben, Jira-rendszerben, GitHub-tárakban, felhőkonfigurációs eszközökben és változtatási jegyekben.

Egy NIS2-re felkészített bizonyítékcsomag egy célzott sprintben felépíthető.

1. lépés: A kockázati forgatókönyv meghatározása

Kockázat: egy internet felől elérhető alkalmazásban, függőségben vagy felhőkomponensben található kihasználható sérülékenység szolgáltatáskimaradást, jogosulatlan hozzáférést vagy ügyféladat-kitettséget okoz.

A kockázati nyilvántartásnak tartalmaznia kell a leírást, valószínűséget, hatást, pontszámot, felelőst és kockázatkezelési tervet. A kezelési tervnek hivatkoznia kell az ISO 27001:2022 8.8 Technikai sérülékenységek kezelése kontrolljára, valamint az eszköznyilvántartáshoz, biztonságos fejlesztéshez, naplózáshoz, hozzáférés-szabályozáshoz, beszállítókezeléshez és incidensreagáláshoz kapcsolódó kontrollokra.

2. lépés: A kockázat hozzárendelése a NIS2 Article 21 követelményeihez

A kockázat támogatja az Article 21 követelményeit a biztonságos beszerzés, fejlesztés és karbantartás, a sérülékenységkezelés és bejelentés, a kockázatelemzés, az incidenskezelés, az ellátási lánc biztonsága és a kontrollhatékonyság-értékelés területén.

3. lépés: A működési szabályok szabályzatban való rögzítése

Alkalmazz sérülékenységkezelési eljárást, biztonságos fejlesztési szabványt, javításkezelési követelményeket, biztonsági tesztelési szabályzatot és auditbizonyítékokra vonatkozó szabályokat.

A vállalati Biztonsági tesztelési és red teaming szabályzat 6.1 pontja kimondja:

Teszttípusok: a biztonsági tesztelési programnak legalább a következőket kell tartalmaznia: (a) sérülékenységvizsgálat, amely hálózatok és alkalmazások automatizált heti vagy havi vizsgálatából áll az ismert sérülékenységek azonosítása érdekében; (b) penetrációs tesztelés, amely meghatározott rendszerek vagy alkalmazások képzett tesztelők általi, manuális, mélyreható teszteléséből áll az összetett gyengeségek azonosítása érdekében; és (c) red teaming gyakorlatok, amelyek valós támadásokat modellező, forgatókönyv-alapú szimulációkból állnak, beleértve a szociális manipulációt és más taktikákat is, a szervezet egészének észlelési és reagálási képességeinek tesztelése érdekében.

Ez a pont igazolható tesztelési alapvonalat hoz létre. Összhangban áll a DORA elvárásával is, amely az érintett pénzügyi szervezeteknél ismétlődő, kockázatalapú digitális operatív reziliencia tesztelést vár el.

4. lépés: A bizonyítékmetaadatok meghatározása

Az Audit- és megfelelőség-monitoring szabályzat – KKV 6.2.3 pontja kimondja:

A metaadatokat — például ki gyűjtötte, mikor és melyik rendszerből — dokumentálni kell.

A sérülékenységi bizonyítékok esetében a csomagnak rögzítenie kell:

• Vizsgálati eszköz neve és konfigurációja
• Vizsgálat dátuma és időpontja
• Eszközhatály és kizárások
• Kritikus és magas besorolású megállapítások
• Jegyszám és felelős
• Javítási vagy kockázatcsökkentési döntés
• Kockázatelfogadási döntés, ahol alkalmazandó
• Helyesbítő intézkedés dátuma
• Ellenőrző vizsgálat
• Változásbejegyzés hivatkozása
• Kivétel felelőse és lejárati dátuma

5. lépés: Naplózási bizonyíték hozzáadása

A Naplózási és monitoring szabályzat – KKV 5.4.4 pontja például a következő rendszernaplókat tartalmazza:

Rendszernaplók: konfigurációváltozások, adminisztratív műveletek, szoftvertelepítések, javítási tevékenység

Egy javítási jegy önmagában nem feltétlenül bizonyítja, hogy a változás megtörtént. A konfigurációs naplók, adminisztratív műveletek és szoftvertelepítési nyilvántartások megerősítik a bizonyítékláncot.

6. lépés: Mintaaudit végrehajtása

Válassz ki öt kritikus vagy magas besorolású sérülékenységet az előző negyedévből. Minden tételnél ellenőrizd, hogy az eszköz szerepelt-e a nyilvántartásban, a vizsgálati eszköz észlelte-e a megállapítást, a jegyet SLA-n belül megnyitották-e, kijelöltek-e felelőst, a helyesbítő intézkedés megfelelt-e a súlyosságnak és kihasználhatóságnak, a naplók mutatják-e a változást, az ellenőrzés megerősíti-e a lezárást, és minden kivétel rendelkezik-e kockázatgazdai jóváhagyással és lejárati dátummal.

Ez a sprint NIS2-re felkészített sérülékenységi bizonyítékcsomagot és ISO 27001:2022 belső auditmintát eredményez.

A beszállítói biztonság ökoszisztéma-irányítás

A NIS2 Article 21 előírja az ellátási lánc biztonságát, beleértve a közvetlen beszállítókkal és szolgáltatókkal fennálló kapcsolatok biztonsági szempontjait. Elvárja továbbá, hogy a szervezetek figyelembe vegyék a beszállítói sérülékenységeket, a termékminőséget, a beszállítók kiberbiztonsági gyakorlatát és a biztonságos fejlesztési gyakorlatokat.

Maria hiányosságelemzésének első változata ezen a ponton volt a leggyengébb. Felsorolta a beszállítókat, de nem bizonyította a kellő gondosságot, a szerződéses biztonsági záradékokat, a monitoringot vagy a kilépési felkészültséget.

A Harmadik fél és beszállítói biztonsági szabályzat adja a szabályzati alapot. A kapcsolódó bevezetést támogathatja a Biztonságos fejlesztési szabályzat, az Információbiztonsági tudatossági és képzési szabályzat, a Sérülékenység- és javításkezelési szabályzat, a Kriptográfiai kontrollok szabályzata, a Hozzáférés-szabályozási szabályzat és a Távmunka-szabályzat.

Egyetlen beszállítói bizonyítéknyilvántartás támogathatja a NIS2, DORA és ISO 27001:2022 követelményeit.

Ez a táblázat megelőzi a párhuzamos kérdőíveket, a párhuzamos nyilvántartásokat és az ellentmondásos kontrollfelelősségeket.

Egyetlen incidens-munkafolyamat a NIS2, DORA és GDPR számára

A NIS2 Article 23 előírja, hogy a jelentős incidenseket indokolatlan késedelem nélkül be kell jelenteni. Szakaszos határidőrendszert állapít meg: korai figyelmeztetés az észleléstől számított 24 órán belül, incidensbejelentés 72 órán belül az elsődleges súlyossági vagy hatásvizsgálattal és a rendelkezésre álló kompromittálódási indikátorokkal, közbenső frissítések kérés esetén, valamint végleges jelentés legkésőbb az incidensbejelentést követő egy hónapon belül.

A DORA hasonló életciklust ír elő a pénzügyi szervezetek számára: észlelés, osztályozás, naplózás, súlyossági értékelés, eszkaláció, ügyfélkommunikáció, hatósági jelentéstétel, gyökérok-elemzés és helyesbítő intézkedés. A GDPR személyesadat-sértési elemzést ad hozzá, beleértve az adatkezelői és adatfeldolgozói szerepeket, az érintettekre gyakorolt hatást és az alkalmazandó 72 órás bejelentési határidőt.

A helyes kialakítás nem három külön incidensfolyamat. Hanem egyetlen incidens-munkafolyamat szabályozói döntési ágakkal.

Az Incidenskezelési szabályzat – KKV 5.4.1 pontja kimondja:

Minden incidensvizsgálatot, megállapítást és helyesbítő intézkedést az ügyvezető által fenntartott incidensnyilvántartásban kell rögzíteni.

Egy erős incidensnyilvántartásnak tartalmaznia kell:

A GDPR-kapcsolatot nem szabad alábecsülni. A NIS2 illetékes hatóságai tájékoztathatják a GDPR szerinti felügyeleti hatóságokat, ha a kiberbiztonsági kockázatkezelési vagy jelentéstételi hibák személyesadat-sértéssel járhatnak. Az IBIR-nek ezért az adatvédelmi értékelést az incidensek elsődleges értékelésének részévé kell tennie, nem utólagos gondolatként kell kezelnie.

Hogyan fogják az auditorok és szabályozó hatóságok tesztelni a NIS2-bizonyítékokat

Egy 2026-ra felkészült szervezetnek számítania kell arra, hogy ugyanazt a kontrollt különböző nézőpontokból tesztelik.

Egy ISO 27001:2022 auditor az IBIR-rel kezdi. Meg fogja kérdezni, hogy a NIS2-kötelezettségeket az érdekelt felek követelményeiként azonosították-e, az IBIR alkalmazási területe lefedi-e a releváns szolgáltatásokat és függőségeket, a kockázatokat értékelték és kezelték-e, az alkalmazhatósági nyilatkozat indokolja-e az alkalmazandó kontrollokat, és a nyilvántartások bizonyítják-e a működést.

Egy NIS2 illetékes hatóság a jogi eredményekre fog összpontosítani. Megkérdezheti, hogy az Article 21 valamennyi intézkedését kezelték-e, a kontrollok megfelelőek és arányosak-e, a vezetés jóváhagyta és felügyeli-e az intézkedéseket, és az incidensjelentés képes-e teljesíteni az előírt határidőket.

Egy DORA-felügyeleti szerv az érintett pénzügyi szervezeteknél az IKT-kockázatkezelést, az incidensosztályozást, a rezilienciatesztelést, a harmadik féllel kapcsolatos kockázatot, a szerződéses megállapodásokat, a koncentrációs kockázatot és a kilépési stratégiákat fogja tesztelni.

Egy GDPR-felülvizsgáló azt fogja tesztelni, hogy a technikai és szervezeti intézkedések védik-e a személyes adatokat, az adatvédelmi incidensek értékelése beépül-e az incidenskezelésbe, egyértelműek-e az adatkezelői és adatfeldolgozói szerepek, és léteznek-e elszámoltathatósági nyilvántartások.

Egy NIST CSF 2.0 vagy COBIT 2019-szerű értékelő az irányításra, a kockázattulajdonosi felelősségre, a teljesítménymutatókra, a jelenlegi és célállapot szerinti eredményekre, a folyamatképességre és a vállalati kockázatvállalási hajlandósággal való összhangra fog összpontosítani.

A vállalati Audit- és megfelelőség-monitoring szabályzat 3.4 pontja rögzíti a bizonyíték célját:

Igazolható bizonyítékok és auditnyom előállítása szabályozó hatósági megkeresések, jogi eljárások vagy ügyfélbizonyossági igények támogatására.

Ez az a működési szabvány, amely felé a NIS2-csapatoknak építkezniük kell.

Vezetői elszámoltathatóság: az igazgatóság nem szervezheti ki a NIS2-t

A NIS2 Article 20 előírja, hogy az alapvető és fontos szervezetek vezető testületei hagyják jóvá a kiberbiztonsági kockázatkezelési intézkedéseket, felügyeljék azok végrehajtását, és képzésben részesüljenek. A vezető testületek tagjai a nemzeti felelősségi szabályok szerint felelősségre vonhatók a jogsértésekért.

Ez összhangban áll az ISO 27001:2022 vezetési követelményeivel. A felső vezetésnek biztosítania kell, hogy az információbiztonsági szabályzat és a célkitűzések összhangban legyenek a stratégiai iránnyal, az IBIR-követelmények beépüljenek az üzleti folyamatokba, rendelkezésre álljanak az erőforrások, kommunikálják a fontosságot, kijelöljék a felelősségeket és előmozdítsák a folyamatos fejlesztést.

A vezető testületnek nincs szüksége nyers vizsgálatieszköz-exportokra vagy teljes SIEM-naplókra. Döntéshozatalra alkalmas bizonyosságra van szüksége.

Egy negyedéves NIS2 vezető testületi bizonyítékcsomagnak tartalmaznia kell:

1. Hatály- és szabályozói státuszváltozások
2. Legfontosabb NIS2-kockázatok és kezelési státusz
3. Article 21 kontrollhatékonysági irányítópult
4. Jelentős incidensek, majdnem bekövetkezett események és jelentéstételi döntések
5. Beszállítói és felhőkockázati kivételek
6. Belső auditmegállapítások, helyesbítő intézkedések és lejárt határidejű bizonyítékok

Ez a csomag megadja a vezetésnek azokat az információkat, amelyek szükségesek az intézkedések jóváhagyásához, a kivételek megkérdőjelezéséhez és a maradványkockázat elfogadásához.

A 2026-os Clarysec működési modell

A NIS2 technikai intézkedéseinek ISO 27001:2022 szerinti működésbe ültetése egyszerű, de fegyelmezett modellt igényel:

• A NIS2, DORA, GDPR és szerződéses kötelezettségek hatályba helyezése az IBIR-en belül
• Kötelezettségek hozzárendelése kockázatokhoz, szabályzatokhoz, kontrollokhoz, felelősökhöz és bizonyítékokhoz
• Az alkalmazhatósági nyilatkozat használata kontrollalapú igazságforrásként
• Bizonyítékcsomagok kialakítása a magas kockázatú Article 21 területekhez
• Az incidensjelentés integrálása egyetlen szabályozói munkafolyamatba
• A beszállítói biztonság életciklusként, nem kérdőívként való kezelése
• Belső auditok végrehajtása valós mintákon
• Kontrollhatékonyság jelentése a vezető testületek felé
• Fejlesztés incidensek, auditmegállapítások, tesztek és szabályozói változások alapján

Maria számára a fordulópont annak felismerése volt, hogy nincs szüksége külön NIS2-projektre. Erősebb IBIR bizonyítékmotorra volt szüksége.

A Clarysec szabályzatai, a Zenith Blueprint és a Zenith Controls úgy készültek, hogy együtt működjenek. A szabályzatok meghatározzák az elvárt magatartást és nyilvántartásokat. A Zenith Blueprint adja a 30 lépéses bevezetési és auditútvonalat. A Zenith Controls biztosítja a keresztmegfelelési térképezést, hogy a NIS2, ISO 27001:2022, DORA, GDPR, NIST CSF és COBIT-szerű bizonyosság egyetlen koherens programként legyen kezelhető.

Következő lépés: építsd fel a NIS2–ISO 27001:2022 bizonyítéktérképet

Ha a NIS2-munkád még mindig egy hiányossági táblázatban él, 2026 az az év, amikor működésbe kell ültetni.

Kezdj egy magas kockázatú technikai intézkedéssel, például a sérülékenységkezeléssel, az incidenskezeléssel vagy a beszállítói biztonsággal. Rendeld hozzá az ISO 27001:2022 szerinti kockázatokhoz, szabályzatokhoz, A melléklet szerinti kontrollokhoz, felelősökhöz, eljárásokhoz és bizonyítékokhoz. Ezután mintavételezd az előző negyedév nyilvántartásait, és tedd fel a nehéz kérdést: megfelelne ez egy szabályozó hatóságnak, egy ügyfélértékelőnek és egy ISO 27001:2022 auditornak?

A Clarysec segíthet ennek a válasznak a kialakításában a szabályzatkönyvtár, a Zenith Blueprint és a Zenith Controls segítségével.

A cél nem a több dokumentáció. A cél az igazolható, ismételhető bizonyíték arra, hogy a NIS2 szerinti technikai intézkedéseid ténylegesen működnek.