10-те задължителни мерки по NIS2 — какво означават на практика за българска фирма

Съществените и важните субекти трябва да прилагат десетте мерки по чл. 21 от NIS2 — от анализа на риска и действията при инцидент до криптографията и многофакторното удостоверяване. Българският закон ги въвежда в чл. 22 и добавя две точки. Мерките са пропорционални на риска, а проверяващият иска доказателства, не намерения.

Кои са задължителните мерки по NIS2 и как ги въвежда българският закон?

Директивата изброява десет минимални мерки в чл. 21, пар. 2, а Законът за киберсигурност ги възпроизвежда в чл. 22, ал. 2 като точки 1–10 и добавя още две. Мерките трябва да са технически, оперативни и организационни, да обхващат всички опасности и да са пропорционални на риска, размера и вероятността от инциденти.

Задълженията важат за съществените и важните субекти от 17 февруари 2026 г., когато влязоха в сила измененията на закона, обнародвани в ДВ бр. 17 от 13 февруари 2026 г. Дали фирмата ви е такъв субект, проверете с нашия тест за обхвата. Пропорционалността не е освобождаване: при преценката се отчитат „степента на излагане на рискове на субекта, размерът на субекта и вероятността от възникване на инциденти, както и тяхната значимост“ (чл. 22, ал. 1), но всяко от направленията трябва да бъде покрито.

За доставчиците на DNS услуги, регистрите на домейни от първо ниво, облачните услуги, центровете за данни, мрежите за доставка на съдържание, управляваните услуги и управляваните услуги за сигурност, онлайн местата за търговия, търсачките, социалните мрежи и удостоверителните услуги техническите изисквания са определени пряко в Регламент за изпълнение (ЕС) 2024/2690. За останалите той не е задължителен, но според нас е най-добрият наличен ориентир какво означава „подходяща“ мярка. Националната наредба за минималните мерки трябва да бъде приведена в съответствие със закона до 17 октомври 2026 г.; както към октомври 2026 г. проект не е публикуван и действа наредбата от 2019 г.

Във всеки раздел по-долу описваме практическия минимум, доказателствата, които проверяващият обичайно иска (по техническите насоки на ENISA от юни 2025 г.), и съответните контроли от ISO/IEC 27001:2022 според таблицата за съпоставка на ENISA. ENISA изрично уточнява, че съпоставката не означава еквивалентност между стандартите.

1. Какво изисква политиката за анализ на риска и сигурност на информационните системи?

Мярката изисква две неща: документирана политика за сигурност на мрежовите и информационните системи, одобрена от ръководството, и работещ процес за оценка и третиране на риска. По Регламент 2024/2690 и двете се преглеждат поне веднъж годишно и след значителен инцидент или промяна — разумен ориентир и за останалите субекти.

Практически минимум. Обща политика за сигурност с цели, роли и отговорности, одобрена от управителния орган — по чл. 21, ал. 1 от закона ръководството одобрява мерките и следи прилагането им. Регистър на рисковете, който обхваща не само кибератаките, а всички опасности, включително природни и физически. План за третиране на риска, при който остатъчните рискове се приемат от ръководството или от лице с правомощия (Регламент 2024/2690, приложение, т. 1.1, 1.2 и 2.1).

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

ISO/IEC 27001:2022. Клаузи 5.2, 6.1, 8.2, 8.3 и 9.3 и контролите A.5.1 „Policies for information security“ и A.5.4 „Management responsibilities“.

2. Как да организирате действията при инцидент?

Нужни са политика и процедура за откриване, анализ, ограничаване, възстановяване, документиране и докладване на инциденти, с ясни роли и критерии кога инцидентът е значителен. За значителните инциденти законът изисква ранно предупреждение до секторния екип за реагиране (СЕРИКС) до 24 часа, уведомление до 72 часа и окончателен доклад до един месец.

Практически минимум. Политика за действия при инцидент с категоризация на събитията и критерии за значителност. Значителен е инцидентът, който причинява или може да причини сериозно оперативно смущение или финансова загуба или значителни вреди за други лица (§ 3, т. 57 от допълнителните разпоредби на закона). Прост канал, по който служители, доставчици и клиенти съобщават подозрителни събития, журнали и наблюдение на критичните системи, готови шаблони за трите уведомления по чл. 23, ал. 5 и преглед след всеки значителен инцидент с анализ на първопричината (Регламент 2024/2690, приложение, т. 3.1–3.6). Ако инцидентът засяга лични данни, паралелно тече 72-часовото уведомление до КЗЛД по GDPR.

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

ISO/IEC 27001:2022. A.5.24 „Information security incident management planning and preparation“, A.5.25–A.5.27 (оценка, реагиране и поуки), A.6.8 „Information security event reporting“, A.8.15 „Logging“ и A.8.16 „Monitoring activities“.

3. Какво означават непрекъснатост на дейността, резервни копия и управление на кризи?

Мярката изисква план за непрекъснатост на дейността и възстановяване след бедствие, основан на оценката на риска, управление на резервните копия и процедура за управление на кризи. На практика проверяващият иска да види не само, че правите резервни копия, а че периодично възстановявате данни от тях и сте изпитали плановете си.

Практически минимум. Анализ на въздействието върху дейността и целево време за възстановяване на критичните системи. Резервни копия, включително на конфигурациите и на данните в облака, съхранявани на сигурно място или места, които „не са в същата мрежа като системата“ и са на достатъчно разстояние от основния обект. Редовни проверки на целостта на копията и изпитвания на възстановяването. Изпитване и преглед на плановете през планирани интервали и след значителни инциденти, както и ясни роли и канали при криза (Регламент 2024/2690, приложение, т. 4.1–4.3).

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

ISO/IEC 27001:2022. A.5.29 „Information security during disruption“, A.5.30 „ICT readiness for business continuity“, A.8.13 „Information backup“ и A.8.14 „Redundancy of information processing facilities“.

4. Как се управлява сигурността на веригата за доставка?

Трябва да управлявате рисковете, които идват от преките ви доставчици на ИКТ продукти и услуги. Законът изисква да отчитате уязвимостите на всеки пряк доставчик, качеството на продуктите и практиките му за сигурност, включително процедурите за сигурно разработване, както и резултатите от координираните оценки на риска на равнище ЕС (чл. 22, ал. 3).

Практически минимум. Политика за сигурност на веригата за доставка и регистър на преките доставчици с контакти и предоставяните ИКТ продукти и услуги, подредени по критичност. В договорите, когато е целесъобразно: изисквания за киберсигурност и обучение, проверка на персонала на доставчика, задължение за уведомяване за инциденти без неоправдано забавяне, право на одит или на одитни доклади и задължение за отстраняване на уязвимости (Регламент 2024/2690, приложение, т. 5.1.4 и 5.2). Редовен преглед на изпълнението и на инцидентите при доставчиците.

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

ISO/IEC 27001:2022. A.5.19 „Information security in supplier relationships“, A.5.20 „Addressing information security within supplier agreements“, A.5.21 „Managing information security in the ICT supply chain“ и A.5.22 „Monitoring, review and change management of supplier services“.

5. Какво се изисква при придобиване, разработване и поддръжка на системите?

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

Практически минимум. Изисквания за сигурност в заданията за доставка на ИКТ и правила за сигурно разработване, ако разработвате сами. Процедура за управление на промените. Корекциите за сигурност се прилагат „в разумен срок“, след изпитване и само от надеждни източници, а когато корекция не бъде приложена — с допълнителни мерки и приет остатъчен риск. Следене на информацията за уязвимости, периодично сканиране, приоритетно третиране на критичните уязвимости, мрежова сегментация и защита от зловреден софтуер (Регламент 2024/2690, приложение, т. 6.1–6.10).

Какво ще поиска проверяващият. Процедурата за корекциите и журнала на внедряването им, приоритизацията на критичните, документираните решения за неприлагане с компенсиращите мерки, оценката на уязвимостите (например по CVSS), актуалните мрежови диаграми и правилата на защитните стени.

ISO/IEC 27001:2022. A.8.8 „Management of technical vulnerabilities“, A.8.25 „Secure development life cycle“, A.8.32 „Change management“, A.8.20 „Networks security“, A.8.22 „Segregation of networks“ и A.8.7 „Protection against malware“.

6. Как се доказва, че мерките действат?

Трябва да можете да докажете, че мерките действат, а не само че са описани. Нужни са политика и процедури, които определят какво се наблюдава и измерва, с какви методи, колко често, кой измерва и кой анализира резултатите, като се отчитат оценката на риска и миналите значителни инциденти.

Практически минимум. Годишен план за оценка, който съчетава самооценка, оценка на уязвимостите, тестове за проникване и вътрешен одит — сред методите, посочени в насоките на ENISA. Няколко постоянни показателя, например дял на обучените служители, време за отстраняване на уязвимостите, брой инциденти и несъответствия. Отчет до ръководството и преглед на политиката при значителни промени и инциденти (Регламент 2024/2690, приложение, т. 7.1–7.3). Независим преглед от лица, които не са подчинени на проверяваната област, а при малки субекти — алтернативни гаранции за безпристрастност (т. 2.3).

Какво ще поиска проверяващият. Документираната политика за оценка, целите и показателите, отчетите до управителните органи, записите от предишни оценки и графика на следващите.

ISO/IEC 27001:2022. Клаузи 6.2, 9.1 и 9.3; за независимия преглед — клауза 9.2 и контролът A.5.35 „Independent review of information security“.

7. Какво е киберхигиена и какво обучение изисква законът?

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

Законът дава и легално определение: киберхигиената е „съвкупност от стандартни практики, процедури и поведенчески модели, прилагани на индивидуално и организационно ниво“, които включват редовна поддръжка и защита на системите и крайните устройства, управление на достъпа, план за реакция при инциденти и обучение на служителите (§ 3, т. 62 от допълнителните разпоредби).

Практически минимум. Програма за осведоменост, планирана във времето, която обхваща новопостъпилите, членовете на ръководството и при нужда преките доставчици (Регламент 2024/2690, приложение, т. 8.1). Обучение на членовете на управителните органи на всеки две години (чл. 21, ал. 2 от закона). Редовно обучение за служителите, чиито функции изискват умения по сигурност, като ефективността му се оценява (т. 8.2). За изграждането на програмата вижте и материала ни за обучение на служители с ролеви учебни планове.

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

ISO/IEC 27001:2022. Клаузи 7.2 и 7.3 и контролът A.6.3 „Information security awareness, education and training“.

8. Кога е задължителна криптографията?

Мярката не изисква всичко да е криптирано. Нужни са политика и процедури, които според класификацията на информацията определят кога и какви криптографски мерки се прилагат за данните в покой и при пренос, кои протоколи и алгоритми са допустими и как се управляват ключовете. Криптирането се прилага, „когато е целесъобразно“.

Практически минимум. Политика за криптографията, свързана с класификацията на активите. Списък с одобрени протоколи, алгоритми и дължини на ключовете, който се обновява при развитие на технологиите. Правила за управление на ключовете — създаване, съхранение, смяна и отнемане (Регламент 2024/2690, приложение, т. 9.1–9.3).

Какво ще поиска проверяващият. Политиката и насоките за криптиране, списъка на допустимите алгоритми и протоколи, мерките за защита на частните ключове, доказателства за криптиране на данните в покой и при пренос и записите от прегледите на политиката.

ISO/IEC 27001:2022. A.8.24 „Use of cryptography“ и A.5.31 „Legal, statutory, regulatory and contractual requirements“.

9. Какво включват сигурността на персонала, контролът на достъпа и управлението на активите?

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

Практически минимум. Пълен, точен и актуален опис на активите с история на промените и класификация на информацията (Регламент 2024/2690, приложение, т. 12.1 и 12.4). Права на достъп по принципите „необходимост да се знае“, „функциониране с най-малка привилегия“ и „разделяне на задълженията“, регистър на правата и периодичен преглед (т. 11.2). Отделни профили за администриране със строго удостоверяване (т. 11.3). Проверка на служителите, доколкото е възможно и пропорционално на ролята (т. 10.2) — при спазване на трудовото законодателство и GDPR, виж проверките на кандидати при наемане. Връщане на активите и отнемане на достъпа при напускане (т. 10.3 и 12.5).

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

ISO/IEC 27001:2022. A.5.9 „Inventory of information and other associated assets“, A.5.15 „Access control“, A.5.18 „Access rights“, A.6.1 „Screening“ и A.6.5 „Responsibilities after termination or change of employment“.

10. Кога е нужно многофакторно удостоверяване и защитени комуникации?

Мярката изисква многофакторно или непрекъснато удостоверяване, защитени гласови, видео и текстови съобщения и защитени системи за спешна комуникация „когато е целесъобразно“. Целесъобразността се преценява по риска и по класификацията на системите, а за субектите по Регламент 2024/2690 решението да не се приложи изискване се обосновава писмено.

Практически минимум. Регламент 2024/2690 изисква многофакторно удостоверяване за достъп до системите, когато е целесъобразно според класификацията на актива (приложение, т. 11.7). Според нас най-напред то трябва да покрие отдалечения достъп, профилите за администриране, електронната поща и облачните услуги. Определете одобрени инструменти за гласова, видео и текстова комуникация и резервен канал за спешна връзка, който работи и при срив на основната инфраструктура.

Какво ще поиска проверяващият. Журнали, които показват използването на многофакторно удостоверяване, конфигурацията на решенията за удостоверяване и политиката за контрол на достъпа, която описва методите, включително дали са устойчиви на фишинг.

ISO/IEC 27001:2022. A.8.5 „Secure authentication“ и A.5.17 „Authentication information“.

Какво добавя българският закон към десетте мерки?

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

• Управление на измененията на информационните активи (чл. 22, ал. 2, т. 11). „Информационни активи“ по закона са не само системите, но и поддържащите ги съоръжения, процесите, служителите и външните организации (§ 3, т. 60). Според нас на практика тази точка се покрива от управлението на промените по мярка 5 и от актуалния опис по мярка 9.
• Обучение на ръководството на всеки две години (чл. 21, ал. 2). Директивата изисква обучение, но не определя периодичност. Нарушението се наказва с лична глоба от 500 до 5000 евро (чл. 29, ал. 4).
• Ограничаване на рискови технологии (чл. 27). Министерският съвет може с постановление да ограничи използването на конкретни технологии или вериги за доставка; засегнатите субекти трябва да ги спрат в тригодишен срок, а при висок риск за националната сигурност — в по-кратък.
• Коригиращи мерки. Когато установите пропуск, трябва да предприемете всички необходими, подходящи и пропорционални коригиращи мерки (чл. 22, ал. 4).

Както към октомври 2026 г. неизпълнението на задълженията за мерки и докладване се наказва с имуществена санкция до 10 млн. евро или 2 % от световния оборот за съществените субекти и до 7 млн. евро или 1,4 % за важните, като минимумите са 25 000 и 12 500 евро (чл. 29, ал. 2 и 3). Повече за санкциите и надзора — в статията ни NIS2 в България.

Адв. Десислава Димитрова & Адв. Йордан Чолаков

Dimitrova, Cholakov & Partners · Innovires

Адв. Димитрова е CIPP/E сертифициран специалист по защита на лични данни с дългогодишен опит в правото на ЕС. Адв. Чолаков е експерт по GDPR съответствие, международни трансфери на данни и подаване на сигнали. Заедно консултират над 90 компании за пълно GDPR съответствие.