Adatvédelmi incidens történt: mit kell tenni az első 72 órában?

Egy adatvédelmi incidens első óráiban a szervezetnek egyszerre kell megállítania a károkozást, feltárnia a történteket, megőriznie a bizonyítékokat, értékelnie az érintetteket fenyegető kockázatokat, és döntenie az esetleges hatósági bejelentésről.

Mindezt úgy, hogy a GDPR szerinti 72 órás határidő már futhat.

A leggyakoribb hiba ilyenkor nem feltétlenül a rossz jogi értékelés, hanem a szervezetlenség: az informatikai szolgáltató vizsgálódik, a vezetés nem kap pontos információt, az adatvédelmi tisztviselőt későn vonják be, és senki nem rögzíti egyértelműen, mikor jutott a szervezet tudomására az incidens.

A 72 óra ezért nem egyszerűen bejelentési határidő. Ez az az időszak, amelyben működésbe kell lépnie a szervezet teljes incidenskezelési rendszerének.

A lényeg egy mondatban

Az adatkezelőnek az adatvédelmi incidenst indokolatlan késedelem nélkül, lehetőség szerint a tudomásszerzéstől számított 72 órán belül be kell jelentenie az illetékes felügyeleti hatóságnak, kivéve, ha az incidens valószínűsíthetően nem jár kockázattal a természetes személyek jogaira és szabadságaira nézve. GDPR 33. cikk (1) bekezdés.

A 72 órás határidő nem arra szolgál, hogy a szervezet addig várjon. Arra szolgál, hogy a már megkezdett kivizsgálás alapján időben meghozza és dokumentálja a szükséges döntéseket.


Mit jelent az adatvédelmi incidens?

Adatvédelmi incidens a biztonság olyan sérülése, amely személyes adatok véletlen vagy jogellenes megsemmisítését, elvesztését, megváltoztatását, jogosulatlan közlését vagy az azokhoz való jogosulatlan hozzáférést eredményezi. GDPR 4. cikk 12. pont.

Az adatvédelmi incidens ezért három alapvető biztonsági tulajdonságot érinthet.

Bizalmassági incidens

Személyes adathoz jogosulatlan személy fér hozzá, vagy annak részére adatot továbbítanak.

Például:

  • egy e-mailt téves címzettnek küldenek;
  • illetéktelen személy hozzáfér egy munkavállalói mappához;
  • nyilvánossá válik egy korábban nem nyilvános adatbázis;
  • adathalász támadás miatt megszerzik egy felhasználó hitelesítési adatait.

Sértetlenségi incidens

A személyes adatot jogosulatlanul vagy véletlenül megváltoztatják.

Például:

  • hibás adatimport felülírja az ügyféladatokat;
  • illetéktelenül módosítják a nyilvántartás tartalmát;
  • rossz személyhez kapcsolnak egy egészségügyi, pénzügyi vagy hatósági adatot.

Rendelkezésre állási incidens

A személyes adat megsemmisül, elveszik, vagy átmenetileg nem hozzáférhető.

Például:

  • zsarolóvírus titkosítja az adatokat;
  • meghibásodás miatt elérhetetlenné válik egy nyilvántartás;
  • véletlenül törölnek egy adatállományt, és nincs használható mentés;
  • elveszik egy személyes adatokat tartalmazó irat vagy eszköz.

Az EDPB szerint az adatvédelmi incidens a bizalmasság, a sértetlenség vagy a rendelkezésre állás sérelméből egyaránt eredhet. Nem minden információbiztonsági esemény adatvédelmi incidens, de személyes adatok érintettsége esetén a látszólag tisztán technikai eseményt is adatvédelmi szempontból kell értékelni.

Téves tehát az a gyakorlat, amely csak az adatszivárgást vagy az adatok nyilvánosságra kerülését tekinti adatvédelmi incidensnek. Egy rendszerleállás vagy adatvesztés akkor is incidens lehet, ha nincs bizonyíték arra, hogy bárki lemásolta az adatokat.


Nem minden informatikai incidens adatvédelmi incidens

Egy vírusfertőzés, szolgáltatáskimaradás vagy illetéktelen belépési kísérlet önmagában még nem feltétlenül minősül adatvédelmi incidensnek.

A döntő kérdés az, hogy az esemény:

  • személyes adatokat érintett-e;
  • ténylegesen sértette-e azok bizalmasságát, sértetlenségét vagy rendelkezésre állását;
  • vagy észszerű bizonyossággal megállapítható-e ilyen sérelem.

Az EDPB kifejezetten elkülöníti egymástól a biztonsági incidenseket és a személyes adatok megsértését: minden adatvédelmi incidens biztonsági esemény, de nem minden biztonsági esemény érint személyes adatokat.

Példa

Egy nyilvános, személyes adatot nem tartalmazó vállalati weboldal néhány perces leállása információbiztonsági esemény lehet, de nem feltétlenül adatvédelmi incidens.

Ha azonban ugyanez a támadás hozzáférést biztosított a kapcsolatfelvételi űrlapon megadott nevekhez, e-mail-címekhez és üzenetekhez, akkor már adatvédelmi incidensről is szó lehet.


Mikor kezdődik a 72 órás határidő?

A határidő nem feltétlenül az incidens tényleges bekövetkezésének időpontjában kezdődik, hanem akkor, amikor az adatkezelő az incidensről tudomást szerez. GDPR 33. cikk (1) bekezdés.

Az EDPB szerint a szervezet akkor tekinthető az incidensről tudomással bíró adatkezelőnek, amikor észszerű mértékű bizonyossággal rendelkezik arról, hogy biztonsági esemény történt, és az személyes adatokat érintett.

Nem kell minden gyanúnál azonnal elindítani a határidőt

Egy nem ellenőrzött riasztás vagy bizonytalan felhasználói jelzés még nem feltétlenül jelenti azt, hogy adatvédelmi incidens történt.

A szervezet jogosult rövid előzetes vizsgálatot végezni annak megállapítására, hogy:

  • valódi esemény történt-e;
  • érintettek-e személyes adatok;
  • sérült-e a bizalmasság, sértetlenség vagy rendelkezésre állás.

Ez a vizsgálat azonban nem húzható indokolatlanul hosszúra.

Nem biztonságos abból kiindulni, hogy a 72 óra csak akkor kezdődik, amikor az adatvédelmi tisztviselő vagy a vezető írásos jelentést kap. Ha a szervezet valamely illetékes szervezeti egysége már megfelelő bizonyossággal tud az incidensről, az információ belső továbbításának késedelme nem használható a határidő mesterséges kitolására.

A 72 óra nem három munkanap

A GDPR 72 órát határoz meg, nem három munkanapot. A hétvége, munkaszüneti nap vagy a vezető távolléte ezért nem állítja meg a határidőt. Az incidenskezelési rendszernek munkaidőn kívül is biztosítania kell a megfelelő értesítési és döntési útvonalat. E következtetés a GDPR 33. cikkében meghatározott, órákban számított határidőből következik.


Ki köteles bejelenteni az incidenst?

Adatkezelő

A felügyeleti hatóság felé fennálló bejelentési kötelezettség az adatkezelőt terheli. Az adatkezelő az a szervezet, amely meghatározza a személyes adatok kezelésének céljait és eszközeit.

Adatfeldolgozó

Az adatfeldolgozó az incidensről való tudomásszerzést követően indokolatlan késedelem nélkül köteles értesíteni az adatkezelőt. Az adatfeldolgozó főszabály szerint nem az adatkezelő helyett teszi meg a GDPR 33. cikke szerinti hatósági bejelentést. GDPR 33. cikk (2) bekezdés.

Az adatfeldolgozói szerződésben célszerű egyértelműen meghatározni:

  • milyen csatornán kell az incidenst jelezni;
  • kit kell értesíteni;
  • milyen minimális információkat kell átadni;
  • hogyan történik a további kivizsgálás;
  • milyen technikai bizonyítékokat és naplókat kell megőrizni;
  • milyen időközönként kell helyzetjelentést adni.

Az adatfeldolgozói értesítési határidőnek a gyakorlatban lényegesen rövidebbnek kell lennie 72 óránál, mert az adatkezelőnek saját kockázatértékelést és hatósági döntést is kell készítenie.


Az első 72 óra gyakorlati menetrendje

Az alábbi időbeosztás nem jogszabályi részletszabály, hanem a GDPR-kötelezettségek teljesítését támogató gyakorlati munkarend.

Az egyes feladatok részben párhuzamosan futnak. Egy súlyos incidensnél nem szabad megvárni az egyik szakasz teljes lezárását a következő megkezdéséhez.


0–1. óra: jelzés, korlátozás és időpont-rögzítés

1. Azonnal aktiválni kell az incidenskezelési folyamatot

A bejelentést fogadó személynek nem saját hatáskörben kell eldöntenie, hogy az eset „elég súlyos-e”. A jelzést az előre meghatározott incidenskezelési csatornán továbbítani kell legalább:

  • az incidens kezeléséért felelős vezetőnek;
  • az informatikai vagy információbiztonsági felelősnek;
  • az adatvédelmi tisztviselőnek vagy adatvédelmi szakértőnek;
  • szükség esetén a jogi, kommunikációs és üzletmenet-folytonossági felelősnek.

Az adatvédelmi tisztviselő bevonása nem jelenti azt, hogy a teljes incidenskezelést neki kell lefolytatnia. A technikai korlátozás az informatikai terület, a szervezeti döntés az adatkezelő vezetése, az adatvédelmi értékelés pedig több szakterület együttműködésének feladata.

2. Rögzíteni kell a tudomásszerzés időpontját

Legalább a következő időpontokat érdemes azonnal dokumentálni:

  • mikor történt vagy történhetett az esemény;
  • mikor észlelték először;
  • ki észlelte;
  • mikor jelezték a kijelölt felelősnek;
  • mikor vált észszerű bizonyossággal megállapíthatóvá, hogy személyes adatok is érintettek;
  • ki döntött a tudomásszerzés időpontjáról.

Az EDPB javasolja, hogy a szervezetek olyan belső rendszert működtessenek, amelyből megállapítható, mikor és hogyan szereztek tudomást az incidensről, és miként értékelték annak kockázatait.

3. Meg kell állítani vagy korlátozni kell a további károkozást

A szükséges intézkedés az eseménytől függően lehet például:

  • kompromittált felhasználói fiók letiltása;
  • aktív munkamenetek megszakítása;
  • jelszó vagy hozzáférési kulcs visszavonása;
  • érintett eszköz hálózatról történő leválasztása;
  • hibásan közzétett dokumentum eltávolítása;
  • téves címzett azonnali megkeresése;
  • adatszivárgást okozó megosztási jogosultság megszüntetése;
  • biztonsági mentések elkülönítése;
  • sérülékeny szolgáltatás ideiglenes korlátozása.

A GDPR kockázattal arányos technikai és szervezési intézkedéseket követel meg, ideértve a rendszerek bizalmasságát, sértetlenségét, rendelkezésre állását, helyreállíthatóságát és a védelmi intézkedések rendszeres értékelését. GDPR 32. cikk.

4. Meg kell őrizni a bizonyítékokat

A korlátozó intézkedés során kerülni kell azokat a lépéseket, amelyek szükségtelenül megsemmisítik:

  • a rendszer- és hozzáférési naplókat;
  • az e-mail-fejléceket;
  • a felhőszolgáltatási auditnaplókat;
  • az érintett konfigurációkat;
  • a káros fájlokat vagy technikai indikátorokat;
  • az esemény időbeli rekonstruálásához szükséges adatokat.

A CISA az incidenskezelés során a releváns naplók, rendszerképek, memóriatartalmak és más gyorsan elvesző bizonyítékok megőrzését javasolja, mert ezek szükségesek lehetnek az esemény hatókörének és következményeinek feltárásához.

A „kapcsoljunk ki mindent” vagy „töröljük a fertőzött fájlokat” reflex bizonyos esetekben megállíthatja a támadást, de egyúttal megsemmisítheti a későbbi kockázatértékeléshez nélkülözhetetlen bizonyítékokat. Súlyos eseménynél informatikai incidenskezelő vagy digitális forenzikai szakértő bevonása indokolt lehet.


1–4. óra: az alapvető tények feltárása

Ebben a szakaszban még nem feltétlenül kell minden technikai részletet ismerni. A cél annak megállapítása, hogy mi történt, és milyen személyes adatok lehetnek érintettek.

Legalább az alábbi kérdésekre kell választ keresni

Mi történt?

  • jogosulatlan hozzáférés;
  • adatkiszivárgás;
  • téves továbbítás;
  • adatvesztés;
  • adatváltoztatás;
  • rendszerleállás;
  • eszköz- vagy iratvesztés;
  • zsarolóvírus vagy más kártékony program;
  • hibás jogosultság vagy nyilvános megosztás.

Mikor történt?

  • egyszeri vagy folyamatos esemény volt;
  • ismert-e a kezdő és záró időpont;
  • fennáll-e még a jogosulatlan hozzáférés;
  • mennyi ideig lehettek az adatok veszélyben.

Milyen rendszerek érintettek?

  • levelezés;
  • fájlszerver;
  • felhőtárhely;
  • ügyviteli rendszer;
  • weboldal vagy online űrlap;
  • munkavállalói nyilvántartás;
  • kamerarendszer;
  • papíralapú irattár;
  • külső szolgáltató rendszere.

Érintettek-e személyes adatok?

A személyes adatok lehetnek például:

  • név és elérhetőség;
  • azonosító adatok;
  • pénzügyi vagy számlázási adatok;
  • munkavállalói adatok;
  • ügyfél- és ügyiratadatok;
  • helyadatok;
  • hitelesítési adatok;
  • egészségügyi vagy más különleges adatok;
  • büntetőjogi felelősségre vonatkozó adatok.

Kik az érintettek?

  • munkavállalók;
  • ügyfelek;
  • lakosok vagy ügyfelek;
  • kiskorúak;
  • betegek;
  • szociális ellátásban részesülők;
  • álláskeresők;
  • partnerek kapcsolattartói;
  • más kiszolgáltatott helyzetben lévő személyek.

A kezdeti felmérésnél nem a tökéletes pontosság az első cél. A hozzávetőleges érintetti és adatmennyiség is elegendő lehet az első kockázatértékeléshez, feltéve, hogy a szervezet egyértelműen jelzi a bizonytalanságokat és folytatja a vizsgálatot.


4–12. óra: az incidens minősítése

1. Biztonsági esemény vagy adatvédelmi incidens?

Ha személyes adat nem érintett, a GDPR 33–34. cikke szerinti bejelentési kötelezettség nem áll fenn. Ettől még az eseményt más információbiztonsági, ágazati vagy szerződéses szabályok alapján kezelni és jelenteni kellhet.

2. Adatkezelőként vagy adatfeldolgozóként történt az esemény?

Egy informatikai szolgáltató, felhőszolgáltató, könyvelő vagy bérszámfejtő ugyanazon incidensben adatfeldolgozó lehet, miközben a megbízó szervezet az adatkezelő.

Az adatfeldolgozónak nem szabad megvárnia a teljes technikai vizsgálat eredményét, ha már észszerű bizonyossággal megállapítható, hogy a megbízó személyes adatai sérültek. Az adatkezelőt indokolatlan késedelem nélkül értesíteni kell.

3. Milyen típusú adatvédelmi incidens történt?

Az eset egyszerre több típust is érinthet.

Például egy zsarolóvírus:

  • elérhetetlenné teheti az adatokat – rendelkezésre állási incidens;
  • módosíthatja vagy károsíthatja azokat – sértetlenségi incidens;
  • az adatokat a titkosítás előtt el is lophatja – bizalmassági incidens.

Nem szabad automatikusan abból kiindulni, hogy zsarolóvírus esetén csak rendelkezésre állási probléma történt. Vizsgálni kell az adatkimásolás és jogosulatlan hozzáférés lehetőségét is.


12–24. óra: kockázatértékelés

A bejelentési döntés központi kérdése nem egyszerűen az, hogy történt-e incidens, hanem az, hogy az milyen kockázatot jelenthet az érintett természetes személyek jogaira és szabadságaira.

A három döntési szint

1. Az incidens valószínűsíthetően nem jár kockázattal

Ebben az esetben:

  • a NAIH felé főszabály szerint nem szükséges bejelentés;
  • az érintetteket sem kell tájékoztatni;
  • az incidenst és a döntés indokait azonban dokumentálni kell.

2. Az incidens kockázattal járhat

Ebben az esetben:

  • az incidenst be kell jelenteni az illetékes felügyeleti hatóságnak;
  • a bejelentést indokolatlan késedelem nélkül, lehetőség szerint 72 órán belül kell megtenni;
  • az érintettek tájékoztatása csak akkor kötelező, ha a kockázat magasnak minősül.

3. Az incidens magas kockázattal járhat

Ebben az esetben:

  • a hatósági bejelentés mellett;
  • az érintetteket is indokolatlan késedelem nélkül tájékoztatni kell.

A hatósági bejelentés küszöbe a kockázat, az érintettek tájékoztatásának küszöbe pedig a magas kockázat. GDPR 33. cikk (1) bekezdés és 34. cikk (1) bekezdés.


Milyen szempontok alapján kell értékelni a kockázatot?

A kockázatértékelést mindig az adott incidens körülményeire kell alapozni. Nem elegendő pusztán az érintettek számát vagy az adatállomány méretét vizsgálni.

1. Az incidens típusa

A jogosulatlan nyilvánosságra hozatal, az adatvesztés és az átmeneti elérhetetlenség eltérő következményekkel járhat.

2. Az adatok jellege és érzékenysége

Nagyobb kockázatot jelenthetnek különösen:

  • egészségügyi adatok;
  • biometrikus vagy genetikai adatok;
  • szociális vagy gyermekvédelmi adatok;
  • pénzügyi adatok;
  • személyazonosító okmányok másolatai;
  • hitelesítési adatok és jelszavak;
  • politikai, vallási vagy érdekképviseleti adatok;
  • büntetőjogi felelősségre vonatkozó információk;
  • bizalmas szakmai vagy magánéleti adatok.

3. Az adatok mennyisége és részletessége

Egyetlen e-mail-cím elvesztése rendszerint más kockázatot jelent, mint egy teljes ügyfélprofil vagy személyi iratanyag nyilvánosságra kerülése.

4. Az érintettek azonosíthatósága

A kockázatot csökkentheti, ha az adatok megfelelően titkosítottak vagy pszeudonimizáltak, és a további azonosításhoz szükséges információ nem került illetéktelen kézbe.

Ez azonban nem azonos azzal, hogy az adatok automatikusan névtelenné váltak.

5. A lehetséges következmények súlyossága

Vizsgálni kell többek között:

  • a személyazonossággal való visszaélés;
  • csalás vagy pénzügyi veszteség;
  • hátrányos megkülönböztetés;
  • jó hírnév sérelme;
  • munkahelyi vagy társadalmi hátrány;
  • titoktartási kötelezettség megsértése;
  • fizikai vagy pszichés sérelem;
  • az érintett joggyakorlásának akadályozása;
  • az adatai feletti ellenőrzés elvesztése

lehetőségét. Az EDPB szerint az adatvédelmi incidensek vagyoni, nem vagyoni és akár fizikai károkat is okozhatnak.

6. Az érintettek sajátosságai

Nagyobb kockázatot jelenthet, ha az incidens:

  • gyermekeket;
  • időseket;
  • betegeket;
  • fogyatékossággal élő személyeket;
  • szociálisan kiszolgáltatott embereket;
  • bántalmazás vagy üldöztetés veszélyének kitett személyeket

érint.

7. A jogosulatlan címzett vagy hozzáférő személy jellege

Más megítélés alá eshet, ha:

  • az adat nyilvánosan hozzáférhetővé vált;
  • ismeretlen támadó töltötte le;
  • versenytárs jutott hozzá;
  • titoktartásra kötelezett, megbízható címzett kapta meg tévedésből, majd igazoltan törölte.

A téves címzett törlési nyilatkozata csökkentheti a kockázatot, de nem szünteti meg automatikusan az incidenst. Vizsgálni kell, hogy az adatot megnyitották-e, továbbították-e, lemásolták-e, és a címzett valóban megbízhatónak tekinthető-e.

8. Az érintettek száma

A nagy érintetti létszám növelheti az incidens összhatását, de egyetlen érintett esetében is fennállhat magas kockázat, ha az adat különösen érzékeny vagy a lehetséges következmény súlyos.

Az EDPB incidensbejelentési iránymutatásai a kockázatértékelést az adatok jellegére, az incidens típusára, az érintettek azonosíthatóságára, a lehetséges következményekre és az érintetti kör sajátosságaira kiterjedő összetett vizsgálatként kezelik.


24–48. óra: a bejelentési döntés előkészítése

Ekkorra a szervezetnek lehetőség szerint rendelkeznie kell:

  • az incidens rövid, tényszerű leírásával;
  • a tudomásszerzés dokumentált időpontjával;
  • az érintett rendszerek és adatkezelések körével;
  • az érintetti és adatkategóriákkal;
  • a hozzávetőleges érintetti létszámmal;
  • a várható következményekkel;
  • az elvégzett és tervezett intézkedésekkel;
  • a kockázatértékelés eredményével;
  • a hatósági és érintetti tájékoztatásra vonatkozó döntési javaslattal.

Ha nincs még minden információ

Ha valamennyi szükséges adat nem áll egyszerre rendelkezésre, az információk szakaszosan is megadhatók, további indokolatlan késedelem nélkül. GDPR 33. cikk (4) bekezdés.

A NAIH szintén azt javasolja, hogy ha az adatkezelő már észszerű bizonyossággal tud az incidensről, de még nem rendelkezik minden részlettel, éljen a szakaszos bejelentés lehetőségével, majd később egészítse ki vagy helyesbítse a korábban megadott adatokat.

A teljes forenzikai jelentés hiánya önmagában nem megfelelő indok a bejelentés elhalasztására. Az első bejelentésben egyértelműen fel kell tüntetni:

  • mely információk biztosak;
  • melyek előzetes becslések;
  • mely kérdések vizsgálata van még folyamatban;
  • mikorra várható további tájékoztatás.

48–72. óra: bejelentés, érintetti kommunikáció és dokumentálás

Mikor kell a NAIH-hoz bejelentést tenni?

A NAIH felé akkor kell bejelenteni az incidenst, ha az valószínűsíthetően kockázattal jár a természetes személyek jogaira és szabadságaira nézve. Ha a bejelentés 72 órán túl történik, a késedelem okait is meg kell indokolni.

Hogyan lehet bejelenteni?

A NAIH adatvédelmi incidensbejelentő rendszert működtet az adatkezelők számára. Az elektronikus ügyintézésre kötelezett szervezetek számára a Hatóság formanyomtatványt és elektronikus ügyindítási lehetőséget is biztosít; az alkalmazandó benyújtási módot a szervezet jogállása alapján kell kiválasztani.

Mit kell tartalmaznia a hatósági bejelentésnek?

A bejelentésnek legalább az alábbiakat kell tartalmaznia:

  1. az adatvédelmi incidens jellegét;
  2. lehetőség szerint az érintettek kategóriáit és hozzávetőleges számát;
  3. az érintett személyesadat-állományok kategóriáit és hozzávetőleges mennyiségét;
  4. az adatvédelmi tisztviselő vagy más kapcsolattartó nevét és elérhetőségét;
  5. az incidens valószínűsíthető következményeit;
  6. az incidens kezelésére és következményeinek mérséklésére megtett vagy tervezett intézkedéseket.

GDPR 33. cikk (3) bekezdés.

A bejelentés legyen tényszerű

A bejelentésben világosan el kell különíteni:

  • a bizonyított tényeket;
  • a valószínű feltételezéseket;
  • a még vizsgálat alatt álló körülményeket;
  • a becsült adatokat;
  • a már végrehajtott és a csak tervezett intézkedéseket.

A bizonytalan adatot nem célszerű biztos tényként feltüntetni. Ugyanakkor az sem megfelelő, ha a szervezet minden lényeges kérdésre kizárólag azt válaszolja, hogy „vizsgálat alatt”, miközben már rendelkezésére állnak előzetes információk.


Mikor kell az érintetteket is tájékoztatni?

Ha az adatvédelmi incidens valószínűsíthetően magas kockázattal jár a természetes személyek jogaira és szabadságaira nézve, az adatkezelőnek indokolatlan késedelem nélkül tájékoztatnia kell az érintetteket. GDPR 34. cikk (1) bekezdés.

Az érintetti tájékoztatásra nem 72 órás határidő vonatkozik

A GDPR az érintettek esetében nem konkrét 72 órát, hanem indokolatlan késedelem nélküli kommunikációt követel meg.

Ha az érintettek azonnali intézkedéssel csökkenthetik a veszélyt – például jelszócserével, bankkártya letiltásával vagy csaló üzenetek felismerésével –, a gyors kommunikáció különösen indokolt.

Súlyos esetben nem célszerű megvárni a 72. órát az érintettek tájékoztatásával. Ha az érintett csak gyors figyelmeztetés alapján tudja megvédeni magát, a kommunikációt a szükséges alapinformációk rendelkezésre állásakor meg kell kezdeni.

Mit kell tartalmaznia az érintetti tájékoztatásnak?

A tájékoztatásnak világos és közérthető nyelven be kell mutatnia:

  • az incidens jellegét;
  • az adatvédelmi tisztviselő vagy más kapcsolattartó elérhetőségét;
  • az incidens valószínű következményeit;
  • a megtett vagy tervezett intézkedéseket;
  • a káros következmények mérséklését szolgáló lépéseket.

GDPR 34. cikk (2) bekezdés.

Gyakorlati tartalmi elemek

Az érintetti tájékoztatásban célszerű egyértelműen megadni:

  • pontosan milyen adatok érintettek;
  • mit nem érintett az incidens, ha ez biztosan megállapítható;
  • mikor történt az esemény;
  • mit tett a szervezet;
  • mit tegyen az érintett;
  • milyen gyanús jelekre figyeljen;
  • hol kérhet további segítséget;
  • várható-e újabb tájékoztatás.

Mikor nem kell külön értesíteni az érintettet?

Nem kötelező az egyedi tájékoztatás, ha:

  1. az adatokat olyan megfelelő védelmi intézkedés védte, amely azokat az illetéktelen személy számára értelmezhetetlenné tette, például megfelelő titkosítás;
  2. az adatkezelő későbbi intézkedése megszüntette a magas kockázat valószínűségét;
  3. az egyedi tájékoztatás aránytalan erőfeszítést igényelne, amely esetben nyilvános vagy hasonlóan hatékony közlést kell alkalmazni.

GDPR 34. cikk (3) bekezdés.

Az adat titkosítottsága csak akkor lehet érdemi kockázatcsökkentő tényező, ha a titkosítás ténylegesen megfelelő volt, és a visszafejtéshez szükséges kulcs vagy hitelesítési adat nem került veszélybe.


Minden adatvédelmi incidenst dokumentálni kell

Az adatkezelő köteles valamennyi adatvédelmi incidenst dokumentálni, beleértve az incidens tényeit, hatásait és a megtett helyreállító intézkedéseket. A dokumentációnak alkalmasnak kell lennie arra, hogy a felügyeleti hatóság ellenőrizhesse a GDPR 33. cikkének való megfelelést. GDPR 33. cikk (5) bekezdés.

Ez a kötelezettség azokra az esetekre is vonatkozik, amelyeket:

  • nem jelentettek be a NAIH-nak;
  • nem közöltek az érintettekkel;
  • alacsony kockázatúnak értékeltek;
  • rövid időn belül sikerült kezelni.

Az EDPB külön kiemeli, hogy a hatóságnak be nem jelentett incidensek esetében is rögzíteni kell legalább az esemény alapadatait, a kockázatértékelést, a hatásokat és a válaszintézkedéseket.

Mit tartalmazzon az incidensnyilvántartás?

Javasolt mezők:

  • egyedi incidensazonosító;
  • észlelés időpontja;
  • tudomásszerzés megállapított időpontja;
  • bejelentő személy és szervezeti egység;
  • incidens rövid leírása;
  • érintett rendszerek;
  • érintetti és adatkategóriák;
  • hozzávetőleges adatmennyiség és érintetti szám;
  • incidens típusa;
  • azonnali intézkedések;
  • valószínű következmények;
  • kockázatértékelés;
  • hatósági bejelentési döntés és annak indokolása;
  • érintetti tájékoztatási döntés és annak indokolása;
  • bejelentés időpontja és hivatkozási száma;
  • további vizsgálati eredmények;
  • helyesbítő és megelőző intézkedések;
  • felelősök és határidők;
  • lezárás és utóellenőrzés.

A puszta mondat, hogy „az incidens nem volt bejelentésköteles”, nem elegendő. A dokumentációból annak is ki kell derülnie, milyen tények és milyen kockázati szempontok alapján jutott erre a következtetésre az adatkezelő.


Gyakori incidensek és várható értékelési szempontjaik

Az alábbi példák nem automatikus minősítések. Azonos eseménytípus eltérő adatok, címzettek és következmények mellett más bejelentési eredményhez vezethet.

Téves címzettnek küldött e-mail

Vizsgálni kell:

  • milyen adatokat tartalmazott;
  • hány érintettre vonatkozott;
  • a címzett megnyitotta-e;
  • továbbította vagy lementette-e;
  • megbízható és titoktartásra kötelezett személy-e;
  • igazolhatóan törölte-e az adatokat.

Egy általános időpont-egyeztetés és egy egészségügyi dokumentum téves továbbítása nyilvánvalóan nem azonos kockázatú.

Elveszett vagy ellopott laptop

A kockázatot befolyásolja:

  • volt-e teljes lemeztitkosítás;
  • erős volt-e a hitelesítés;
  • távolról törölhető-e az eszköz;
  • milyen adatok voltak rajta;
  • tárolt-e bejelentkezési adatokat;
  • hozzáférhetett-e felhőszolgáltatásokhoz;
  • veszélybe került-e a titkosítási kulcs.

Zsarolóvírus

Vizsgálni kell:

  • történt-e adatkimásolás;
  • milyen adatokat titkosítottak;
  • rendelkezésre áll-e sértetlen mentés;
  • mennyi ideig voltak elérhetetlenek az adatok;
  • okozott-e ellátási, hatósági vagy szolgáltatási kiesést;
  • érintett-e különleges vagy kiszolgáltatott személyekre vonatkozó adatokat.

Az EDPB incidenspéldái külön foglalkoznak a zsarolóvírus-támadásokkal, az adatkinyeréssel, az elveszett eszközökkel és a tévesen továbbított dokumentumokkal. Az értékelés minden esetben a tényleges védelmi intézkedésekre és a lehetséges érintetti következményekre épül.

Nyilvánosan elérhetővé vált dokumentum

Vizsgálni kell:

  • mennyi ideig volt elérhető;
  • keresőmotor indexelte-e;
  • ismert-e a letöltések száma;
  • közvetlen link vagy nyilvános keresés útján volt hozzáférhető;
  • tartalmazott-e érzékeny adatokat;
  • megmaradhatott-e gyorsítótárban vagy archívumban.

Elérhetetlenné vált nyilvántartás

A kockázat annál nagyobb lehet, minél inkább függ az érintett jogainak, ellátásának vagy biztonságának biztosítása az adatok azonnali elérhetőségétől.

Egy marketinglista rövid kiesése és egy sürgősségi betegnyilvántartás elérhetetlensége nem azonos súlyú rendelkezésre állási incidens.


A leggyakoribb hibák az első 72 órában

1. A szervezet megvárja a teljes informatikai vizsgálatot

A hatósági bejelentéshez nem szükséges a végleges forenzikai jelentés. A GDPR lehetővé teszi a szakaszos bejelentést.

2. Nem rögzítik a tudomásszerzés időpontját

Ennek hiányában később nem bizonyítható, hogy a szervezet mikor és miért tekintette megkezdettnek a 72 órás határidőt.

3. Minden biztonsági eseményt automatikusan bejelentenek

A túlzott bejelentés nem helyettesíti a kockázatértékelést. Először meg kell állapítani, történt-e személyesadat-sérelem, és milyen kockázatot jelent az érintettek számára.

4. A be nem jelentett eseményt nem dokumentálják

Ez közvetlenül ellentétes a GDPR 33. cikk (5) bekezdésében meghatározott dokumentálási kötelezettséggel.

5. Az adatvédelmi tisztviselőt csak a végén értesítik

A késői bevonás csökkenti annak lehetőségét, hogy a kockázatértékelés, a bejelentés és az érintetti kommunikáció szakmailag megalapozott legyen.

6. Csak az informatikai kárt vizsgálják

Az adatvédelmi kockázat nem azonos a szervezet üzleti kárával. Lehetséges, hogy a szervezet gyorsan helyreállítja a rendszert, miközben az érintetteket továbbra is személyazonosság-lopás, csalás vagy más hátrány fenyegeti.

7. Nem vizsgálják az érintettek tájékoztatásának szükségességét

A NAIH bejelentése és az érintettek tájékoztatása két külön kötelezettség, eltérő kockázati küszöbbel.

8. Túl általános érintetti tájékoztatást küldenek

Az olyan közlés, hogy „biztonsági esemény történt, de mindent megteszünk”, nem segíti az érintettet saját védelmi intézkedéseinek megtételében.

9. A kommunikáció nincs összehangolva

Eltérő információ jelenik meg:

  • a NAIH-nak küldött bejelentésben;
  • az érintetti tájékoztatásban;
  • a sajtóközleményben;
  • az ügyfélszolgálati válaszokban;
  • a belső vezetői jelentésben.

Az egyes dokumentumok célja eltérhet, de a tényszerű alapadatoknak következetesnek kell lenniük.


Az incidens lezárása nem ér véget a bejelentéssel

A hatósági bejelentés után is folytatni kell:

  • a technikai kivizsgálást;
  • a károk korlátozását;
  • az érintetti kockázatok figyelését;
  • a bejelentés kiegészítését;
  • a kapcsolódó kérelmek kezelését;
  • a kiváltó okok feltárását;
  • a helyesbítő intézkedések végrehajtását.

Gyökérok-elemzés

Nem elegendő megállapítani, hogy „a munkatárs rossz címre küldte az e-mailt” vagy „feltörték a fiókot”.

Vizsgálni kell például:

  • miért volt lehetséges a téves továbbítás;
  • megfelelőek voltak-e a hozzáférések;
  • működött-e a többtényezős hitelesítés;
  • észlelte-e a rendszer a szokatlan belépést;
  • elegendő ideig álltak-e rendelkezésre naplók;
  • megfelelően választották-e ki a szolgáltatót;
  • ismerte-e a munkatárs a bejelentési folyamatot;
  • volt-e korábban hasonló esemény;
  • végrehajtották-e a korábbi intézkedéseket.

Helyesbítő intézkedési terv

Minden intézkedéshez célszerű rögzíteni:

  • a feladatot;
  • a felelőst;
  • a határidőt;
  • a szükséges erőforrást;
  • a végrehajtás bizonyítékát;
  • az utóellenőrzés módját.

A GDPR a megfelelő biztonsági intézkedések rendszeres tesztelését, értékelését és felülvizsgálatát is megköveteli. GDPR 32. cikk (1) bekezdés d) pont.


Hogyan lehet előre felkészülni a 72 órás határidőre?

Az incidenskezelést nem az esemény bekövetkezésekor kell először megtervezni.

1. Incidenskezelési szabályzat és eljárás

A dokumentumnak legalább meg kell határoznia:

  • mi minősül bejelentendő eseménynek;
  • milyen csatornán kell jelezni;
  • ki fogadja a jelzést;
  • ki vezeti a kivizsgálást;
  • ki készíti a kockázatértékelést;
  • ki jogosult a NAIH-bejelentés jóváhagyására;
  • ki kommunikál az érintettekkel.

2. Elérhető incidensbejelentési csatorna

Például:

  • külön e-mail-cím;
  • telefonszám;
  • belső hibajegy;
  • szolgáltatói sürgősségi elérhetőség.

Ennek munkaidőn kívül is működőképesnek kell lennie, ha a szervezet működési kockázatai ezt indokolják.

3. Felelősségi mátrix

Előre tisztázni kell a vezetés, az informatika, az EIBF, az adatvédelmi tisztviselő, a HR, a jogi terület és a kommunikáció feladatait.

4. NAIH-bejelentési sablon

A szervezet előre kialakíthatja a szükséges adatmezőket, hogy incidens esetén ne a határidő alatt kelljen eldönteni, milyen információkat kell összegyűjteni.

5. Érintetti tájékoztató sablon

A sablon tartalmazhatja az alapstruktúrát, de az egyedi eseményre kell szabni. Előre elkészíthető több kommunikációs csatornára:

  • e-mail;
  • postai levél;
  • weboldali közlemény;
  • telefonos ügyfélszolgálati forgatókönyv.

6. Adatfeldolgozói incidensfeltételek

Minden jelentős adatfeldolgozói szerződésnek világosan rendeznie kell az értesítést, az együttműködést, a bizonyítékok átadását és a vizsgálathoz szükséges információkat.

7. Naplózás és bizonyítékmegőrzés

A naplókat úgy kell kialakítani és megőrizni, hogy azokból utólag rekonstruálható legyen:

  • ki;
  • mikor;
  • melyik rendszerhez;
  • milyen fiókkal;
  • milyen adatokat ért el vagy módosított.

A megfelelő naplózás és a naplók jogosulatlan módosítással vagy törléssel szembeni védelme alapvető az incidensek felismeréséhez és kivizsgálásához.

8. Incidensgyakorlat

Egy asztali gyakorlat során szimulálható például:

  • zsarolóvírus-támadás;
  • téves adattovábbítás;
  • ellopott laptop;
  • kompromittált Microsoft 365-fiók;
  • nyilvánossá vált dokumentumtár;
  • adatfeldolgozói incidens.

A gyakorlat célja nem annak bizonyítása, hogy mindenki ismeri a szabályzatot, hanem annak feltárása, hogy a tényleges döntési, információs és kommunikációs útvonalak működnek-e.


Gyakori kérdések

Minden adatvédelmi incidenst be kell jelenteni a NAIH-nak?

Nem. A hatósági bejelentés akkor kötelező, ha az incidens valószínűsíthetően kockázattal jár az érintettek jogaira és szabadságaira nézve. A be nem jelentett incidenseket is dokumentálni kell.

Mikor indul a 72 órás határidő?

Akkor, amikor az adatkezelő észszerű mértékű bizonyossággal tudomást szerez arról, hogy személyes adatokat érintő biztonsági esemény történt.

Megvárható a teljes informatikai jelentés?

Nem, ha a bejelentési határidő közben lejárna. A rendelkezésre álló információk alapján előzetes bejelentést kell tenni, amely később szakaszosan kiegészíthető.

Az adatfeldolgozónak is 72 órája van?

Nem. Az adatfeldolgozó az incidensről való tudomásszerzést követően indokolatlan késedelem nélkül köteles értesíteni az adatkezelőt. A 72 órás hatósági kötelezettség főszabály szerint az adatkezelőt terheli.

Az érintetteket is 72 órán belül kell tájékoztatni?

A GDPR erre nem 72 órás határidőt állapít meg. Magas kockázat esetén az érintetteket indokolatlan késedelem nélkül kell tájékoztatni. Ez egyes helyzetekben a hatósági bejelentésnél is gyorsabb kommunikációt tehet szükségessé.

Elveszett egy titkosított laptop. Ez automatikusan nem bejelentendő?

Nem automatikusan. Vizsgálni kell a titkosítás megfelelőségét, a kulcsok védelmét, a hitelesítést, a távoli hozzáférést és az eszközön tárolt adatokat. A megfelelően titkosított és más módon is védett adat esetében a kockázat jelentősen csökkenhet.

Zsarolóvírus történt, de van mentés. Ez nem adatvédelmi incidens?

A mentés csökkentheti a rendelkezésre állási kockázatot, de nem zárja ki az incidenst. Vizsgálni kell, hogy az adatok mennyi ideig voltak elérhetetlenek, sérültek-e, illetve történt-e jogosulatlan hozzáférés vagy adatkinyerés.

Elég rendőrségi feljelentést tenni?

Nem. A büntetőeljárási vagy kiberbiztonsági bejelentés nem helyettesíti a GDPR 33. cikke szerinti felügyeleti hatósági bejelentést. Minden alkalmazandó bejelentési kötelezettséget külön kell értékelni.

Mi történik, ha kicsúszunk a 72 órából?

A bejelentést ettől még meg kell tenni, és mellékelni kell a késedelem indokait. A késedelmet nem szabad további halasztással növelni.


Miért jelent súlyos kockázatot a rosszul kezelt incidens?

A GDPR 32–34. cikke szerinti adatbiztonsági és incidenskezelési kötelezettségek megsértése legfeljebb 10 millió euró, vállalkozás esetén pedig az előző pénzügyi év teljes világpiaci éves forgalmának legfeljebb 2%-a szerinti bírságkategóriába tartozik, a kettő közül a magasabb összeg figyelembevételével. GDPR 83. cikk (4) bekezdés.

A konkrét jogkövetkezmény megállapításakor a hatóság figyelembe veszi többek között:

  • a jogsértés jellegét és súlyát;
  • az érintettek számát és az elszenvedett kárt;
  • a szándékos vagy gondatlan jelleget;
  • a kárenyhítő intézkedéseket;
  • a szervezet felelősségének mértékét;
  • az együttműködést;
  • az érintett adatok kategóriáit;
  • valamint azt, hogy a szervezet bejelentette-e az incidenst.

GDPR 83. cikk (2) bekezdés.

Egy incidens bekövetkezése önmagában nem feltétlenül jelenti azt, hogy a szervezet megsértette a GDPR-t. Az azonban már önálló megfelelési probléma lehet, ha a szervezet:

  • nem észleli időben az eseményt;
  • nem vizsgálja ki;
  • nem dokumentálja;
  • elmulasztja a szükséges bejelentést;
  • nem tájékoztatja a veszélyeztetett érintetteket;
  • vagy nem hajt végre megfelelő helyesbítő intézkedéseket.

Külön megjegyzés az Infotv. hatálya alá tartozó incidensekről

Ez a cikk elsősorban a GDPR hatálya alá tartozó adatkezelésekre vonatkozik.

A bűnüldözési, honvédelmi és nemzetbiztonsági célú adatkezelések egyes eseteire az Infotv. külön incidenskezelési szabályai alkalmazandók. A NAIH ezekhez elkülönített tájékoztatást biztosít, ezért a megfelelő jogi rezsimet az adatkezelés célja és jogalapja alapján kell meghatározni.


Összefoglalás

A GDPR az adatkezelőtől nemcsak azt követeli meg, hogy 72 órán belül szükség esetén bejelentést tegyen, hanem azt is, hogy valamennyi incidenst dokumentáljon, értékelje az érintetti kockázatokat, és magas kockázat esetén indokolatlan késedelem nélkül tájékoztassa az érintetteket.

Az első 72 órában a szervezetnek:

  1. meg kell állítania vagy korlátoznia kell az incidenst;
  2. meg kell őriznie a bizonyítékokat;
  3. rögzítenie kell a tudomásszerzés időpontját;
  4. fel kell tárnia az érintett adatokat és személyeket;
  5. értékelnie kell a kockázatot;
  6. döntenie kell a NAIH-bejelentésről;
  7. magas kockázat esetén tájékoztatnia kell az érintetteket;
  8. dokumentálnia kell a döntéseket és intézkedéseket;
  9. folytatnia kell a kivizsgálást és a helyesbítő intézkedéseket.

 

A helyes megközelítés ezért nem az, hogy: „Van még 72 óránk.”

Hanem az, hogy: „Az incidenskezelés már megkezdődött, és minden órával pontosabbá tesszük a kockázatértékelést és a szükséges intézkedéseket.”

Utolsó szakmai felülvizsgálat: 2026. július