NIS2 перетворилася з «директиви ЄС на горизонті» на «регулятора біля ваших дверей» тієї миті, коли Румунія транспонувала її Законом 124/2025. Пʼятисторінкового резюме, яке ваш CIO прочитав у 2023 році, більше не досить: інспектори DNSC читають ту саму статтю 21, що й ви, і очікують, що операційна модель безпеки виглядатиме так, як її описує директива.
Ця стаття — версія, яку нам самим хотілося б отримати перед першим аудитом NIS2. Вона припускає, що ви вже знаєте про існування директиви, і зосереджується на тому, чого практично вимагають стаття 21, стаття 23 та положення про керівний орган, а також які докази витримують перевірку, коли приходить інспектор.
Стаття 21 операційною мовою
Стаття 21 перелічує десять «належних і пропорційних технічних, операційних та організаційних заходів». У перекладі на мову програми безпеки це означає щонайменше:
- Програму управління вразливостями, що працює циклічно, з документованою пріоритезацією та усуненням у визначені терміни. Щорічні сканування, скинуті в PDF, цього не закривають.
- Документований процес реагування на інциденти з поіменними ролями, черговими ротаціями та випробуваними плейбуками. Директива вживає формулювання «політики та процедури для оцінки ефективності» — тобто статичної IR-політики недостатньо; треба вміти показати, що її відпрацьовували.
- Безпеку ланцюга постачання: реєстр критичних ІКТ-провайдерів, оцінку їхнього рівня захищеності та контрактні положення, що дозволяють вимагати від них того самого. Стаття 21(2)(d) щодо цього однозначна.
- Практики кібергігієни та базове навчання з обізнаності для всього персоналу, з документованим відвідуванням та оцінюванням. Формальний e-learning «прогорнув і закрив», на думку автора, не рахується.
- Політики криптографії та контролю доступу, що відповідають критичності активів, включно з MFA для привілейованого доступу. Формулювання свідомо не вимагає конкретних алгоритмів — воно вимагає пропорційності, і саме її промацуватиме аудитор.
24-годинний відлік — звітування про інциденти за статтею 23
Три терміни, один інцидент:
- Раннє попередження протягом 24 годин з моменту виявлення. Це саме сповіщення, а не повний звіт. Найкраща практика: односторінковий шаблон раннього попередження, заздалегідь узгоджений із DNSC, який можна відправити просто зі штабної вправи.
- Повідомлення протягом 72 годин, з початковою оцінкою серйозності та впливу. Писати його з нуля під тиском інциденту — жорстоко; майте шаблон, що підтягує дані з вашої форензик-хронології.
- Фінальний звіт протягом 1 місяця, з першопричиною та вжитими заходами. Аудитор читатиме його, звіряючи з вашою IR-політикою. Неузгодженості спливають швидко.
24-годинне раннє попередження — положення, яке недооцінює більшість організацій. Коли ви зрозумієте інцидент достатньо добре, щоб написати справжнє повідомлення, ви вже спізнилися.
Персональна відповідальність керівного органу
Стаття 20 робить керівний орган — членів ради, виконавчих директорів — персонально відповідальним за дотримання статті 21 та за затвердження заходів управління ризиками. Румунська транспозиція зберігає ці «зуби». У наших проєктах із публічним сектором і великим приватним бізнесом це єдине положення зрушило більше бюджету, ніж будь-який технічний аргумент за пʼять років GDPR-роботи до NIS2.
Що насправді запитують інспектори DNSC
З інспекцій DNSC, які ми супроводжували як технічний радник — не називаючи залучених організацій:
- Реєстр активів. Не дамп CMDB, а реєстр, що ранжує активи за критичністю для бізнесу та привʼязує кожен до власника. Якщо у вашому реєстрі є «нічиї» сервери, інспекція зупиняється на цьому на кілька годин.
- Беклог вразливостей за віком. Час від виявлення та час від розгортання виправлення, у розрізі серйозності. Ми бачили, як заяви «100% критичних знахідок усунено» розвалювалися за пʼять хвилин одним вибірковим запитом до SLA-дашборда.
- Журнали реагування на інциденти за останні дванадцять місяців — навіть якщо інцидентів не було. Відсутність інцидентів має бути видимою: сповіщення, що спрацювали та були закриті як хибні, теж є доказом того, що програма працює.
- Матрицю навчання: хто яке навчання пройшов, коли та з яким результатом. Стережіться відповіді «всі пройшли e-learning» — сучасні інспектори питають, які ролі отримали рольове навчання, включно з керівним органом.
- Перелік критичних сторонніх ІКТ-провайдерів із контрактними положеннями за статтею 21(2)(d) та вибіркою нещодавніх оцінок. Це найпоширеніша прогалина, яку ми спостерігаємо.
Дворічна програма, що переживає інспекцію
Захищувана програма NIS2 — це не проєкт, а програма, що працює безперервно та продукує докази як побічний ефект. Мінімальний життєздатний дворічний ритм:
- Квартал 1: базовий реєстр активів + перший прохід по вразливостях + IR-плейбук v1 + брифінг для керівного органу.
- Квартал 2: оцінка критичних постачальників + перша штабна IR-вправа + перший цикл усунення.
- Квартал 3: пентест кластера активів із найвищим ризиком + навчання персоналу v1 + опубліковані KPI.
- Квартал 4: огляд програми управління вразливостями + повторна робота з постачальниками + повторний брифінг керівного органу з метриками.
- Рік 2 дзеркалить рік 1 із глибшим red team, ширшим охопленням постачальників і повністю рольовим навчанням.
Де тут Sandline
Ми ведемо технічний шар цієї програми — оцінку вразливостей на Centraleyezer, тестування на проникнення, привʼязане до конкретних пунктів статті 21, ретейнери реагування на інциденти з шаблонами звітування за NIS2 та навчання персоналу, що закриває статтю 21(2)(g). Ми не будемо вашим DPO і не писатимемо ваш статут управління; ми готуємо докази, які аудитор має прочитати.