Kötelező-e a behatolásvizsgálat? A NIS2 magyar szabályai cellánként

A magyar piacon két mondat kering a NIS2 és a tesztelés kapcsán. Az első szerint a jogszabály évente kötelezővé teszi a penetrációs tesztet. A második szerint behatolásvizsgálat nélkül nem lehet átmenni a kiberbiztonsági auditon. Egyik sem igaz, és nem is értelmezés kérdése: a magyar szabályozás cellánként megmondja, melyik biztonsági osztályban mit kell megtenni. A behatolásvizsgálat pontosan egy cellában kötelező. Alább kiírjuk a védelmi intézkedések katalógusának vonatkozó sorait, szó szerint idézzük a törvény szövegét, és megnézzük, mi következik mindebből annak, aki most készül a következő auditra.

Kötelező-e a behatolásvizsgálat Magyarországon?

Általánosságban nem. Kötelező a kétévenkénti kiberbiztonsági audit, és kötelező a sérülékenységek rendszeres ellenőrzése. Maga a behatolásvizsgálat egyetlen helyen jelenik meg kötelező elemi követelményként: a magas biztonsági osztályban, független szakértő vagy csapat bevonásával. Alap és jelentős osztályban opcionális.

A NIS2 irányelvet Magyarországon a Magyarország kiberbiztonságáról szóló 2024. évi LXIX. törvény (a továbbiakban: Kiberbiztonsági tv.) ülteti át. 2025. január 1-jén lépett hatályba, és ugyanezzel a nappal hatályát vesztette a 2023. évi XXIII. törvény (128. §) és a 2013. évi L. törvény (116. §) is. Ha egy összefoglaló még ezekre hivatkozik, elavult forrásból dolgozik – és a tesztelési kötelezettségről szóló állításai is onnan származnak.

A kérdés eldöntéséhez viszont nem elsősorban a törvény kell, hanem a hozzá tartozó katalógus. A 10. § (1) bekezdése szerint az elektronikus információs rendszereket „alap”, „jelentős” vagy „magas” biztonsági osztályba kell sorolni, a besorolásról pedig a 10. § (2) bekezdése alapján a szervezet vezetője dönt. Hogy egy adott osztályban milyen védelmi intézkedéseket kell alkalmazni, azt a 10. § (3) bekezdése utalja külön rendeletbe. Ezért a helyes sorrend: előbb besorolás, utána tesztelési terv. Aki a besorolás előtt rendel tesztet, a hatókört találgatja.

Mit ír elő a 7/2024. (VI. 24.) MK rendelet 2. melléklete?

A védelmi intézkedések katalógusa a biztonsági osztályba sorolás követelményeiről, valamint az egyes biztonsági osztályok esetében alkalmazandó konkrét védelmi intézkedésekről szóló 7/2024. (VI. 24.) MK rendelet 2. melléklete. Egy pontosítás rögtön az elején: ugyanezt a számot két rendelet viseli. A 7/2024. (VI. 24.) MK rendelet a védelmi intézkedések katalógusa, a 7/2024. (VI. 24.) SZTFH rendelet pedig az auditori nyilvántartásról szól. A kettőt a piaci összefoglalók rendszeresen összekeverik, pedig a kibocsátó megkülönbözteti őket.

A melléklet oszlopai a három biztonsági osztály. Az alábbi táblázat a rendelet saját jelöléseit adja vissza: az X kötelező elemi követelményt jelöl, a vízszintes vonás azt, hogy az adott osztályban a szervezet maga dönt róla.

Mit jelentenek a cellák?

• 5.21 – Behatolásvizsgálat. A kontroll szövege így szól: „A szervezet behatolásvizsgálatot végez a szervezet által meghatározott gyakorisággal a meghatározott EIR-eken vagy rendszerelemeken.” Két dolog látszik belőle. Egyrészt a gyakoriságot maga a rendelet bízza a szervezetre, tehát éves ütem sem itt, sem máshol nem szerepel. Másrészt a sor mindhárom osztályban vonással szerepel: az önálló behatolásvizsgálat opcionális védelmi intézkedés. (Az EIR a jogszabályok szóhasználatában az elektronikus információs rendszer rövidítése.)


• 5.22 – Független szakértő vagy csapat. „A szervezet független szakértőt vagy csapatot alkalmaz az EIR vagy a rendszerelemek behatolásvizsgálatának elvégzésére.” Ez az egyetlen X a behatolásvizsgálat sorai között, és kizárólag a magas osztályban. Ha tehát egy szervezetnek van magas osztályba sorolt rendszere, akkor rá nézve a független behatolásvizsgálat kötelező elemi követelmény – nem az auditor döntése, nem ajánlás.


• 5.23 – „Vörös csapat” (red team) gyakorlatok. A rendelet saját elnevezése ez; a szolgáltatás piaci neve Red Teaming (célzott, ellenfél-szimulációs támadás). Mindhárom osztályban opcionális. Aki azt hallja, hogy a magas osztály Red Teaminget követel meg, rossz sort néz.


• 5.24 – Fizikai környezet. Az EIR fizikai környezetének vizsgálata, bejelentett vagy be nem jelentett kísérletekkel. Szintén opcionális mindhárom osztályban.


• 15.9 – Sérülékenységek ellenőrzése. X, X, X. Ez az a sor, amely gyakorlatilag minden érintett szervezetet köt, és a piaci kommunikációban mégis a legkevesebbet szerepel.


• 15.10 – Sérülékenységmenedzsment. A jelentős osztálytól felfelé kötelező. A megtalált hibákat tehát nyilván kell tartani, rangsorolni és lezárni: ha a rendszer jelentős vagy magas osztályba került, ez elemi követelmény.


• 5.16 – Független értékelés. A folyamatos felügyelethez tartozó, tágabb kontroll: független értékelőket vagy értékelőcsoportokat kell alkalmazni, jelentős osztálytól felfelé. Ez nem behatolásvizsgálatot ír elő, de ugyanabba az irányba mutat: a szervezet saját magáról kiállított bizonyítványát a rendelet a jelentős osztálytól kezdve nem fogadja el elegendőnek.

Három állítás következik ebből, és mindhárom ellenőrizhető a rendelet szövegén. Az önálló behatolásvizsgálat egyetlen osztályban sem kötelező. Független szakértő vagy csapat bevonása kizárólag a magas osztályban az. A rendszeres, dokumentált sérülékenységvizsgálat viszont mindenkit köt – vagyis a piac a ritkább kötelezettséget hirdeti hangosan, és a mindenkire vonatkozót hagyja szó nélkül.

Mit jelent a magas osztály 5.22 kontrollja a gyakorlatban?

A rendelet egy szót emel ki: független. A „külső” szó nem szerepel benne. A követelmény tehát nem az, hogy a szakértő a szervezeten kívülről érkezzen, hanem az, hogy ne a saját munkáját minősítse. A gyakorlatban ezt külső szolgáltatóval a legegyszerűbb igazolni, mert a függetlenség így önmagában dokumentálható: szerződés, hatókör, jelentés, aláírás.

Fontos elhatárolás következik. A magas osztály 5.22 kontrolljának teljesítéséhez megrendelt behatolásvizsgálat kereskedelmi szolgáltatás, nem a Kiberbiztonsági tv. 57. §-a szerinti hatósági eljárás. Az 57. § rendszere az 1. § (9) bekezdése szerint az 1. § (1) bekezdés a)–c) és f) pontja szerinti szervezetekre terjed ki, a 60. § (1) bekezdése pedig a d) és e) pont szerintieket kiveszi alóla. A d) vagy e) pont alá tartozó magánvállalkozásnak tehát nem kell nyilvántartásba vett szolgáltatót keresnie ahhoz, hogy tesztet rendeljen – ezt a félreértést külön cikkben bontottuk ki, mert a keresőben ma pontosan az ellenkezője olvasható.

Ami az 5.22 teljesítéséhez ténylegesen kell: pontos hatókör, dátum, ellenőrzött megállapítások bizonyítékkal, kockázati besorolás és a javítások nyoma. Egy automatizált eszköz nyers kimenete ehhez kevés, mert nem mutatja meg, hogy a talált hiba a gyakorlatban kihasználható-e. A különbséget külön is összeszedtük; a rendelet szempontjából annyi számít, hogy a 15.9 kontrollhoz a rendszeres, eszközzel támogatott felderítés is bizonyíték lehet, az 5.22 kontroll teljesítéséhez viszont vizsgálat és jelentés kell.

Mit mond a Kiberbiztonsági tv. 22. § (1) bekezdése?

Itt oszlik el a második tévhit, és a bekezdés első igéje oszlatja el. A szöveg szó szerint:

„A 21. § (1) bekezdése szerinti megfelelőség ellenőrzésére az auditor jogosult a tevékenység nyomon követésére alkalmas módon a következő vizsgálatokat elvégezni: a) belső informatikai biztonsági és távoli sérülékenységvizsgálatot, valamint »jelentős« vagy »magas« biztonsági osztály esetén behatolásvizsgálatot […]”

A felsorolás b) pontja a kriptográfiai megfelelőségvizsgálat, a c) pont pedig jelentős vagy magas osztály esetén a kritikus biztonsági funkciókat végző, egyedileg fejlesztett szoftverek biztonsági forráskódvizsgálata. A bekezdés tehát nem kötelezettséget ír elő a szervezetre, hanem jogosultságot ad az auditornak: eldöntheti, hogy a felsorolt módszerek közül melyiket használja. Ezt megerősíti az 1/2025. (I. 31.) SZTFH rendelet 2. § (2) bekezdése is, amely szerint ezek a módszerek „alkalmazhatóak”.

A pontatlan idézet, amelyet érdemes felismerni

Egy szó itt komoly különbséget jelent. A törvény az a) pontban belső informatikai biztonsági vizsgálatot mond. A kamarai NIS2-portálon közzétett, széles körben terjesztett iránymutatás ezen a ponton „külső” informatikai biztonsági vizsgálatot idéz, és a hibás idézet több szolgáltatói oldalra is átkerült. A különbség nem szőrszálhasogatás: a 4. § 12. pontja meg is határozza a fogalmat, mert belső informatikai biztonsági vizsgálatról akkor van szó, ha a sérülékenységvizsgálat a belső hálózati végpontról közvetlenül történik, vagy ha a belső hálózatban használt eszköz, illetve rendszerelem vizsgálata zajlik. Aki a külső változatot olvassa, rossz hatókörre szerződik: kifelé néző vizsgálatot rendel oda, ahol a törvény a belső hálózatot említi.

Ugyanennek az iránymutatásnak a szóhasználatából ered egy másik félreértés is. A „sérülékenységkeresés” kifejezés sem a Kiberbiztonsági tv.-ben, sem a hozzá tartozó rendeletekben nem szerepel; a katalógus saját szavai a „sérülékenységek ellenőrzése” (15.9) és a „sérülékenységmenedzsment” (15.10). Ha egy ajánlat harmadik, önálló tevékenységként árazza a „sérülékenységkeresést”, olyan kategóriát számláz, amelyet a jogszabály nem ismer.

Végül egy fogalmi pont, amely a teljes cikk logikáját tartja. A behatolásvizsgálat a magyar jogban nem önálló tevékenység: a 4. § 11. pontja sérülékenységvizsgálati módszerként határozza meg, amely a rendszer „gyenge pontjainak feltárására és kihasználhatóságának ellenőrzésére” irányul, rosszindulatú támadások szimulációjával. Aki behatolásvizsgálatot rendel, a törvény olvasatában a sérülékenységvizsgálat egyik módszerét rendeli meg.

Kinek kell auditot végeztetnie, és milyen gyakran?

A 16. § (1) bekezdése kétévenkénti kiberbiztonsági auditot ír elő. A kötelezettség az 1. § (1) bekezdés b) pontja szerinti azon szervezetet köti, amely egyúttal a 2. vagy a 3. melléklet szerinti szervezet is, továbbá a d) pont szerinti szervezetet, valamint – a mikrovállalkozás kivételével – az e) pont szerinti szervezetet. Ezen felül a hatáskörrel rendelkező kiberbiztonsági hatóság külön is elrendelheti.

A ciklus tehát kétéves, nem éves. Ez a piacon a leggyakrabban elrontott részlet, és egy megfelelési vezető azonnal észreveszi, ha egy szolgáltató éves auditról beszél. A határidők a nyilvántartásba vételhez igazodnak: a 16. § (2) bekezdés a) pontja szerint a szerződést a nyilvántartásba vételtől számított 120 napon belül kell megkötni, az első auditot pedig a b) pont szerint két éven belül elvégeztetni. A már 2025. január 1. előtt is működő szervezeteknek a 89. § (2) bekezdése 2026. június 30-ig adott időt.

Ez a kör lezárult. Az SZTFH 2026. augusztus 26-i közleménye szerint 2194 szervezet végezte el az első kiberbiztonsági auditot a határidőig, mintegy 90% megfelelt, és mintegy 10% kapta meg a legjobb minősítést, az „Elhanyagolható kockázattal megfelelt” besorolást. A hatóság egy visszatérő hiányosságot is megnevezett: a távoli hozzáférés megoldásait a szervezetek komolyan vették, a rendszerdokumentáció viszont sok helyen hiányos volt. Vagyis nem a hiányzó behatolásvizsgálat vitte le a pontszámokat, hanem az, hogy a meglévő védelemről nem állt rendelkezésre bizonyíték.

A kétéves ciklusból következik a naptár is: a következő audithullám már formálódik, és aki 2026 nyarán zárt, annak 2028-ig van ideje – de a besorolás, a dokumentáció és a javítások átfutása ebből több hónapot elvisz. A kiberbiztonsági auditra való felkészülést ezért érdemes visszafelé ütemezni a határidőtől. Hogy egyáltalán kire terjed ki a törvény a 2026. januári módosítás után, arról a hatályt tárgyaló cikkünkben írtunk.

Honnan ered az „évente kötelező penetrációs teszt” tévhit?

Három forrásból. Mindhárom önmagában igaz állítás, és attól lesz pontatlan, hogy a magyar kiberbiztonsági szabályozásra vetítik.

1. Más keretrendszerek éves ritmusa. Kártyás környezetben, tanúsító auditban vagy egy nagyvállalati beszállítói szerződésben valóban szerepelhet éves tesztelési elvárás. Ezek viszont szerződéses vagy szabványkövetelmények, nem a Kiberbiztonsági tv. előírásai. A kettő gyakran ugyanazzal az egy vizsgálattal teljesíthető, de a jogalapjuk különbözik – és ha az ISO 27001 tanúsítvány már megvan, [attól még marad magyar kötelezettség](/hu/cikkek/eleg-e-az-iso-27001-a-kiberbiztonsagi-torvenyhez).


2. A pénzügyi szektor elvárásai. A Magyar Nemzeti Bank 1/2025. (I. 13.) számú ajánlása az informatikai rendszer védelméről a felügyelt pénzügyi szervezetektől valóban rendszeres, részben negyedéves, részben legalább éves vizsgálatot vár el. Ez azonban ajánlás, felügyeleti elvárás – nem jogszabály, és a címzettjei sem esnek a Kiberbiztonsági tv. hatálya alá: a DORA hatálya alá tartozó pénzügyi szervezeteket az 1. § (1) bekezdés c) pontja és az 1. § (2) bekezdése kifejezetten kiveszi a törvény hatálya alól. A [tesztelési gyakoriságot az MNB oldaláról](/hu/cikkek/milyen-gyakran-kell-penetracios-tesztet-vegezni-mnb) külön cikkben szedtük össze.


3. A 15.9 és a behatolásvizsgálat összemosása. Ez a leggyakoribb. A sérülékenységek ellenőrzése minden osztályban kötelező, tehát a „kötelező” szó jogosan hangzik el – csak nem a behatolásvizsgálatra vonatkozik. Az ajánlatokban a kettő gyakran egyetlen tételként jelenik meg, és a szervezet a végén drágábban vásárol kevesebb bizonyítékot: egy évi egy tesztet ott, ahol folyamatos felderítésre és dokumentált hibakezelésre lenne szüksége.

Ehhez jön a fentebb tárgyalt pontatlan idézet. Aki a 22. § (1) bekezdés a) pontjában felismeri a „külső” szót, ugyanabból az anyagból a „sérülékenységkeresés” kategóriáját is kiszűri.

Mit érdemes megrendelni, ha nem kötelező?

A jogi válasz és a mérnöki válasz itt válik szét, és mindkettőt érdemes kimondani. Jogilag az önálló behatolásvizsgálat a legtöbb szervezetnél opcionális. Gyakorlatilag viszont az auditor azt fogja kérni, hogy a szervezet bizonyítsa: a védelmi intézkedések nemcsak megvannak, hanem működnek is. Erre a szabályzat nem bizonyíték, a vizsgálati jelentés igen.

Az alábbi táblázat harmadik oszlopa nem jogszabályi előírás, hanem a mi javaslatunk arra, mi hozza a legtöbbet az adott osztályban.

Az időzítés önmagában is számít. Az a jelentés, amelyben a kritikus megállapítások már lezárultak, egészen más beszélgetést indít az auditorral, mint egy nyitott hibalista. A teszt tehát nem az audit megkettőzése, hanem a felkészülés része – néhány hét, amely alatt a szervezet még maga javíthat.

Mit adunk át a vizsgálat végén?

A 16. § szerinti kiberbiztonsági auditot az SZTFH nyilvántartásában szereplő, független auditor folytatja le. Az a technikai bizonyíték viszont, amelyet bekér, a szervezetnél áll elő – és ezt a részt készítjük el. Penetrációs tesztet és sérülékenységvizsgálatot végzünk kereskedelmi szolgáltatásként, elismert módszertanok szerint – webalkalmazásoknál az OWASP ASVS és a WSTG szerint –, és a jelentés megnevezi, mi alapján dolgoztunk.

• Hatókör és időpont. Pontosan melyik rendszert, melyik felületet és melyik jogosultsági szintet vizsgáltuk, mikortól meddig, milyen modellben.


• Megállapítások bizonyítékkal. Minden tétel mellett ott a reprodukció lépései és a bizonyíték arra, hogy a hiba a gyakorlatban is kihasználható.


• Kockázati besorolás az Ön környezetére vetítve. A CVSS-pontszám mellett leírjuk, mit jelent a hiba az adott szervezetben: ügyféladat, leállás, pénzügyi veszteség.


• Javítási sorrend. Nem „frissítse a rendszert”, hanem melyik komponenst, melyik verzióra, melyik beállítást hogyan – és mit érdemes elsőként megcsinálni.


• Írásos igazolás az újratesztelésről. A javítások után újra megnézzük a megállapításokat, és leírjuk, melyik zárult le. Ez az a dokumentum, amely a hibalistát intézkedéssé változtatja.

Minden tesztelőnk rendelkezik OSCP-tanúsítvánnyal, a Haxoris ISO/IEC 27001 tanúsítványát pedig a TÜV SÜD adta ki – tehát a saját tanúsításunk tapasztalatából is tudjuk, hogyan néz ki egy auditor számára használható bizonyíték. A megfelelési oldalról ugyanezt a munkát a NIS2 penetrációs teszt oldalán írtuk le részletesen.

Összefoglalva: egy cella kötelező, a bizonyíték mindenhol kell

A behatolásvizsgálat a magyar szabályozásban egyetlen helyen kötelező elemi követelmény: a magas biztonsági osztályban, független szakértő vagy csapat bevonásával (5.22). Az önálló behatolásvizsgálat (5.21), a „vörös csapat” gyakorlatok (5.23) és a fizikai környezet vizsgálata (5.24) mindhárom osztályban opcionális. Ami viszont mindenkit köt, az a sérülékenységek ellenőrzése (15.9), a jelentős osztálytól felfelé pedig a sérülékenységmenedzsment (15.10) is. A kétéves ciklust a 16. § (1) bekezdése adja, a 22. § (1) bekezdése pedig az auditornak ad jogosultságot, nem a szervezetre ró kötelezettséget.

A gyakorlati következtetés viszont egyszerűbb, mint a cellák. Az auditor bizonyítékot keres, a támadó pedig nem a besorolást nézi. Ne a következő audit derítse ki, hol a leggyengébb pont. Kérjen ingyenes konzultációt: a besorolás alapján végigvesszük, mi kötelező, mi ajánlott, és mit érdemes legelőször tesztelni.

Behatolásvizsgálat és NIS2 – gyakori kérdések

Kapcsolódó Haxoris-szolgáltatások: penetrációs teszt a NIS2-megfeleléshez · webalkalmazások és infrastruktúra penetrációs tesztelése