NIS2, организациите и доставчиците на софтуер: какво трябва да направят двете страни

01Докъде е стигнала NIS2 през есента на 2026 г.

Директивата NIS2 (отваря външен сайт), Директива (ЕС) 2022/2555, е обнародвана в Официален вестник на 27 декември 2022 г. и е в сила от 16 януари 2023 г. Държавите членки трябваше да приемат и публикуват националните си мерки до 17 октомври 2024 г. и да ги прилагат от 18 октомври 2024 г., когато първата директива в тази област, Директива (ЕС) 2016/1148, беше отменена.

Тъй като NIS2 е директива, организацията е обвързана от националния закон, който я въвежда. Въвеждането протича неравномерно: някои държави членки прилагат закона си навреме, други едва през 2025 или 2026 г., а Европейската комисия започна производства за нарушение срещу държавите, които пропуснаха срока. В България NIS2 е въведена с изменения на Закона за киберсигурност (ДВ, бр. 17 от 13 февруари 2026 г.), които са в сила от 17 февруари 2026 г.; законът е изменен отново с ДВ, бр. 55 от 16 юни 2026 г. Задълженията за регистрация, каналите за докладване и надзорните органи затова се различават в отделните държави.

02Съществени и важни субекти

NIS2 се прилага за публични и частни субекти в секторите по приложение I (с висока критичност: енергетика, транспорт, банково дело, инфраструктури на финансовия пазар, здравеопазване, питейна вода, отпадъчни води, цифрова инфраструктура, управление на ИКТ услуги, публична администрация и космическо пространство) и по приложение II (други критични сектори: пощенски и куриерски услуги, управление на отпадъците, химикали, храни, производство, цифрови доставчици и научни изследвания). По правило обхваща средните и големите организации. Някои субекти са в обхвата независимо от размера си, например доставчиците на удостоверителни услуги, доставчиците на DNS услуги и субектите на централната държавна администрация.

Член 3 разделя тези организации на две категории:

• Съществени субекти: основно големи организации в секторите по приложение I, както и субекти, които са съществени независимо от размера си, например доставчиците на квалифицирани удостоверителни услуги, регистрите на имена на домейни от първо ниво, доставчиците на DNS услуги и субектите на централната държавна администрация. Надзорът над тях е проактивен и може да включва одити и проверки на място.
• Важни субекти: останалите организации в обхвата на приложения I и II. Надзорът е последващ: органът действа, когато има данни, че субектът не спазва изискванията.

Двете категории имат едни и същи основни задължения: мерки за управление на риска (член 21), докладване на инциденти (член 23) и отговорност на ръководството (член 20). Разликата е в надзора и в глобите. За нарушения на член 21 или член 23 директивата изисква националното право да предвижда максимални глоби от най-малко 10 000 000 евро или 2% от общия световен годишен оборот за съществените субекти и от най-малко 7 000 000 евро или 1,4% за важните субекти, като се прилага по-голямата сума. Държавите членки решават дали и доколко глобите се прилагат за субектите на публичната администрация.

Попада ли самият Ви доставчик на софтуер в обхвата?

Разработката на софтуер сама по себе си не е сектор по NIS2. Доставчикът все пак може да попада пряко в обхвата. Приложение I обхваща доставчиците на управлявани услуги, а NIS2 ги определя широко: субекти, които инсталират, управляват, експлоатират или поддържат ИКТ продукти, мрежи, инфраструктура или приложения за клиенти, на място или от разстояние. Затова средно или голямо предприятие, което експлоатира или поддържа приложения за клиентите си, може да попада под NIS2 самостоятелно, както и доставчиците на услуги за облачни изчисления и на услуги на центрове за данни. За тези доставчици Регламент за изпълнение (ЕС) 2024/2690 (отваря външен сайт) описва подробно техническите изисквания. Това може да се отнася и за български ИТ компании, които поддържат системи на клиенти в страната и в чужбина.

Повечето доставчици на софтуер обаче срещат NIS2 чрез клиентите си, които превръщат собственото си задължение за веригата за доставка в договорни клаузи, въпросници и одити. Софтуерните продукти попадат и под Акта за киберустойчивост (отваря външен сайт), Регламент (ЕС) 2024/2847: задълженията му за докладване на активно използвани уязвимости и тежки инциденти се прилагат от 11 септември 2026 г., а останалите задължения от 11 декември 2027 г.

03Десетте минимални мерки по член 21

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

1. 01политики за анализ на риска и сигурност на информационните системи;
2. 02действия при инциденти;
3. 03непрекъснатост на дейността, например управление на резервните копия и възстановяване след бедствия, и управление на кризи;
4. 04сигурност на веригата за доставка, включително аспектите на сигурността в отношенията с преките доставчици на продукти и услуги;
5. 05сигурност при придобиването, разработването и поддръжката на мрежови и информационни системи, включително действия при уязвимости и оповестяването им;
6. 06политики и процедури за оценка на ефективността на тези мерки;
7. 07основни практики за киберхигиена и обучение по киберсигурност;
8. 08политики и процедури за използване на криптография и, където е целесъобразно, криптиране;
9. 09сигурност на човешките ресурси, политики за контрол на достъпа и управление на активите;
10. 10многофакторно или непрекъснато удостоверяване и защитени гласови, видео и текстови съобщения и системи за спешна комуникация, където е целесъобразно.

Точки 4 и 5 са мястото, където се включват доставчиците. Член 21, параграф 3 изисква субектите да отчитат уязвимостите, характерни за всеки пряк доставчик, цялостното качество на продуктите и практиките му в киберсигурността, както и процедурите му за сигурна разработка. От клиентите Ви се очаква да гледат как разработвате софтуера, а не само какво доставяте.

04Ръководството одобрява, наблюдава и отговаря

Съгласно член 20 управителните органи на съществените и важните субекти трябва да одобряват мерките за управление на риска в областта на киберсигурността, да наблюдават прилагането им и могат да носят отговорност за нарушения. Членовете им трябва да преминават обучение, а субектите се насърчават редовно да обучават и служителите си. За публичните органи продължават да се прилагат националните правила за отговорността на публичните институции и длъжностните лица.

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

05Докладване на инциденти: 24 часа, 72 часа, един месец

Член 23 изисква субектите да докладват значителните инциденти на екипа за реагиране при инциденти с компютърната сигурност или на компетентния орган. Инцидентът е значителен, ако е причинил или може да причини сериозно оперативно смущение или финансова загуба за субекта или значителни материални или нематериални вреди за други лица. По българския закон компетентните органи получават уведомленията чрез екипите за реагиране: секторните (СЕРИКС) и националния (НЕРИКС). Докладването протича на етапи:

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

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

06Какво ще поиска клиент по NIS2 от доставчика си на софтуер

На практика член 21 се превръща в технически мерки и доказателства, които доставчикът трябва да може да покаже, без да започва нов проект. Най-често срещаните:

• Сигурен жизнен цикъл на разработката. Моделиране на заплахите при значими промени, преглед на кода от колеги, автоматизирани тестове за сигурност и проверка на зависимостите във веригата за внедряване, подписани компилации и списък на софтуерните компоненти (SBOM) за всяка версия.
• Обработка и оповестяване на уязвимости. Публикуван начин за докладване на уязвимости, договорени срокове за реакция според тежестта и уведомление до клиента, когато уязвимост засяга неговата среда.
• Контрол на достъпа за служителите на доставчика. Поименни акаунти, многофакторно удостоверяване, минимални права, временен повишен достъп и запис на всяко административно действие в средата на клиента.
• Записи и доказателства при инциденти. Събития, свързани със сигурността, записани с надеждни времеви отпечатъци, съхранявани за договорен срок и с възможност за експорт, така че клиентът да може да отговори на въпросите на ранното предупреждение и на окончателния доклад.
• Сътрудничество при инциденти. Определено лице за контакт и канал, срок за уведомяване далеч в рамките на 24-те часа на клиента и помощ при анализа на първопричината.
• Непрекъснатост и възстановяване. Резервни копия, доказани чрез възстановяване, цели за възстановяване, съгласувани с тези на клиента, и отработена процедура.
• Документация за веригата за доставка. Актуален списък на подизпълнителите и местата на хостинг, както и на основните компоненти и услуги на трети страни, от които зависи решението.
• Изходен план. Експорт на данните в използваеми формати, документация и помощ при предаването, така че клиентът да може да смени доставчика, без да губи контрол над услугата.

Нищо от това не е ново за зрелите инженерни екипи. NIS2 променя това, че клиентът трябва да може да го докаже. Страницата ни Доверие и съответствие описва как работим като доставчик, включително системата ни за управление на информационната сигурност, сертифицирана по ISO/IEC 27001.

07Контролен списък за договорите и обществените поръчки

1. 01Свържете доставчиците с услугите. Запишете кои доставчици поддържат кои услуги в обхвата и кои имат достъп до системите или данните Ви.
2. 02Класифицирайте според критичността. Прилагайте най-строгите изисквания към доставчиците, които експлоатират или могат да променят критични системи.
3. 03Впишете мерките в договора. Изисквания за сигурност, срок и канал за уведомяване при инцидент, обработка на уязвимости, записи и срок за съхранението им, права на одит или на доказателства, правила за подизпълнители и места. При обществените поръчки по ЗОП включете тези изисквания още в техническата спецификация.
4. 04Искайте доказателства, а не декларации. Сертификати с обхвата им, резултати от тестове, SBOM, датата на последния тест за възстановяване.
5. 05Договорете изхода предварително. Връщане на данните, помощ при прехода и периодът, в който доставчикът продължава да поддържа услугата.
6. 06Упражнявайте заедно. Проведете учение за инцидент с критичните си доставчици, включително ранното предупреждение до 24 часа.
7. 07Преглеждайте редовно. Доставчиците, услугите и заплахите се променят; регистър на доставчиците, обновяван веднъж годишно, е остарял през по-голямата част от годината.

08Подробностите решава националният закон

Регистрацията, каналите за докладване, формулярите, компетентният орган и допълнителните изисквания идват от националното право. По правило субектът попада под юрисдикцията на държавата членка, в която е установен. Член 26 предвижда изключения: доставчиците на обществени електронни съобщителни услуги попадат под всяка държава, в която предоставят услуги, доставчиците на облачни услуги, центрове за данни и управлявани услуги и няколко други цифрови доставчици под държавата на основното си място на стопанска дейност, а субектите на публичната администрация под държавата, която ги е създала. В България Законът за киберсигурност възлага на Министерския съвет с решение да определи националните компетентни органи за секторите по приложения I и II, освен ако специален закон не ги създава. Според закона в сегашната му редакция (с измененията от юни 2026 г.) Министерството на иновациите и дигиталната трансформация е компетентен орган за всички административни органи и към него е Националното единно звено за контакт; от май 2026 г. Министерството на електронното управление е част от това министерство. Компетентните органи идентифицират съществените и важните субекти по методика, приета от Министерския съвет. За доставчиците на министерства, агенции и общини това означава, че клиентите им вече имат конкретен надзорен орган.

09Какво да следите през следващите месеци

• Прилагането на Закона за киберсигурност в България: актовете на Министерския съвет за секторните компетентни органи и за идентифицирането на субектите, както и указанията на компетентния за Вашия сектор орган.
• Предложението на Комисията за сборен пакет от мерки в областта на цифровите технологии (отваря външен сайт) от 19 ноември 2025 г., COM(2025) 837, според което докладите за инциденти по NIS2, Общия регламент относно защитата на данните (GDPR), DORA и други актове ще минават през единна входяща точка, поддържана от ENISA. През октомври 2026 г. то все още се разглеждаше от Европейския парламент (отваря външен сайт)); докато не бъде прието и не започне да се прилага, остават сегашните канали и срокове.
• Координираните оценки на риска на ниво ЕС за критичните вериги за доставка на ИКТ по член 22, които субектите трябва да отчитат при избора на мерки за доставчиците си.
• Графика на Акта за киберустойчивост за софтуерните продукти, който се прилага изцяло от 11 декември 2027 г.

За финансовите субекти Регламентът относно оперативната устойчивост на цифровите технологии замества правилата на NIS2 за управлението на риска в областта на ИКТ, докладването на инциденти и надзора; вижте статията ни DORA и трети страни доставчици на ИКТ услуги. Комисията поддържа преглед на NIS2 и актовете за изпълнението ѝ на своята страница за NIS2 (отваря външен сайт).