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

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

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

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

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

Пропадащ отговор: „Темата е на ИТ отдела" без поименно назначение. Или „имаме 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 месеца, с документиран резултат - дали целевите стойности са постигнати.

Пропадащ отговор: „Имаме бекъпи всяка нощ". Бекъп без тестов restore не е RTO/RPO. Често разбираме на проверката, че последното реално възстановяване е било на dev среда преди 4 години.

Въпрос 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. Как се управлява предоставянето и оттеглянето на достъп?

Проходен отговор: Имаме процедура с искане-одобрение-изпълнение-преглед. Минимални привилегии (least privilege) са правилото. Когато служител напуска, достъпите се закриват в рамките на същия работен ден; HR системата спуска тригер. Имаме периодичен преглед на достъпите поне веднъж на 6 месеца за критичните системи.

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

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

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

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

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

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

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

Въпрос 15. Имате ли централизирано събиране на логове и алертинг?

Проходен отговор: Логовете от критичните системи (домейн контролери, M365, EDR, firewall, ключови приложения) се изпращат към централна система (SIEM или managed SOC), с дефинирани правила за тревога и оператор, който ги преглежда. Срокът на съхранение е поне 12 месеца. Имаме примери на обработени тревоги от последния месец.

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

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

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

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

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

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

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

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

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

Пропадащ отговор: „Ще се обадим на нашия юрист". Юристът ви не е надзорният орган. И не помни ESM шаблоните в нощта на инцидента.

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

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

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

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

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

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

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

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

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

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

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

Пропадащ отговор: „Доверяваме се на партньорите си." Без класификация по риск разделянето на усилието е невъзможно и почти сигурно отделяте твърде малко на критичните доставчици.

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

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

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

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

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

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

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

Проходен отговор: За всеки критичен доставчик имаме описан план за неизправност, включително алтернативен доставчик или временен механизъм. Договорите включват exit план - връщане на данните в указан формат, минимален период на достъп след прекратяване. Тествали сме поне един от тези планове в последните 12 месеца (поне на хартия).

Пропадащ отговор: „Ще се справим, когато стане." Зависимост от един доставчик без план е критичен корпоративен риск, освен от регулаторен. Инспекторите специално търсят single-points-of-failure в групата на доставчиците.

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

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

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

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

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

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

4. Какво се случва, ако пропаднем самооценката?

Самооценката не е официална оценка с резултат, който се изпраща някъде. Тя е вътрешен инструмент. „Пропадане" значи, че сте идентифицирали значителни пропуски преди регулаторът да дойде. Това е добра новина, защото имате контрол над срока. Лошата версия е, ако открием 7+ значителни пропуска и реалната проверка е след 4 седмици. В този случай приоритизирайте групи 1 и 4 (Управление и Инциденти), защото те създават най-силно впечатление, и подгответе план за останалите групи с конкретни срокове - ако инспекторът види, че знаете къде сте слаби и работите по тях, шансовете за наказателно постановление падат значително.

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

За компания с 50 до 250 души, бюджетите за външна самооценка са обикновено между 6 000 и 18 000 лв в зависимост от обхвата (само въпросник или с практически тестове на контролите), наличието на ISO 27001/SOC 2 и това дали трябва да съставим липсващи документи или само да ги преглеждаме. Това е значително по-малко от разходите за реална подготовка „на парче" след констатация на регулатора. Заявете оферта с фиксирана цена и ясен обхват - устните оценки „зависи" не са приемливи в тази задача.

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

Поне веднъж годишно, плюс при значими промени: придобиване или сливане, нов критичен доставчик, преминаване към нова основна платформа (например миграция на ERP в облака), значим инцидент или промяна в обхвата на закона. Годишният преглед се вписва добре в дисциплината на разумна грижа - тримесечните прегледи в УС събират оперативния пулс, а годишната самооценка прави цялостен срез. Това е и ритъмът, който инспекторът очаква да види - „проверихме се преди година" е добър отговор; „проверихме се преди три години" не е.