NIS2, DORA, SOC 2: що насправді хочуть бачити клієнти і регулятори

Клієнти, аудитори й регулятори дедалі менше вірять у товсті папки з політиками й дедалі більше дивляться на те, чи компанія реально управляє кіберризиками, контролює постачальників, готується до інцидентів і може це довести артефактами, журналами, тестами та управлінськими рішеннями. Це випливає і з логіки NIS2 як фреймворку кіберстійкості для 18 критичних секторів ЄС, і з DORA як обов’язкової регуляторної моделі цифрової операційної стійкості для фінансового сектору, і з SOC 2 як звіту про контрольне середовище, на який спирається широка група користувачів і клієнтів.

Чому ця тема стала ще важливішою саме у 2026 році

Директива NIS2 Directive уже діє в новому регуляторному циклі. Країни Європейського Союзу мали впровадити її положення у своє національне законодавство до 17 жовтня 2024 року. Водночас Європейська комісія у травні 2025 року повідомляла, що 19 країн ЄС ще не завершили цей процес повністю.

Паралельно, у січні 2026 року Європейська комісія запропонувала новий пакет змін у сфері кібербезпеки, який передбачає точкове оновлення директиви для спрощення виконання вимог і підвищення юридичної визначеності.

Це означає, що у 2026 році компаніям важливо не просто знати вимоги директиви, а вміти працювати в умовах, коли основні обов’язки вже діють, але деталі застосування та підходи до нагляду ще продовжують узгоджуватися між країнами ЄС.

Для фінансового сектору вимоги є ще жорсткішими. Регламент Digital Operational Resilience Act (DORA) застосовується з 17 січня 2025 року і вже не є «майбутнім документом», а повноцінною чинною нормою.

Окрім базових вимог щодо управління ІКТ-ризиками, реагування на інциденти, тестування та контролю ризиків, пов’язаних із зовнішніми постачальниками, у 2025–2026 роках активно розвивається і наглядова складова. Європейські наглядові органи перейшли до прямого нагляду за критично важливими постачальниками ІКТ-послуг.

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

NIS2: про кіберризики, стійкість і управлінську відповідальність

NIS2 Directive це директива Європейського Союзу, яка встановлює єдину правову рамку кібербезпеки для 18 критично важливих секторів. Вона має ширшу сферу застосування та більш жорсткі механізми нагляду порівняно з попередньою редакцією.

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

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

DORA: про цифрову операційну стійкість фінансових установ

Digital Operational Resilience Act (DORA) це не директива, а регламент ЄС, який застосовується безпосередньо і поширюється на фінансовий сектор. Європейське управління з цінних паперів та ринків описує його як рамку, що гармонізує правила цифрової операційної стійкості для 21 типу фінансових установ.

На практиці DORA зосереджується на п’яти ключових напрямах: управління ІКТ-ризиками, управління інцидентами, тестування операційної стійкості, управління ризиками, пов’язаними з ІКТ-постачальниками, а також обмін інформацією. Окрему увагу приділено договірним вимогам до провайдерів, веденню реєстру ІКТ-залежностей і більш формалізованому підходу до тестування стійкості, включно з поглибленим тестуванням для окремих організацій.

SOC 2: не регуляторика, а ринкова довіра

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

Такі звіти призначені для клієнтів і партнерів, яким потрібне підтвердження надійності постачальника. Тобто, якщо NIS2 і DORA визначають, що бізнес зобов’язаний робити в межах регуляторних вимог, то SOC 2 допомагає відповісти на запитання клієнта: «Чому вам можна довіряти як постачальнику?».

Що насправді хочуть бачити клієнти й регулятори у 2026 році

1. Не політику саму по собі, а governance, який реально працює

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

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

2. Ризик-орієнтовані заходи замість чекліст із шаблонів

Стаття 21 NIS2 вимагає саме appropriate and proportionate (належних і пропорційних) заходів. Це ключове формулювання. Воно означає, що зріла компанія не копіює чужий перелік контролів, а показує логіку: які є критичні сервіси, де найбільша залежність від постачальників, які сценарії інцидентів найбільш болючі, що вже зроблено, що лишається в roadmap і чому.

Digital Operational Resilience Act (DORA) вимагає формалізовану систему управління ІКТ-ризиками, а SOC 2 оцінює контрольне середовище як інструмент управління ризиком, а не набір «галочок».

У результаті в 2026 році найбільшу цінність має не перелік політик, а зв’язка: реєстр ризиків + мапа контролів + журнал рішень + план усунення недоліків.

3. Готовність до інцидентів і здатність звітувати

ENISA підкреслює, що NIS2 прямо пов’язує управління ризиками з обов’язком повідомляти про суттєві інциденти. DORA також виділяє інциденти як окремий блок вимог.

Тому сьогодні важливий не документ «політика реагування», а реальний процес: класифікація інцидентів, критерії ескалації, ролі, шаблони повідомлень, журнал рішень, аналіз після інцидентів і навчання на їх основі.

4. Контроль постачальників і supply chain, а не тільки свій периметр

Один із головних фокусів регуляторики - залежності від зовнішніх постачальників. У NIS2 це прямо включено до вимог, а DORA деталізує управління ризиками ІКТ-постачальників, включно з контрактними умовами, реєстрами та наглядом.

Європейські наглядові органи вже визначили критичних ІКТ-провайдерів і оцінюють їхню здатність забезпечувати стійкість послуг.

5. Перевірку ефективності контролів, а не віру в них

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

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

6. Доказова база, яку можна показати швидко

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

Які докази зрілості важливі

У центрі уваги не документи, а логічний ланцюг: контроль існує → працює → перевіряється → покращується.

Найсильніший набір включає:

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

Де бізнес найчастіше помиляється

Перша помилка - спроба «закрити» NIS2 Directive, Digital Operational Resilience Act або SOC 2 документами. Насправді всі ці підходи орієнтовані на реальні процеси, тестування і контроль середовища.

Друга помилка -  намагатися одним артефактом закрити три різні задачі. NIS2 це про регуляторну стійкість, DORA - про фінансовий сектор, SOC 2 - про довіру клієнтів. У них є перетини, але вони не взаємозамінні. Наприклад, SOC 2 може допомогти в комерційній довірі, але не замінить секторних обов’язків DORA; а відповідність DORA сама по собі не завжди задовольнить enterprise-клієнта зі США, який чекає саме SOC 2 report.  

Практичний підхід без зайвих витрат

Крок 1. Визначити, яка логіка для вас головна

Спершу потрібно зрозуміти, що для бізнесу є основним драйвером: регуляторика ЄС, фінансовий нагляд, вимога клієнтів або sales enablement. Якщо працюєте на європейському критичному секторі, дивимося на NIS2; якщо ви фінансова організація або ICT provider для неї - на DORA; якщо продаєте B2B SaaS-рішення або керовані послуги і клієнти запитують підтвердження надійності, тоді для вас SOC 2.  

Крок 2. Створити односторінкову мапу контролів

Замість сотні окремих файлів варто спочатку побудувати просту мапу: вимога → контроль → власник → доказ → статус. Саме така логіка найкраще працює і для регуляторного gap assessment, і для підготовки до SOC 2, і для перевірки постачальників або клієнтів. Це також відповідає підходу ENISA, яка прямо орієнтує компанії на mapping obligations to roles and deliverables. 

Крок 3. Винести third-party risk в окремий потік

У 2026 році постачальники вже не можуть лишатися “додатком до procurement”. Для NIS2 це частина статті 21, для DORA це окремий великий блок із контрактними та реєстровими вимогами. Тому окремо варто визначити: хто є критичним постачальником, які є доступи, які сервіси підтримують критичні або важливі функції, які договірні умови вже є, а яких бракує. 

Крок 4. Налаштувати регулярне формування доказової бази

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

Крок 5. Перевірити контролі, перш ніж вас перевірять інші

Навіть одне настільне навчання з реагування на інцидент, один цільовий тест контролів і один цикл перевірки постачальників часто дають більше користі, ніж п’ять нових політик. Це особливо важливо там, де DORA робить тестування окремою вимогою, а NIS2 прямо вимагає оцінювати ефективність заходів.

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

Чим NIS2 відрізняється від DORA?

NIS2 це широка директива ЄС для 18 критичних секторів, яка встановлює вимоги до кіберризиків, інцидентів і стійкості. DORA це спеціалізований регламент для фінансового сектору, який робить акцент на ICT risk management, incident management, resilience testing та ICT third-party risk.  

Чи замінює SOC 2 відповідність NIS2 або DORA?

Ні. SOC 2 це звіт про контроли сервісної організації для широкого кола користувачів і клієнтів. Він може підтримати довіру та продажі, але не замінює регуляторні обов’язки за NIS2 або DORA.  

Що найчастіше хочуть бачити enterprise-клієнти?

Як правило, вони хочуть доказів того, що у постачальника є працююче контрольне середовище: управління, контроль доступу, готовність до інцидентів, нагляд за постачальниками, навчання, тестування та зрозумілий пакет доказів. Це узгоджується і з логікою SOC 2, і з практичними підходами ENISA до впровадження NIS2.

Які артефакти найцінніші для перевірки зрілості?

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

Наша GRC-команда допомагає підготуватися до вимог NIS2 Directive, Digital Operational Resilience Act та SOC 2: від оцінки поточного стану і побудови governance-моделі до впровадження контролів, підготовки доказової бази й супроводу під час перевірок.