Накратко: Ако при атака бъде нарушена сигурността на личните данни, чл. 33 от ОРЗД изисква уведомление до надзорния орган, по възможност в рамките на 72 часа от узнаването, ако съществува риск за засегнатите лица. При висок риск по чл. 34 се добавя уведомяването на засегнатите лица. Независимо от това всяко нарушение трябва да се документира. Тази страница е обща информация и не представлява правен съвет.
Не е правен съвет: дали и кога в конкретния случай съществува задължение за уведомяване, преценява Вашето длъжностно лице по защита на данните или адвокат. Ние предоставяме техническите факти, върху които се основава тази преценка.
Нарушение на данните и срок за уведомяване от 72 часа: какво урежда чл. 33
Чл. 33 от ОРЗД се отнася до „нарушение на сигурността на личните данни“. Има се предвид всяко нарушение на сигурността, което води до унищожаване, загуба, промяна, неразрешено разкриване или неразрешен достъп до лични данни. Компрометиран уеб сървър с клиентска база данни, контактни формуляри или данни на кандидати може да попадне тук.
Уведомлението до надзорния орган трябва да се направи без ненужно забавяне и по възможност в рамките на 72 часа след като администраторът е узнал за нарушението. То отпада, ако нарушението вероятно не води до риск за правата и свободите на физическите лица. Който уведоми по-късно от 72 часа, трябва да обоснове забавянето. Информацията може да се допълва поетапно.
Какво трябва да съдържа уведомлението
Чл. 33, пар. 3 от ОРЗД посочва минимално съдържание. Подгответе тези точки, дори да не е известно още всичко:
- естество на нарушението, по възможност с категории и приблизителен брой на засегнатите лица и записи
- име и данни за контакт на длъжностното лице по защита на данните или на друго звено за контакт
- вероятни последици от нарушението
- предприети или предложени мерки за отстраняване и за смекчаване на евентуалните неблагоприятни последици
Именно при атаки срещу уеб сървъри обхватът в началото често е неясен. Тогава помага честно първоначално уведомление с известното състояние и обявяване, че допълнителните констатации ще бъдат предоставени по-късно.
Кога започва срокът след атака срещу сървър?
Срокът е свързан с узнаването, а не с момента на атаката. На практика разграничението често е трудно: съобщение за уязвимост като PHP2Shell само по себе си още не означава узнаване за нарушение на защитата на данните. Ако обаче откриете конкретни данни за проникване, например уеб шел или подозрителни заявки към базата данни, положението може да е различно.
Затова документирайте още от самото начало с часове кой кога каква информация е получил и какви стъпки са последвали. Тази времева линия помага при правната преценка и при въпроси на органа. Внимателно техническо разследване, например чрез ИТ криминалистика, изяснява дали и какви данни са действително засегнати.
Уведомяване на засегнатите лица по чл. 34
Ако нарушението вероятно води до висок риск за личните права и свободи, трябва без забавяне да се уведомят и засегнатите лица. Това може да е така, например, при данни за вход, банкови данни или здравни данни. Уведомлението трябва с ясен и прост език да опише какво се е случило и да посочи най-малко звеното за контакт, вероятните последици и предприетите мерки.
Чл. 34 предвижда изключения, например когато данните са направени недостъпни за неоправомощени лица, примерно чрез криптиране. Ако уведомяването на всяко отделно лице би изисквало непропорционални усилия, може вместо това да се обмисли публично съобщение или също толкова ефективна мярка. Дали се прилага изключение, е част от правната преценка. Как да информирате клиентите разбираемо, описва Кризисна комуникация след атака.
Задължение за документиране по чл. 33, пар. 5
Независимо от задължението за уведомяване чл. 33, пар. 5 от ОРЗД изисква всяко нарушение да се документира: фактите, последиците и предприетите коригиращи мерки. Тази документация трябва да позволява на надзорния орган да провери. Това важи и когато след проверка стигнете до извода, че уведомление не е нужно.
За уеб сървърите на практика това означава: запазвайте логовете, преди да бъдат ротирани, фиксирайте находките с момент, записвайте решенията и тяхната обосновка. При PHP2Shell специализираната преса препоръчва логовете на сървъра да се пазят от 20.10.2026 г. нататък. Освен това пачът не премахва вече внесен зловреден софтуер и не доказва, че преди това нищо не се е случило.
Практически ред в първите часове
- Съобщете подозрението вътрешно на определено звено и привлечете длъжностното лице по защита на данните.
- Запазете доказателствата: логове, списъци на файлове, извлечения от база данни, преди да се изтрие или да се инсталира наново каквото и да е.
- Изяснете технически дали може да са засегнати лични данни.
- Правна преценка на задължението за уведомяване и за известяване, при нужда с адвокат и застраховател.
- Уведомление чрез формуляра на компетентния надзорен орган, допълнения при нови констатации.
Подготвен ИТ авариен план значително съкращава тези стъпки.
Как помага PHP SOS конкретно?
- Запазваме логове и системни състояния така, че да останат използваеми за преценката и за по-късна проверка.
- Изясняваме технически дали и какви данни са били достъпни и предоставяме разбираемо резюме за длъжностните лица по защита на данните и за адвокатите.
- Водим времева линия на техническите констатации, която можете да ползвате за уведомлението и за документацията.
- При потвърдено проникване поемаме Incident Response и почистването.
Често задавани въпроси
От кога тече срокът от 72 часа?
Според чл. 33 от ОРЗД от момента, в който администраторът е узнал за нарушението. Кога може да се приеме това в конкретния случай, е правна преценка. Затова документирайте точно кой кога каква информация е имал.
Трябва ли да се съобщава за всяка уязвимост в сигурността?
Не. Самата уязвимост още не е нарушение на сигурността на личните данни. Задължение за уведомяване може да възникне, ако има данни, че неоправомощени лица са имали или са могли да имат достъп до такива данни и от това възниква риск за засегнатите лица.
Какво да направя, ако след 72 часа още не знам всичко?
Чл. 33, пар. 4 от ОРЗД позволява информацията да се предоставя поетапно, ако не може да бъде предоставена едновременно. Забавено уведомление трябва да се обоснове. Изчакването на пълна яснота по правило не е причина да оставите срока да изтече.
Кой уведомява, ако доставчикът на хостинг е бил засегнат?
Задължен да уведоми е администраторът, т.е. по правило фирмата, която управлява уебсайта. Обработващ лични данни като доставчика на хостинг трябва да информира администратора без забавяне съгласно чл. 33, пар. 2 от ОРЗД.
Къде да съобщя за нарушение на сигурността на данните?
На компетентния надзорен орган по защита на данните, за фирмите най-често органа на федералната провинция, в която е седалището им. Повечето органи предлагат за това онлайн формуляри.