NIS2 срещу ISO 27001 - къде остават пропуски
Ако вече имате ISO 27001, може да си мислите, че Директива NIS2 не ви касае допълнително. Истината е по-нюансирана.
Промените в Закона за киберсигурност (ЗКС, ДВ, бр. 17/2026), транспониращи Директива (ЕС) 2022/2555 (NIS2), въвеждат 12 конкретни мерки за сигурност в чл. 22 от ЗКС (съответстващи на чл. 21 от Директивата). ISO 27001 покрива част от тях - но не всички и не в необходимата дълбочина.
В тази статия ще съпоставим всяка от 12-те мерки с контролите от Annex A на ISO 27001:2022, ще посочим точно къде остават пропуски и ще ви дадем практични стъпки за действие. Ако не сте сигурни дали организацията ви попада в обхвата на ЗКС, започнете с безплатната NIS2 самооценка.
12-те мерки и ISO 27001 - бърз преглед
Таблицата по-долу съпоставя всяка мярка по чл. 22 от ЗКС с приложимите контроли от Annex A на ISO 27001:2022.
| Мярка по чл. 22 от ЗКС | ISO 27001 контроли | Покритие |
|---|---|---|
| 1. Анализ на риска и политика за сигурност | A.5.1, 6.1/8.2/8.3 | Частично |
| 2. Реагиране при инциденти | A.5.24–A.5.27 | Частично |
| 3. Непрекъсваемост и управление на кризи | A.5.29–A.5.30 | Частично |
| 4. Сигурност на веригата за доставки | A.5.19–A.5.22 | Частично |
| 5. Сигурност при разработка и поддръжка | A.8.25–A.8.28 | Пълно |
| 6. Оценка на ефективността | A.5.35–A.5.36 | Частично |
| 7. Кибер хигиена и обучение | A.6.3 | Частично |
| 8. Криптография | A.8.24 | Пълно |
| 9. Контрол на достъпа и управление на активи | A.5.9–A.5.18, A.8.2, A.8.18 | Частично |
| 10. Многофакторно удостоверяване | A.8.5 | Частично |
| 11. Управление на промените | A.8.9, A.8.32 | Пълно |
| 12. Управление на риска по веригата (CER) | A.5.19–A.5.23 | Частично |
Равносметката: 3 мерки с пълно покритие, 9 с частично. ISO 27001 е необходима основа, но не е достатъчна за съответствие с ЗКС.
Какво вече покривате с ISO 27001
Добрата новина: ако имате сертификация по ISO 27001:2022, три от дванадесетте мерки по чл. 22 от ЗКС вече са покрити.
Сигурност при разработка и поддръжка (т. 5) - Annex A контроли A.8.25–A.8.28 обхващат сигурния жизнен цикъл на разработка, тестови среди, изисквания за сигурност и управление на промени в кода. Точно това изисква и ЗКС.
Криптография (т. 8) - A.8.24 покрива политиката за криптографска защита, включително управление на ключове. Изискванията на ЗКС тук не надхвърлят ISO стандарта.
Управление на промените (т. 11) - A.8.9 и A.8.32 обхващат управлението на конфигурации и промени. ЗКС не добавя изисквания отвъд стандарта.
Тези три области вече са документирани, одитирани и поддържани чрез вашата СУИС. Не е нужно да ги преизграждате - просто се уверете, че са актуални.
Къде остават пропуски - 9-те мерки, които изискват допълнителна работа
Тук е същинската стойност на тази статия. За всяка от деветте частично покрити мерки обясняваме какво точно добавя ЗКС отвъд ISO 27001.
1. Анализ на риска и политика за сигурност (т. 1)
ISO 27001 изисква методология за оценка на риска (клауза 6.1.2) и третиране на риска (клауза 8.3). Процесът е солиден, но ЗКС добавя секторно-специфични изисквания: регулаторът може да определи минимална периодичност на прегледа на риска и задължителни сценарии за вашия сектор. ISO 27001 покрива „как” да управлявате риска, но ЗКС може да диктува „кога” и „за какво конкретно”.
Какво да направите: Проверете дали вашата оценка на риска включва сценарии, специфични за сектора ви, и дали честотата на преглед отговаря на регулаторните указания.
2. Реагиране при инциденти (т. 2)
Това е най-голямата разлика между двата стандарта. ISO 27001 (контроли A.5.24–A.5.27) изисква план за реагиране при инциденти. ЗКС обаче въвежда конкретни срокове за докладване към СЕРИКС (чл. 23 от ЗКС):
- 24 часа - ранно предупреждение от момента на узнаване
- 72 часа - пълно уведомление с оценка на въздействието
- 1 месец - окончателен доклад с анализ на причините и предприетите мерки
Тези срокове просто не съществуват в ISO 27001. Нямате ги документирани, нямате ги тествани, нямате определени роли за комуникация с СЕРИКС. Ако разчитате само на ISO стандарта, при реален инцидент ще нарушите закона още в първите 24 часа.
Какво да направите: Създайте процедура за докладване към СЕРИКС с ясни роли, шаблони и ескалационна верига. Тествайте я с настолно учение.
3. Непрекъсваемост и управление на кризи (т. 3)
ISO 27001 покрива ИКТ готовност за непрекъсваемост (A.5.30), но ЗКС изисква изрична рамка за управление на кризи - не само технологично възстановяване, а координиран организационен отговор при мащабен кибер инцидент. Трябва да имате стратегия за резервно копиране и възстановяване, но и ясна командна верига при криза.
Какво да направите: Допълнете плана за непрекъсваемост с кризисен протокол - кой взема решения, как се комуникира с регулатора, клиентите и медиите.
4. Сигурност на веригата за доставки (т. 4)
ISO 27001 (A.5.19–A.5.22) обхваща управлението на взаимоотношенията с доставчици. ЗКС обаче добавя изрично изискване за оценка на уязвимостите на преките доставчици (чл. 22, ал. 3 от ЗКС). Не е достатъчно да имате договорни клаузи - трябва активно да оценявате нивото на киберсигурност на доставчиците си.
Какво да направите: Въведете периодична оценка на сигурността на ключовите доставчици - въпросник, одит или изискване за сертификация.
5. Оценка на ефективността (т. 6)
ISO 27001 изисква вътрешен одит (клауза 9.2) и преглед от ръководството (9.3). ЗКС обаче може да изисква конкретни KPI за киберсигурност - не просто „одитираме се периодично”, а измерими показатели: среден час за реагиране при инцидент, процент на служители, преминали обучение, брой непатчнати уязвимости.
Какво да направите: Дефинирайте поне 5–7 KPI за киберсигурност и ги включете в прегледа от ръководството.
6. Кибер хигиена и обучение (т. 7)
ISO 27001 (A.6.3) изисква обучение за осведоменост. ЗКС отива значително по-далеч: чл. 21 от ЗКС изрично задължава ръководството да преминава обучение по киберсигурност и носи лична отговорност за неизпълнение. Това не е „изпратете имейл на всички за фишинга”. Това е структурирана програма с фиксиран двугодишен интервал, която включва борда на директорите.
Какво да направите: Организирайте целево обучение за висшето ръководство - не общо ИТ обучение, а фокусирано върху управленска отговорност по ЗКС и вземане на решения при кибер инциденти.
7. Контрол на достъпа и управление на активи (т. 9)
ISO 27001 (A.5.9–A.5.18) покрива инвентаризация на активи, класификация и контрол на достъпа. Но ENISA Technical Implementation Guidance (юни 2025) и ЗКС изискват изрично управление на привилегиран достъп (A.8.2) и контрол на привилегировани помощни програми (A.8.18). Ако нямате отделна политика за привилегировани акаунти - администраторски достъпи, сервизни акаунти, root достъп - имате пропуск.
Какво да направите: Въведете управление на привилегиран достъп (PAM) - отделна процедура за предоставяне, преглед и отнемане на администраторски права. Ограничете и документирайте използването на привилегировани помощни програми.
8. Многофакторно удостоверяване (т. 10)
ISO 27001 (A.8.5) изисква „сигурно удостоверяване”, но не конкретизира метода. ЗКС изрично изисква многофакторно или непрекъснато удостоверяване за критични системи. Ако разчитате само на пароли - дори сложни - не покривате изискването.
Какво да направите: Внедрете MFA за всички критични системи и административни достъпи. Документирайте къде се прилага и обосновете изключенията.
9. Управление на риска по веригата - CER (т. 12)
Тази мярка е специфична за субекти, попадащи и под Директива (ЕС) 2022/2557 за устойчивостта на критичните субекти (CER). Изисква междусекторна оценка на риска, която надхвърля класическата оценка на ИТ риска. ISO 27001 не покрива физическата устойчивост и кроссекторните зависимости, които CER директивата изисква.
Какво да направите: Ако попадате под CER, допълнете оценката на риска с анализ на физическите и междусекторните зависимости.
ENISA потвърждава - ISO 27001 е начало, не край
Не сме единствените, които правят това съпоставяне. ENISA публикува техническо ръководство за внедряване (юни 2025) - 170 страници с детайлно картографиране на изискванията по чл. 21 от Директива NIS2 към ISO 27001 и други стандарти. Изводът е същият: ISO 27001 е отлична основа, но не покрива всички изисквания.
За субекти от цифровата инфраструктура изискванията са още по-детайлни - Регламент за изпълнение (ЕС) 2024/2690 разбива мерките на 49 подизисквания с конкретни критерии за съответствие. Ние анализирахме тези 170 страници на английски, за да ви дадем практичния извод на български - и таблицата по-горе е резултатът.
Какво да направите - три пътя
Правилният подход зависи от вашата отправна точка.
Път А: „Имам ISO 27001”
Вие сте в добра позиция - основата е налице. Фокусирайте се върху деветте частично покрити мерки. Най-критичните стъпки:
- Процедура за докладване на инциденти към СЕРИКС с конкретни срокове (24 ч / 72 ч / 1 м)
- Обучение на ръководството по чл. 21 от ЗКС с документирана периодичност
- Оценка на доставчиците - активна, не само договорна
Подготвяме NIS2 Toolkit за внедряване с готово съпоставяне на контроли - свържете се с нас, за да разберете първи когато е наличен.
Път Б: „Нямам ISO 27001, но трябва да спазвам NIS2”
Добрата новина: можете да внедрите и двете едновременно. ISO 27001 сертификацията ви дава структурата, а NIS2 допълненията се надграждат естествено. Вместо два отделни проекта, правите един интегриран - спестявате време и ресурси.
Започнете с безплатната NIS2 самооценка, за да разберете мащаба на задачата.
Път В: „Не знам дали попадам под NIS2”
Направете безплатната NIS2 самооценка - отнема под 5 минути. Ако резултатът покаже, че попадате в обхвата, прочетете подробното ръководство за обхвата на NIS2.
Следващата стъпка
ISO 27001 ви дава преднина - но не и пълно съответствие. Колкото по-рано идентифицирате пропуските, толкова повече време имате да ги адресирате преди регулаторните проверки.
- Безплатна NIS2 самооценка - разберете дали попадате в обхвата
- NIS2 GAP анализ - идентифицираме конкретните пропуски за вашата организация
- Какво се промени в ЗКС - пълен преглед на законодателните промени
Нека поговорим за вашата конкретна ситуация - свържете се с нас.