Закон за киберсигурност · Докладване на инциденти · Май 2026

Докладване на инцидент за 24 и 72 часа: практически протокол по новия Закон за киберсигурност

Часовникът тръгва от момента, в който узнаете за значителен киберинцидент. 24 часа за ранно предупреждение, 72 часа за разширено уведомление, един месец за финален доклад. Пропускът на който и да е от трите срока е тежко нарушение с глоба до 1 000 000 лв. Това е практическият протокол, който ще ви помогне да отговорите на тези срокове, дори когато ИТ екипът ви още гаси пожара. Стъпка по стъпка, с примери, шаблони и кой какво прави в коя минута.

Най-важното накратко

• Задължението за докладване е тристъпково: 24 часа ранно уведомление за значителен инцидент, 72 часа подробен доклад с оценка на въздействието, 1 месец финален доклад с първопричина и предприети мерки. И трите срока текат от момента, в който узнаете за инцидента.
• Уведомлението се подава до националния CSIRT при МЕУ (за повечето сектори) или до съответния секторен регулатор (БНБ за финансовите институции, КРС за телекомите). За съществените субекти има допълнително задължение да се уведоми и компетентният орган.
• „Значителен инцидент" означава такъв, който е причинил или има потенциал да причини сериозни оперативни смущения или финансови загуби, или е засегнал физически или юридически лица чрез причиняване на материална или морална вреда. Не всички инциденти са докладваеми. Спам, единични фишинг опити, и блокиран зловреден код не са задължителни за докладване.
• Освен националното уведомление, ако инцидентът е довел и до пробив на лични данни, се пуска отделно уведомление до КЗЛД по чл. 33 от GDPR в рамките на същите 72 часа. Двата режима съществуват паралелно и не се заместват взаимно.
• Най-чести грешки, водещи до санкция: забавяне над 24 часа заради опити да се изясни всичко преди първото уведомление, липса на писмена обосновка защо инцидентът не е значителен (когато сте го преценили така), уведомление до грешен орган (МЕУ вместо БНБ за банка), и липса на проследяване на 72-часовия и финалния доклад.
• Защитата изисква предварителен процес: дефинирани прагове за значителност, назначен координатор за докладване (обикновено CISO или DPO), обучен дежурен екип и шаблон на уведомлението, попълнен предварително с фирмени данни. Без този процес първото уведомление винаги ще закъснее.

Законът въвежда тристъпков режим на докладване, който отговаря на трите фази на типичния отговор на инцидент: ранно сигнализиране (когато знаете малко, но е важно органите да са информирани), детайлно уведомление (когато имате оценка на въздействието) и финален доклад (когато сте идентифицирали първопричината и сте предприели коригиращи мерки). Всеки от трите срока тече независимо от другите.

24-часовото ранно предупреждение е първото и най-критичното уведомление. Целта му не е да даде пълна картина на инцидента, а да информира националния CSIRT (или съответния секторен регулатор), че сериозно събитие е настъпило. Съдържа: идентификация на дружеството, дата и час на узнаване, кратко описание на инцидента (две до три изречения), предполагаемо естество (умишлено или случайно), и индикация дали инцидентът все още е в ход. Не се очаква точна оценка на въздействието.

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

Едномесечният финален доклад е окончателният писмен следотпечатък. Тук се описват първопричината (root cause analysis), пълното въздействие (включително финансови загуби, ако са установими), всички предприети технически и организационни мерки за възстановяване, и планираните дългосрочни мерки за предотвратяване на повторение. Този документ често се иска от застрахователя при претенция по киберполица и от одитори при последващ одит. Пишете го така, сякаш ще го четете на свидетелски разпит, защото в случай на спор точно това става.

Не всички инциденти трябва да се докладват. Законът ограничава задължението до „значителните" киберинциденти - тези, които са причинили или имат потенциал да причинят сериозни оперативни смущения, значителни финансови загуби, или материална/морална вреда за физически или юридически лица. Това е сравнително широка дефиниция, но в практиката за повечето български компании работят следните прагове.

Практическият подход, който прилагаме при клиентите си, е следният. Дефинирайте трите нива: L1 - не докладваеми (нормален шум, блокиран от защитните системи), L2 - вътрешно проследими (отнасят се в инцидентния регистър, но не достигат прага за външно докладване), и L3 - докладваеми (попадат в категориите по-горе). Гранични случаи се ескалират към CISO или DPO за решение в писмен вид.

Едно важно правило за защита: когато сте преценили, че инцидент НЕ е значителен и не сте го докладвали, документирайте писмено решението си. Една параграфа е достатъчна: дата, кратко описание на събитието, оценка на въздействието, основание за решение „не значителен", подпис на CISO или равнопоставен ръководител. Това е защита, ако в по-късен момент органите решат, че събитието е трябвало да бъде докладвано. Без писмена обосновка позицията „преценихме, че не е значително" не се приема.

Втората типична грешка е обратната: докладване на всичко „за всеки случай". Това натоварва националния CSIRT, но и създава репутационна история на дружеството ви. В практиката надзорните органи започват да следят дружества с подозрително висок брой докладвания, защото може да означава, че дружеството има хронични проблеми с базовата защита. Правилната практика е дисциплина: ясни прагове, писмени решения, докладване само на това, което действително е значително.

Уведомлението не се подава автоматично към един универсален орган. Законът разпределя надзора между националния CSIRT и секторните регулатори. Подаването в грешен орган може да доведе до закъснение в обработката и в най-лошия случай - до санкция за неспазен срок, ако правилният орган не получи уведомлението в 24-часовия прозорец.

За повечето български компании в обхвата на закона (логистика, производство, здравеопазване, ИТ услуги, държавна и общинска администрация) компетентният орган е националният CSIRT при Министерството на електронното управление. Уведомленията се подават през портал, който се очаква да бъде в пълна експлоатация преди 1 юни 2026 г., с резервен канал по електронна поща.

За финансовия сектор - банки, платежни институции, дружества за електронни пари - компетентен орган е БНБ. Тук съществува и режимът на DORA от 17 януари 2025 г., който има свои собствени срокове и формуляри. На практика финансовите институции трябва да поддържат два паралелни процеса на докладване, които сливат в общ оперативен поток. Един от инцидентите ни през последните три месеца включваше банка, която забрави да докладва на БНБ в 24 часа, защото DORA уведомлението беше изпратено навреме - двата режима не се заместват.

За телекомуникационните оператори и доставчиците на интернет компетентен орган е Комисията за регулиране на съобщенията (КРС). И за всички, при които киберинцидентът е причинил и пробив на лични данни, се пуска паралелно уведомление до КЗЛД по чл. 33 от GDPR. Внимавайте: 72-часовият срок по GDPR се изчислява по същите правила като 72-часовия срок по новия закон, но двете уведомления имат различни формуляри и съдържание.

Под „шаблон" разбираме параметризиран документ, в който фиксираните полета (име на дружеството, ЕИК, контактно лице, секторна принадлежност, статут на субект) се попълват предварително, а полетата за конкретния инцидент остават празни за бързо попълване. Този подход спестява критичните 30 до 60 минути при реален инцидент.

Изготвянето на шаблона е работа за един час с DPO или CISO. Съхранява се на достъпно за дежурния екип място (Confluence страница, споделен Drive, физическо копие в реактивната папка), маркирано с цвят или икона. При активиране на инцидентен план шаблонът се отваря в първите 15 минути, попълват се конкретните полета, и в рамките на 4 до 6 часа от инцидента е готов за подаване. Останалите часове до 24-те са буфер за вътрешно одобрение (CEO, юрист) преди изпращане.

Без предварително разпределени роли първите часове на инцидента са хаос. Всеки прави всичко, никой не пише уведомлението, и 24-часовият срок изтича преди някой да си спомни за него. Препоръчителната рамка е следната, базирана на 27 инцидента, които сме координирали за български клиенти от 2024 г. насам.

SOC и дежурен IT екип работят непрекъснато от момента на засичане. Тяхната задача не включва уведомлението - те ограничават щетата, събират технически индикатори, и подават доклади към координатора. Опитът да включиш техническия екип в писмената работа намалява скоростта и на двете дейности.

CISO или DPO е координаторът на докладването. Той прави първоначалната преценка „значителен ли е инцидентът", активира инцидентния план, и започва попълването на шаблона на 24-часовото уведомление в рамките на първите 4 часа. След това координира с останалите роли - технически данни от SOC, правен преглед от юриста, одобрение от CEO. Без назначен координатор задачата „пишеш уведомлението" остава ничия.

CEO и юрист преглеждат и одобряват уведомлението в прозореца час 10 до 18. Тук се проверяват юридическите формулировки, точността на бизнес информацията, и съответствието със секторните регулатори. CEO подписва документа от името на дружеството - това е изрично негова отговорност и не може да се делегира.

Комуникационната роля (или CEO в малките дружества) подготвя външните съобщения - към клиенти, медии при необходимост, регулатори в режим. Тази роля се активира в час 16 и работи паралелно с финалното одобрение на уведомлението. Готов клиентски имейл преди подаване на уведомлението не е грешка; нагласа към „първо подадем, после мислим за клиентите" причинява щета на репутацията.

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

Как Atlant Security помага

Готов протокол за докладване на инциденти за вашата компания

Координирали сме 27 киберинцидента за български клиенти през последните 18 месеца. Знаем кои са правилните формулировки за всеки секторен регулатор, как се избягват най-честите грешки в първите часове, и как се изгражда защитимият писмен следотпечатък. Можем да подготвим протокола ви за докладване, да обучим дежурния екип, и да служим като координатор „на повикване" при реален инцидент.

• Готов 24-часов и 72-часов шаблон на уведомление, попълнен с фирмени данни за всеки секторен регулатор
• Двучасово обучение на дежурния екип върху прагове, роли и срокове
• Подготвен инцидентен план с интеграция към GDPR (КЗЛД) и DORA (БНБ) режимите
• 24/7 координация „на повикване" за първите 72 часа на реален инцидент - от 4 000 лв. абонамент
• Тримесечно учебно учение (tabletop exercise) с пълно документирано протоколиране
• Първоначална консултация безплатна за компании в обхвата на закона

Запазете консултация →

Ако четете тази публикация без активен инцидент, имате най-ценното - време. Един час сега, прекаран в попълване на шаблон с фирмени данни и в определяне на координатора, ще спести 6 до 10 часа при реален инцидент. Това е разликата между „спазен срок без санкция" и „пропуснат срок с глоба от стотици хиляди левове".

Ако четете публикацията с активен инцидент - не четете до края. Назначете координатор, започнете изолацията, отворете шаблона ако имате, попълнете това, което знаете, и изпратете уведомлението до съответния орган в рамките на първите 18 часа. Останалото време оставете за вътрешно одобрение и подобряване. Изпратеното непълно уведомление в срок винаги печели срещу пълно уведомление след срока.

Имате нужда от готов протокол за докладване или координация при активен инцидент? Запазете консултация или пишете директно на alexander@atlantsecurity.com.