Общини · ЗКС · Реакция при инциденти
Новият Закон за киберсигурност изисква всяка от 264-те български общини да има действаща, писмена политика за реакция при инциденти. Не е достатъчно някой да знае какво да прави - процедурата трябва да е документирана, ролите назначени, а сроковете 24 и 72 часа разбрани от хората, които ще трябва да ги спазят посред нощ. Това е практическият наръчник за общинските секретари, юрисконсулти и ИТ отговорници: какво точно трябва да съдържа политиката, кой носи коя роля, как се класифицира инцидент, какви документи иска ОЕЦ при проверка, и шестте грешки, които превръщат политиката в лист хартия без стойност.
Основни изводи
- Политиката за реакция при инциденти е една от 13-те задължителни мерки по чл. 21 от Закона за киберсигурност (ЗКС). За общината, която е съществен субект, тя не е препоръка, а задължение с пълно действие от 1 юни 2026 г.
- Законът налага три последователни срока: ранно предупреждение до 24 часа, уведомление до 72 часа и окончателен доклад до 1 месец. Часовникът тръгва от момента, в който общината узнае за значим инцидент, а не от момента, в който го разреши.
- Добрата политика се събира на 8 до 12 страници и отговаря на пет въпроса: какво е инцидент, кой какво прави, как се класифицира, как се документира и на кого се докладва. По-дълъг документ обикновено не се чете и не се прилага.
- Най-честата грешка не е липсата на политика, а политика без назначен отговорник и без нито едно проведено учение. Неизпробваната процедура може да се окаже неприложима при реален инцидент.
- Когато инцидентът засяга лични данни, проверява се и отделното задължение за уведомяване на КЗЛД до 72 часа по GDPR. Политиката трябва да предвижда паралелното проследяване на двата срока.
- Политиката е документ, който се преглежда и актуализира. Предвидете поне едно практическо учение и един преглед годишно, както и актуализация след всеки реален инцидент.
Секретар на малка община ни се обади през пролетта, два дни след като служител в дирекция "Местни данъци и такси" беше отворил прикачен файл от имейл, който се представяше за съобщение от НАП. Антивирусната програма беше блокирала част от заразата, но не цялата, а компютърът на служителя се държеше странно от сутринта.
Въпросът на секретаря не беше технически. Той беше процедурен и тревожен едновременно: "Това инцидент ли е по смисъла на закона? Трябва ли да го докладваме, на кого и в какъв срок? Някой спомена 24 часа, а вече минаха повече от два дни. И най-важното - кой в общината изобщо отговаря за това? Защото в момента всеки пита всеки друг."
Основният проблем беше липсата на ясна процедура: какво се счита за инцидент, кой определя тежестта му, кой уведомява външните органи и в какъв срок. Без разпределени отговорности реакцията се забавя и важни стъпки могат да бъдат пропуснати.
Статията е за общинските секретари, юрисконсултите и отговорниците за ИТ. Разглеждаме структурата на политиката, ролите, класифицирането на инцидентите, документирането и докладването, както и често срещаните пропуски при прилагането на процедурата.
Част 1
Защо писмената политика не е формалност
Лесно е общинската администрация да възприеме политиката за инциденти като поредния документ, който се пише, защото го изисква закон, и след това се прибира в папка. Това е грешка, която струва скъпо, и си струва да обясним защо.
Първата причина е правна. Управлението на инцидентите е изрично сред 13-те минимални мерки по чл. 21 от Закона за киберсигурност. Общината попада в обхвата на закона като съществен субект от сектор "Публична администрация" и дължи тези мерки в действащ вид. ОЕЦ има правомощие да извършва проверки, а при проверка първото, което се иска, е документът. Устната увереност "ние знаем какво да правим" няма стойност пред проверяващ. Това, което има стойност, е писмената политика, дневникът на инцидентите и доказателството, че процедурата е репетирана.
Втората причина е оперативна и тя е по-важната. Реалният инцидент не настъпва в удобно време. Той настъпва в петък следобед, когато ИТ отговорникът е в отпуск, или в неделя през нощта, когато дежури само един човек. В този момент никой няма нито спокойствието, нито времето да измисля процедура. Хората правят това, което е записано, или това, което си спомнят, а под напрежение паметта е лош съветник. Писмената политика е разликата между организирана реакция и паника, в която часовникът на закона тече, а никой не го гледа.
Срокът започва от узнаването, а не от овладяването на инцидента
Най-скъпото недоразумение в общинската администрация е убеждението, че инцидентът се докладва, след като бъде овладян. Законът мисли обратното. Срокът за ранно предупреждение тече от момента, в който общината узнае за значим инцидент, докато той още е в ход. Политика, която не казва това ясно на първа страница, оставя общината да изпусне 24-часовия срок, докато все още се опитва да "оправи нещата" вътрешно.
Третата причина е свързана с доверието. Общината обработва лични данни на хиляди граждани, данъчна информация, регистри, понякога данни на социално уязвими лица. Когато настъпи инцидент, гражданите, общинският съвет и медиите ще задават въпроси. Община, която може да покаже, че е имала ясна процедура, я е следвала и е докладвала в срок, излиза от ситуацията с непокътната репутация. Община, която импровизира, излиза от нея разклатена дори когато техническата щета е била малка.
Част 2
Какво е инцидент и кога започват да текат сроковете
Политиката трябва ясно да определя какво се счита за инцидент и от кой момент започва срокът за докладване. От това зависят всички следващи действия.
Инцидент в смисъла на закона е събитие, което застрашава наличността, цялостта, поверителността или автентичността на информационните системи на общината или на данните в тях. Това е широко определение и нарочно. То покрива заразяване със зловреден софтуер, компрометиран служебен акаунт, криптовирус, който заключва файлове, неоторизиран достъп до регистър, изтичане на лични данни, но също така и продължителна недостъпност на ключова система, дори когато няма злонамерен извършител. Не всеки инцидент обаче е значим инцидент, който подлежи на докладване. Значим е този, който е причинил или може да причини сериозно оперативно нарушение или финансови загуби, или е засегнал други лица със значителни вреди.
Политиката трябва да съдържа практичен критерий, който дежурният служител може да приложи в 23:00 ч. без да звъни на юрист. Добрият критерий е въпрос от рода на: спряла ли е услуга за гражданите, засегнати ли са лични данни, разпространява ли се проблемът, и има ли признаци за умишлено действие. Ако отговорът на който и да е от тези въпроси е "да" или "вероятно", инцидентът се третира като значим, докато не се докаже обратното. По-добре е да задействате процедурата и да я отмените, отколкото да я задействате със закъснение.
Забележете нещо важно за каскадата. Ранното предупреждение в първите 24 часа не е пълен доклад. То е кратко съобщение, че има значим инцидент, с първоначална преценка дали изглежда злонамерен и дали може да има трансгранично отражение. Общината не е длъжна да знае всичко на 24-ия час. Тя е длъжна да каже, че нещо се случва. Подробностите идват с уведомлението на 72-ия час, а анализът на първопричината - с окончателния доклад до един месец.
Дежурният служител трябва да разпознае проблема и да подаде сигнал. Не се очаква да приключи разследването за 24 часа. Затова политиката трябва да посочва ясни критерии и конкретни контакти и канали за уведомяване.
Част 3
Какво трябва да съдържа политиката: задължителните раздели
Добрата политика за реакция при инциденти е кратка. Тя се събира на 8 до 12 страници и съдържа девет раздела. Всеки раздел отговаря на конкретен въпрос, който някой ще си зададе по време на реален инцидент. Ако документът ви е по-дълъг от това, рискувате никой да не го прочете докрай. Ако е по-кратък, вероятно пропуска нещо.
Два от тези раздели общините най-често пишат лошо. Първият е разделът за определения. Изкушението е да се препише дефиницията от закона дума по дума. Това е безполезно за дежурния служител. По-добре е законовата дефиниция да присъства, но до нея да стои практичният критерий от предишната част - конкретните въпроси, които служителят може да си зададе и да получи отговор за минута.
Разделът за външно докладване трябва да посочва сроковете, каналите за подаване, отговорното лице и кой одобрява доклада. Отделно опишете действията при нарушение на сигурността на лични данни и уведомяването на КЗЛД.
И още нещо. Половината от практическата стойност на политиката е в приложенията, не в основния текст. Списъкът с контакти - вътрешни и външни, с резервни телефони - е документът, който се отваря пръв при реален инцидент. Шаблоните за трите доклада спестяват часове в момент, когато часовете са най-скъпи. Картата на критичните системи на общината казва веднага кое трябва да се защити първо. Политика без приложения е теория. Политика с приложения е инструмент.
Част 4
Роли и отговорности: кой какво прави
Политика, в която отговорността е разпределена мъгливо, се проваля по предсказуем начин: всички предполагат, че някой друг е поел задачата. Затова разделът за ролите трябва да назначава конкретни длъжности, а не имена - длъжностите остават, когато хората се сменят - и да описва за всяка роля какво точно прави в първия час на инцидента.
Не е необходим голям екип, но всяка задача трябва да има определен отговорник.
Централната роля е тази на координатора на инцидента. В повечето български общини това е отговорникът по сигурността на информацията, а когато общината е възложила тази функция външно, координаторът е виртуалният CISO. Координаторът не е човекът, който поправя сървъра. Той е човекът, който държи цялостната картина: класифицира инцидента, решава дали е значим, води дневника в реално време, изготвя трите доклада и следи часовника. Без назначен координатор всеки инцидент се разпада на паралелни, несвързани усилия.
Кметът или секретарят носи крайната отговорност и две конкретни задачи: одобрява докладите, които излизат навън от името на общината, и решава кой и какво казва на гражданите и медиите. Това не е символична роля. Доклад до компетентен орган, изпратен без знанието на ръководството, и противоречиви публични изявления са два от най-честите начини един овладян технически инцидент да се превърне в репутационна криза.
Най-подценяваната роля е тази на обикновения служител. Политиката трябва да му каже три неща с прости думи: подай сигнал веднага, щом забележиш нещо нередно; не се опитвай да "оправиш" проблема сам; и не изтривай, не форматирай и не изключвай нищо без указание, защото това унищожава доказателствата, които ще трябват за доклада и за проверката. Един служител, който знае тези три правила, скъсява времето за реакция повече от всеки технически инструмент.
Когато един служител изпълнява няколко роли
В община с 40 служители често един и същ човек поддържа компютрите, отговаря за сигурността и е заместник на секретаря. Разпределението на ролите пак има смисъл, защото инцидентът пак изисква някой да координира, някой да изпълнява технически и някой да одобрява. Решението при недостиг на хора не е да слеете ролите в едно име, а да възложите функцията на сигурността външно. Виртуалният CISO покрива ролята на координатор законно и без да зависи от това дали единственият ИТ човек е на работа в деня на инцидента.
Част 5
Процедурата стъпка по стъпка и класификацията
Процедурата описва действията от първия сигнал до приключването на инцидента. Следващите шест етапа определят основните задачи, като докладването трябва да се извършва в съответните срокове успоредно с техническата работа.
Етап първи е откриване и регистриране. Сигнал постъпва - от служител, от автоматична аларма, от външен орган. Координаторът открива нов запис в дневника на инцидента с дата, час и източник на сигнала. От тази минута всичко се документира.
Етап втори е класификация. Координаторът преценява тежестта и решава дали инцидентът е значим. Това решение задейства или не задейства часовника за докладване навън, затова е критично и не бива да се отлага. При съмнение инцидентът се класифицира нагоре, не надолу.
Етап трети е ограничаване. Целта е проблемът да спре да се разпространява: изолиране на засегнатия компютър от мрежата, блокиране на компрометиран акаунт, спиране на засегната услуга. Важно е политиката да подчертае, че ограничаването не означава унищожаване на доказателства - компютърът се изолира, но не се форматира.
Етап четвърти е отстраняване на причината и възстановяване: премахване на причината и връщане на системите в безопасно работно състояние от проверени резервни копия. Етап пети е докладване в приложимите срокове. Шестият етап е преглед след инцидента - спокоен анализ какво се случи, какво проработи и какво трябва да се промени в политиката.
Класификацията заслужава внимание, защото точно тук общините най-често грешат. Има две посоки на грешката. Едната е класифициране надолу - желанието проблемът да изглежда малък, за да не се налага докладване, защото докладването се възприема като признаване на провал. Това е опасно: ако инцидентът по-късно се окаже значим, общината е изпуснала срок и е добавила към техническия проблем и нарушение на закона. Другата посока е парализа - инцидентът не се класифицира изобщо, защото никой не иска да поеме решението. Решението е политиката изрично да назначи класификацията като задача на координатора и да каже ясно, че при съмнение нивото се качва.
Полезно е политиката да съдържа три или четири нива на тежест с кратко описание какво задейства всяко. Ниският инцидент се обработва вътрешно и само се вписва в дневника. Средният активира екипа и се следи отблизо. Високият, тоест значимият инцидент, задейства цялата каскада от срокове за докладване. Когато нивата са описани с конкретни примери, познати на общинските служители, класификацията спира да бъде източник на колебание.
Част 6
Документирането: дневникът и докладите
Действията се документират по време на инцидента. Основата е дневникът с точна хронология, от който се подготвят и външните доклади.
Дневникът на инцидента е хронологичен запис. Всяко действие, всяко решение, всяко наблюдение се вписва с дата и час. Кой подаде сигнала и кога. Кога инцидентът беше класифициран и на какво ниво. Кога засегнатият компютър беше изолиран. Кога беше изпратено ранното предупреждение. Този запис изглежда дребнав, докато не дойде моментът да се пише окончателният доклад или да се отговаря на ОЕЦ - тогава дневникът е единственото нещо, което превръща мъгливия спомен в точна картина. Той трябва да е достъпен за хората, които го водят, и защитен от подправяне.
| Документ | Срок | Какво съдържа |
|---|---|---|
| Ранно предупреждение | до 24 часа | Кратко: има значим инцидент, първоначална преценка дали изглежда злонамерен и дали може да има трансгранично отражение. Без подробен анализ. |
| Уведомление | до 72 часа | Подробно: обхват на инцидента, оценка на тежестта, засегнати системи и услуги, индикатори за компрометиране, предприети до момента мерки. |
| Окончателен доклад | до 1 месец | Пълен: анализ на първопричината, общ обхват и тежест на щетата, тип на заплахата, предприети и планирани мерки за предотвратяване в бъдеще. |
| Уведомление до КЗЛД | до 72 часа | Само при засегнати лични данни. Независим срок по GDPR. Естество на нарушението, категории и брой засегнати лица, вероятни последствия, взети мерки. |
| Дневник на инцидента | в реално време | Вътрешен. Хронологичен запис на всички действия, решения и наблюдения. Основа за всички доклади и за проверката от ОЕЦ. |
Шаблоните за трите доклада трябва да са готови предварително и да стоят като приложения към политиката. Никой не бива да съчинява структурата на доклад до компетентен орган в часовете, в които часовникът тече. Готовият шаблон с предварително попълнени полета - наименование на общината, лице за контакт, начин на подаване - оставя на координатора само да впише фактите по конкретния инцидент. Това спестява час или два в момент, когато всеки час е скъп.
Има и един въпрос за съхранението на доказателствата, който политиката трябва да уреди. При значим инцидент засегнатите компютри, дневниците на системите и образите на дисковете може да са нужни седмици по-късно - за окончателния доклад, за проверка, понякога за работа с органите на реда. Политиката трябва да укаже, че тези доказателства не се изтриват и не се презаписват, докато инцидентът не бъде официално закрит. Това е дребно правило, което общините редовно пропускат и съжаляват. Ако не искате да водите това в таблици, NIS2 модулът на Venvera свързва всяко изискване със съответните доказателства.
Част 7
Шест чести грешки и как да поддържате политиката актуална
Виждали сме много общински политики за инциденти. Грешките се повтарят и почти всички са поправими, ако ги познавате предварително.
1. Преписана политика от друга община или от шаблон в интернет
Преписаният документ изброява системи, които общината няма, имена на роли, които не съществуват в нейното щатно разписание, и канали за връзка, които не са проверени. Той изглежда готов и е безполезен. Шаблонът е добра начална точка, но трябва да бъде адаптиран към конкретната община - нейните реални системи, нейните реални длъжности.
2. Политика без назначен координатор
Ако няма определен координатор, оценката на тежестта, сроковете и докладването могат да останат без отговорник. Политиката трябва изрично да възлага тези задачи.
3. Нито едно проведено учение
Политика, която никога не е била изпробвана, се проваля на първия реален инцидент. Едно практическо учение - двучасова симулация на масата, без техника - разкрива неработещи телефони, неясни роли и пропуснати стъпки, докато това още не струва нищо.
4. Списък с контакти, който никой не поддържа
Хората сменят телефони и напускат. Списък с контакти отпреди две години е почти толкова безполезен, колкото никакъв списък. Той трябва да се преглежда поне веднъж годишно и след всяка кадрова промяна в ключова роля.
5. Политика, която мълчи за личните данни
Много общински политики разглеждат само срока по ЗКС и пропускат, че при засегнати лични данни тече и независим 72-часов срок към КЗЛД. Резултатът е изпуснато уведомление и второ нарушение върху първото. Политиката трябва да задейства двата часовника едновременно.
6. Документ, който не се актуализира след реален инцидент
Всеки реален инцидент показва къде политиката е била неточна. Община, която не вписва тези уроци обратно в документа, повтаря същите грешки. Прегледът след инцидента не е формалност - той е най-евтиният начин политиката да става по-добра.
Поддържайте политиката с ежегоден преглед, практическо учение и актуален списък с контакти. След реален инцидент анализирайте какво е проработило и нанесете необходимите промени.
Ако започвате от нула, реалистичният път е следният. Адаптирайте шаблона към своята община за една до две седмици. Дайте го за одобрение от ръководството с протокол. Проведете първото практическо учение в рамките на месец след одобрението. Така до 1 юни 2026 г. общината има не просто документ, а документ, който поне веднъж е бил изпробван и чиито роли хората познават.
Как помага Atlant Security
Политика, която работи в часа, в който е нужна
Изготвяме политики за реакция при инциденти в общинската администрация, адаптирани към реалните системи, длъжности и капацитет на конкретната община. Документът не е преписан шаблон - той е готов за одобрение от ръководството и идва с приложенията, които носят половината от стойността му: списък с контакти, шаблони за трите доклада, дневник на инцидента, карта на критичните системи.
- Политика, съобразена с чл. 21 от ЗКС и сроковете от 24 и 72 часа
- Готови приложения: контакти, шаблони за доклади, дневник, карта на системите
- Практическо учение с екипа на общината, за да не е документът само на хартия
- Покритие и на 72-часовия срок към КЗЛД при засегнати лични данни
- Възможност функцията на координатор да се поеме от виртуален CISO
Често задавани въпроси
Въпроси от общинските секретари
Трябва ли да докладваме всеки инцидент, или само значимите?
Навън, към компетентните органи, се докладват значимите инциденти - тези, които са причинили или могат да причинят сериозно оперативно нарушение, финансови загуби или значителни вреди за други лица. Дребните събития се вписват само във вътрешния дневник на инцидента. Точно затова класификацията е централна стъпка в процедурата. При съмнение дали инцидентът е значим, политиката трябва да укаже, че се класифицира нагоре, защото изпуснат срок за значим инцидент е по-скъп от едно ненужно ранно предупреждение.
Откога точно тече 24-часовият срок?
От момента, в който общината узнае за значим инцидент, а не от момента, в който той бъде разрешен. Това е най-честото недоразумение и трябва да е написано на първа страница на политиката. Ранното предупреждение е кратко уведомление, че има инцидент, и не изисква общината да е разбрала всичко - то се подава, докато инцидентът още е в ход. Подробният анализ идва с уведомлението на 72-ия час и с окончателния доклад до един месец.
Имаме само един ИТ човек. Кой да поеме ролята на координатор?
Ролята на координатор на инцидента и ролята на техническа поддръжка са различни и е добре да не се сливат в един човек, защото при инцидент координаторът трябва да държи цялостната картина, а не да е погълнат от техническата работа. Когато общината няма капацитет за отделен отговорник по сигурността, практичното решение е тази функция да се възложи на виртуален CISO. Така ролята на координатор е покрита независимо от това дали единственият ИТ служител е на работа в деня на инцидента.
Какво иска ОЕЦ да види при проверка?
Преди всичко самата писмена политика, одобрена от ръководството с дата. След това доказателството, че тя е действаща, а не само формална: дневникът на инцидентите, протоколът от проведено практическо учение, актуалният списък с контакти, и при наличие на минали инциденти - докладите по тях. Проверката търси не съвършенство, а доказателство, че общината има процес и го прилага. Документ без нито един признак, че е бил използван или изпробван, изглежда точно като това, което е - формалност.
Инцидентът засегна лични данни. Достатъчно ли е да докладваме по ЗКС?
Не. Когато инцидентът засяга лични данни на граждани или служители, освен докладването по реда на ЗКС тече и независим срок по GDPR: уведомление до КЗЛД в рамките на 72 часа от узнаването, а когато нарушението е свързано с висок риск за правата на засегнатите лица - и съобщение до самите лица. Това са два отделни режима с отделни адресати. Политиката трябва да предвиди и двата и да задейства часовниците им едновременно, не последователно.
Колко често трябва да актуализираме политиката?
Минимумът е един преглед годишно, плюс актуализация след всеки реален инцидент и след всяка значима промяна - нова ключова система, реорганизация на дирекции, смяна на хора в ключови роли. Годишният преглед е добре да съвпада с практическото учение: учението показва къде документът не работи, а прегледът веднага вписва поправките. Политика, която не се е променяла от датата на приемането си, почти сигурно вече не отговаря на реалната общинска среда.
Нуждаете се от помощ с NIS2? Услугата ни за съответствие с NIS2 включва определяне на обхвата, десетте мерки по член 21, регистрацията и подготовката на доказателства за изпълнение.
Преди 1 юни 2026 г.
Подгответе общината за реакция при реален инцидент.
Изготвяме и въвеждаме политики за реакция при инциденти в общинската администрация - адаптирани към вашите системи и хора, с готови приложения и проведено практическо учение. Ако вече имате политика, ще ви кажем честно дали ще издържи проверка и реален инцидент.
Запазете 30-минутен разговор