Elég-e az ISO 27001 a kiberbiztonsági törvényhez?

Nem elég. Ez a teljes válasz a címben feltett kérdésre, és nem érdemes hígítani: a tanúsítvány önkéntes, a törvény pedig a hatálya alá tartozó szervezetre a jog erejénél fogva vonatkozik. Tanúsító szervezet papírja nem old fel jogszabályi kötelezettséget.

Az ellenkező mondat viszont – hogy a szabványnak semmi köze a törvényhez – ugyanennyire téves, és többe kerül. A tartalmi átfedés nagy. Akkora, hogy egy élő információbiztonsági irányítási rendszerrel dolgozó cég előtt hetek munkája áll, nem negyedév. Alább szétszedjük a kettőt: mit zár le a tanúsítvány, mit nem zár le soha, és milyen sorrendben érdemes pótolni a maradékot.

Miért nem váltja ki a tanúsítvány a törvényt?

A két dokumentum másra válaszol. A szabvány azt kérdezi, ismételhető módon irányítja-e a szervezet a biztonságot. A törvény azt kérdezi, elvégezte-e a szervezet azt, amit előírtak neki, és határidőre végezte-e el.

A második sor a legfontosabb. Az IBIR hatókörét a szervezet jelöli ki, és sok tanúsítvány gondosan kiválasztott szeletet ír le. A törvényi kötelezettség hatókörét viszont az dönti el, mivel foglalkozik a cég és mekkora. Ha a tanúsítványban „az X telephelyen üzemeltetett adatközpont” szerepel, a törvény pedig a teljes ügyfélkiszolgáló platformra vonatkozik, akkor a papír nem arról szól, amiről a hatóság kérdezni fog.

Mit zár le az ISO 27001 a magyar követelményekből?

Most a jó hír, és jár mindenkinek, aki végigcsinálta a tanúsítást. A törvény működő információbiztonsági irányítási rendszert ír elő, és ez ugyanaz a fajta konstrukció, amelyet a szabvány leír. Nem kell másodikat építeni az első mellé. Megfelelési táblázatot kell építeni: ugyanaz a bizonyíték, csak kontrollszám helyett jogszabályi hivatkozással.

Egy feltétel van, és nem formai: a rendszernek a tanúsítás hetén kívül is működnie kell. Az a kockázatnyilvántartás, amelyet évente egyszer, a tanúsító szervezet érkezése előtti napon frissítenek, átmegy a tanúsításon, és nem megy át egy incidensen.

Hét kötelezettség, amelyet a tanúsítvány nem zár le

Ezeknek nincs megfelelőjük a szabványban. Nem azért, mert a szabvány gyenge, hanem azért, mert nem ismeri a felügyeleti hatóság fogalmát.

1. Nyilvántartásba vétel az SZTFH-nál

A magánszektorban a 8. § (5) bekezdése harminc napot ad: a működés megkezdésétől vagy a törvény hatálya alá kerüléstől számítva ennyi idő alatt kell megküldeni a nyilvántartásba vételhez szükséges adatokat az SZTFH részére. Az űrlap az SZTFH-420; az adatok változását az SZTFH-421 lapon kell bejelenteni. Az 1. § (1) bekezdés a)–c) pontja szerinti közszférabeli szervezetek ugyanezt az NBSZ Nemzeti Kiberbiztonsági Intézete (NKI) felé teljesítik, lépcsőzetes határidőkkel (8. § (4)).

Ezt a lépést nem végzi el senki a szervezet helyett. A hatóság hivatalból nem sorol be senkit, a tanúsító szervezet pedig végképp nem, mert a szabvány ilyen cselekményt nem ismer. Tiszta adminisztráció, és éppen ezért csúszik el a leggyakrabban: az IBIR ütemtervében nincs benne, tehát senkinek nem jut eszébe. A mulasztás ára viszont nem jelképes. A 418/2024. (XII. 23.) Korm. rendelet 3. melléklete szerint az elmaradt adatszolgáltatásért legalább 1 000 000 Ft bírság jár, a felső határ pedig az árbevétel 2%-a, legfeljebb 150 000 000 Ft.

2. Biztonsági osztályba sorolás: alap, jelentős vagy magas

A 10. § (1) bekezdése szerint minden elektronikus információs rendszert be kell sorolni: „alap”, „jelentős” vagy „magas” osztályba. A besorolásról a szervezet vezetője dönt (10. § (2)), a követelményeket pedig a 7/2024. (VI. 24.) MK rendelet adja meg (10. § (3)). Két határidő tartozik hozzá. Ha a besorolás az alap fölé kerül, az adott osztály intézkedéseit legfeljebb két éven belül kell bevezetni (10. § (6)). A besorolást ezen felül legalább kétévente felül kell vizsgálni, és soron kívül is, ha biztonságot érintő változás történik (10. § (7)).

Az ISO 27001 kockázatelemzése ezt nem váltja ki, mert más a kimenete. A szabvány kockázatokat rangsorol, és a szervezet dönti el, melyik intézkedést vezeti be. A besorolás ezzel szemben egy jogszabályi katalógusból nyit meg egy oszlopot, és abban az oszlopban X-ek állnak. Az SZTFH saját megfogalmazása szerint „nem a teljes megfelelés, hanem a kockázatokkal arányos védelem kialakítása a cél” – hogy mi arányos, azt viszont itt az osztály mondja meg.

3. A kétévenkénti kiberbiztonsági audit

A 16. § (1) bekezdése kétévenkénti kiberbiztonsági auditot ír elő, és a hatáskörrel rendelkező kiberbiztonsági hatóság ezen felül külön is elrendelheti. Kétévente, nem évente: ez a piacon a leggyakrabban elrontott részlet, és egy megfelelési vezető azonnal észreveszi.

A tanúsító audit nem lép a helyébe. Más a jogalapja, más a hatóköre, és más az eredmény címzettje: a 22. § (2) bekezdése szerint az auditor a megállapításait haladéktalanul megküldi az SZTFH-nak és a szervezetnek is. Az auditot a 4. § 10. pontja szerinti auditor folytatja le, vagyis az SZTFH nyilvántartásában szereplő független gazdálkodó szervezet, amelynek a 21. § (2) bekezdése alapján egyben az 57. § (1) bekezdés c) pontja szerinti, sérülékenységvizsgálat lefolytatására jogosult szervezetnek is kell lennie.

A határidők a nyilvántartásba vételtől futnak: a szerződést 120 napon belül kell megkötni (16. § (2) a) pont), az első auditot két éven belül elvégeztetni (16. § (2) b) pont). A 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ő auditot, és mintegy 90% megfelelt.

Itt segít a tanúsítvány, csak máshogy, mint sokan várják. A szabványhoz összegyűjtött bizonyítékok nagy része átdolgozás nélkül átadható az auditornak. A felkészülés rövidül, a kötelezettség nem. Hogy pontosan mit kér be az auditor, azt külön cikkben szedtük össze.

4. Az információbiztonsági felelős kijelölése

A Kiberbiztonsági tv. 11. §-a megnevezett szerepkört kíván: az elektronikus információs rendszer biztonságáért felelős személyt, akit a piac információbiztonsági felelősként, röviden IBF-ként emleget. A közszférában ezt a személyt a 8. § (4) bekezdése szerint harminc napon belül be is kell jelenteni.

A szabvány 5.1 fejezete a vezetőség elkötelezettségét kéri, és a szervezethez beszél. A törvény konkrét személyhez. Egy vezetőségi átvizsgálási jegyzőkönyv nem nevez meg felelőst, egy kinevezés igen – és a felügyelet ez utóbbit keresi.

5. Incidensbejelentés az NKI felé

Az A.5.24–A.5.26 kontrollok az incidenskezelés belső folyamatát írják le: ki minősít, ki dönt, hogyan kell dokumentálni. Amit nem ismernek, az a hatóság felé futó óra.

A törvény ilyen órát is indít, és a bejelentést az NKI fogadja – attól függetlenül, hogy a szervezet felügyeletét az SZTFH vagy az NBSZ látja el. A meglévő incidenskezelési folyamat jó alap, de kell bele egy új ág: ki dönti el éjjel, hogy a bejelentési küszöb teljesült-e, és ki küldi el ténylegesen a bejelentést. A határidőt, a címzettet és a formát a törvény hatályos szövegéből érdemes kiolvasni, mielőtt bekerül az eljárásrendbe. Itt a jogszabály köti a szervezetet, nem egy összefoglaló.

6. Kiberbiztonsági felügyeleti díj

A 7. § (2) bekezdése szerint a kiberbiztonsági felügyeleti díj legfeljebb az előző évi nettó árbevétel 0,015%-a, szervezetenként legfeljebb 10 000 000 Ft, csoportszinten pedig legfeljebb 50 000 000 Ft. A díjtételeket a 2/2025. (I. 31.) SZTFH rendelet adja meg, a csoporttagságról szóló nyilatkozatot pedig az SZTFH-422 űrlapon, minden év január 31-ig kell megtenni.

Ez az egyetlen tétel a listán, amelyhez nem kell mérnök. Az elmaradásáért mégis bírság jár: a 418/2024. (XII. 23.) Korm. rendelet 3. melléklete legalább 500 000 Ft-ot ír elő, a felső határ pedig az éves felügyeleti díj tízszerese.

7. Független behatolásvizsgálat a magas osztályban

Az A.8.29 kontroll biztonsági tesztelést ír elő a fejlesztés és az átvétel során, azt viszont nem mondja meg, hogy külső csapatnak kell elvégeznie. A magyar katalógusban éppen ez a különbség.

Az önálló, kötelező behatolásvizsgálat kérdését nem a törvény, hanem a 7/2024. (VI. 24.) MK rendelet 2. melléklete dönti el, cellánként. Az X kötelező elemi követelményt jelöl, a gondolatjel azt, hogy az adott osztályban nem az.

Három dolog következik ebből. Az önálló behatolásvizsgálat (5.21) egyetlen osztályban sem kötelező elemi követelmény, és a „vörös csapat” gyakorlatok (5.23) sem. Független szakértő vagy csapat bevonása (5.22) kizárólag a magas osztályban kötelező – ott viszont maga a függetlenség a követelmény, tehát a saját üzemeltetői csapat munkája nem elég hozzá. A sérülékenységek ellenőrzése (15.9) mindhárom osztályban kötelező, a sérülékenységmenedzsment (15.10) a jelentős osztálytól felfelé: a rendszeres, dokumentált vizsgálat tehát gyakorlatilag mindenkit érint.

Az audit során ehhez jön még egy jogosultság. A 22. § (1) bekezdés a) pontja szerint az auditor belső informatikai biztonsági és távoli sérülékenységvizsgálatot végezhet, „jelentős” vagy „magas” biztonsági osztály esetén pedig behatolásvizsgálatot is. Egy szót érdemes pontosan idézni: a törvény belső vizsgálatot mond, nem külsőt. A közkézen forgó összefoglalók egy része itt téveszt, és a hibás idézet több szolgáltatói oldalra is átkerült. A cellákat és a következményeiket külön cikkben bontottuk ki.

A leggyakoribb rés: a hatókör

A hét pont mindegyike elvégezhető: idő kell hozzá és felelős. Egyetlen hiba van, amely viszont az egész gondolatmenetet érvényteleníti, és ez a hatókör. Ha a tanúsítvány nem terjed ki arra a szolgáltatásra, amely miatt a cég a törvény hatálya alá esik, akkor a lefedettségről szóló érvelés összeomlik: a bizonyítékok jó része más rendszerről szól, mint amiről a hatóság kérdez.

A hatályt ráadásul többször átírták. A 2026. január 6-tól hatályos módosítás – a 2025. évi CXXXV. törvény 4. § (2) bekezdése – az 1. § (1) bekezdés d) pontjában a kis- és középvállalkozásokra utaló fordulatot saját, abszolút küszöbökre cserélte, és ezzel szervezetek kerültek ki a hatály alól. Aki 2025-ös összefoglaló alapján állapította meg az érintettségét, jól teszi, ha újranézi; hogy pontosan mi változott, arról külön cikkben írtunk.

Egy vizsgálat, kétféle bizonyíték

Van egy pont, ahol a szabvány és a jogszabály pontosan ugyanazt kéri – és ahol a gyakorlatban a leggyakrabban hiányzik a bizonyíték.

Az A.8.8 kontroll a technikai sérülékenységek kezelését írja elő: információt kell gyűjteni a használt rendszerek sérülékenységeiről, fel kell mérni a kitettséget, és intézkedni kell. Az A.8.29 ehhez biztonsági tesztelést tesz hozzá a fejlesztés és az átvétel során. A magyar katalógusban ugyanez a 15.9 (Sérülékenységek ellenőrzése) és a 15.10 (Sérülékenységmenedzsment), a magas osztályban pedig az 5.22.

Ez egy munka, nem kettő. Folyamatosan a sérülékenységvizsgálat fogja ki az újonnan publikált hibákat a használt komponensekből; időszakosan a penetrációs teszt mutatja meg, hogy a bevezetett védelem megállítja-e a támadót. Egy projekt mindkét oldalra ad bizonyítékot, ha a jelentés megnevezi, melyik követelményhez tartozik az adott megállapítás – így írjuk a jelentést az ISO 27001 tanúsító auditra készülő cégeknek, és ugyanígy a NIS2-megfeleléshez is.

Hol húzódik pontosan a határ az automatizált felderítés és a kézi teszt között? Azt külön cikkben szedtük össze.

Mit adunk át a megfeleléshez?

A 16. § szerinti kiberbiztonsági auditot az SZTFH nyilvántartásában szereplő 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. Egyetlen tesztprojektből kijön az a csomag, amelyet a tanúsító szervezet és az auditor is használni tud:

• 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, hogy a hiba a gyakorlatban is kihasználható.
• Kockázati besorolás a saját környezetre vetítve. A CVSS-pontszám mellett leírjuk, mit jelent a hiba ebben a szervezetben: ügyféladat, leállás, pénzügyi veszteség.
• Javítási lépések sorrendben. Nem „frissítse a rendszert”, hanem melyik komponenst, melyik verzióra, melyik beállítást hogyan – és mivel érdemes kezdeni.
• Í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.
• Követelményhivatkozás mindkét oldalra. Minden megállapítás mellé odaírjuk, melyik szabványpontot és melyik védelmi intézkedést támasztja alá, tehát a megfelelési táblázat sorai készen érkeznek.

A vizsgálatot elismert módszertanok szerint végezzük – webalkalmazásoknál az OWASP ASVS és a WSTG szerint –, a tesztelőink pedig OSCP-tanúsítvánnyal rendelkeznek. A Haxoris ISO/IEC 27001 tanúsítványát a TÜV SÜD adta ki, tehát a bizonyíték formáját saját bevezetésből ismerjük; tanúsítást viszont nem mi végzünk: a tanúsítványt a tanúsító szervezet adja ki. A megfelelési oldalról ugyanezt a munkát az IT-biztonsági audit oldalán írtuk le. Azt pedig, hogy a törvény szerinti sérülékenységvizsgálatot melyik szervezet végezheti, a ki végezhet sérülékenységvizsgálatot című cikkünkben bontottuk ki.

Ha van tanúsítvány: ebben a sorrendben érdemes haladni

1. Vesse össze a hatóköröket. Lefedi-e az IBIR azt a szolgáltatást, amely miatt a cég a törvény hatálya alá esik? Ez az első kérdés, és ennek a legsúlyosabb a következménye.
2. Állapítsa meg az érintettséget, és jelentkezzen be. Ágazat és méret az 1. § (1) bekezdése, valamint a 2. és a 3. melléklet alapján, utána a nyilvántartásba vétel harminc napon belül.
3. Sorolja be a rendszereket. A besorolás dönti el, mely védelmi intézkedések vonatkoznak rájuk – és azt is, kell-e független behatolásvizsgálat. Enélkül a tesztelés hatóköre találgatás.
4. Építsen megfelelési táblázatot. Egyik oszlopban a törvény és a rendelet követelményei, a másikban a szabvány kontrolljai és a meglévő bizonyítékok azonosítója. A sorok nagy részét egy már meglévő dokumentum számával lehet kitölteni.
5. Pótolja a négy hiányzó elemet. Felelős kijelölése, bejelentési eljárás a törvényi határidőkkel, a felügyeleti díj rendezése és az auditorral kötendő szerződés.
6. Mérje meg a hatékonyságot. Az a penetrációs teszt, amely az A.8.29 kontroll miatt amúgy is esedékes, egyszerre ad bizonyítékot a 15.9 és a 15.10 intézkedéshez – feltéve, hogy a jelentés meg is nevezi őket.

Egy élő IBIR-rel dolgozó cégnél ez néhány hét, és az idő nagy része a megfelelési táblázatra és a bejelentési eljárásra megy el.

Ha nincs ISO 27001 tanúsítvány

Tanúsítási kötelezettség nincs. A törvény működő védelmet és bizonyítható intézkedéseket ír elő, nem tanúsító szervezet papírját. Az A melléklet ettől még a legjobban átgondolt terv egy ilyen rendszer felépítéséhez, mert kész intézkedésekre bontja a feladatot, amelyeket nem kell újra kitalálni.

Két út van, mindkettő védhető:

• Tanúsítással, ha a dokumentumra amúgy is szükség van beszerzési eljárásokhoz és ügyfelek biztonsági kérdőíveihez. A tanúsítási ciklus jellemzően három év, évenkénti felügyeleti audittal.
• Tanúsítás nélkül, az A mellékletet szerkezetként használva. Így megspórolható a tanúsító audit költsége, és elvész egy kereskedelmi érv.

A technikai rész mindkét úton ugyanaz, és egyedül ezt nem lehet későbbre tolni: meg kell tudni mutatni, hogy a védelem működik.

Összefoglalva: előny, nem mentesség

Az ISO 27001 tanúsítvány nem megfelelési igazolás a magyar kiberbiztonsági törvényhez, hanem előny a felkészülésben. A tartalom nagy részét lezárja, a hatósággal szembeni kötelezettségeket viszont nem: a bejelentkezést, a besorolást, a kétévenkénti auditot, a felelős kijelölését, az incidensbejelentést és a felügyeleti díjat a szervezetnek magának kell elintéznie. A hetedik pont, a magas osztály független behatolásvizsgálata pedig az egyetlen, amelyet nem lehet házon belül letudni.

A Haxoris ebben a folyamatban a technikai oldalon dolgozik. Penetrációs tesztet és sérülékenységvizsgálatot végzünk, a jelentést pedig eleve olyan formában adjuk át, amelyet mindkét oldal elfogad: megnevezett módszertannal, ellenőrzött megállapításokkal, kockázati besorolással, javítási sorrenddel és írásos igazolással az újratesztelésről. Kérjen ingyenes konzultációt, és nézzük meg, mi hiányzik még a bizonyítékok közül.

ISO 27001 és a kiberbiztonsági törvény – gyakori kérdések

Kapcsolódó Haxoris-szolgáltatások: penetrációs teszt az ISO 27001 felkészítéshez · penetrációs teszt a NIS2-megfeleléshez