Директива NIS2: кого стосується та як підготувати компанію

Директива NIS2 упорядковує вимоги кібербезпеки для визначених секторів та організацій. На практиці йдеться про відповідальність, управління ризиками й реагування на інциденти. Я не починав би з придбання чергової захисної програми. Спочатку треба встановити застосовність правил і відповідальних за конкретні дії. Інакше легко заплатити за уявну готовність.

Що змінюється поза відділом IT

Європейські правила розширюють сферу попередньої директиви NIS. Вони розрізняють ключові та важливі суб’єкти й охоплюють більше секторів. Серед них цифрова інфраструктура, транспорт, охорона здоров’я, енергетика та визначені послуги управління ICT. Додаються певні виробництва й інші види діяльності з додатків. Перелік потрібно читати разом із критеріями застосування. [1]

Сам сектор ще не дає відповіді для конкретної компанії. Значення мають діяльність, розмір суб’єкта й передбачені винятки. Деякі організації підпадають під вимоги незалежно від розміру. Тому твердження про автоматичне виключення всіх малих компаній неправильне. Кваліфікацію краще документувати, а не будувати на галузевому скороченні. [1]

Правила стосуються також ролі керівництва. Керівники мають розуміти ризики, затверджувати відповідні заходи й наглядати за виконанням. Перекладання всієї відповідальності на адміністратора сервера проблему не розв’язує. Особливо коли він не визначає бюджет, наймання працівників та умови договорів. Потрібне узгодження управлінських і технічних рішень. [2] [6]

Стан у Польщі: важливі дати замість старих анонсів

Польську новелізацію закону про національну систему кібербезпеки опубліковано під позицією 252 Dziennik Ustaw за 2026 рік. Вона набула чинності 3 квітня 2026 року. Отже, йдеться вже не лише про проєкт закону. Директива NIS2 впроваджується національними нормами, які читаємо разом із галузевими правилами. Стаття описує саме польський контекст. [3]

Міністерство визначило 3 жовтня 2026 року строком самореєстрації певних суб’єктів, які відповідали критеріям уже 3 квітня. На дату перевірки цього тексту строк минув. Це стосується зазначеної групи, а не кожної майбутньої організації в системі. Відсутність запису не доводить відсутності обов’язку. Спочатку перевірмо власну ситуацію. [4]

Перехідні періоди й строки окремих обов’язків потрібно встановлювати для конкретного випадку. Адміністрація описує дванадцятимісячний період підготовки до визначених вимог. Він не означає автоматичного відкладення всіх обов’язків на рік. Почнімо з кваліфікації, компетентного органу та законодавчого графіка. Не змішуймо строк реєстрації з іншими строками. [5]

Перший етап: знаємо, що саме захищаємо

Складемо перелік систем, даних, послуг і відповідальних осіб. Врахуймо застосунки окремих відділів та інструменти поза головним сервером. Потім визначмо наслідки недоступності або втрати даних. Дві години простою магазину та системи керування виробництвом можуть означати різні збитки. Одного загального списку програм для цього недостатньо.

Призначмо власників процесів і критерії прийнятності ризику. Запишімо, що можна відкласти, а що блокує безпечну роботу. Такий перелік допомагає конкретно обговорювати бюджет. Замість одночасного придбання всього визначмо головні залежності та реальні строки поліпшення. Кожне завдання має отримати відповідального, а не лише пріоритетний колір.

Другий етап: перевірювані заходи захисту

Заходи охоплюють реагування на інциденти, безперервність роботи, безпеку постачальників і безпечний розвиток систем. Додаються керування доступом, кібергігієна й належне використання багатофакторної автентифікації. Вибір має відповідати ризикам, масштабу й характеру організації. Назва придбаного продукту не доводить ефективності захисту. Потрібні результати реальних перевірок. [2] [6]

Перевірмо відкликання доступу колишнього працівника, відновлення копії й оновлення критичного застосунку. Визначмо, хто приймає тривогу поза робочим часом. Перевірмо аварійний доступ за відсутності основного адміністратора. Це не видовищні завдання, але вони показують реальність процедур. Після перевірки запишімо знайдені прогалини й строки виправлення.

У постачальників уточнімо відповідальність, порядок повідомлень і можливість повернення даних. Хостинг не бере автоматично відповідальність за кожну помилку застосунку. Договір має визначати, хто оновлює систему й усуває вразливості. Інакше обидві сторони можуть вважати, що це робить інша. Особливо небезпечно виявити таку прогалину під час аварії.

Третій етап: реагування та докази роботи

Європейська директива передбачає поетапне повідомлення про значні інциденти, з раннім попередженням і наступним повідомленням. Конкретні строки та одержувача перевірмо в правилах відповідного суб’єкта. Не переносьмо спрощену інфографіку безпосередньо до робочої процедури. Команді потрібна зрозуміла ескалація, навіть коли причина збою ще невідома. Цю послідовність варто відпрацювати заздалегідь. [2] [6]

Проведімо вправу з недоступним застосунком, утраченим обліковим записом адміністратора або підозрою витоку. Запишімо рішення, час реакції та відсутні дозволи. Потім виправмо процедуру й визначмо дату повторення. Документація має допомагати діяти, а не лише красиво виглядати під час контролю. Корисним результатом є короткий список конкретних змін.

Директива NIS2 потребує відповідальності в повсякденній роботі. Я не обіцяв би відповідності після одного аудиту чи встановлення інструмента. Підготовка охоплює людей, договори й повсякденну експлуатацію. Початок — перелік прогалин із відповідальними та строками. Правову кваліфікацію підтвердьмо зі спеціалістом, який знає конкретну організацію. Технічне впорядкування можна починати одразу, не очікуючи на рекламну назву готового пакета.

Джерела та дата перевірки

2026-10-14

1. European Commission: NIS2 Directive
2. Dyrektywa (UE) 2022/2555 — art. 20, 21 i 23
3. Dziennik Ustaw 2026 poz. 252: nowelizacja KSC
4. Ministerstwo Cyfryzacji: termin samorejestracji 3 października
5. Administracja publiczna: nowelizacja KSC — kogo obejmuje
6. Ministerstwo Cyfryzacji: FAQ KSC — materiał pomocniczy, niewiążący