Trenutno stanje: PHP2Shell. Dve kritični ranljivosti PHP (CVSS 9,2) omogočata izvedbo škodljive kode brez prijave. Popravki od 21. 10. 2026.Kaj je zdaj treba storiti →

Obveznost prijave po GDPR: 72 ur po incidentu

Po napadu na spletni strežnik lahko obstaja obveznost prijave nadzornemu organu. Tu je splošno pojasnjeno, kdaj teče 72 ur in kaj sodi zraven.

Stanje 4 min branjaPravo in skladnost

Na kratko: Če je ob napadu kršeno varstvo osebnih podatkov, 33. člen GDPR zahteva prijavo nadzornemu organu, če je mogoče v 72 urah od seznanitve, če za posameznike obstaja tveganje. Pri visokem tveganju se po 34. členu pridruži obveščanje prizadetih. Ne glede na to morate dokumentirati vsako kršitev. Ta stran je splošna informacija in ne pravno svetovanje.

Pomembno

Ni pravno svetovanje: ali in kdaj v posameznem primeru obstaja obveznost prijave, ocenita vaš pooblaščenec za varstvo podatkov ali odvetnica. Mi zagotovimo tehnična dejstva, na katera se ta presoja opira.

Kršitev varstva podatkov in prijava v 72 urah: kaj ureja 33. člen

  1. člen GDPR se nanaša na „kršitev varstva osebnih podatkov“. Mišljena je vsaka varnostna kršitev, ki vodi do uničenja, izgube, spremembe, nepooblaščenega razkritja ali nepooblaščenega dostopa do osebnih podatkov. Kompromitiran spletni strežnik z bazo strank, kontaktnimi obrazci ali podatki kandidatov lahko spada sem.

Prijava nadzornemu organu naj bo opravljena nemudoma in če je mogoče v 72 urah po tem, ko je upravljavec za kršitev izvedel. Odpade, če kršitev verjetno ne povzroči tveganja za pravice in svoboščine posameznikov. Kdor prijavi pozneje kot po 72 urah, mora zamudo utemeljiti. Informacije se lahko posredujejo postopoma.

Kaj naj prijava vsebuje

  1. odstavek 33. člena GDPR navaja minimalno vsebino. Te točke pripravite, tudi če vsega še ni mogoče opredeliti:
  • vrsta kršitve, po možnosti s kategorijami in približnim številom prizadetih posameznikov in zapisov
  • ime in kontaktni podatki pooblaščenca za varstvo podatkov ali druge kontaktne točke
  • verjetne posledice kršitve
  • sprejeti ali predlagani ukrepi za odpravo in za omilitev morebitnih škodljivih posledic

Prav pri napadih na spletne strežnike je obseg na začetku pogosto nejasen. Takrat pomaga iskrena prva prijava z znanim stanjem in napovedjo, da boste nadaljnje ugotovitve posredovali naknadno.

Kdaj po napadu na strežnik začne teči rok?

Rok je vezan na seznanitev, ne na čas napada. V praksi je razmejitev pogosto težka: obvestilo o varnostni ranljivosti, kot je PHP2Shell, samo po sebi še ne utemeljuje seznanitve s kršitvijo varstva podatkov. Če pa najdete konkretne znake vloma, na primer spletno lupino (webshell) ali sumljive poizvedbe v zbirki podatkov, je lahko stanje drugačno.

Zato od začetka z uro dokumentirajte, kdo je kdaj prejel katero informacijo in kateri koraki so sledili. Ta časovnica pomaga pri pravni presoji in pri vprašanjih organa. Skrbna tehnična preiskava, na primer prek digitalne forenzike IT, pojasni, ali in kateri podatki so bili dejansko prizadeti.

Obveščanje prizadetih po 34. členu

Če kršitev verjetno povzroči visoko tveganje za osebne pravice in svoboščine, je treba nemudoma obvestiti tudi prizadete posameznike. To je lahko primer pri dostopnih podatkih, bančnih povezavah ali zdravstvenih podatkih. Obvestilo naj v jasnem in preprostem jeziku opiše, kaj se je zgodilo, in navede vsaj kontaktno točko, verjetne posledice in sprejete ukrepe.

  1. člen predvideva izjeme, na primer če so bili podatki nepooblaščenim onemogočeni dostopni, denimo s šifriranjem. Če bi bilo obveščanje vsakega posameznika nesorazmerno zahtevno, pride namesto tega v poštev javno obvestilo ali enako učinkovit ukrep. Ali izjema velja, sodi k pravni presoji. Kako stranke razumljivo obvestiti, opisuje stran Krizno komuniciranje po napadu.

Dolžnost dokumentiranja po 5. odstavku 33. člena

Ne glede na obveznost prijave 5. odstavek 33. člena GDPR zahteva, da dokumentirate vsako kršitev: dejstva, učinke in sprejete popravljalne ukrepe. Ta dokumentacija mora nadzornemu organu omogočati preverjanje. To velja tudi, če po preverjanju ugotovite, da prijava ni potrebna.

Za spletne strežnike to praktično pomeni: zavarujte dnevnike, preden se zavrtijo, najdbe zabeležite s časom, odločitve in njihove razloge zapišite. Pri PHP2Shell strokovni tisk priporoča hranjenje dnevnikov strežnika od 20. 10. 2026 naprej. Popravek poleg tega ne odstrani že vnesene škodljive programske opreme in ne dokazuje, da se prej ni zgodilo nič.

Praktičen potek v prvih urah

  1. Sum notranje sporočite stalni kontaktni točki in vključite pooblaščenca za varstvo podatkov.
  2. Zavarujte dokaze: dnevnike, sezname datotek, izvlečke zbirke podatkov, preden se kar koli izbriše ali postavi znova.
  3. Tehnično razjasnite, ali bi lahko bili prizadeti osebni podatki.
  4. Pravna presoja obveznosti prijave in obveščanja, po potrebi z odvetnikom in zavarovalnico.
  5. Prijava prek obrazca pristojnega nadzornega organa, dopolnitve ob novih ugotovitvah.

Pripravljen načrt ukrepanja ob IT-incidentu te korake bistveno skrajša.

Kako PHP SOS konkretno pomaga?

  • Dnevnike in sistemska stanja zavarujemo tako, da ostanejo uporabni za presojo in poznejše preverjanje.
  • Tehnično pojasnimo, ali in kateri podatki so bili dosegljivi, ter pripravimo razumljiv povzetek za pooblaščence za varstvo podatkov in odvetnike.
  • Vodimo časovnico tehničnih ugotovitev, ki jo lahko uporabite za prijavo in dokumentacijo.
  • Ob potrjenem vlomu prevzamemo Incident Response in čiščenje.

Pogosta vprašanja

Od kdaj teče 72 ur?

Po 33. členu GDPR od trenutka, ko je upravljavec izvedel za kršitev. Kdaj je to v posameznem primeru treba šteti, je pravna presoja. Zato natančno dokumentirajte, kdaj je kdo imel katero informacijo.

Ali je treba prijaviti vsako varnostno ranljivost?

Ne. Ranljivost sama še ni kršitev varstva osebnih podatkov. Prijava lahko postane obvezna, če obstajajo znaki, da so nepooblaščeni imeli ali bi lahko imeli dostop do takih podatkov in iz tega nastane tveganje za posameznike.

Kaj, če po 72 urah še ne vem vsega?

4. odstavek 33. člena GDPR dovoljuje, da se informacije posredujejo postopoma, če jih ni mogoče zagotoviti hkrati. Zamudo pri prijavi je treba utemeljiti. Čakanje na popolno jasnost zato praviloma ni razlog, da bi rok pustili poteči.

Kdo prijavi, če je bil prizadet ponudnik gostovanja?

Prijavo mora podati upravljavec, torej praviloma podjetje, ki upravlja spletno stran. Obdelovalec, kot je ponudnik gostovanja, mora upravljavca po 2. odstavku 33. člena GDPR nemudoma obvestiti.

Kam prijavim kršitev varstva podatkov?

Pristojnemu nadzornemu organu za varstvo podatkov, v Sloveniji je to Informacijski pooblaščenec. Večina organov za to ponuja spletne obrazce.

Viri

Takojšnji stik

Vsaka ura šteje. Pišite nam zdaj.

Na kratko opišite sistem, različico PHP in opažanje. Odzovemo se, razjasnimo stanje in delamo na daljavo, dokler incident ni zaključen in dokumentiran.

Takojšnja pomoč