Validátor-nézet

Információ: A szakértői validáláshoz készült munkafelület: a platform teljes jogi tartalma egyben, nyomtathatóan — a besorolási kérdésektől a kontroll-könyvtáron, a határidő-logikán, a GDPR-modulon és az ISO-megfeleltetéseken át a képzési tananyagig és az audit-rendelet szerinti nyilvántartásokig, az általunk azonosított nyitott kérdésekkel megjelölve.

Ez az oldal a szakértői validáláshoz készült: a Certando minden jogi tartalma egyben, nyomtathatóan — a besorolási varázsló kérdéseitől az ISO-megfeleltetésekig. A „Validálandó” jegyzetek az általunk azonosított nyitott jogi kérdéseket jelölik.

1. Besorolási kérdéssor

A) Cégadatok

Azonosítás — a besorolás naplózásához.

A1

Melyik cégről van szó? (cégnév)

Típus: szabad szöveg

Nem befolyásolja az eredményt; a naplóbejegyzéshez kell.

B) Ágazat

Érintettség első feltétele: listás ágazatban működik-e a szervezet.

B1

Az alábbi ágazatok közül melyikben működik a cég? (Ha több is igaz, a szigorúbbat válaszd.)

Típus: egyválasztós

  • Kiemelten kockázatos ágazat — energia, közlekedés, bank/pénzügy, egészségügy, ivóvíz/szennyvíz, digitális infrastruktúra (adatközpont, felhő, internet, DNS), IKT-szolgáltatáskezelés, űripar
  • Kockázatos ágazat — posta/futár, hulladékgazdálkodás, vegyipar, élelmiszer, gyártás (orvostechnika, elektronika, gépek, járművek), digitális szolgáltatók (piactér, kereső, közösségi platform), kutatás
  • Egyik sem — a cég tevékenysége egyik felsorolt ágazatba sem tartozik

Validálandó: az ágazati példa-felsorolások hiánytalanok és pontosak-e a törvény mellékletei szerint.

C) Méret

Érintettség második feltétele: méretküszöb. Kapcsolt vállalkozásokkal együtt számolva.

C1

Létszám (fő) — a kapcsolt vállalkozásokkal együtt

Típus: szám

C2

Éves nettó árbevétel (millió euróban, kb. — 1 M€ ≈ 400 M Ft). A jogszabály a mérlegfőösszeget is nézi alternatívaként — ha a kettő eltér, a kedvezőtlenebbel számolunk.

Típus: szám

Validálandó: a mérlegfőösszeg-alternatíva kezelése így elegendő-e, vagy külön mezőben kell kérdezni.

D) Kivételek

Méretküszöb nélkül is fennálló érintettségi esetek.

D1

Nyújt-e a cég DNS-, domain-regisztrációs, bizalmi (pl. e-aláírás) vagy nyilvános hírközlési szolgáltatást?

Típus: igen/nem

Validálandó: a 4 szolgáltatástípus egy kérdésben — szét kell-e bontani?

D2

Állami vagy önkormányzati többségi tulajdonban van a cég?

Típus: igen/nem

D3

Szolgáltat-e rendszeresen legalább 20 000 embernek, vagy legalább 5 másik, a törvény hatálya alá tartozó szervezetnek?

Típus: igen/nem

Validálandó: a küszöbszámok és a 'rendszeresen' fordulat jogszabályi pontossága.

D4

Kapott-e a cég hatósági határozatot arról, hogy a törvény hatálya alá tartozik?

Típus: igen/nem

E) Rendszerhatás (biztonsági osztályhoz)

A biztonsági osztály (alap/jelentős/magas) meghatározása a bizalmasság–sértetlenség–rendelkezésre állás sérülésének lehetséges hatása alapján. A legrosszabb reális esetet kérdezzük.

E1

Ha a tárolt adatok illetéktelen kézbe kerülnének… (bizalmasság)

Típus: egyválasztós

  • Nem okozna érdemi kárt
  • A cégnek okozna kárt (pénzügyi / működési)
  • Ügyfeleknek, partnereknek is kárt okozna
  • Emberéletet, kritikus szolgáltatást vagy sok embert érintene
E2

Ha az adatokat valaki észrevétlenül meghamisítaná… (sértetlenség)

Típus: egyválasztós

  • Nem okozna érdemi kárt
  • A cégnek okozna kárt (pénzügyi / működési)
  • Ügyfeleknek, partnereknek is kárt okozna
  • Emberéletet, kritikus szolgáltatást vagy sok embert érintene
E3

Ha a rendszer napokra leállna… (rendelkezésre állás)

Típus: egyválasztós

  • Nem okozna érdemi kárt
  • A cégnek okozna kárt (pénzügyi / működési)
  • Ügyfeleknek, partnereknek is kárt okozna
  • Emberéletet, kritikus szolgáltatást vagy sok embert érintene
E4

Kezel-e a rendszer nagy mennyiségű személyes adatot, különleges adatot (pl. egészségügyi), vagy más szervezetek bizalmas adatait?

Típus: igen/nem

A szokásos munkavállalói adminisztráció (bérszámfejtés) tudatosan NEM tartozik ide — enélkül minden cég 'jelentős'-be esne. Validálandó: a szűkítés jogilag helytálló-e.

2. Besorolási döntési szabályok

R1

HA D4 = igen (hatósági kijelölés) → ÉRINTETT, biztosan.

R2

HA B1 = listás ágazat ÉS (C1 ≥ 50 fő VAGY C2 ≥ 10 M€) → ÉRINTETT.

A VAGY szándékos: elég az egyik küszöb.

R3

HA D1 = igen (DNS/bizalmi/hírközlés) → ÉRINTETT méretküszöb nélkül is, de 'valószínűleg' jelöléssel + hatósági állásfoglalás javaslattal.

R4

HA B1 = listás ÉS méretküszöb NEM teljesül, DE (D2 = igen VAGY D3 = igen) → ÉRINTETT 'valószínűleg' jelöléssel + hatósági állásfoglalás javaslattal.

R5

HA B1 = listás, de semelyik méret/kivétel-feltétel nem teljesül → NEM ÉRINTETT, 'valószínűleg' jelöléssel (határeset-figyelmeztetés).

R6

HA B1 = egyik sem ÉS nincs kivétel → NEM ÉRINTETT.

R7

Kategória: HA B1 = kiemelten kockázatos ÉS (C1 ≥ 250 fő VAGY C2 ≥ 50 M€) → ALAPVETŐ szervezet; egyébként FONTOS.

Validálandó: a nagyvállalati küszöbök és a kategória-szabály pontos jogszabályi megfelelése.

R8

Osztály: HA max(E1,E2,E3) = kritikus szint (4. opció) → MAGAS.

R9

Osztály: HA max(E1,E2,E3) = ügyfél/partner-kár (3. opció) VAGY E4 = igen VAGY kategória = alapvető → JELENTŐS.

Validálandó feltevés: 'alapvető szervezet → legalább jelentős osztály' — logikus, de nem idézett jogszabályhely.

R10

Osztály: minden más esetben → ALAP.

A validálás kérése

Kérjük soronként jelölni: helyes / javítandó (mivel) / törlendő / hiányzik (mi). A ⚠ jegyzetek az általunk azonosított nyitott kérdések — ezekre külön kérjük a visszajelzést. A besorolási szabályok gépi tesztje (11 forgatókönyv) a projektben elérhető és újrafuttatható.

3. NIS2 kontroll-könyvtár — 24 tétel

Ez a lista adja az ügyfél megfelelési feladatait. A „min. osztály” azt jelenti, hogy a kontroll melyik biztonsági osztálytól kötelező — az alap osztályba sorolt szervezetnél a jelentős/magas tételek meg sem jelennek. Validálandó egészében: a jogszabályi hivatkozások pontossága, a minimum osztály besorolása, és hogy nem hiányzik-e kötelező védelmi intézkedés a listáról.

AzonosítóKategóriaKontrollJogszabályi hivatkozásMin. osztályFelülv.
IRANYITAS_FELELOSIrányítás

Kiberbiztonsági felelős kijelölése

A szervezet vezetése írásban kijelöli az elektronikus információs rendszerek biztonságáért felelős személyt.

2024. évi LXIX. tv. (piszkozat)Alap
IRANYITAS_VEZETOI_KEPZESIrányítás

Vezetői kiberbiztonsági képzés

A vezető tisztségviselők rendszeres kiberbiztonsági képzésen vesznek részt, a részvétel dokumentált.

2024. évi LXIX. tv. (piszkozat)Alap12 hó
IRANYITAS_IBSZIrányítás

Információbiztonsági szabályzat (IBSZ)

A szervezet rendelkezik jóváhagyott, hatályos információbiztonsági szabályzattal, amely kiterjed minden elektronikus információs rendszerre.

7/2024. (VI. 24.) MK rend. (piszkozat)Alap12 hó
KOCKAZAT_ERTEKELESKockázatkezelés

Kockázatértékelés elvégzése

Dokumentált kockázatértékelés az elektronikus információs rendszerekre: fenyegetések, valószínűség, hatás, intézkedések.

2024. évi LXIX. tv. (piszkozat)Alap12 hó
KOCKAZAT_BESOROLASKockázatkezelés

Biztonsági osztályba sorolás dokumentálása

Minden elektronikus információs rendszer biztonsági osztályba sorolt (alap/jelentős/magas), a besorolás indoklással dokumentált.

7/2024. (VI. 24.) MK rend. (piszkozat)Alap
KOCKAZAT_TERVKockázatkezelés

Kockázatkezelési terv karbantartása

Az azonosított kockázatokhoz intézkedési terv tartozik felelőssel és határidővel; a terv rendszeresen felülvizsgált.

2024. évi LXIX. tv. (piszkozat)Jelentős6 hó
HOZZAFERES_MATRIXHozzáférés-kezelés

Jogosultsági mátrix vezetése

Nyilvántartás arról, hogy mely munkakör mely rendszerekhez milyen szintű hozzáféréssel rendelkezik (need-to-know elv).

7/2024. (VI. 24.) MK rend. (piszkozat)Alap6 hó
HOZZAFERES_MFAHozzáférés-kezelés

Többtényezős azonosítás (MFA)

Rendszergazdai és távoli hozzáférésű fiókoknál a többtényezős azonosítás kötelező és technikailag kikényszerített.

7/2024. (VI. 24.) MK rend. (piszkozat)Alap
HOZZAFERES_VISSZAVONASHozzáférés-kezelés

Hozzáférés visszavonása kilépéskor

Munkaviszony megszűnésekor a hozzáférések 24 órán belül visszavonásra kerülnek, a visszavonás dokumentált.

7/2024. (VI. 24.) MK rend. (piszkozat)Alap
HOZZAFERES_PRIVILEGIZALTHozzáférés-kezelés

Privilegizált fiókok külön kezelése

A rendszergazdai fiókok elkülönítettek a napi munkavégzésre használt fiókoktól, használatuk naplózott.

7/2024. (VI. 24.) MK rend. (piszkozat)Jelentős
UZEM_MENTESÜzemeltetés-biztonság

Mentési rend és helyreállítási terv

Rendszeres, dokumentált mentések; a helyreállítás tesztelt, a tesztek jegyzőkönyvezettek.

7/2024. (VI. 24.) MK rend. (piszkozat)Alap6 hó
UZEM_FRISSITESÜzemeltetés-biztonság

Biztonsági frissítések kezelése

A szoftverek biztonsági frissítései ellenőrzött folyamat szerint, dokumentáltan települnek.

7/2024. (VI. 24.) MK rend. (piszkozat)Alap
UZEM_VIRUSVEDELEMÜzemeltetés-biztonság

Kártevő elleni védelem

Minden végponton és szerveren aktív, központilag felügyelt kártevő elleni védelem működik.

7/2024. (VI. 24.) MK rend. (piszkozat)Alap
UZEM_NAPLOZASÜzemeltetés-biztonság

Központi naplózás és napló-felülvizsgálat

A kritikus rendszerek eseménynaplói központilag gyűjtöttek, rendszeres felülvizsgálatuk dokumentált.

7/2024. (VI. 24.) MK rend. (piszkozat)Jelentős3 hó
UZEM_TITKOSITASÜzemeltetés-biztonság

Titkosítás érzékeny adatokon

Az érzékeny adatok tárolás közben és átvitel során titkosítottak; a kulcskezelés szabályozott.

7/2024. (VI. 24.) MK rend. (piszkozat)Jelentős
INCIDENS_ELJARASIncidenskezelés

Incidenskezelési eljárásrend

Írásos eljárás a biztonsági események azonosítására, osztályozására, kezelésére és eszkalációjára.

2024. évi LXIX. tv. (piszkozat)Alap12 hó
INCIDENS_BEJELENTESIncidenskezelés

Hatósági bejelentési képesség (24 óra / 72 óra / 1 hónap)

A szervezet képes a jelentős incidensről korai riasztást adni 24 órán belül, eseménybejelentést tenni 72 órán belül, és zárójelentést készíteni egy hónapon belül; a felelős és a csatorna kijelölt.

2024. évi LXIX. tv. + 418/2024. Korm. rend. 77. § (piszkozat)Alap
INCIDENS_NAPLOIncidenskezelés

Incidensnyilvántartás vezetése

Minden biztonsági esemény nyilvántartott: időpont, leírás, intézkedések, lezárás.

2024. évi LXIX. tv. (piszkozat)Alap
ELLATAS_FELMERESEllátási lánc

Kritikus beszállítók kockázatfelmérése

A kritikus beszállítók azonosítottak, kiberbiztonsági szempontú felmérésük dokumentált.

2024. évi LXIX. tv. (piszkozat)Jelentős12 hó
ELLATAS_SZERZODESEllátási lánc

Biztonsági kikötések a beszállítói szerződésekben

A kritikus beszállítói szerződések tartalmaznak kiberbiztonsági és incidens-együttműködési kikötéseket.

2024. évi LXIX. tv. (piszkozat)Jelentős
MAGAS_SERULEKENYSEGVIZSGALATEmelt szintű védelem

Rendszeres sérülékenységvizsgálat és behatolásteszt

A kritikus rendszerek biztonsága rendszeres, dokumentált sérülékenységvizsgálattal és időszakos behatolásteszttel (etikus hackerteszttel) ellenőrzött.

7/2024. (VI. 24.) MK rend. 2. melléklet (piszkozat)Magas12 hó
MAGAS_MONITORINGEmelt szintű védelem

Folyamatos biztonsági felügyelet (monitoring)

A kritikus rendszerek eseményeit folyamatos, valós idejű biztonsági felügyelet figyeli (pl. SIEM-megoldás), riasztási és reagálási képességgel.

7/2024. (VI. 24.) MK rend. 2. melléklet (piszkozat)Magas
MAGAS_REDUNDANCIAEmelt szintű védelem

Magas rendelkezésre állás és tartalék-infrastruktúra

A kritikus szolgáltatások redundáns kialakításúak; katasztrófa-helyreállítási terv és tartalék-kapacitás biztosítja a folytonosságot súlyos kiesés esetén is.

7/2024. (VI. 24.) MK rend. 2. melléklet (piszkozat)Magas12 hó
OKTATAS_MUNKAVALLALOIOktatás

Munkavállalói biztonságtudatossági képzés

Minden munkavállaló rendszeres kiberbiztonsági alapképzésben részesül (pl. adathalászat-felismerés); a részvétel dokumentált.

2024. évi LXIX. tv. (piszkozat)Alap12 hó

4. Incidensbejelentési és felülvizsgálati határidők

A termék legkockázatosabb része: ha egy határidő rosszul van számolva, az ügyfél hatósági határidőt mulaszt. A motor minden határidőt az incidens „tudomásszerzés” időpontjából számol.

H1

Korai riasztás — a tudomásszerzéstől számított 24 órán belül.

Alapja: NIS2 23. cikk; 2024. évi LXIX. törvény és végrehajtási rendelete

Validálandó: a „tudomásszerzés” kezdőidőpontjának magyar értelmezése — mikortól ketyeg pontosan az óra?

H2

Eseménybejelentés — a tudomásszerzéstől számított 72 órán belül.

Alapja: NIS2 23. cikk; 2024. évi LXIX. törvény és végrehajtási rendelete

H3

Zárójelentés — a tudomásszerzéstől számított 1 hónapon belül. A motor ezt 30 nappal számolja.

Alapja: NIS2 23. cikk

Validálandó: az „1 hónap” naptári hónapot jelent-e — akkor a 30 napos közelítés a hosszabb hónapokban 1 nappal korábbi (biztonságos irányba téved), februárban viszont későbbi lenne. Kérjük megerősíteni, hogy a szigorúbb 30 nap elfogadható.

H4

Adatvédelmi incidens bejelentése a NAIH felé — 72 órán belül. Csak akkor generálódik, ha a felhasználó az incidensnél bejelölte, hogy személyes adatot is érint.

Alapja: GDPR 33. cikk

Validálandó: helyes-e ezt a felhasználó önbevallására bízni, vagy kérdéssorral kellene eldönteni. Továbbá: az érintettek értesítése (GDPR 34. cikk) jelenleg NEM generál külön határidőt — kell-e?

H5

Kontroll-felülvizsgálati határidők: az egyes kontrollokhoz rendelt felülvizsgálati ciklus (3/6/12 hónap) alapján, a kontroll utolsó módosításától számítva.

Alapja: Belső logika — nem közvetlen jogszabályi előírás

Validálandó: a ciklusok összhangban vannak-e az auditori elvárással, illetve melyik kontrollnál mennyi az elvárt gyakoriság.

5. GDPR-modul — nyilvántartás és jogalapok

A NIS2 és a GDPR ugyanazon a szervezeti alapon fut; a modul a 30. cikk szerinti nyilvántartást és a hatásvizsgálat (DPIA) állapotát kezeli.

G1

Az adatkezelési tevékenységek nyilvántartásának (ROPA) mezői: megnevezés, cél, adatkategóriák, érintettek köre, jogalap, megőrzési idő, címzettek/adatfeldolgozók, DPIA-állapot, megjegyzés.

Validálandó: a GDPR 30. cikk (1) szerinti kötelező tartalmi elemek hiánytalanok-e. Tudatosan nem tevékenységenként kérjük az adatkezelő nevét/elérhetőségét, a harmadik országba történő továbbítás megjelölését és a technikai-szervezési intézkedések leírását — ezek szervezeti szinten adottak. Elfogadható-e így, vagy tevékenységenként is kell?

G2

Választható jogalapok (GDPR 6. cikk (1)): Hozzájárulás — GDPR 6. cikk (1) a); Szerződés teljesítése — GDPR 6. cikk (1) b); Jogi kötelezettség teljesítése — GDPR 6. cikk (1) c); Létfontosságú érdek — GDPR 6. cikk (1) d); Közérdekű feladat — GDPR 6. cikk (1) e); Jogos érdek — GDPR 6. cikk (1) f).

Validálandó: kell-e külön mező a különleges adatok 9. cikk szerinti jogalapjához (egészségügyi, biometrikus stb.), vagy a megjegyzés mezőben kezelhető.

G3

DPIA-állapotok: Nem szükséges; Szükséges — még nincs elvégezve; Elvégezve. A rendszer nem dönti el a felhasználó helyett, hogy kell-e hatásvizsgálat — csak jelzi, ha „szükséges, de nincs elvégezve” állapotban áll.

Validálandó: kell-e a NAIH kötelező DPIA-listájára épülő automatikus javaslat, vagy jogilag kockázatos gépi következtetést levonni.

G4

Az incidens-modulban a „személyes adatot is érint” jelölés indítja a NAIH felé futó 72 órás határidőt (lásd H4).

6. ISO/IEC 27001:2022 irányítási követelmények (4–10. fejezet) — 25 tétel

Ezek magát az irányítási rendszert írják le; a tanúsításnál kötelezően auditáltak, és nem zárhatók ki (szemben az Annex A kontrollokkal). Validálandó: a magyar megfogalmazások szakmailag helytállóak-e, az „elvárt bizonyíték” megfelel-e a tanúsító auditor gyakorlatának, és jogos-e a feltüntetett NIS2-megfeleltetés.

4. A szervezet környezete4 követelmény
4.1

A szervezet és környezetének megértése

Azoknak a külső és belső tényezőknek a meghatározása, amelyek befolyásolják az információbiztonsági célok elérését.

Elvárt bizonyíték: Dokumentált elemzés a külső/belső tényezőkről (pl. jogszabályi, piaci, technológiai).

NIS2-megfeleltetés: nincs — teljesen új munka

4.2

Az érdekelt felek igényeinek megértése

Az érdekelt felek (ügyfelek, hatóságok, tulajdonosok, munkavállalók) azonosítása és elvárásaik meghatározása.

Elvárt bizonyíték: Érdekelt felek jegyzéke az elvárásaikkal és a rájuk vonatkozó követelményekkel.

NIS2-megfeleltetés: nincs — teljesen új munka

4.3

Az ISMS hatókörének meghatározása

Az irányítási rendszer határainak és alkalmazhatóságának meghatározása és dokumentálása.

Elvárt bizonyíték: Hatókör-nyilatkozat: mely szervezeti egységek, telephelyek, rendszerek tartoznak bele.

NIS2-megfeleltetés: KOCKAZAT_BESOROLAS

4.4

Az információbiztonsági irányítási rendszer

Az ISMS kialakítása, bevezetése, fenntartása és folyamatos fejlesztése a szabvány szerint.

Elvárt bizonyíték: Az ISMS folyamatainak leírása és azok kölcsönhatásai.

NIS2-megfeleltetés: IRANYITAS_IBSZ

5. Vezetői szerepvállalás3 követelmény
5.1

Vezetői elkötelezettség

A felső vezetés bizonyítja elkötelezettségét az ISMS iránt (erőforrások, célkitűzések, kommunikáció).

Elvárt bizonyíték: Vezetői döntések, erőforrás-biztosítás dokumentumai, vezetőségi átvizsgálás jegyzőkönyvei.

NIS2-megfeleltetés: IRANYITAS_VEZETOI_KEPZES

5.2

Információbiztonsági politika

A vezetés által jóváhagyott politika, amely keretet ad a biztonsági céloknak és elkötelezettséget vállal a fejlesztésre.

Elvárt bizonyíték: Jóváhagyott, kihirdetett és elérhető információbiztonsági politika.

NIS2-megfeleltetés: IRANYITAS_IBSZ

5.3

Szerepek, felelősségek és hatáskörök

A biztonsági szerepkörök kijelölése, a felelősségek és hatáskörök kiosztása és kommunikálása.

Elvárt bizonyíték: Szervezeti ábra, kijelölő dokumentumok, munkaköri leírások biztonsági részekkel.

NIS2-megfeleltetés: IRANYITAS_FELELOS

6. Tervezés5 követelmény
6.1

Kockázatok és lehetőségek kezelése

A kockázatértékelési és -kezelési folyamat meghatározása, beleértve a kritériumokat és a felelősöket.

Elvárt bizonyíték: Dokumentált kockázatértékelési módszertan, kockázati kritériumok.

NIS2-megfeleltetés: KOCKAZAT_ERTEKELES

6.1.2

Információbiztonsági kockázatértékelés

A kockázatok azonosítása, elemzése és értékelése a meghatározott kritériumok szerint, ismételhető módon.

Elvárt bizonyíték: Kockázati regiszter az azonosított kockázatokkal, szintekkel és felelősökkel.

NIS2-megfeleltetés: KOCKAZAT_ERTEKELES

6.1.3

Információbiztonsági kockázatkezelés

A kockázatkezelési opciók kiválasztása, a szükséges kontrollok meghatározása és összevetése az Annex A-val.

Elvárt bizonyíték: Kockázatkezelési terv, Alkalmazhatósági nyilatkozat (SoA), a kockázatgazdák jóváhagyása.

NIS2-megfeleltetés: KOCKAZAT_TERV

6.2

Információbiztonsági célok

Mérhető biztonsági célok kitűzése a releváns szinteken, a teljesítésük megtervezése.

Elvárt bizonyíték: Célkitűzések listája mérőszámokkal, felelősökkel, határidőkkel.

NIS2-megfeleltetés: nincs — teljesen új munka

6.3

Változások tervezése

Az ISMS-t érintő változások tervezett, szabályozott módon történő végrehajtása.

Elvárt bizonyíték: Változáskezelési nyilvántartás az ISMS-t érintő módosításokról.

NIS2-megfeleltetés: UZEM_FRISSITES

7. Támogatás5 követelmény
7.1

Erőforrások

Az ISMS kialakításához, működtetéséhez és fejlesztéséhez szükséges erőforrások biztosítása.

Elvárt bizonyíték: Erőforrás-terv, költségvetés, létszám- és eszközallokáció.

NIS2-megfeleltetés: nincs — teljesen új munka

7.2

Kompetencia

A biztonsági feladatokat ellátó személyek szükséges kompetenciájának meghatározása és biztosítása.

Elvárt bizonyíték: Kompetencia-mátrix, képzési nyilvántartás, bizonyítványok.

NIS2-megfeleltetés: OKTATAS_MUNKAVALLALOI

7.3

Tudatosság

A munkatársak ismerjék a politikát, a saját hozzájárulásukat és a szabályok megsértésének következményeit.

Elvárt bizonyíték: Tudatossági képzések anyagai és a részvétel igazolása.

NIS2-megfeleltetés: OKTATAS_MUNKAVALLALOI, IRANYITAS_VEZETOI_KEPZES

7.4

Kommunikáció

A belső és külső biztonsági kommunikáció rendjének meghatározása (mit, mikor, kinek, hogyan).

Elvárt bizonyíték: Kommunikációs terv, incidens-kommunikációs eljárás.

NIS2-megfeleltetés: INCIDENS_ELJARAS

7.5

Dokumentált információ

A szabvány által megkövetelt és a szervezet által szükségesnek ítélt dokumentumok létrehozása, kezelése, verziózása.

Elvárt bizonyíték: Dokumentumjegyzék verziószámokkal, jóváhagyásokkal, hozzáférés-szabályozással.

NIS2-megfeleltetés: IRANYITAS_IBSZ

8. Működés3 követelmény
8.1

Működés tervezése és felügyelete

A biztonsági követelmények teljesítéséhez szükséges folyamatok tervezése, bevezetése és felügyelete.

Elvárt bizonyíték: Üzemeltetési eljárások, folyamatleírások, a kiszervezett folyamatok felügyelete.

NIS2-megfeleltetés: IRANYITAS_IBSZ

8.2

Kockázatértékelés végrehajtása

A kockázatértékelés tervezett időközönkénti, illetve jelentős változás esetén történő elvégzése.

Elvárt bizonyíték: Elvégzett kockázatértékelések dokumentált eredményei, dátumokkal.

NIS2-megfeleltetés: KOCKAZAT_ERTEKELES

8.3

Kockázatkezelés végrehajtása

A kockázatkezelési terv végrehajtása és az eredmények dokumentálása.

Elvárt bizonyíték: A kockázatkezelési terv teljesülésének nyomon követése, maradványkockázat elfogadása.

NIS2-megfeleltetés: KOCKAZAT_TERV

9. Teljesítményértékelés3 követelmény
9.1

Figyelemmel kísérés, mérés, elemzés

Annak meghatározása, mit kell mérni, mikor, ki által, és az eredmények kiértékelése.

Elvárt bizonyíték: Mérőszámok (KPI-k) és a mérési eredmények dokumentált kiértékelése.

NIS2-megfeleltetés: MAGAS_MONITORING

9.2

Belső audit

Tervezett időközönkénti belső auditok az ISMS megfelelőségének és hatékonyságának ellenőrzésére.

Elvárt bizonyíték: Belső audit program (ütemterv), auditjelentések, a megállapítások kezelése.

NIS2-megfeleltetés: nincs — teljesen új munka

9.3

Vezetőségi átvizsgálás

A felső vezetés tervezett időközönként átvizsgálja az ISMS-t (bemenetek: auditok, incidensek, célok, kockázatok).

Elvárt bizonyíték: Vezetőségi átvizsgálás jegyzőkönyve a szabvány által előírt bemenetekkel és döntésekkel.

NIS2-megfeleltetés: nincs — teljesen új munka

10. Fejlesztés2 követelmény
10.1

Folyamatos fejlesztés

Az ISMS alkalmasságának, megfelelőségének és hatékonyságának folyamatos javítása.

Elvárt bizonyíték: Fejlesztési intézkedések nyilvántartása, trendek elemzése.

NIS2-megfeleltetés: nincs — teljesen új munka

10.2

Nemmegfelelőség és helyesbítő tevékenység

A nemmegfelelőségekre való reagálás, az okok elemzése, helyesbítő intézkedések és azok hatékonyságának értékelése.

Elvárt bizonyíték: Nemmegfelelőségi napló: leírás, gyökérok, intézkedés, felelős, határidő, lezárás.

NIS2-megfeleltetés: INCIDENS_NAPLO

7. ISO/IEC 27001:2022 Annex A — 93 kontroll

A „NIS2-megfeleltetés” oszlop az üzleti ígéretünk alapja: azt állítjuk, hogy a szervezet a NIS2-munkájával 61 ISO-kontrollt már részben vagy egészben lefed. Ez a legkritikusabb validálandó tartalom — ha egy megfeleltetés téves, az ügyfél késznek hisz egy kontrollt, ami valójában nincs kész. Az üres megfeleltetés azt jelenti: külön munka kell hozzá.

Szervezeti kontrollok (A.5)37 kontroll
Az.KontrollNIS2-megfeleltetés
A.5.1

Információbiztonsági szabályzatok

A vezetés által jóváhagyott, közzétett és rendszeresen felülvizsgált információbiztonsági szabályzat és a hozzá kapcsolódó tematikus szabályzatok.

IRANYITAS_IBSZ
A.5.2

Információbiztonsági szerepkörök és felelősségek

A biztonsági felelősségek egyértelmű kijelölése és dokumentálása a szervezeten belül.

IRANYITAS_FELELOS
A.5.3

Feladatkörök szétválasztása

Az egymással ütköző feladatok és felelősségek szétválasztása a visszaélés és a hiba kockázatának csökkentésére.

HOZZAFERES_MATRIX
A.5.4

Vezetői felelősségek

A vezetés megköveteli minden munkatárstól a szabályzatok és eljárások betartását.

IRANYITAS_VEZETOI_KEPZES
A.5.5

Kapcsolattartás a hatóságokkal

Kapcsolattartási rend a hatóságokkal (bejelentések, együttműködés incidens esetén).

INCIDENS_BEJELENTES
A.5.6

Kapcsolattartás szakmai érdekcsoportokkal

Kapcsolat szakmai fórumokkal, szövetségekkel a fenyegetési információk megosztására.

nincs
A.5.7

Fenyegetettségi információk gyűjtése

Fenyegetettségi információk (threat intelligence) gyűjtése és elemzése a védelem alakításához.

MAGAS_MONITORING
A.5.8

Információbiztonság a projektmenedzsmentben

A biztonsági szempontok beépítése a projektek tervezésébe és végrehajtásába.

nincs
A.5.9

Információk és eszközök leltára

Az információs eszközök nyilvántartása felelősökkel együtt (vagyonleltár).

KOCKAZAT_BESOROLAS
A.5.10

Eszközök elfogadható használata

Az információk és eszközök megengedett használatának szabályai, a munkatársak számára kommunikálva.

IRANYITAS_IBSZ
A.5.11

Eszközök visszaszolgáltatása

A munkaviszony vagy szerződés megszűnésekor minden átadott eszköz visszavétele.

HOZZAFERES_VISSZAVONAS
A.5.12

Információk osztályozása

Az információk bizalmassági, sértetlenségi és rendelkezésre állási igény szerinti besorolása.

KOCKAZAT_BESOROLAS
A.5.13

Információk címkézése

Az osztályozásnak megfelelő címkézési eljárás alkalmazása.

KOCKAZAT_BESOROLAS
A.5.14

Információtovábbítás

Az információk biztonságos továbbításának szabályai a szervezeten belül és kívülre.

UZEM_TITKOSITAS
A.5.15

Hozzáférés-szabályozás

A hozzáférések szabályozása üzleti és biztonsági követelmények alapján.

HOZZAFERES_MATRIX
A.5.16

Identitáskezelés

A felhasználói identitások teljes életciklusának kezelése (létrehozás, módosítás, törlés).

HOZZAFERES_MATRIX, HOZZAFERES_VISSZAVONAS
A.5.17

Hitelesítési információk kezelése

Jelszavak és egyéb hitelesítési adatok kiosztásának, kezelésének szabályai.

HOZZAFERES_MFA
A.5.18

Hozzáférési jogosultságok

A jogosultságok kiosztása, rendszeres felülvizsgálata és visszavonása.

HOZZAFERES_MATRIX, HOZZAFERES_VISSZAVONAS
A.5.19

Információbiztonság a beszállítói kapcsolatokban

A beszállítói kapcsolatokból eredő kockázatok kezelése.

ELLATAS_FELMERES
A.5.20

Biztonsági követelmények a beszállítói szerződésekben

A vonatkozó biztonsági követelmények rögzítése a beszállítói szerződésekben.

ELLATAS_SZERZODES
A.5.21

Az IKT-ellátási lánc biztonsága

Az információtechnológiai termékek és szolgáltatások ellátási láncából eredő kockázatok kezelése.

ELLATAS_FELMERES
A.5.22

Beszállítói szolgáltatások felügyelete és változáskezelése

A beszállítói szolgáltatások rendszeres nyomon követése, felülvizsgálata és a változások kezelése.

ELLATAS_FELMERES
A.5.23

Felhőszolgáltatások biztonsága

A felhőszolgáltatások beszerzésének, használatának és megszüntetésének biztonsági követelményei.

ELLATAS_FELMERES, ELLATAS_SZERZODES
A.5.24

Incidenskezelés tervezése és előkészítése

Incidenskezelési folyamatok, szerepkörök és felelősségek előzetes meghatározása.

INCIDENS_ELJARAS
A.5.25

Biztonsági események értékelése és döntés

A biztonsági események értékelése és annak eldöntése, hogy incidensnek minősülnek-e.

INCIDENS_ELJARAS
A.5.26

Reagálás a biztonsági incidensekre

Az incidensekre való reagálás a dokumentált eljárásoknak megfelelően.

INCIDENS_BEJELENTES
A.5.27

Tanulás az incidensekből

Az incidensekből levont következtetések beépítése a védelmi intézkedésekbe.

INCIDENS_NAPLO
A.5.28

Bizonyítékok gyűjtése

Az incidensekkel kapcsolatos bizonyítékok azonosítása, gyűjtése és megőrzése.

INCIDENS_NAPLO
A.5.29

Információbiztonság üzemzavar idején

A biztonsági szint fenntartása üzemzavar, katasztrófa esetén is.

UZEM_MENTES
A.5.30

IKT-felkészültség az üzletmenet-folytonossághoz

Az informatikai rendszerek felkészítése az üzletmenet-folytonossági célok teljesítésére (RTO/RPO).

UZEM_MENTES, MAGAS_REDUNDANCIA
A.5.31

Jogszabályi és szerződéses követelmények

A vonatkozó jogszabályi, hatósági és szerződéses követelmények azonosítása és teljesítése.

IRANYITAS_IBSZ
A.5.32

Szellemi tulajdonjogok

A szellemi tulajdonhoz fűződő jogok védelmét biztosító eljárások (pl. szoftverlicencek).

nincs
A.5.33

Nyilvántartások védelme

A nyilvántartások védelme elvesztés, megsemmisülés, hamisítás és jogosulatlan hozzáférés ellen.

UZEM_NAPLOZAS, UZEM_MENTES
A.5.34

Személyes adatok védelme

A személyes adatok védelmére vonatkozó követelmények azonosítása és teljesítése (GDPR).

nincs
A.5.35

Az információbiztonság független felülvizsgálata

Az információbiztonsági irányítási rendszer rendszeres, független átvizsgálása.

MAGAS_SERULEKENYSEGVIZSGALAT
A.5.36

Szabályzatoknak és szabványoknak való megfelelés

A szabályzatok, szabályok és szabványok betartásának rendszeres ellenőrzése.

IRANYITAS_IBSZ
A.5.37

Dokumentált üzemeltetési eljárások

Az információfeldolgozó eszközök üzemeltetési eljárásainak dokumentálása és elérhetővé tétele.

IRANYITAS_IBSZ
Személyi kontrollok (A.6)8 kontroll
Az.KontrollNIS2-megfeleltetés
A.6.1

Munkaerő-ellenőrzés

A jelöltek háttér-ellenőrzése a felvétel előtt, a jogszabályi kereteken belül.

nincs
A.6.2

Munkaszerződési feltételek

Az információbiztonsági felelősségek rögzítése a munkaszerződésekben.

nincs
A.6.3

Biztonságtudatossági képzés

Rendszeres biztonságtudatossági oktatás és képzés minden munkatársnak.

OKTATAS_MUNKAVALLALOI, IRANYITAS_VEZETOI_KEPZES
A.6.4

Fegyelmi eljárás

Dokumentált fegyelmi eljárás a biztonsági szabályok megsértése esetére.

nincs
A.6.5

Felelősségek a munkaviszony megszűnése után

A munkaviszony megszűnése vagy változása után is fennálló biztonsági kötelezettségek rögzítése.

HOZZAFERES_VISSZAVONAS
A.6.6

Titoktartási megállapodások

Titoktartási vagy nyilvánosságra hozatalt tiltó megállapodások alkalmazása és felülvizsgálata.

nincs
A.6.7

Távmunka

A távmunkában dolgozók biztonsági intézkedéseinek meghatározása.

HOZZAFERES_MFA
A.6.8

Biztonsági események bejelentése

Csatorna és eljárás a munkatársak által észlelt biztonsági események bejelentésére.

INCIDENS_BEJELENTES
Fizikai kontrollok (A.7)14 kontroll
Az.KontrollNIS2-megfeleltetés
A.7.1

Fizikai biztonsági határok

Az érzékeny információkat tartalmazó területek fizikai határainak kijelölése és védelme.

nincs
A.7.2

Fizikai belépés

A védett területekre való belépés szabályozása belépés-ellenőrzési eszközökkel.

nincs
A.7.3

Irodák, helyiségek és létesítmények védelme

Az irodák és technikai helyiségek fizikai védelmének kialakítása.

nincs
A.7.4

Fizikai biztonsági felügyelet

A védett területek folyamatos megfigyelése jogosulatlan belépés észlelésére.

nincs
A.7.5

Védelem fizikai és környezeti fenyegetések ellen

Védelem tűz, árvíz, földrengés és egyéb környezeti fenyegetések ellen.

nincs
A.7.6

Munkavégzés védett területeken

A védett területeken végzett munkára vonatkozó biztonsági intézkedések.

nincs
A.7.7

Tiszta asztal és tiszta képernyő

Szabályok a papíralapú dokumentumok és a képernyőn megjelenő adatok védelmére.

nincs
A.7.8

Eszközök elhelyezése és védelme

Az eszközök biztonságos elhelyezése a kockázatok és a jogosulatlan hozzáférés csökkentésére.

nincs
A.7.9

Telephelyen kívüli eszközök biztonsága

A szervezet telephelyén kívül használt eszközök védelme.

nincs
A.7.10

Adathordozók

Az adathordozók kezelése a teljes életciklusuk során (beszerzés, szállítás, selejtezés).

UZEM_TITKOSITAS
A.7.11

Kiszolgáló közművek

Az áramellátás és egyéb közművek meghibásodásából eredő kockázatok kezelése.

MAGAS_REDUNDANCIA
A.7.12

Kábelezés biztonsága

Az adat- és energiakábelek védelme lehallgatás és sérülés ellen.

nincs
A.7.13

Eszközök karbantartása

Az eszközök megfelelő karbantartása a rendelkezésre állás és sértetlenség biztosítására.

nincs
A.7.14

Eszközök biztonságos selejtezése vagy újrahasznosítása

Az adatok biztonságos törlése az eszközök selejtezése vagy újrafelhasználása előtt.

nincs
Technológiai kontrollok (A.8)34 kontroll
Az.KontrollNIS2-megfeleltetés
A.8.1

Felhasználói végponti eszközök

A végponti eszközökön tárolt vagy feldolgozott információk védelme.

UZEM_VIRUSVEDELEM
A.8.2

Privilegizált hozzáférési jogosultságok

A kiemelt jogosultságok kiosztásának és használatának korlátozása és felügyelete.

HOZZAFERES_PRIVILEGIZALT
A.8.3

Információ-hozzáférés korlátozása

Az információkhoz és alkalmazásfunkciókhoz való hozzáférés korlátozása a hozzáférési szabályzat szerint.

HOZZAFERES_MATRIX
A.8.4

Forráskódhoz való hozzáférés

A forráskódhoz és a fejlesztői eszközökhöz való hozzáférés szabályozása.

nincs
A.8.5

Biztonságos hitelesítés

Biztonságos hitelesítési technológiák és eljárások alkalmazása (pl. többtényezős azonosítás).

HOZZAFERES_MFA
A.8.6

Kapacitáskezelés

Az erőforrás-felhasználás nyomon követése és a kapacitásigények tervezése.

MAGAS_MONITORING
A.8.7

Védelem kártevők ellen

Kártevő elleni védelem megvalósítása, felhasználói tudatosítással kiegészítve.

UZEM_VIRUSVEDELEM
A.8.8

Technikai sérülékenységek kezelése

A sérülékenységekről szóló információk gyűjtése és a kockázatok kezelése.

UZEM_FRISSITES, MAGAS_SERULEKENYSEGVIZSGALAT
A.8.9

Konfigurációkezelés

A hardver, szoftver és hálózati konfigurációk biztonságos beállítása és felügyelete.

UZEM_FRISSITES
A.8.10

Információk törlése

Az információk törlése, ha már nincs rájuk szükség (jogszabályi megőrzési időn túl).

nincs
A.8.11

Adatmaszkolás

Adatmaszkolás alkalmazása a hozzáférési szabályzatnak és a jogszabályoknak megfelelően.

nincs
A.8.12

Adatszivárgás megelőzése

Adatszivárgás-megelőző intézkedések az érzékeny információt kezelő rendszereken.

UZEM_TITKOSITAS
A.8.13

Információk mentése

Rendszeres mentés készítése és a visszaállíthatóság tesztelése.

UZEM_MENTES
A.8.14

Információfeldolgozó eszközök redundanciája

Redundancia kialakítása a rendelkezésre állási követelmények teljesítéséhez.

MAGAS_REDUNDANCIA
A.8.15

Naplózás

A tevékenységek, kivételek és biztonsági események naplózása, a naplók megőrzése és elemzése.

UZEM_NAPLOZAS
A.8.16

Tevékenységek felügyelete

A hálózatok és rendszerek folyamatos figyelése a rendellenes viselkedés észlelésére.

MAGAS_MONITORING
A.8.17

Óraszinkronizálás

A rendszerórák szinkronizálása jóváhagyott időforrással (a naplók összevethetősége miatt).

UZEM_NAPLOZAS
A.8.18

Privilegizált segédprogramok használata

A rendszervédelmet megkerülni képes segédprogramok használatának korlátozása és felügyelete.

HOZZAFERES_PRIVILEGIZALT
A.8.19

Szoftvertelepítés az üzemi rendszereken

A szoftverek üzemi rendszerekre való telepítésének biztonságos kezelése.

UZEM_FRISSITES
A.8.20

Hálózatok biztonsága

A hálózatok és hálózati eszközök védelme és felügyelete.

MAGAS_MONITORING
A.8.21

Hálózati szolgáltatások biztonsága

A hálózati szolgáltatások biztonsági mechanizmusainak és szolgáltatási szintjeinek meghatározása.

nincs
A.8.22

Hálózatok szegmentálása

Az információs szolgáltatások, felhasználók és rendszerek elkülönítése a hálózaton.

nincs
A.8.23

Webes tartalomszűrés

A külső webhelyekhez való hozzáférés szűrése a káros tartalmak elkerülésére.

UZEM_VIRUSVEDELEM
A.8.24

Titkosítás alkalmazása

Titkosítási szabályok kialakítása és megvalósítása, kulcskezeléssel együtt.

UZEM_TITKOSITAS
A.8.25

Biztonságos fejlesztési életciklus

A szoftverek és rendszerek biztonságos fejlesztésére vonatkozó szabályok.

nincs
A.8.26

Alkalmazásbiztonsági követelmények

A biztonsági követelmények meghatározása az alkalmazások fejlesztésekor és beszerzésekor.

nincs
A.8.27

Biztonságos rendszerarchitektúra és tervezési elvek

Biztonságos tervezési elvek alkalmazása a rendszerek kialakításánál.

nincs
A.8.28

Biztonságos kódolás

Biztonságos kódolási elvek alkalmazása a szoftverfejlesztés során.

nincs
A.8.29

Biztonsági tesztelés fejlesztés és átvétel során

Biztonsági tesztelési folyamatok meghatározása és végrehajtása a fejlesztési életciklusban.

MAGAS_SERULEKENYSEGVIZSGALAT
A.8.30

Kiszervezett fejlesztés

A kiszervezett rendszerfejlesztési tevékenységek irányítása és felügyelete.

ELLATAS_SZERZODES
A.8.31

Fejlesztői, teszt- és üzemi környezetek szétválasztása

A fejlesztői, tesztelési és üzemi környezetek elkülönítése és védelme.

nincs
A.8.32

Változáskezelés

Az információfeldolgozó eszközöket és rendszereket érintő változások szabályozott kezelése.

UZEM_FRISSITES
A.8.33

Tesztadatok kezelése

A tesztadatok megfelelő kiválasztása, védelme és kezelése.

nincs
A.8.34

Rendszerek védelme auditvizsgálat során

Az üzemi rendszereket érintő auditvizsgálatok tervezése és egyeztetése a fennakadás elkerülésére.

nincs

8. Vezetői kiberbiztonsági képzés — tananyag és vizsga

A képzés elvégzése maga is törvényi kötelezettség, és a Certando naplója szolgál a teljesítés bizonyítékául. Validálandó: a tananyag jogi állításai helytállóak-e, a 8 kérdéses vizsga és a 6 helyes válaszos ponthatár elfogadható-e az auditornak a „megtörtént képzés” igazolásához, és elegendő-e ez a terjedelem.

1. Miért érinti ez a céget — és miért téged?

A NIS2 az Európai Unió kiberbiztonsági irányelve, amelyet Magyarországon a 2024. évi LXIX. törvény (kiberbiztonsági törvény) ültetett át. Nem ajánlás, hanem kötelező jogszabály: a hatálya alá tartozó szervezeteknek védelmi intézkedéseket kell működtetniük, nyilvántartást kell vezetniük, és kétévente független auditon kell bizonyítaniuk a megfelelésüket.

A törvény újdonsága a vezetői felelősség: a megfelelés nem az informatikai osztály belügye. A szervezet vezetése hagyja jóvá a kiberbiztonsági kockázatkezelési intézkedéseket, felügyeli a végrehajtásukat — és a mulasztásért személyében is felelősségre vonható. Ezért kötelező eleme a törvénynek az, amit most csinálsz: a vezetői kiberbiztonsági képzés.

A tét üzleti: egy sikeres kibertámadás leállíthatja a termelést, elviheti az ügyféladatokat, és a helyreállítás költsége mellett hatósági szankcióval is járhat. A megfelelés tehát nem adminisztrációs teher, hanem a cég működőképességének biztosítása.

2. A vezetés felelőssége

A NIS2 20. cikke szerint az irányító testület (ügyvezetés, igazgatóság) három kötelezettséget visel: jóváhagyja a kockázatkezelési intézkedéseket, felügyeli azok végrehajtását, és felelős a kötelezettségek megsértéséért. Ez a felelősség nem delegálható el teljes egészében — az IT-vezető vagy külső szolgáltató megbízása nem mentesíti a vezetést.

A magyar törvény kijelöli az elektronikus információs rendszerek biztonságáért felelős személyt is: minden érintett szervezetnek ki kell neveznie egy megfelelő szakértelemmel rendelkező felelőst (belső munkatárs vagy szerződött külső szakértő), aki a biztonsági feladatokat koordinálja.

A vezetői képzés maga is törvényi kötelezettség: a vezető tisztségviselőknek olyan képzésen kell részt venniük, amely képessé teszi őket a kiberbiztonsági kockázatok és gyakorlatok megítélésére — és a részvételt dokumentálni kell. Ez a modul pontosan ezt a dokumentált képzést adja: az elvégzés a Certando kitörölhetetlen naplójába kerül.

3. A tíz kötelező intézkedési terület

A NIS2 21. cikke tíz kockázatkezelési területet ír elő minden érintett szervezetnek: (1) kockázatelemzés és biztonsági szabályzatok; (2) incidenskezelés; (3) üzletmenet-folytonosság — mentések, helyreállítás, válságkezelés; (4) a beszállítói lánc biztonsága; (5) biztonságos rendszerbeszerzés és -fejlesztés; (6) az intézkedések hatékonyságának mérése; (7) kiberhigiénia és képzés; (8) titkosítás; (9) személyzeti biztonság és hozzáférés-kezelés; (10) többtényezős azonosítás (MFA) és biztonságos kommunikáció.

Vezetőként nem a technikai részleteket kell ismerned, hanem azt, hogy mindegyik területen van-e működő intézkedés, ki a felelőse, és mikor volt utoljára felülvizsgálva. A Certando kontroll-listája pontosan ezt mutatja meg — a te dolgod a számonkérés: ha egy kontroll hónapok óta »Hiányzik«, annak következménye legyen.

Külön kiemelendő az MFA (többtényezős azonosítás): a jelszó mellé egy második igazoló lépés (pl. telefonos kód). A sikeres támadások jelentős része ellopott jelszóval indul — az MFA ezt önmagában megakadályozza, ezért az egyik legjobb ár-érték arányú védelem.

4. Incidenskezelés és a szigorú határidők

Jelentős biztonsági incidens esetén a bejelentés három lépcsőben kötelező: korai riasztás 24 órán belül, részletes eseménybejelentés 72 órán belül, és zárójelentés 1 hónapon belül (418/2024. Korm. rendelet). A határidők a tudomásszerzéstől számítanak — nem attól, amikor már minden részlet ismert.

Vezetőként két dolgot kell biztosítanod: legyen kijelölt felelős és begyakorolt folyamat (ki, kit, mikor értesít), és a szervezetben mindenki tudja: incidens-gyanú esetén azonnal jelezni kell — a késlekedés vagy eltitkolás a legrosszabb döntés, mert a határidő akkor is ketyeg.

A Certando incidens-modulja rögzítéskor automatikusan indítja a visszaszámlálókat és naplózza a lépéseket — de a folyamat emberi oldala (ki veszi észre, ki dönt) a szervezet felkészültségén múlik. Érdemes évente legalább egy próbariadót tartani.

5. Beszállítói lánc és hozzáférések

A támadók gyakran nem a célszervezetet, hanem annak gyengébben védett beszállítóját törik fel — ezért a NIS2 önálló intézkedési területként kezeli a beszállítói lánc biztonságát. A gyakorlatban: fel kell mérni, mely szolgáltatók férnek hozzá a rendszereidhez vagy adataidhoz, és velük szerződésben kell rögzíteni a biztonsági elvárásokat.

A hozzáférés-kezelés alapelve a szükséges minimum: mindenki csak ahhoz férjen hozzá, ami a munkájához kell. Kilépő munkatárs vagy lejáró szerződés esetén a hozzáférést azonnal vissza kell vonni — az elfelejtett, »árva« fiókok a leggyakoribb támadási kapuk közé tartoznak.

Vezetői ökölszabály: évente legalább egyszer kérj listát arról, kinek milyen hozzáférése van (belsősök és külsősök), és kérdezz rá a kivételekre. Ez egyetlen megbeszélés, és a leggyakoribb réseket zárja.

6. Vezetői ellenőrzőlista — a napi gyakorlat

Negyedévente: nézd meg a megfelelési műszerfalat (kész / folyamatban / hiányzó kontrollok), kérdezz rá a lejárt határidőkre, és győződj meg róla, hogy az incidens-felelős és a helyettese naprakész.

Évente: vezetői képzés felfrissítése (ez a modul), hozzáférés-felülvizsgálat, mentés-visszaállítási próba (nem az a kérdés, készül-e mentés, hanem hogy visszaállítható-e), és legalább egy incidens-szimuláció.

Audit előtt: a Certando auditkész exportja egyetlen kattintással előállítja a teljes bizonyíték-csomagot — ha a fenti rutint tartod, az audit nem projekt, hanem formalitás. Pontosan ez a cél: a megfelelés ne kampány legyen, hanem működési rutin.

Vizsgakérdések — 8 kérdés, ponthatár: 6 helyes válasz

Jelentős incidens esetén mennyi időn belül kötelező a korai riasztás?

  • 24 órán belül ✓ (a rendszer szerint ez a helyes)
  • 72 órán belül
  • 8 napon belül

Ki felel végső soron a szervezet kiberbiztonsági megfeleléséért?

  • Az informatikai osztály
  • A szervezet vezetése (irányító testülete) ✓ (a rendszer szerint ez a helyes)
  • A külső IT-szolgáltató

Milyen gyakran kötelező a független kiberbiztonsági audit?

  • Évente
  • Kétévente ✓ (a rendszer szerint ez a helyes)
  • Ötévente

Mi igaz a vezetői kiberbiztonsági képzésre?

  • Ajánlott, de nem kötelező
  • Csak az IT-vezetőnek kötelező
  • A vezető tisztségviselőknek kötelező, és a részvételt dokumentálni kell ✓ (a rendszer szerint ez a helyes)

Mit jelent az MFA (többtényezős azonosítás)?

  • A jelszó mellett egy második igazoló lépés is szükséges a belépéshez ✓ (a rendszer szerint ez a helyes)
  • Több felhasználó közös fiókot használ
  • A jelszót havonta cserélni kell

Mi a teendő, ha egy munkatárs incidens gyanúját észleli?

  • Várjon, amíg megbizonyosodik róla, hogy valódi támadás történt
  • Azonnal jelezze a kijelölt felelősnek — a bejelentési határidők a tudomásszerzéstől számítanak ✓ (a rendszer szerint ez a helyes)
  • Először állítsa helyre a rendszert, és utána jelentse

Mennyi időn belül kell elkészíteni az incidens zárójelentését?

  • 72 órán belül
  • 1 hónapon belül ✓ (a rendszer szerint ez a helyes)
  • 6 hónapon belül

Miért kiemelt terület a beszállítói lánc biztonsága?

  • Mert a beszállítói számlák pontossága jogszabályi követelmény
  • Mert a támadók gyakran a gyengébben védett beszállítón keresztül jutnak be ✓ (a rendszer szerint ez a helyes)
  • Mert a beszállítókat évente cserélni kell

9. Az audit-rendelet szerinti nyilvántartások (EIR, eltérések, kérdőív)

Az 1/2025. (I. 31.) SZTFH rendelet kötött oszlopszerkezetű nyilvántartásokat ír elő, amelyeket az auditnak át kell adni. A táblázatok szerkezetét a mellékletekből vettük át; a kitöltési szabályokhoz kérjük a visszajelzést. Az SZ5 kérdés a legfontosabb az egész dokumentumban.

SZ1

EIR-nyilvántartás: rendszerenként rögzítjük a megnevezést, a támogatott üzleti célt, a besorolási szempont azonosítóját, a bizalmasság/sértetlenség/rendelkezésre állás érintettségét (igen/nem), az indoklást és a rendszer saját biztonsági osztályát.

Alapja: 1/2025. (I. 31.) SZTFH rendelet 1. melléklet (A–G oszlop)

Validálandó: a „besorolási szempont azonosító” mezőt jelenleg szabad szövegként kérjük. Kell-e helyette az MKr. 1. melléklete szerinti zárt választéklista, és ha igen, mi a hivatalos azonosító-készlet?

SZ2

A rendszer biztonsági osztályát a felhasználó állítja be; a Certando nem vezeti le automatikusan a D–F oszlop válaszaiból.

Alapja: 1/2025. SZTFH rendelet 1. melléklet; MKr.

Validálandó: levezethető-e egyáltalán gépiesen az osztály a három szempont érintettségéből, vagy szándékosan szakértői döntés? Ha levezethető, kérjük a szabályt.

SZ3

Eltérés-nyilvántartás: érintett EIR, követelménycsoport-hivatkozás, relevancia, helyettesítő kontrollcsoport, az eltérés okának típusa, releváns fenyegetések, kockázati szint, és a maradványkockázat felvállalásának indoklása.

Alapja: 1/2025. (I. 31.) SZTFH rendelet 4. melléklet (A–H oszlop)

Validálandó: az „eltérés okának típusa” és a „fenyegetések” mezőknél a jogszabály zárt listára hivatkozik (MKr. 3. melléklet fenyegetés-katalógus). Ezt még nem építettük be — kérjük a katalógus hiteles forrását, illetve hogy kötelező-e onnan választani.

SZ4

Szervezeti kérdőív: a 25 adatból a rendszerekre vonatkozó 6 kérdést (EIR-számok osztályonként, egyedi szoftvert futtató rendszerek) az EIR-nyilvántartásból számoljuk, nem kérdezzük külön.

Alapja: 1/2025. (I. 31.) SZTFH rendelet 2. melléklet

Validálandó: elfogadható-e a származtatás, vagy az auditor külön, kézzel megadott értéket vár ezekre a sorokra is.

SZ5

A VMI (Védelmi Megfelelési Index) és a SZEKI szöveges sávjait ismerjük és megjelenítjük (≥95 / ≥90 / ≥80 / ≥70 / 70 alatt „nem felel meg”), de a Certando NEM számol hivatalos VMI-t.

Alapja: 1/2025. (I. 31.) SZTFH rendelet 5. melléklet 2.2.5. és 2.3.2. pont

EZ A LEGFONTOSABB NYITOTT KÉRDÉS. A pontszámítás képlete a rendeletben képként szerepel, ezért nem tudtuk átvenni. Kérjük: (a) a képlet szöveges alakját, (b) a „biztosító” és „támogató” követelménycsoportok súlyozását, (c) hogy az eltérés-pontértékek (0 / 1 / 4 / 10 / 1000) hogyan állnak össze indexszé. Enélkül szándékosan nem mutatunk becsült megfelelési pontszámot — inkább semmit, mint tévesen megnyugtatót.

Összegzés a validátornak

A fenti 142 szakmai tétel és 24 döntési szabály együtt adja a Certando teljes jogi tartalmát. Minden itt szereplő anyag piszkozat: éles ügyfélnél csak validálás után használjuk. A visszajelzést tételszinten, azonosítóra hivatkozva kérjük.