КЗЛД · 72-часов план · Юни 2026

Уведомление до КЗЛД за 72 часа: готовият план, който спестява глобите при инцидент с лични данни

Петък вечер 21:47 ч. IT администраторът ви праща съобщение в Viber: "Един от счетоводителите е въвел паролата си в подменена страница, имейлите му изглежда са били чели от някой друг. Какво правим?" Часовникът по чл. 33 от GDPR току що тръгна. До неделя 21:47 ч. трябва да решите дали и как уведомявате КЗЛД, как уведомявате засегнатите физически лица по чл. 34, и как документирате решението си в Регистъра по чл. 33(5). Това е работният протокол, който прилагаме при реални инциденти в български компании, шаблоните на двете уведомления, и шестте грешки, които превръщат малък инцидент в глоба от 50 000 до 320 000 лв.

Основни изводи

• 72-часовият срок по чл. 33 GDPR не започва от момента на компромет, а от момента, в който администраторът узнае за нарушението (час 0). Точното документиране на този час е първото нещо, което КЗЛД иска и първото нещо, което повечето български компании не са направили
• Подаването на уведомление, когато инцидентът не попада в обхвата на чл. 33 (без вероятност от риск за правата на физическите лица), е практическа грешка, която обременява администратора с допълнителни задължения и в няколко случая от последните 24 месеца е довело до проверка от КЗЛД
• Уведомлението по чл. 34 към засегнатите физически лица е отделно решение с по-висок праг (висок риск, не просто риск). От 47 инцидента в български компании, които сме обработвали последните 30 месеца, чл. 34 уведомление е било задължително в 11 случая и преценено в 8
• КЗЛД приема предварително (initial) уведомление в рамките на 72 часа дори когато все още не са установени всички факти. Допълването с подробности по чл. 33(4) се изпраща след това с препращане към първоначалния номер на преписката. Това е практически най-важният параграф в чл. 33 за компании с непълна вътрешна форензика
• Регистърът по чл. 33(5) е задължителен и без уведомление към КЗЛД. Дори когато решите да не уведомявате, инцидентът трябва да се впише с обосновка защо. Липсващ регистър е една от трите най-чести причини за глоба при проверка по жалба
• При проверка КЗЛД иска: датата на узнаване, хронологията на действията в първите 72 часа, копие на уведомлението, шаблона на уведомление до физическите лица (дори ако решите да не го изпращате), и протокол за оценка на риска. Подготовка на тези пет документа предварително отнема 8 часа и спестява средно 4 до 7 дни в реално време

Чл. 33(1) GDPR указва срока с прецизен текст: "без необосновано забавяне и когато е възможно, не по-късно от 72 часа след узнаване". Думата "узнаване" е техническият термин, който определя час 0. КЗЛД и Европейският комитет по защита на данните (ЕКЗД) са разяснили дефиницията в Guidelines 9/2022 на ЕКЗД и в Решение № ПД-001-2024 на КЗЛД. Узнаването е моментът, в който администраторът има достатъчна степен на сигурност, че е настъпило нарушение на сигурността на лични данни.

Тази формулировка прави две практически разлики, които повечето български компании не правят правилно. Първо, узнаването не е моментът на компромета. Ако паролата е била открадната в петък в 17:20, но IT мениджърът е научил за нея в неделя в 09:14, час 0 е неделя в 09:14. Второ, узнаването не е първият неустановен сигнал. Един алерт от SIEM-а в петък, който е бил класифициран като нископриоритетен и не е довел до разследване, не стартира брояча. Узнаването изисква наличие на достатъчна сигурност, не просто хипотеза.

КЗЛД проверява тази дефиниция строго при всяка проверка. Първото нещо, което искат в писменото запитване, е документиран хронологичен запис на това кога са се случили събитията и кога администраторът е разбрал. Ако записът показва, че алертът в петък е бил пренебрегнат и инцидентът е научен реално чак в неделя, КЗЛД приема неделя като час 0. Ако записът обаче показва, че алертът е бил видян от дежурен в петък, отбелязан като "проверка след почивните дни" и след това забравен, КЗЛД ще приеме петък като час 0 и ще съществува потенциална глоба за забавено уведомление.

Тригерите, които стартират брояча, са пет: (1) IT инцидент с потвърдена компрометация на акаунт или система с лични данни, (2) загубено или откраднато устройство съдържащо лични данни, (3) грешно изпратен документ или имейл към грешен получател, ако обемът е значителен или съдържанието е специфично, (4) злонамерено вътрешно действие от служител с достъп, (5) физическо нарушение на сигурността (кражба на хартиени документи, неоторизирано влизане в офис). Ransomware атака стартира брояча в момента, в който е потвърдена; не в момента, в който екипът е надеждно изключил всички възможни алтернативни обяснения.

Практически съвет от 47-те инцидента, които сме придружавали: документирайте час 0 в самото начало на инцидента с конкретни доказателства (timestamp от тикет системата, screen-shot от поща, лог запис) и не променяйте по-късно. Опит за "оптимизиране" на час 0 е една от грешките, които КЗЛД разпознава най-бързо.

Не всеки инцидент с лични данни се уведомява. Чл. 33(1) указва уведомление само когато нарушението "вероятно ще доведе до риск за правата и свободите на физическите лица". Това е критериум с три нива (никакъв риск, риск, висок риск), приложен по конкретен анализ, и въз основа на него зависят и двата задължителни доклада (към КЗЛД по чл. 33 и към физическите лица по чл. 34).

ЕКЗД Guidelines 9/2022 описват тестовете в детайли. Накратко: оценете типа на компрометираните данни, контекста на обработването, естеството и обхвата на нарушението, лекотата на идентификация на физическите лица, тежестта на потенциалните последици, и специалните характеристики на администратора и засегнатите лица. Резултатът се документира писмено и се добавя към регистъра по чл. 33(5), независимо от решението.

Шест типови сценария от практиката ни в България, с приетата практика от КЗЛД:

Решението не е бинарно. КЗЛД очаква писмена оценка с конкретни обстоятелства на случая. Решете и документирайте. Ако решите да не уведомявате, впишете в регистъра по чл. 33(5) причината с препратка към ЕКЗД Guidelines 9/2022 раздели и съответните факти на случая.

КЗЛД приема уведомления чрез електронен формуляр на портала си (предпочитан), чрез системата за сигурно електронно връчване (ССЕВ), или с подписан PDF по имейл към dpo@cpdp.bg. Електронният формуляр е стандартизиран и съдържа всички задължителни полета по чл. 33(3). Подаването с подписан PDF е приемливо когато порталът е недостъпен или при по-сложни случаи с прикачени файлове.

Задължителните полета по чл. 33(3) са четири: (а) описание на естеството на нарушението, включително категориите и приблизителния брой на засегнатите субекти и категориите и приблизителния брой на засегнатите записи; (б) данни за контакт на длъжностното лице по защита на данните или друго лице за контакт; (в) описание на вероятните последици; (г) описание на предприетите или предложените мерки за смекчаване на последиците. Чл. 33(4) разрешава поетапно подаване на тази информация.

По-долу е работен шаблон, който прилагаме в нашите ангажименти. Адаптирайте го към конкретния си случай.

След подаване КЗЛД издава номер на преписка. Запазете го. Цялата по-нататъшна кореспонденция трябва да го реферира. Допълнителното подаване по чл. 33(4) се изпраща с препратка към същия номер и описание на новите факти. Не подавайте ново уведомление за същия инцидент с нов номер.

Уведомлението към физическите лица е отделно решение с по-висок праг от уведомлението към КЗЛД. Чл. 34(1) изисква уведомление само когато нарушението "вероятно ще доведе до висок риск за правата и свободите на физическите лица". Чл. 34(3) описва три изключения, при които задължението отпада: данните са били криптирани с подходящи технически мерки, рискът е бил смекчен с последващи мерки, или индивидуалното уведомление е невъзможно с непропорционално усилие (в който случай се прибягва до публично оповестяване).

Високият риск се преценява по същите критерии като в раздел 2, само че с по-висок праг. Типичните високорискови случаи: компрометация на пароли към финансови услуги, изтичане на медицински данни, изтичане на ЕГН-та в комбинация с други идентификатори, изтичане на данни за деца, или ситуации, в които засегнатите лица са в особена уязвимост (например жертви на домашно насилие, които биха могли да бъдат идентифицирани).

Съдържанието на уведомлението по чл. 34(2) е по-кратко от това към КЗЛД и трябва да е написано на разбираем език. Четири задължителни елемента: (1) описание на естеството на нарушението с прости думи, (2) име и контакти на DPO или друго лице за контакт, (3) описание на вероятните последици, (4) описание на предприетите или предложените мерки и препоръки към лицето как да се защити.

Каналът на уведомление е важен. Имейл е допустим, но трябва да достигне реално до получателя; ако имейл адресите ви са стари и над 25 на сто се връщат, КЗЛД ще иска допълнителен канал. SMS е добър вторичен канал. Препоръчано писмо е първокласен (но скъп) канал когато инцидентът засяга малък брой лица. Публикация на корпоративен сайт е допустима само като третично средство и не отменя индивидуалното уведомление освен в случай на непропорционално усилие.

Чл. 33(5) изисква администраторът да документира всички нарушения на сигурността на лични данни, включително фактите по нарушението, последствията и предприетите мерки за смекчаване. Това задължение съществува независимо от подаването на уведомление към КЗЛД и независимо от уведомлението към засегнатите лица.

КЗЛД може да поиска регистъра при проверка по всяко време. На практика регистърът се преглежда винаги при проверки по жалба, винаги при планови проверки на администратори с висок риск, и често при последващи проверки след подадено уведомление. Липсващ регистър е една от трите най-чести причини за санкция при проверка, заедно с липса на DPIA за високорискови дейности и липса на DPA с обработващи.

Минималното съдържание на един запис в регистъра, въз основа на най-добрите практики на КЗЛД и проверена практика на ЕКЗД:

Форматът на регистъра не е предписан. Excel таблица е достатъчна за малка компания. Системи за управление на инциденти (например ServiceNow, JIRA Service Management с custom template) са препоръчителни за компании с над 100 души. Каквото и да изберете, регистърът трябва да бъде достъпен за DPO, защитен от несанкционирана модификация (audit trail), и съхраняван минимум 5 години.

Грешка 1: Подаване на уведомление, когато не е задължително. Когато компанията е несигурна и реши "за всеки случай" да уведоми, тя поема ангажименти, които не би имала иначе (последващи доклади, отговори на въпроси на КЗЛД, евентуална проверка). В 6 от 47-те случая, които сме обработвали, "защитното" уведомяване доведе до отваряне на преписка, която иначе нямаше да съществува. Решение: оценявайте риска писмено преди да решите, не след.

Грешка 2: Подаване на непълно уведомление без използване на чл. 33(4). Когато компанията подава уведомление с празни полета "ще допълним по-късно" без формално препращане към чл. 33(4) и без обяснение какво се изяснява, КЗЛД това приема като опит за избягване на отговорност. Решение: ако подавате частично, изрично цитирайте чл. 33(4) и описвайте кои факти все още се изясняват и кога ще се допълни.

Грешка 3: Подценяване на броя засегнати лица. Първоначална оценка от 200 лица, която след форензика се оказва 5 600, е сигурна причина за по-сериозна санкция. Решение: ако нямате точна оценка, посочете диапазон с описание на методологията и подайте допълнително уведомление в момента, в който числото се изясни.

Грешка 4: Уведомяване на физическите лица с общ текст, който не описва конкретните рискове. "Имаше технически проблем, моля сменете паролата си" не отговаря на чл. 34(2). Решение: пишете на разбираем език, но включете конкретните 4 елемента (естество, контакт, последици, мерки) и съветвайте конкретно (наблюдавайте сметката си, активирайте 2FA, регистрирайте се в Системата за управление на лични данни на КЗЛД при съмнение за злоупотреба).

Грешка 5: Липсваща координация с обработващите (processors). Ако данните се обработват от външен доставчик (cloud, payroll, CRM), той има задължение по чл. 33(2) да уведоми администратора без необосновано забавяне. На практика повечето DPA-та регламентират срокове (например 24 часа). Ако обработващият узнае днес и забави уведомяването с 5 дни, вашият брояч стартира когато вие узнаете, но КЗЛД може да оцени, че сте имали недостатъчен надзор върху обработващите. Решение: добавете в DPA-тата конкретни срокове и периодично тествайте процеса.

Грешка 6: Липса на регистър по чл. 33(5). Това е най-простата грешка за избягване и най-честата на практика. Регистърът трябва да съществува дори за случаи, които сте решили да не уведомявате. Решение: създайте регистър днес. Един празен Excel файл с правилните колони е по-добре от нищо.

Следваща стъпка

Искате 72-часов план за вашата компания, преди да е нужен?

Изготвяме готови шаблони за уведомления по чл. 33 и чл. 34, регистър по чл. 33(5), и провеждаме tabletop exercise с екипа ви, за да тестваме процедурата преди реалния инцидент. Подготовката отнема 3 до 5 работни дни и струва между 3 200 и 9 800 лв. за компания с 50 до 250 души.