NIS2 és a kiberbiztonsági törvény: mit kell tennie a szervezetnek és a szoftver­szállítónak

01Hol tart a NIS2 Magyarországon 2026 őszén

A NIS2-irányelv (külső webhelyet nyit meg), az (EU) 2022/2555 irányelv, 2022. december 27-én jelent meg a Hivatalos Lapban, és 2023. január 16-án lépett hatályba. A tagállamoknak 2024. október 17-ig kellett elfogadniuk és kihirdetniük nemzeti intézkedéseiket, és 2024. október 18-tól, az első NIS-irányelv hatályon kívül helyezésének napjától kellett alkalmazniuk azokat.

Mivel a NIS2 irányelv, egy szervezetet az azt átültető nemzeti jogszabály köt. Magyarországon ez a 2024. évi LXIX. törvény Magyarország kiberbiztonságáról (külső webhelyet nyit meg), amelyet 2024. december 20-án fogadtak el, és 2025. január 1-jén lépett hatályba; hatályon kívül helyezte a 2013. évi L. és a 2023. évi XXIII. törvényt. Végrehajtási rendelete a 418/2024. (XII. 23.) Korm. rendelet. A magánszféra alapvető és fontos szervezeteit a Szabályozott Tevékenységek Felügyeleti Hatósága (SZTFH) felügyeli, a közigazgatási és állami tulajdonú szervezeteket az NKI, amely a Nemzetbiztonsági Szakszolgálaton belül működik.

Az átültetés uniós szinten egyenetlen volt: egyes tagállamok időben alkalmazták a törvényüket, mások csak 2025-ben vagy 2026-ban, és az Európai Bizottság kötelezettségszegési eljárást indított a határidőt elmulasztó tagállamok ellen. A nyilvántartásba vételi kötelezettségek, a bejelentési felületek és a felügyeleti hatóságok ezért országonként eltérnek, ami a több országban működő csoportoknál külön figyelmet kíván.

02Alapvető és fontos szervezetek

A NIS2 az I. melléklet ágazataiban (kiemelten kritikus ágazatok: energia, közlekedés, bankszektor, pénzügyi piaci infrastruktúrák, egészségügy, ivóvíz, szennyvíz, digitális infrastruktúra, IKT-szolgáltatás-kezelés, közigazgatás és űrágazat) és a II. melléklet ágazataiban (egyéb kritikus ágazatok: postai és futárszolgáltatások, hulladékgazdálkodás, vegyipar, élelmiszeripar, gyártás, digitális szolgáltatók és kutatás) működő köz- és magánszervezetekre vonatkozik. Főszabályként a közép- és nagyvállalatokra terjed ki. Egyes szervezetek méretüktől függetlenül a hatálya alá tartoznak, például a bizalmi szolgáltatók, a DNS-szolgáltatók és a központi közigazgatási szervek.

A 3. cikk ezeket a szervezeteket két kategóriába sorolja:

• Alapvető szervezetek: főként az I. melléklet ágazataiba tartozó nagy szervezetek, valamint a méretüktől függetlenül alapvetőnek minősülő szervezetek, például a minősített bizalmi szolgáltatók, a legfelső szintű doménnév-nyilvántartók, a DNS-szolgáltatók és a központi közigazgatási szervek. Felügyeletük proaktív, ami auditot és helyszíni ellenőrzést is jelenthet.
• Fontos szervezetek: az I. és II. melléklet hatálya alá tartozó többi szervezet. Felügyeletük utólagos: a hatóság akkor lép, ha jelek utalnak arra, hogy a szervezet nem felel meg a szabályoknak.

Mindkét kategóriának ugyanazok az alapkötelezettségei: kockázatkezelési intézkedések (21. cikk), incidensbejelentés (23. cikk) és vezetői felelősség (20. cikk). A különbség a felügyeletben és a bírságokban van: az irányelv a két kategóriára eltérő bírságmaximumokat ír elő, amelyeket a nemzeti jognak legalább biztosítania kell. A tagállamok döntik el, hogy a közigazgatási szervekre vonatkoznak-e bírságok, és ha igen, milyen mértékben. A magyar szankciókat a kiberbiztonsági törvény hatályos szövegéből ellenőrizze.

Mikor tartozik maga a szoftver­szállító is a hatály alá

A szoftverfejlesztés önmagában nem NIS2-ágazat. Egy szállító ennek ellenére közvetlenül is a hatály alá tartozhat. Az I. melléklet kiterjed a menedzselt szolgáltatókra, és a NIS2 tágan határozza meg őket: olyan szervezetek, amelyek ügyfeleik számára IKT-termékeket, hálózatokat, infrastruktúrát vagy alkalmazásokat telepítenek, kezelnek, üzemeltetnek vagy tartanak karban, helyben vagy távolról. Egy közepes vagy nagyobb szállító, amely ügyfelei alkalmazásait üzemelteti vagy tartja karban, így önállóan is a NIS2 hatálya alá eshet, csakúgy, mint a felhő- és adatközpont-szolgáltatók. Ezekre a szolgáltatókra az (EU) 2024/2690 végrehajtási rendelet (külső webhelyet nyit meg) részletesen meghatározza a technikai követelményeket.

A legtöbb szoftverszállító azonban az ügyfelein keresztül találkozik a NIS2-vel: az ügyfelek saját ellátásilánc-kötelezettségüket szerződéses kikötésekké, kérdőívekké és auditokká alakítják. A szoftvertermékekre ráadásul a kiberreziliencia-jogszabály (külső webhelyet nyit meg), az (EU) 2024/2847 rendelet is vonatkozik: az aktívan kihasznált sérülékenységekre és a súlyos incidensekre vonatkozó bejelentési kötelezettségei 2026. szeptember 11-től, a többi kötelezettsége 2027. december 11-től alkalmazandó.

03A 21. cikk tíz minimális intézkedése

A 21. cikk megfelelő és arányos technikai, operatív és szervezeti intézkedéseket ír elő, minden veszélyt figyelembe vevő megközelítés alapján. Ezeknek tükrözniük kell a technika állását és a releváns európai és nemzetközi szabványokat, és arányosnak kell lenniük a szervezet kockázati kitettségével, méretével és az incidensek valószínű súlyosságával. Legalább a következőkre terjednek ki:

1. 01kockázatelemzési és információsrendszer-biztonsági szabályzatok;
2. 02incidenskezelés;
3. 03üzletmenet-folytonosság, például a biztonsági mentések kezelése és a katasztrófa utáni helyreállítás, valamint válságkezelés;
4. 04az ellátási lánc biztonsága, beleértve a közvetlen beszállítókkal és szolgáltatókkal fennálló kapcsolatok biztonsági vonatkozásait;
5. 05biztonság a hálózati és információs rendszerek beszerzése, fejlesztése és karbantartása során, beleértve a sérülékenységek kezelését és közzétételét;
6. 06szabályzatok és eljárások az intézkedések hatékonyságának értékelésére;
7. 07alapvető kiberhigiéniai gyakorlatok és kiberbiztonsági képzés;
8. 08a kriptográfia és adott esetben a titkosítás alkalmazására vonatkozó szabályzatok és eljárások;
9. 09humánerőforrás-biztonság, hozzáférés-szabályozási szabályzatok és eszközgazdálkodás;
10. 10többtényezős vagy folyamatos hitelesítés, valamint adott esetben biztonságos hang-, videó- és szöveges kommunikáció és vészhelyzeti kommunikáció.

A 4. és az 5. pontnál lépnek be a szállítók. A 21. cikk (3) bekezdése előírja, hogy a szervezetek vegyék figyelembe az egyes közvetlen beszállítók sajátos sérülékenységeit, termékeik és kiberbiztonsági gyakorlataik általános minőségét, valamint biztonságos fejlesztési eljárásaikat. Az ügyfelei tehát azt is vizsgálják, hogyan fejleszt szoftvert, nem csak azt, amit lead.

04A vezetés jóváhagyja, felügyeli és felel érte

A 20. cikk szerint az alapvető és fontos szervezetek vezető testületeinek jóvá kell hagyniuk a kiberbiztonsági kockázatkezelési intézkedéseket, felügyelniük kell azok végrehajtását, és felelősségre vonhatók a jogsértésekért. Tagjaiknak képzésen kell részt venniük, és a szervezeteket arra ösztönzik, hogy munkatársaikat is rendszeresen képezzék. A közszférabeli szervezeteknél továbbra is a közintézmények és a köztisztviselők felelősségére vonatkozó nemzeti szabályok érvényesek.

Ez megváltoztatja a szállítókkal folytatott párbeszédet. Egy vezetés, amelynek jóvá kell hagynia az intézkedéseket, követhető bizonyítékot kér: mely szállítók mely szolgáltatásokat támogatják, milyen kockázatok maradnak fenn, és mit teszteltek ténylegesen. A kiberbiztonsági auditra is érdemes ilyen bizonyítékokkal készülni.

05Incidens­bejelentés: 24 óra, 72 óra, egy hónap

A 23. cikk előírja, hogy a szervezetek jelentsék a jelentős incidenseket a CSIRT-nek vagy az illetékes hatóságnak. Magyarországon a kiberbiztonsági törvény szerinti nemzeti kiberbiztonsági incidenskezelő központ (CSIRT) a Nemzetbiztonsági Szakszolgálat. Egy incidens akkor jelentős, ha súlyos működési zavart vagy pénzügyi veszteséget okozott vagy okozhat a szervezetnek, vagy jelentős vagyoni vagy nem vagyoni kárt okozott vagy okozhat másoknak. A bejelentés szakaszokban történik:

Adott esetben a szervezeteknek indokolatlan késedelem nélkül tájékoztatniuk kell szolgáltatásaik igénybevevőit azokról a jelentős incidensekről, amelyek valószínűleg érintik ezeket a szolgáltatásokat. A bejelentés formáját és csatornáját a nemzeti szabályok határozzák meg.

Az óra akkor indul, amikor a szervezet tudomást szerez az incidensről. Ha az incidens egy szállító rendszerében kezdődik, az ügyfél csak akkor tudja tartani a 24 órás határidőt, ha a szállító órákon belül észleli, felismeri és továbbítja. Az észlelés, a naplózás és az egyeztetett értesítési csatorna ezért szerződéses feltétel, nem csupán mérnöki részlet.

06Mit kér egy NIS2 hatálya alá tartozó ügyfél a szoftver­szállítójától

A gyakorlatban a 21. cikk olyan technikai intézkedésekké és bizonyítékokká alakul, amelyeket egy szállítónak külön projekt nélkül is fel kell tudnia mutatni. A leggyakoribbak:

• Biztonságos fejlesztési életciklus. Fenyegetésmodellezés a jelentős változásoknál, kollégák általi kódellenőrzés, automatikus biztonsági tesztek és függőségvizsgálat a folyamatban, aláírt buildek és szoftverösszetevő-jegyzék (SBOM) minden kiadáshoz.
• Sérülékenységkezelés és -közzététel. Nyilvános módja a sérülékenységek bejelentésének, súlyosság szerint egyeztetett válaszidők, és értesítés az ügyfélnek, ha egy sérülékenység érinti a környezetét.
• Hozzáférés-szabályozás a szállító munkatársainál. Névre szóló fiókok, többtényezős hitelesítés, legkisebb jogosultság, időkorlátos emelt szintű hozzáférés és minden adminisztratív művelet naplózása az ügyfél környezetében.
• Naplózás és incidensbizonyíték. A biztonsági szempontból releváns események naplózása megbízható időbélyeggel, egyeztetett ideig megőrizve és exportálhatóan, hogy az ügyfél meg tudja válaszolni a korai előrejelzés és a zárójelentés kérdéseit.
• Együttműködés incidens esetén. Megnevezett kapcsolattartó és csatorna, az ügyfél 24 órájánál jóval rövidebb értesítési idő, és támogatás a kiváltó ok elemzésében.
• Folytonosság és helyreállítás. Visszaállítással igazolt biztonsági mentések, az ügyféléhez igazított helyreállítási célok és begyakorolt eljárás.
• Az ellátási lánc dokumentálása. Naprakész lista az alvállalkozókról és a tárhelyek helyéről, valamint azokról a fő külső komponensekről és szolgáltatásokról, amelyekre a megoldás épül.
• Kilépési terv. Adatexport használható formátumokban, dokumentáció és átadási támogatás, hogy az ügyfél a szolgáltatás feletti kontroll elvesztése nélkül válthasson szállítót.

Ezek egyike sem új az érett fejlesztőcsapatok számára. A NIS2 azt változtatja meg, hogy az ügyfélnek bizonyítania kell mindezt, például egy SZTFH által felügyelt szervezet kiberbiztonsági auditján. A Bizalom és megfelelés oldalunk bemutatja, hogyan dolgozunk szállítóként, beleértve ISO/IEC 27001 szerint tanúsított információbiztonsági irányítási rendszerünket.

07Ellenőrzőlista szerződésekhez és beszerzésekhez

1. 01Rendelje a szállítókat a szolgáltatásokhoz. Rögzítse, mely szállítók mely érintett szolgáltatásokat támogatják, és melyiknek van hozzáférése a rendszereihez vagy adataihoz.
2. 02Sorolja be őket kritikusság szerint. A legszigorúbb követelményeket azokra a szállítókra alkalmazza, amelyek kritikus rendszereket üzemeltetnek vagy módosíthatnak.
3. 03Írja bele az intézkedéseket a szerződésbe. Biztonsági követelmények, incidensértesítési idő és csatorna, sérülékenységkezelés, naplózás és megőrzés, audit- vagy bizonyítékkérési jog, alvállalkozói szabályok és helyszínek.
4. 04Bizonyítékot kérjen, ne nyilatkozatot. Tanúsítványok a hatókörükkel, teszteredmények, SBOM, az utolsó visszaállítási teszt dátuma.
5. 05Előre egyezzenek meg a kilépésről. Adatvisszaadás, átállási támogatás és az az időszak, amíg a szállító fenntartja a szolgáltatást.
6. 06Gyakoroljanak együtt. Tartson incidensgyakorlatot a kritikus szállítóival, a 24 órás korai előrejelzést is beleértve.
7. 07Rendszeresen vizsgálja felül. A szállítók, a szolgáltatások és a fenyegetések változnak; az évente egyszer frissített szállítói nyilvántartás az év nagy részében elavult.

08A részleteket a nemzeti jog dönti el

A nyilvántartásba vétel, a bejelentési felületek, az űrlapok, az illetékes hatóság és az esetleges további követelmények mind a nemzeti jogból fakadnak; Magyarországon a kiberbiztonsági törvényből és a 418/2024. (XII. 23.) Korm. rendeletből, valamint az SZTFH és az NKI útmutatóiból. Főszabályként egy szervezet annak a tagállamnak a joghatósága alá tartozik, ahol letelepedett. A 26. cikk kivételeket tesz: a nyilvános elektronikus hírközlési szolgáltatók minden olyan ország alá tartoznak, ahol szolgáltatást nyújtanak, a felhő-, adatközpont- és menedzselt szolgáltatók és több más digitális szolgáltató a fő tevékenységi helyük szerinti ország alá, a közigazgatási szervek pedig az őket létrehozó állam alá. Egy magyar telephelyet is működtető, több országban jelen lévő csoport ezért több hatósággal is kapcsolatban állhat.

09Mire érdemes figyelni a következő hónapokban

• A hazai szabályok alkalmazása: az SZTFH és az NKI útmutatói, valamint a kiberbiztonsági auditok tapasztalatai.
• A Bizottság 2025. november 19-i digitális omnibusz javaslata (külső webhelyet nyit meg), a COM(2025) 837, amely a NIS2, a GDPR, a DORA és más jogszabályok szerinti incidensbejelentéseket egyetlen, az ENISA által működtetett belépési ponton keresztül vezetné. 2026 októberében még az Európai Parlament előtt volt (külső webhelyet nyit meg)); amíg el nem fogadják és nem alkalmazandó, a jelenlegi csatornák és határidők érvényesek.
• Az ellátási láncok 22. cikk szerinti összehangolt uniós kockázatértékelései, amelyeket a szervezeteknek figyelembe kell venniük a szállítókra vonatkozó intézkedések kiválasztásakor.
• A kiberreziliencia-jogszabály ütemezése a szoftvertermékekre, 2027. december 11-i teljes alkalmazással.

A pénzügyi szervezeteknél a digitális működési rezilienciáról szóló rendelet (DORA) váltja fel a NIS2 IKT-kockázatkezelési, incidensbejelentési és felügyeleti szabályait; lásd a DORA-ról és az IKT-szolgáltatókról szóló cikkünket. A Bizottság a NIS2-ről és végrehajtási jogi aktusairól a NIS2-oldalán (külső webhelyet nyit meg) ad áttekintést.