Кібербезпека 6 хв читання

NIS2, ISO/IEC 27001 та КСЗІ: як інтегрувати вимоги регуляторів у єдину систему

Як поєднати директиву NIS2, стандарт ISO 27001 та вимоги КСЗІ без дублювання процесів. Практичний підхід до архітектури безпеки на базі NIST CSF 2.0.

У 2026 році відповідність вимогам кібербезпеки остаточно перестала бути формальністю. Згідно зі звітом ENISA Threat Landscape 2025, який проаналізував 4 875 інцидентів за період з 1 липня 2024 по 30 червня 2025 року, 53.7% постраждалих організацій належать до категорії essential entities (критично важливих суб'єктів). Це робить приведення корпоративних систем у відповідність до директиви NIS2 та сучасних міжнародних стандартів критичним завданням для бізнесу.

Проте на практиці українські компанії, що працюють з європейськими партнерами, стикаються з проблемою синхронізації вимог. Їм необхідно одночасно відповідати жорстким директивам ЄС (NIS2), проходити процесну сертифікацію ISO/IEC 27001 та підтримувати комплексну систему захисту інформації (КСЗІ) для вітчизняних регуляторів. Спроба впроваджувати ці вимоги ізольовано призводить до хаосу, подвійних аудитів і створення «паперової безпеки», яка не зупиняє реальних кібератак.

Три виміри регуляцій: чим відрізняються NIS2, ISO/IEC 27001 та КСЗІ

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

  • NIS2 (Директива ЄС): Це директивний акт, обов'язковий для критичних секторів. Він жорстко фокусується на відповідальності керівництва, безпеці ланцюгів постачання та терміновому повідомленні про інциденти (зокрема, протягом 24 та 72 годин). Недотримання вимог NIS2 тягне за собою значні штрафи та ризики для менеджменту компаній.
  • ISO/IEC 27001: Міжнародний стандарт, що описує процеси Системи управління інформаційною безпекою (СУІБ). Наявність сертифіката ISO 27001 автоматично не дорівнює повній відповідності NIS2. Стандарт надає міцну основу для побудови процесів, але для комплаєнсу з Директивою ЄС необхідний додатковий gap-аналіз.
  • КСЗІ: Українська нормативна база, що фокусується на технічному контурі захисту, апаратних рішеннях та документальному підтвердженні захищеності конкретних систем. КСЗІ та ISO 27001 не є еквівалентними за методологією, оскільки КСЗІ вирішує завдання технічного атестування державного зразка, а не гнучкого управління корпоративними ризиками.

Анатомія загроз: чому паперовий комплаєнс не захистить від фішингу

Ідеально описані політики марні, якщо вони не реалізовані технічно. За даними звіту ENISA, на сектор цифрової інфраструктури та сервісів припало близько 27.7% усіх витоків даних. Основними векторами початкового доступу залишаються цільовий фішинг та атаки на ланцюги постачання (supply chain attacks), коли зловмисники компрометують компанію через довірених підрядників.

Для переходу від формального заповнення чеклістів до реального захисту необхідне моделювання поведінки атакуючих. База знань MITRE ATT&CK дозволяє структурувати тактики та техніки зловмисників. Інтеграція матриці MITRE ATT&CK у процеси Security Operations Center (SOC) допомагає налаштовувати детекції аномалій під актуальний ландшафт загроз, гарантуючи, що моніторинг захищає інфраструктуру щомиті, а не лише в день аудиту.

Крос-мапування вимог: побудова єдиної системи на базі NIST CSF 2.0

Уникнути дублювання ресурсів можна за допомогою єдиної методологічної рамки управління ризиками. Ефективним інструментом є NIST Cybersecurity Framework (CSF) 2.0. Хоча це добровільна рамка, вона дозволяє провести крос-мапування (crosswalk) вимог до ISO/IEC 27001 та інших стандартів. Зокрема, функція Govern (GV) у NIST CSF 2.0 наголошує на кіберризику як частині загального корпоративного управління.

Критерій безпекиNIS2 (Директива ЄС)ISO/IEC 27001 (Стандарт)КСЗІ (Україна)NIST CSF 2.0 (Фреймворк)
Управління ризикамист. 21 (Risk management)Розділи 6 та 8Загальні вимоги до СУІБФункція Govern (GV)
Ланцюг постачанняБезпека постачальниківКонтроль A.5.19 - A.5.23Не покриває безпосередньоGV.SC (Supply Chain)
Реагування на інцидентист. 23 (Повідомлення за 24/72 год)Контроль A.5.24 - A.5.28Інструкції з реагуванняФункція Respond (RS)

Вбудована безпека: перенесення вимог у технічну архітектуру

Щоб система відповідала всім трьом регуляціям (NIS2, ISO 27001, КСЗІ), принципи безпеки мають бути закладені на рівні архітектури та коду (Security by Design). Інструменти контролю доступу, автентифікації та аудиту повинні бути частиною технологічної платформи.

Прикладом такої архітектурної основи є платформа UnityBase — спільна розробка компаній технологічного альянсу Intecracy Group (де ключовим, але не єдиним розробником виступає InBase). Ця full-stack JavaScript low-code платформа об'єднує дані, UI та API через єдину доменну модель (Domain metadata), забезпечуючи централізований контроль доступу.

Для систем високого навантаження або з жорсткими регуляторними вимогами офіційна документація платформи рекомендує комерційні редакції Enterprise (EE) або Defence (DE). Вони підтримують списки контролю доступу (ACL), атрибутивну безпеку, безпеку на рівні рядків (RLS) та незмінний аудит (audit trail). Слід зазначити, що хоча існує відкрита версія OpenUB (під ліцензією Apache License 2.0), вона має офіційні обмеження щодо використання в організаціях, пов'язаних із державним сектором України.

Технічні механізми UnityBase дозволяють створювати захищені продукти. Наприклад, на цій базі функціонує система електронного документообігу Megapolis.DocNet, яка отримала сертифікат захисту інформації рівня Г2, що безпосередньо закриває вимоги КСЗІ. Інший приклад — DealsSign, система для безпечного юридично значущого зовнішнього документообігу з контрагентами. Використання таких рішень дозволяє інженерним командам фокусуватися на бізнес-логіці, залишаючи питання низькорівневої безпеки та аудиту на боці надійної платформи.

Для комплексної реалізації цих вимог експерти Intecracy Group (зокрема компанії Softengi) допомагають інтегрувати технічний контур захисту на рівні підприємства: від проєктування Zero Trust архітектури та мережевої сегментації до розробки захищеного ПЗ.

Практичні кроки підготовки: від gap-аналізу до моніторингу

Для структурування підготовки до перевірок та реальних кібератак компаніям варто реалізувати наступні етапи:

  1. Gap-аналіз процесів: Визначте, які статті NIS2 та вимоги КСЗІ вже покриваються вашими процесами ISO 27001, а де потрібне технічне посилення.
  2. Синхронізація ризиків: Використайте методологію NIST CSF 2.0 для формування спільного реєстру загроз, що об'єднає бачення ІТ, безпеки та бізнес-менеджменту.
  3. Аудит ланцюга постачання: Оцініть вразливості третіх сторін. Переконайтеся, що базове ПЗ та підрядники відповідають суворим критеріям доступу.
  4. Реалізація Zero Trust: Запровадьте сегментацію мереж, обов'язкову багатофакторну автентифікацію (MFA) та контроль доступу до даних (RLS, ACL).
  5. Безперервний моніторинг: Налаштуйте збір журналів подій безпеки (audit trail) та їхнє опрацювання в SIEM для забезпечення спроможності повідомляти про інциденти у передбачені директивою 24 години.

Поширені питання

Чи покриває сертифікат ISO/IEC 27001 усі вимоги директиви NIS2?

Ні. ISO/IEC 27001 є процесною рамкою для управління безпекою, тоді як NIS2 містить конкретні директивні та юридичні зобов'язання (наприклад, жорсткі терміни повідомлення про інциденти протягом 24/72 годин та спеціальні вимоги до безпеки ланцюгів постачання). Наявність сертифіката суттєво спрощує інтеграцію, але не скасовує необхідності проведення додаткового gap-аналізу.

Як об'єднати вимоги української КСЗІ з міжнародними стандартами безпеки?

Інтеграція відбувається через розділення процесного та технічного рівнів. Процесне управління (оцінка ризиків, менеджмент інцидентів) будується за міжнародними рамками (ISO 27001, NIST CSF 2.0), тоді як технічні вимоги КСЗІ реалізуються за рахунок використання сертифікованих платформ та інструментів із вбудованими механізмами контролю доступу (RLS, ACL, журналювання).

Які наслідки загрожують компаніям за невідповідність європейській директиві NIS2?

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

Джерела даних