Шаблон за политика за реакция при инциденти за общинската администрация: какво трябва да съдържа и как да го въведете

Общини · ЗКС · Реакция при инциденти

Новият Закон за киберсигурност изисква всяка от 264-те български общини да има действаща, писмена политика за реакция при инциденти. Не е достатъчно някой да знае какво да прави - процедурата трябва да е документирана, ролите назначени, а сроковете 24 и 72 часа разбрани от хората, които ще трябва да ги спазят посред нощ. Това е практическият наръчник за общинските секретари, юрисконсулти и ИТ отговорници: какво точно трябва да съдържа политиката, кой носи коя роля, как се класифицира инцидент, какви документи иска ОЕЦ при проверка, и шестте грешки, които превръщат политиката в лист хартия без стойност.

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

• Политиката за реакция при инциденти е една от 13-те задължителни мерки по чл. 21 от Закона за киберсигурност (ЗКС). За общината, която е съществен субект, тя не е препоръка, а задължение с пълно действие от 1 юни 2026 г.
• Законът налага каскада от три срока: ранно предупреждение до 24 часа, уведомление до 72 часа и окончателен доклад до 1 месец. Часовникът тръгва от момента, в който общината узнае за значим инцидент, а не от момента, в който го разреши.
• Добрата политика се събира на 8 до 12 страници и отговаря на пет въпроса: какво е инцидент, кой какво прави, как се класифицира, как се документира и на кого се докладва. По-дълъг документ обикновено не се чете и не се прилага.
• Най-честата грешка не е липсата на политика, а политика без назначен отговорник и без нито едно проведено учение. Документ, който никой не е репетирал, се проваля точно в часа, в който е нужен.
• Когато инцидентът засяга лични данни, тече и втори, независим срок - уведомление до КЗЛД в рамките на 72 часа по GDPR. Политиката трябва да предвиди и двата часовника едновременно.
• Политиката е жив документ. Минимумът за поддръжка е едно настолно учение и един преглед годишно, плюс актуализация след всеки реален инцидент. Това е малко работа, която спестява хаос.

Лесно е общинската администрация да възприеме политиката за инциденти като поредния документ, който се пише, защото го изисква закон, и след това се прибира в папка. Това е грешка, която струва скъпо, и си струва да обясним защо.

Първата причина е правна. Управлението на инцидентите е изрично сред 13-те минимални мерки по чл. 21 от Закона за киберсигурност. Общината попада в обхвата на закона като съществен субект от сектор "Публична администрация" и дължи тези мерки в действащ вид. ОЕЦ има правомощие да извършва проверки, а при проверка първото, което се иска, е документът. Устната увереност "ние знаем какво да правим" няма стойност пред проверяващ. Това, което има стойност, е писмената политика, дневникът на инцидентите и доказателството, че процедурата е репетирана.

Втората причина е оперативна и тя е по-важната. Реалният инцидент не настъпва в удобно време. Той настъпва в петък следобед, когато ИТ отговорникът е в отпуск, или в неделя през нощта, когато дежури само един човек. В този момент никой няма нито спокойствието, нито времето да измисля процедура. Хората правят това, което е записано, или това, което си спомнят, а под напрежение паметта е лош съветник. Писмената политика е разликата между организирана реакция и паника, в която часовникът на закона тече, а никой не го гледа.

Третата причина е свързана с доверието. Общината обработва лични данни на хиляди граждани, данъчна информация, регистри, понякога данни на социално уязвими лица. Когато настъпи инцидент, гражданите, общинският съвет и медиите ще задават въпроси. Община, която може да покаже, че е имала ясна процедура, я е следвала и е докладвала в срок, излиза от ситуацията с непокътната репутация. Община, която импровизира, излиза от нея разклатена дори когато техническата щета е била малка.

Преди да напишете каквато и да е процедура, политиката трябва да даде ясен отговор на два въпроса: какво се счита за инцидент и кога точно стартира срокът за докладване. Ако тези два въпроса останат мъгливи, цялата останала процедура виси във въздуха.

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

Политиката трябва да съдържа практичен критерий, който дежурният служител може да приложи в 23:00 ч. без да звъни на юрист. Добрият критерий е въпрос от рода на: спряла ли е работа на услуга за гражданите, засегнати ли са лични данни, разпространява ли се проблемът, и има ли признаци за умишлено действие. Ако отговорът на който и да е от тези въпроси е "да" или "вероятно", инцидентът се третира като значим, докато не се докаже обратното. По-добре е да задействате процедурата и да я отмените, отколкото да я задействате със закъснение.

Забележете нещо важно за каскадата. Ранното предупреждение в първите 24 часа не е пълен доклад. То е кратко съобщение, че има значим инцидент, с първоначална преценка дали изглежда злонамерен и дали може да има трансгранично отражение. Общината не е длъжна да знае всичко на 24-ия час. Тя е длъжна да каже, че нещо се случва. Подробностите идват с уведомлението на 72-ия час, а анализът на първопричината - с окончателния доклад до един месец.

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

Добрата политика за реакция при инциденти е кратка. Тя се събира на 8 до 12 страници и съдържа девет раздела. Всеки раздел отговаря на конкретен въпрос, който някой ще си зададе по време на реален инцидент. Ако документът ви е по-дълъг от това, рискувате никой да не го прочете докрай. Ако е по-кратък, вероятно пропуска нещо.

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

Вторият проблемен раздел е този за докладването навън. Тук политиката трябва да е безпощадно конкретна: точните срокове, точните канали за подаване на ранното предупреждение и уведомлението, името и телефонът на лицето в общината, което подписва, и отделен, ясно отделен ред за случая със засегнати лични данни и срока към КЗЛД. Обтекаемите формулировки в този раздел са пряка причина за изпуснат срок.

И още нещо. Половината от практическата стойност на политиката е в приложенията, не в основния текст. Списъкът с контакти - вътрешни и външни, с резервни телефони - е документът, който се отваря пръв при реален инцидент. Шаблоните за трите доклада спестяват часове в момент, когато часовете са най-скъпи. Картата на критичните системи на общината казва веднага кое трябва да се защити първо. Политика без приложения е теория. Политика с приложения е инструмент.

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

За общинската администрация работещото разпределение е компактно. То не изисква голям екип. Изисква яснота кой носи коя шапка.

Централната роля е тази на координатора на инцидента. В повечето български общини това е отговорникът по сигурността на информацията, а когато общината е възложила тази функция външно, координаторът е виртуалният CISO. Координаторът не е човекът, който поправя сървъра. Той е човекът, който държи цялостната картина: класифицира инцидента, решава дали е значим, води дневника в реално време, изготвя трите доклада и следи часовника. Без назначен координатор всеки инцидент се разпада на паралелни, несвързани усилия.

Кметът или секретарят носи крайната отговорност и две конкретни задачи: одобрява докладите, които излизат навън от името на общината, и решава кой и какво казва на гражданите и медиите. Това не е символична роля. Доклад до компетентен орган, изпратен без знанието на ръководството, и противоречиви публични изявления са два от най-честите начини един овладян технически инцидент да се превърне в репутационна криза.

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

Сърцето на политиката е процедурата: какво се прави, в какъв ред, от момента на сигнала до затварянето на инцидента. Тя следва шест етапа, които си струва да са изброени точно в този ред, защото редът предотвратява типичните грешки.

Етап първи е откриване и регистриране. Сигнал постъпва - от служител, от автоматична аларма, от външен орган. Координаторът открива нов запис в дневника на инцидента с дата, час и източник на сигнала. От тази минута всичко се документира.

Етап втори е класификация. Координаторът преценява тежестта и решава дали инцидентът е значим. Това решение задейства или не задейства часовника за докладване навън, затова е критично и не бива да се отлага. При съмнение инцидентът се класифицира нагоре, не надолу.

Етап трети е ограничаване. Целта е проблемът да спре да се разпространява: изолиране на засегнатия компютър от мрежата, блокиране на компрометиран акаунт, спиране на засегната услуга. Важно е политиката да подчертае, че ограничаването не означава унищожаване на доказателства - компютърът се изолира, но не се форматира.

Етап четвърти е изкореняване и възстановяване: премахване на причината и връщане на системите в безопасно работно състояние от проверени резервни копия. Етап пети е докладване по каскадата от срокове. Етап шести е преглед след инцидента - спокоен анализ какво се случи, какво проработи и какво трябва да се промени в политиката.

Класификацията заслужава внимание, защото точно тук общините най-често грешат. Има две посоки на грешката. Едната е класифициране надолу - желанието проблемът да изглежда малък, за да не се налага докладване, защото докладването се възприема като признаване на провал. Това е опасно: ако инцидентът по-късно се окаже значим, общината е изпуснала срок и е добавила към техническия проблем и нарушение на закона. Другата посока е парализа - инцидентът не се класифицира изобщо, защото никой не иска да поеме решението. Решението е политиката изрично да назначи класификацията като задача на координатора и да каже ясно, че при съмнение нивото се качва.

Полезно е политиката да съдържа три или четири нива на тежест с кратко описание какво задейства всяко. Ниският инцидент се обработва вътрешно и само се вписва в дневника. Средният активира екипа и се следи отблизо. Високият, тоест значимият инцидент, задейства цялата каскада от срокове за докладване. Когато нивата са описани с конкретни примери, познати на общинските служители, класификацията спира да бъде източник на колебание.

Документирането не е бюрокрация след инцидента. То е дейност, която тече по време на инцидента, и е причината общината да може да докладва в срок и да премине проверка. Има два слоя документиране: дневникът на инцидента, който се води в реално време, и трите доклада навън.

Дневникът на инцидента е хронологичен запис. Всяко действие, всяко решение, всяко наблюдение се вписва с дата и час. Кой подаде сигнала и кога. Кога инцидентът беше класифициран и на какво ниво. Кога засегнатият компютър беше изолиран. Кога беше изпратено ранното предупреждение. Този запис изглежда дребнав, докато не дойде моментът да се пише окончателният доклад или да се отговаря на ОЕЦ - тогава дневникът е единственото нещо, което превръща мъгливия спомен в точна картина. Той трябва да е достъпен за хората, които го водят, и защитен от подправяне.

Шаблоните за трите доклада трябва да са готови предварително и да стоят като приложения към политиката. Никой не бива да съчинява структурата на доклад до компетентен орган в часовете, в които часовникът тече. Готовият шаблон с предварително попълнени полета - наименование на общината, лице за контакт, начин на подаване - оставя на координатора само да впише фактите по конкретния инцидент. Това спестява час или два в момент, когато всеки час е скъп.

Има и един въпрос за съхранението на доказателствата, който политиката трябва да уреди. При значим инцидент засегнатите компютри, дневниците на системите и образите на дисковете може да са нужни седмици по-късно - за окончателния доклад, за проверка, понякога за работа с органите на реда. Политиката трябва да укаже, че тези доказателства не се изтриват и не се припокриват, докато инцидентът не бъде официално закрит. Това е дребно правило, което общините редовно пропускат и съжаляват.

Виждали сме много общински политики за инциденти. Грешките се повтарят и почти всички са поправими, ако ги познавате предварително.

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

Ако започвате от нула, реалистичният път е следният. Адаптирайте шаблона към своята община за една до две седмици. Дайте го за одобрение от ръководството с протокол. Проведете първото настолно учение в рамките на месец след одобрението. Така до 1 юни 2026 г. общината има не просто документ, а документ, който поне веднъж е бил изпробван и чиито роли хората познават.

Как помага Atlant Security

Политика, която работи в часа, в който е нужна

Изготвяме политики за реакция при инциденти за общинската администрация, адаптирани към реалните системи, длъжности и капацитет на конкретната община. Документът не е преписан шаблон - той е готов за одобрение от ръководството и идва с приложенията, които носят половината от стойността му: списък с контакти, шаблони за трите доклада, дневник на инцидента, карта на критичните системи.

• Политика, съобразена с чл. 21 от ЗКС и каскадата от срокове 24/72 часа
• Готови приложения: контакти, шаблони за доклади, дневник, карта на системите
• Настолно учение с екипа на общината, за да не е документът само на хартия
• Покритие и на 72-часовия срок към КЗЛД при засегнати лични данни
• Възможност функцията на координатор да се поеме от виртуален CISO

Запазете 30-минутен разговор →

Преди 1 юни 2026 г.

Дайте на общината политика, която ще издържи реален инцидент.

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