Самооценка по НИС2: 25 въпроса, примерни отговори и необходими документи

Въпрос 1. Има ли формално решение на управителния орган за одобряване на мерките по чл. 21?

Добре обоснован отговор: Да, имаме протокол на УС от дата ХХ.ХХ.20ХХ с конкретно решение, в което управителният орган одобрява пакета мерки за управление на риска за киберсигурността и възлага изпълнението на отговорника по сигурност. Протоколът е подписан и съхранен в деловодството.

Отговор, който показва пропуск: „Управителният съвет е запознат с темата“ или „имаме политика, която управителят е подписал“. Запознатост не е одобрение, а политика без отделно решение на УС не доказва участието на ръководството.

Въпрос 2. Кой е назначен отговорник за киберсигурност и какъв е обхватът на правомощията му?

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

Отговор, който показва пропуск: „Темата е на ИТ отдела“ без поименно назначение. Или „имаме CISO, но той докладва на ИТ директора, който докладва на финансовия директор“ - твърде дълга верига, отговорността се разтваря.

Въпрос 3. Кога и как е извършен последният документиран анализ на риска?

Добре обоснован отговор: Последният анализ е извършен в рамките на последните 12 месеца, по структурирана методология (например ISO 27005, NIST RMF или вътрешна, обоснована методология). Резултатът е документ с идентифицирани активи, заплахи, уязвимости, оценка на риска и план за третиране на риска с конкретни срокове. Прегледан и приет от УС.

Отговор, който показва пропуск: „Имаме оценка от 2022 г.“ (твърде стара). Или „имаме списък на рисковете в Excel без методология“. Или „рисковете ги обсъждаме на оперативки“ - без писмен запис не съществуват за проверката.

Въпрос 4. Какъв е годишният бюджет за киберсигурност и как е разпределен?

Добре обоснован отговор: Имаме отделно перо в годишния бюджет, одобрено от УС, с разбивка по основни направления (защитни продукти, услуги, обучение, одити, резерв за инциденти). Бюджетът се изпълнява и при отклонения се докладва.

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

Въпрос 5. Получили ли са членовете на УС обучение по управление на киберриска?

Добре обоснован отговор: Да, в рамките на последните 12 месеца УС е преминал документирано обучение по управление на риска за киберсигурността, с присъствен или удостоверим онлайн формат. Имаме списък с присъстващи и програма на обучението. Планирано е обновяване всяка година.

Отговор, който показва пропуск: „УС е информиран чрез презентация на оперативка“. Или „един от членовете е инженер, другите се доверяват на него“. Чл. 20 изисква обучение на органа като цяло, не разчитане на един човек в него.

Въпрос 6. Имате ли актуален регистър на ИТ активите?

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

Отговор, който показва пропуск: „Списък в Excel от миналата година“ или „имаме инвентаризация от счетоводството“. Счетоводната инвентаризация не съдържа SaaS услуги, виртуални машини и микроуслуги в продукционната среда.

Въпрос 7. Класифицирали ли сте данните според чувствителност?

Добре обоснован отговор: Имаме политика за класификация с поне 3-4 нива (например публични, вътрешни, поверителни, строго поверителни). За всяко ниво е описано как се маркира, съхранява, споделя и унищожава. Служителите са обучени, основните системи прилагат класификацията автоматично, където е възможно.

Отговор, който показва пропуск: „Имаме политика, но в практиката не се прилага систематично“ или „чувствителни данни знаем кои са, ама не сме ги маркирали“. Без работеща класификация всяка следваща мярка (криптография, контрол на достъпа) виси.

Въпрос 8. Имате ли актуална мрежова диаграма и схема на потока на данните?

Добре обоснован отговор: Да, имаме мрежова диаграма с физическата и логическата топология, обновена в последните 6 месеца, плюс схема на потока на критичните данни между основните системи и през интеграциите към доставчици. И двете са версионирани и съхранени контролирано.

Отговор, който показва пропуск: „Имам я в главата си“ или Visio от 2019 г. без последните три миграции към облака. Това е почти универсалният пропуск - изненадващо чест дори в иначе подготвени компании.

Въпрос 9. Какви са текущите ви RTO и RPO за критичните системи, и кога ги тествахте за последно?

Добре обоснован отговор: За всяка критична система имаме декларирани RTO (време за възстановяване) и RPO (приемлива загуба на данни), приети от собственика на бизнес процеса. Имаме тест на възстановяването, проведен в последните 12 месеца, с документиран резултат - дали целевите стойности са постигнати.

Отговор, който показва пропуск: „Правим резервни копия всяка нощ“ не доказва колко време отнема възстановяването и колко данни могат да бъдат загубени. Необходим е тест с измерени резултати, а не само старо възстановяване в среда за разработка.

Въпрос 10. Каква е политиката за съхранение, защита и периодично тестване на резервните копия?

Добре обоснован отговор: Прилагаме 3-2-1 правилото (3 копия, 2 различни среди, 1 офлайн или защитено от промяна), копията са криптирани, имаме политика за съхранение с дефинирани срокове, и поне веднъж на тримесечие правим тестово възстановяване на произволно избран файл или система. Резултатите се документират.

Отговор, който показва пропуск: „Копията са в същата мрежа, до сървърите.“ При ransomware атака те също могат да бъдат засегнати. Проверете дали имате изолирано копие или защита срещу промяна и изтриване.

Въпрос 11. На колко процента от привилегированите акаунти е активирана многофакторна автентикация?

Добре обоснован отговор: На 100% от привилегированите акаунти (Domain Admin, Global Admin в M365, root в Linux, всички DBA), на 100% от външния достъп (VPN, RDP през интернет), и на 100% от служебните пощи. Имаме доклад от съответната платформа (Azure AD/Entra, Okta), който го доказва.

Отговор, който показва пропуск: „MFA имаме навсякъде, освен за някои стари акаунти за услуги“. Тези изключения често са най-уязвимите точки. Инспекторът ще иска списък на изключенията и обосновка за всяко.

Въпрос 12. Как се управлява предоставянето и оттеглянето на достъп?

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

Отговор, който показва пропуск: „ИТ отделът преценява“. Без процедура, без логове, без преглед. Често откриваме акаунти на хора, напуснали преди 2-3 години, които още имат активен достъп.

Въпрос 13. Какво е криптирано и с какви алгоритми и ключове?

Добре обоснован отговор: Всички крайни устройства имат пълно дисково криптиране (BitLocker / FileVault / LUKS). Сървърните дискове и базите данни с поверителни данни са криптирани. TLS 1.2+ за вътрешен и външен трафик. Управлението на ключовете е документирано, с описана процедура за смяна и архивиране.

Отговор, който показва пропуск: „Имаме криптиране, но не сме сигурни на всички устройства“. Без отчет от системата за управление (Intune, Jamf, MDM) не можете да докажете покритието. Това е критична точка особено за лични данни.

Въпрос 14. Как се откриват и отстраняват уязвимостите?

Добре обоснован отговор: Имаме автоматизирано сканиране за уязвимости поне веднъж на месец, плюс външен пентест поне веднъж годишно. Имаме SLA за отстраняване: критични за 7 дни, високи за 30 дни, средни за 90. Поддържаме регистър с отворените позиции и тяхното състояние.

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

Отговор, който показва пропуск: „Имахме пентест преди 3 години“. Или „Windows update е включен“. Това не е управление на уязвимостите, а надежда. Инспекторът ще иска да види последния доклад.

Въпрос 15. Събирате ли централно журналите и получавате ли известия за подозрителни събития?

Добре обоснован отговор: Журналите от критичните системи — домейн контролери, Microsoft 365, EDR, защитни стени и основни приложения — се изпращат към централна система или външен SOC. Има правила за известяване и отговорник, който разглежда сигналите. Записите се пазят поне 12 месеца. Можем да покажем обработени сигнали от последния месец.

Отговор, който показва пропуск: „Логовете остават по системите си“. Без централизация няма откриване, няма разследване, няма доказателства след инцидент. Това е често скъпият пропуск, но решим за 4-6 седмици.

Въпрос 16. Имате ли писмена политика и процедура за реакция при инциденти?

Добре обоснован отговор: Да, имаме одобрена от УС политика, която описва: дефиниция за инцидент, роли (координатор, технически екип, комуникации, юристи), процедура в стъпки, критерии за класификация на тежестта, и срокове за уведомяване. Прегледана и обновена в последните 12 месеца.

Отговор, който показва пропуск: „Знаем кой какво ще прави, ако нещо стане“. Или политика, копирана от шаблон, която никой не е чел, и в която дежурният телефон е грешен.

Въпрос 17. Поддържате ли дневник на инцидентите и как класифицирате тежестта?

Добре обоснован отговор: Имаме регистър на инцидентите за поне последните 12-24 месеца, включително отбелязани като „без значимо въздействие“. За всеки запис: дата, описание, тежест по 3-4 нива, действия, окончателно решение, поуки. Класификацията използва ясни критерии (брой засегнати потребители, продължителност, тип на данните).

Отговор, който показва пропуск: „През последната година не сме имали инциденти“. Това почти винаги означава, че инцидентите не се отчитат, а не че не са се случвали. Инспекторът знае това.

Въпрос 18. Какви са сроковете за уведомяване и как ги спазвате на практика?

Добре обоснован отговор: Знаем от кой момент започват да текат сроковете. Процедурата предвижда ранно предупреждение до 24 часа, доклад до 72 часа и окончателен доклад до 1 месец. Имаме шаблони и актуални контакти. При нарушение на сигурността на лични данни отделно проверяваме задължението за уведомяване на КЗЛД до 72 часа.

Отговор, който показва пропуск: „Ще се обадим на нашия юрист“. Юристът ви не е надзорният орган. И не помни ESM шаблоните в нощта на инцидента.

Въпрос 19. Тествали ли сте плана за реакция при инциденти в последните 12 месеца?

Добре обоснован отговор: Да, имаме поне едно практическо учение по сценарий в последните 12 месеца, с участие на ИТ, юристи, комуникации и представител на ръководството. Сценариите включват ransomware, BEC, изтичане на данни и компрометиран доставчик. Имаме протокол с поуките и план за подобрения.

Отговор, който показва пропуск: „Не сме правили официално упражнение, но имахме реални инциденти и ги решихме“. Реалните инциденти не са замяна на упражнението - те включват само хората, които са били на работа, и не покриват други сценарии.

Въпрос 20. Имате ли план за непрекъсваемост на дейността (BCP) и план за възстановяване (DRP)?

Добре обоснован отговор: Да, имаме BCP с дефинирани критични процеси, приоритети, минимални нива на услугата, и DRP с конкретни технически стъпки за възстановяване по сценарий. И двата документа са одобрени, тествани в последните 12 месеца и преглеждани при значими промени. Ако не искате да водите това в таблици, NIS2 модулът на Venvera свързва всяко изискване със съответните доказателства.

Отговор, който показва пропуск: „BCP-то ни го направиха консултанти преди 5 години“. Или нямате DRP, а само списък с бекъпи. План без тест е надежда.

Въпрос 21. Имате ли регистър на ИКТ доставчиците?

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

Отговор, който показва пропуск: „Познаваме доставчиците си, но нямаме списък.“ Без регистър е трудно да покажете кои доставчици сте оценили и как ги наблюдавате.

Въпрос 22. Класифицирани ли са доставчиците по риск и кога е извършен последният преглед?

Добре обоснован отговор: Имаме поне 3 нива на риск (критичен / среден / нисък) с дефинирани критерии. За критичните доставчици проверката е извършена в последните 12 месеца, имаме копия на актуалните им сертификати (ISO 27001 / SOC 2) или попълнен въпросник за сигурност с дата.

Отговор, който показва пропуск: „Доверяваме се на партньорите си.“ Доверието не заменя оценката. Без класификация по риск не можете да определите кои доставчици изискват най-задълбочена проверка.

Въпрос 23. Какви договорни клаузи за сигурност имате с критичните си доставчици?

Добре обоснован отговор: Имаме стандартни клаузи за: задължение за уведомяване при инцидент в рамките на 24 часа, право на одит, минимални технически и организационни мерки, връщане/унищожаване на данни при прекратяване, подизпълнители, обработващи данни и тяхното одобрение. За GDPR обработващите - и DPA по чл. 28.

Отговор, който показва пропуск: „Договорите ни са стандартни търговски.“ Без отделни клаузи за сигурност нямате договорни лостове в инцидент, а инспекторът ще поиска извадка от трите критични договора.

Въпрос 24. Как следите сигурността на критичните доставчици?

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

Отговор, който показва пропуск: „Ще ни кажат, ако имат проблем.“ Не е така - в практиката новините за пробив идват от пресата или от клиент. Без активен мониторинг сте последни в опашката за информация.

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

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

Отговор, който показва пропуск: „Ще решим, когато се случи.“ Зависимостта от един доставчик без резервен вариант е риск за дейността. Проверете кои услуги могат да спрат изцяло при отказ на един доставчик.

1. Кога точно ще дойде регулаторът за проверка?

Няма публикувано календарно разписание. Първите вълни от проверки очакваме скоро след пълното влизане в сила на закона - първоначално приоритетно на съществените субекти от енергетика, транспорт, банки, здраве и цифрова инфраструктура. След тях идва ред на важните субекти. Освен планови проверки има и проверки по сигнал (например след докладван инцидент) и тематични проверки на цял сектор. Не е разумно да чакате конкретно известие. Подгответе се сега, защото първата „проверка“, която очаквам да получите, може да дойде под формата на въпросник от клиент или от ваш чуждестранен партньор.

2. Имаме ISO 27001 - покрива ли това НИС2?

Покрива голяма част от изискванията по чл. 21, особено в групи 2 (Активи) и 3 (Контроли), плюс много от документите от минималния комплект. Но не е автоматичен паспорт. Има три специфики на НИС2, които ISO 27001 не покрива пълно: задължителни срокове за уведомяване в часове (24/72/30 дни), персоналната отговорност на УС (чл. 20), и конкретното разделяне на отговорностите между съществен и важен субект. Ако имате ISO 27001, използвайте го като 70% от подготовката и допълнете останалите 30% - формално решение на УС, изрични срокове за инциденти, документиран преглед на доставчиците по новите критерии.

3. Можем ли да направим самооценката сами без външна помощ?

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

4. Какво да направим, ако самооценката покаже сериозни пропуски?

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

5. Колко струва самооценката, ако я възлагаме на консултант?

За компания с 50 до 250 души, бюджетите за външна самооценка са обикновено между 3 067,75 и 9 203,25 евро в зависимост от обхвата (само въпросник или с практически тестове на контролите), наличието на ISO 27001/SOC 2 и това дали трябва да съставим липсващи документи или само да ги преглеждаме. Това е значително по-малко от разходите за реална подготовка „на парче“ след констатация на регулатора. Заявете оферта с фиксирана цена и ясен обхват - устните оценки „зависи“ не са приемливи в тази задача.

6. Колко често трябва да повтаряме самооценката?

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