Aktuális helyzet: PHP2Shell. Két kritikus PHP-rés (CVSS 9,2) lehetővé teszi kártékony kód futtatását bejelentkezés nélkül. Javítások 2026. 10. 21. óta.Mi a teendő most →

GDPR-bejelentési kötelezettség: 72 óra az incidens után

Egy webszerver elleni támadás után fennállhat a felügyeleti hatóság felé a bejelentési kötelezettség. Itt általánosan olvashat arról, mikor indul a 72 óra, és mi tartozik hozzá.

Állapot 4 perc olvasási időJog és megfelelés

Röviden: Ha egy támadás során sérül a személyes adatok védelme, a GDPR 33. cikke bejelentést kíván a felügyeleti hatóság felé, lehetőleg a tudomásszerzéstől számított 72 órán belül, amennyiben kockázat áll fenn az érintettekre nézve. Magas kockázat esetén a 34. cikk szerint az érintettek értesítése is hozzájön. Ettől függetlenül minden incidenst dokumentálnia kell. Ez az oldal általános tájékoztatás, nem jogi tanácsadás.

Fontos

Nem jogi tanácsadás: hogy az egyedi esetben fennáll-e bejelentési kötelezettség és mikor, azt az adatvédelmi tisztviselője vagy egy ügyvéd értékeli. Mi a műszaki tényeket szolgáltatjuk, amelyekre ez az értékelés támaszkodik.

Adatvédelmi incidens és bejelentési kötelezettség 72 órán belül: mit szabályoz a 33. cikk

A GDPR 33. cikke a „személyes adatok védelmének megsértésére” vonatkozik. Ez minden olyan biztonsági incidenst jelent, amely személyes adatok megsemmisüléséhez, elvesztéséhez, megváltoztatásához, jogosulatlan közléséhez vagy az azokhoz való jogosulatlan hozzáféréshez vezet. Egy kompromittált webszerver ügyféladatbázissal, kapcsolatfelvételi űrlapokkal vagy álláspályázók adataival ide tartozhat.

A bejelentést a felügyeleti hatóság felé indokolatlan késedelem nélkül, lehetőleg az incidensről való tudomásszerzéstől számított 72 órán belül kell megtenni. Elmarad, 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. Aki 72 óránál később jelent be, annak indokolnia kell a késedelmet. Az információk szakaszosan pótolhatók.

Mit tartalmazzon a bejelentés

A GDPR 33. cikkének (3) bekezdése minimális tartalmat nevez meg. Ezeket a pontokat készítse elő, akkor is, ha még nem áll fenn minden:

  • az incidens jellege, lehetőleg az érintett személyek és adatrekordok kategóriáival és hozzávetőleges számával
  • az adatvédelmi tisztviselő vagy egy másik kapcsolattartó neve és elérhetőségei
  • az incidens valószínű következményei
  • az orvoslására és a lehetséges hátrányos következmények enyhítésére megtett vagy javasolt intézkedések

Különösen a webszerverek elleni támadásoknál az terjedelem eleinte gyakran tisztázatlan. Ilyenkor egy őszinte első bejelentés segít az ismert állapottal, és azzal a közléssel, hogy a további megállapításokat pótolni fogja.

Mikor kezdődik a határidő egy szerver elleni támadás után?

A határidő a tudomásszerzéshez kötődik, nem a támadás időpontjához. A gyakorlatban az elhatárolás gyakran nehéz: egy olyan biztonsági résről szóló hír, mint a PHP2Shell, önmagában még nem alapoz meg tudomást adatvédelmi incidensről. Ha viszont konkrét jeleket talál betörésre, például egy webshellt vagy gyanús adatbázis-lekérdezéseket, a helyzet másképp nézhet ki.

Ezért kezdettől fogva dokumentálja időponttal, ki mikor milyen információt kapott, és milyen lépések követték. Ez az idővonal segít a jogi értékelésben és a hatóság kérdéseinél. Gondos műszaki vizsgálat, például IT-forenzikával, tisztázza, hogy ténylegesen érintettek-e adatok, és melyek.

Az érintettek értesítése a 34. cikk szerint

Ha az incidens valószínűsíthetően magas kockázattal jár a személyes jogokra és szabadságokra nézve, az érintett személyeket is indokolatlan késedelem nélkül értesíteni kell. Ez lehet például hozzáférési adatoknál, bankszámlaadatoknál vagy egészségügyi adatoknál. Az értesítésnek világos és egyszerű nyelven kell leírnia, mi történt, és legalább meg kell neveznie a kapcsolattartó pontot, a valószínű következményeket és a megtett intézkedéseket.

A 34. cikk kivételeket ír elő, például ha az adatokat az illetéktelenek számára hozzáférhetetlenné tették, például titkosítással. Ha minden egyes személy értesítése aránytalan ráfordítással járna, helyette nyilvános közzététel vagy hasonlóan hatékony intézkedés jöhet szóba. Hogy fennáll-e kivétel, az a jogi értékeléshez tartozik. Hogyan tájékoztathatja érthetően az ügyfeleket, azt a Kríziskommunikáció egy támadás után írja le.

Dokumentációs kötelezettség a 33. cikk (5) bekezdése szerint

A bejelentési kötelezettségtől függetlenül a GDPR 33. cikkének (5) bekezdése előírja minden incidens dokumentálását: a tényeket, a hatásokat és a megtett orvoslási intézkedéseket. Ennek a dokumentációnak lehetővé kell tennie a felügyeleti hatóság számára az ellenőrzést. Ez akkor is érvényes, ha vizsgálat után arra jut, hogy bejelentés nem szükséges.

Webszervereknél ez a gyakorlatban azt jelenti: a naplókat el kell menteni, mielőtt rotálják őket, a leleteket időponttal rögzíteni kell, a döntéseket és indokaikat fel kell jegyezni. A PHP2Shellnél a szakmai sajtó azt javasolja, hogy a szervernaplókat 2026. október 20-tól őrizzék meg. A javítás emellett nem távolítja el a már bejuttatott kártevőt, és nem bizonyítja, hogy korábban nem történt semmi.

A gyakorlati menet az első órákban

  1. A gyanút belsőleg jelenteni egy kijelölt helyen, és bevonni az adatvédelmi tisztviselőt.
  2. Bizonyítékokat menteni: naplókat, fájllistákat, adatbázis-kivonatokat, mielőtt bármit törölnek vagy újratelepítenek.
  3. Műszakilag tisztázni, hogy érintettek lehetnek-e személyes adatok.
  4. A bejelentési és értesítési kötelezettség jogi értékelése, adott esetben ügyvéddel és biztosítóval.
  5. Bejelentés az illetékes felügyeleti hatóság űrlapján, pótlások új megállapításoknál.

Egy előkészített IT-vészhelyzeti terv jelentősen lerövidíti ezeket a lépéseket.

Hogyan segít konkrétan a PHP SOS?

  • A naplókat és a rendszerállapotokat úgy mentjük, hogy az értékeléshez és egy későbbi vizsgálathoz felhasználhatók maradjanak.
  • Műszakilag tisztázzuk, hogy elérhetők voltak-e adatok, és melyek, és érthető összefoglalót adunk az adatvédelmi tisztviselőknek és ügyvédeknek.
  • Vezetünk egy idővonalat a műszaki megállapításokról, amelyet a bejelentéshez és a dokumentációhoz felhasználhat.
  • Megerősített betörés esetén átvesszük az Incident Response és a tisztítás feladatát.

Gyakori kérdések

Mikortól számít a 72 óra?

A GDPR 33. cikke szerint attól az időponttól, amikor az adatkezelő tudomást szerzett az incidensről. Hogy ez az egyedi esetben mikorra tehető, jogi értékelés kérdése. Ezért pontosan dokumentálja, ki mikor milyen információval rendelkezett.

Minden biztonsági rést be kell jelenteni?

Nem. Egy rés önmagában még nem jelenti a személyes adatok védelmének megsértését. Bejelentési kötelezettség akkor merülhet fel, ha vannak jelek arra, hogy illetéktelenek hozzáfértek vagy hozzáférhettek ilyen adatokhoz, és ebből kockázat származik az érintettekre nézve.

Mi van, ha 72 óra után még nem tudok mindent?

A GDPR 33. cikkének (4) bekezdése megengedi, hogy az információkat szakaszosan pótolják, ha nem lehet őket egyszerre rendelkezésre bocsátani. A késedelmes bejelentést indokolni kell. A teljes tisztázásra várás ezért általában nem ok arra, hogy a határidő elteljen.

Ki jelent be, ha a tárhelyszolgáltató volt érintett?

Bejelentésre az adatkezelő köteles, vagyis általában a weboldalt üzemeltető vállalkozás. Az adatfeldolgozó, például a tárhelyszolgáltató a GDPR 33. cikkének (2) bekezdése szerint indokolatlan késedelem nélkül köteles tájékoztatni az adatkezelőt.

Hol jelentem be az adatvédelmi incidenst?

Az illetékes adatvédelmi felügyeleti hatóságnál; Németországban a vállalkozások számára ez többnyire a székhelyük szerinti szövetségi tartomány hatósága. A legtöbb hatóság online űrlapot kínál erre.

Források

Azonnali kapcsolat

Minden óra számít. Írjon nekünk most.

Ismertesse röviden a rendszert, a PHP-verziót és a megfigyelését. Jelentkezünk, tisztázzuk a helyzetet, és távolról dolgozunk, amíg az incidens le nem zárul és dokumentálva nem lesz.

Azonnali segítség