# Obveza prijave prema GDPR-u: 72 sata nakon incidenta > Povreda podataka i obveza prijave u roku od 72 sata: što čl. 33. i 34. GDPR-a zahtijevaju nakon napada na poslužitelj i što sada trebate dokumentirati. Izvor: https://phpsos.de/hr/compliance/dsgvo-meldepflicht-72-stunden/ Stanje: 25.10.2026 Pružatelj: PHP SOS, PHP hitna pomoć i sigurnost poslužitelja. Hitna pomoć putem WhatsAppa: https://wa.me/491736494914?text=Pozdrav%20PHP%20SOS%2C%20trebamo%20pomo%C4%87%20s%20na%C5%A1im%20PHP%20poslu%C5%BEiteljem.%20Tvrtka%3A%20%E2%80%A6%20Web-stranica%3A%20%E2%80%A6 **Ukratko:** Ako se pri napadu povrijedi zaštita osobnih podataka, čl. 33. GDPR-a zahtijeva prijavu nadzornom tijelu, ako je moguće u roku od 72 sata od saznanja, pod uvjetom da postoji rizik za ispitanike. Kod visokog rizika prema čl. 34. dolazi i obavještavanje ispitanika. Neovisno o tome svaku povredu morate dokumentirati. Ova stranica je opća informacija, a ne pravni savjet. > **Važno:** > Nije pravni savjet: postoji li u pojedinačnom slučaju obveza prijave i od kada, procjenjuju Vaš službenik za zaštitu podataka ili odvjetnica. Mi isporučujemo tehničke činjenice na kojima se ta procjena temelji. ## Povreda podataka i obveza prijave u 72 sata: što uređuje čl. 33. Čl. 33. GDPR-a odnosi se na „povredu osobnih podataka“. Misli se na svaku povredu sigurnosti koja dovodi do uništenja, gubitka, izmjene, neovlaštenog otkrivanja ili neovlaštenog pristupa osobnim podacima. Kompromitirani web-poslužitelj s bazom podataka korisnika, kontaktnim obrascima ili podacima o kandidatima za posao može spadati ovamo. Prijava nadzornom tijelu treba se podnijeti bez nepotrebne odgode i, ako je moguće, u roku od 72 sata nakon što je voditelj obrade saznao za povredu. Otpada ako povreda vjerojatno neće dovesti do rizika za prava i slobode pojedinaca. Tko prijavi kasnije od 72 sata, mora obrazložiti zakašnjenje. Informacije se smiju dostavljati postupno. ## Što prijava treba sadržavati Čl. 33. st. 3. GDPR-a navodi minimalni sadržaj. Te točke trebali biste pripremiti čak i ako još nije sve utvrđeno: - vrsta povrede, ako je moguće s kategorijama i približnim brojem ispitanika i evidencija podataka - ime i kontaktni podaci službenika za zaštitu podataka ili druge kontaktne točke - vjerojatne posljedice povrede - poduzete ili predložene mjere za otklanjanje i ublažavanje mogućih štetnih posljedica Upravo kod napada na web-poslužitelje opseg je na početku često nejasan. Tada pomaže iskrena prva prijava s poznatim stanjem i najavom da će se daljnji nalazi naknadno dostaviti. ## Kada rok teče nakon napada na poslužitelj? Rok se veže uz saznanje, a ne uz trenutak napada. U praksi je razgraničenje često teško: obavijest o ranjivosti poput PHP2Shella sama po sebi još ne utemeljuje saznanje o povredi zaštite podataka. Ali ako pronađete konkretne naznake provale, primjerice web-shell ili sumnjive upite u bazu podataka, situacija može izgledati drukčije. Zato od početka dokumentirajte s vremenom tko je kada dobio koju informaciju i koji su koraci uslijedili. Taj vremenski slijed pomaže pri pravnoj procjeni i pri upitima tijela. Pažljiva tehnička istraga, primjerice putem [IT forenzike](https://phpsos.de/hr/leistungen/it-forensik/), razjašnjava jesu li i koji podaci stvarno pogođeni. ## Obavještavanje ispitanika prema čl. 34. Ako povreda vjerojatno ima visok rizik za osobna prava i slobode, bez odgode se moraju obavijestiti i pogođene osobe. To može biti slučaj kod pristupnih podataka, bankovnih podataka ili zdravstvenih podataka. Obavijest treba jasnim i jednostavnim jezikom opisati što se dogodilo i navesti barem kontaktnu točku, vjerojatne posljedice i poduzete mjere. Čl. 34. predviđa iznimke, primjerice ako su podaci neovlaštenim osobama učinjeni nedostupnima, na primjer šifriranjem. Ako bi obavještavanje svake pojedine osobe zahtijevalo nerazmjeran napor, umjesto toga može se razmotriti javna objava ili jednako djelotvorna mjera. Primjenjuje li se iznimka, dio je pravne procjene. Kako klijente razumljivo informirati, opisuje članak [Krizna komunikacija nakon napada](https://phpsos.de/hr/compliance/krisenkommunikation/). ## Obveza dokumentiranja prema čl. 33. st. 5. Neovisno o obvezi prijave, čl. 33. st. 5. GDPR-a zahtijeva da se svaka povreda dokumentira: činjenice, učinci i poduzete korektivne mjere. Ta dokumentacija mora nadzornom tijelu omogućiti provjeru. To vrijedi i ako nakon provjere zaključite da prijava nije potrebna. Za web-poslužitelje to praktično znači: osigurati zapisnike prije nego što se rotiraju, nalaze zabilježiti s vremenom, odluke i njihovo obrazloženje zapisati. Kod PHP2Shella stručni tisak preporučuje čuvanje zapisnika poslužitelja od 20. 10. 2026. Zakrpa osim toga ne uklanja već ubačen zlonamjerni softver i ne dokazuje da se prije nije ništa dogodilo. ## Praktičan tijek u prvim satima 1. Sumnju interno prijaviti određenoj službi i uključiti službenika za zaštitu podataka. 2. Osigurati dokaze: zapisnike, popise datoteka, izvatke iz baze podataka, prije nego što se nešto izbriše ili postavi iznova. 3. Tehnički razjasniti mogu li biti pogođeni osobni podaci. 4. Pravna procjena obveze prijave i obavještavanja, po potrebi s odvjetnikom i osiguravateljem. 5. Prijava putem obrasca nadležnog nadzornog tijela, dopune pri novim saznanjima. Pripremljen [IT plan za hitne slučajeve](https://phpsos.de/hr/compliance/notfallplan-erstellen/) znatno skraćuje te korake. ## Kako PHP SOS konkretno pomaže? - Osiguravamo zapisnike i stanja sustava tako da ostanu upotrebljivi za procjenu i kasniju provjeru. - Tehnički razjašnjavamo jesu li i koji podaci bili dostupni te isporučujemo razumljiv sažetak za službenike za zaštitu podataka i odvjetnike. - Vodimo vremenski slijed tehničkih saznanja koji možete koristiti za prijavu i dokumentaciju. - Kod potvrđene provale preuzimamo [odgovor na incidente](https://phpsos.de/hr/leistungen/incident-response/) i čišćenje. ## Česta pitanja **Od kada teče 72 sata?** Prema čl. 33. GDPR-a od trenutka kada je voditelj obrade saznao za povredu. Kada se to u pojedinačnom slučaju može pretpostaviti, pravna je procjena. Zato točno dokumentirajte tko je i kada raspolagao kojom informacijom. **Mora li se svaka sigurnosna ranjivost prijaviti?** Ne. Ranjivost sama po sebi još nije povreda zaštite osobnih podataka. Prijava može postati obvezna ako postoje naznake da su neovlaštene osobe imale ili mogle imati pristup takvim podacima i iz toga proizlazi rizik za ispitanike. **Što ako nakon 72 sata još ne znam sve?** Čl. 33. st. 4. GDPR-a dopušta postupno naknadno dostavljanje informacija ako se ne mogu pružiti istodobno. Zakašnjela prijava mora se obrazložiti. Čekanje potpune jasnoće stoga u pravilu nije razlog da se rok propusti. **Tko prijavljuje ako je pogođen pružatelj hostinga?** Obvezu prijave ima voditelj obrade, dakle u pravilu tvrtka koja vodi web-stranicu. Izvršitelj obrade poput pružatelja hostinga mora prema čl. 33. st. 2. GDPR-a bez odgode obavijestiti voditelja obrade. **Gdje prijavljujem povredu podataka?** Nadležnom nadzornom tijelu za zaštitu podataka. Većina tijela za to nudi online obrasce. ## Izvori - [GDPR čl. 33](https://dsgvo-gesetz.de/art-33-dsgvo/) - [BSI](https://www.bsi.bund.de/) - [php.net: sigurnosne objave](https://www.php.net/)