NIS2 для українських IT-підрядників: що вимагатимуть європейські клієнти

Чому NIS2 стосується компаній за межами ЄС

NIS2 замінила першу директиву NIS і значно розширила коло організацій, на які поширюються вимоги кібербезпеки. Держави-члени мали перенести її в національне законодавство до 17 жовтня 2024 року. Не всі встигли вчасно, тому національні закони в різних країнах ЄС набирають чинності в різний час, і деталі варто перевіряти для кожної країни окремо.

Директива поділяє організації на суттєві (essential) та важливі (important) суб'єкти. До них належать енергетика, транспорт, банки, охорона здоров'я, цифрова інфраструктура, управління ІКТ-послугами у форматі B2B, державне управління, виробництво окремих категорій продукції, цифрові постачальники та інші сектори. Загальне правило охоплює середні та великі підприємства, хоча для деяких типів організацій розмір не має значення.

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

Коли NIS2 може застосовуватися до вас безпосередньо

Для більшості українських підрядників NIS2 діє опосередковано, через договори. Але є важливий виняток. Стаття 26 передбачає, що окремі категорії постачальників цифрових послуг, які не мають закладу в ЄС, але надають послуги в Союзі, повинні призначити представника в одній із держав-членів. Серед них постачальники хмарних послуг, послуг центрів обробки даних, мереж доставки контенту, керовані постачальники послуг (managed service providers) і керовані постачальники послуг безпеки (managed security service providers), а також онлайн-маркетплейси, пошукові системи та соціальні мережі.

Якщо ваша компанія, наприклад, надає європейським клієнтам послуги з адміністрування інфраструктури, моніторингу, підтримки ІТ-систем або SOC як послугу і відповідає критеріям розміру, варто проаналізувати з юристом, чи не підпадаєте ви під цю норму. Висновок залежить від характеру послуги, кількості працівників, обороту і національного законодавства держави, де працюють клієнти.

Для постачальників хмарних послуг, дата-центрів, керованих сервісів та деяких інших цифрових постачальників Європейська комісія ухвалила Імплементаційний регламент (ЄС) 2024/2690 з детальними технічними і методологічними вимогами до заходів безпеки. Якщо ви належите до цих категорій, саме цей документ варто прочитати першим після тексту директиви.

Десять заходів статті 21, які клієнт перенесе у ваш договір

Стаття 21(2) містить мінімальний перелік заходів управління кіберризиками. Саме за цим переліком європейські клієнти будують свої опитувальники постачальників:

• Політики аналізу ризиків і безпеки інформаційних систем.
• Обробка інцидентів.
• Безперервність бізнесу: резервне копіювання, відновлення після аварій, кризове управління.
• Безпека ланцюга постачання.
• Безпека при придбанні, розробці та супроводі систем, включно з обробкою і розкриттям вразливостей.
• Політики і процедури оцінки ефективності заходів.
• Базова кібергігієна і навчання з кібербезпеки.
• Політики використання криптографії та шифрування.
• Безпека персоналу, контроль доступу, управління активами.
• Багатофакторна автентифікація, захищені голосові, відео- і текстові комунікації, захищені канали екстреного зв'язку.

Звітування про інциденти: чому строки важливі і для підрядника

Стаття 23 вимагає від суб'єктів повідомляти про значні інциденти в кілька етапів: раннє попередження протягом 24 годин після того, як стало відомо про інцидент, повідомлення про інцидент протягом 72 годин і остаточний звіт не пізніше ніж через місяць.

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

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

Відповідальність керівництва і що це означає для підрядника

Стаття 20 NIS2 покладає на органи управління суб'єктів обов'язок затверджувати заходи кібербезпеки, контролювати їх виконання і проходити навчання. Керівники можуть нести відповідальність за порушення. Через це директори європейських компаній стали значно уважнішими до постачальників: ризик, що виникає у підрядника, тепер стає персональною проблемою для їхнього керівництва.

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

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

Типові вимоги в договорах і докази, які у вас попросять

На основі статті 21 клієнти формують додатки до договорів і анкети постачальників. Найчастіше від українських IT-компаній очікують таких доказів:

• Затверджена політика інформаційної безпеки і реєстр ризиків.
• Перелік осіб з доступом до систем клієнта, процедура надання і відкликання доступів, регулярний перегляд прав.
• Обов'язкова багатофакторна автентифікація для віддаленого доступу, репозиторіїв коду і хмарних консолей.
• Політика безпечної розробки: перевірка коду, сканування залежностей, управління секретами, розділення середовищ.
• Процедура обробки вразливостей і строки їх усунення.
• План безперервності бізнесу з урахуванням відключень електроенергії, проблем зі зв'язком і мобілізації працівників.
• Записи про навчання персоналу з кібербезпеки.
• Сертифікат ISO/IEC 27001 або звіт SOC 2, якщо вони є, а також результати тестування на проникнення.

Типові помилки підрядників під час перевірки клієнтом

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

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

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

Усі ці прогалини виправляються відносно швидко, якщо їх виявити до того, як вони потраплять у звіт аудитора клієнта.

Як підготуватися без зайвих витрат

Найефективніший шлях полягає в тому, щоб не відповідати кожному клієнту окремо, а побудувати одну систему, яка покриває вимоги більшості. Для цього добре підходить ISO/IEC 27001:2022. Його 93 контролі з Додатка A, згруповані в чотири теми (організаційні, людські, фізичні, технологічні), значною мірою відповідають заходам статті 21. Сертифікат не означає автоматичної відповідності NIS2, але дає клієнтам незалежне підтвердження і скорочує кількість запитань.

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

Для української компанії важливо врахувати й місцевий контекст: воєнні ризики, блекаути, переміщення команд. Європейські клієнти цілком обґрунтовано запитують, як ви забезпечуєте безперервність. Конкретний план з резервним живленням, альтернативним зв'язком і розподіленою командою часто важить більше, ніж загальні формулювання.

Безкоштовна самооцінка на baltum.ai за ISO 27001 покаже, які з цих елементів у вас уже працюють, а які потребують уваги перед наступною перевіркою від клієнта.

Стаття має інформаційний характер і не є юридичною консультацією. baltum.ai — незалежне програмне забезпечення, а не орган із сертифікації.