Постанова НБУ №143 від 09.12.2025 разом із затвердженим нею Положенням формує нову базову модель інформаційної безпеки та кіберзахисту для небанківського фінансового сектору. Вона закріплює підхід, за якого інформаційна безпека розглядається як частина загальної системи керування установою. Це передбачає не лише впровадження засобів захисту, а й документування правил, розподіл повноважень, контроль доступу, керування ризиками та регулярний перегляд запроваджених заходів.
У цій статті наведено спрощений огляд ключових вимог Положення. Мета цього матеріалу – допомогти приблизно зрозуміти його структуру, логіку та основні напрями вимог, а також показати, які класи рішень можуть бути корисними для практичного дотримання нових правил. Це не юридичний коментар і не вичерпний розбір усіх норм документа. З огляду на це, для точного трактування вимог, винятків, строків і формулювань слід звертатися безпосередньо до офіційного тексту постанови та затвердженого нею Положення.
Офіційний текст документа ви зможете знайти тут.
Постанова набрала чинності 13.12.2025. Від цієї дати починається відлік строку на приведення діяльності у відповідність до вимог Положення. Надавачі фінансових послуг мають зробити це протягом 12 місяців. Отже, граничний строк приведення у відповідність – до 13.12.2026.
Кого це стосується
Вимоги поширюються на страховиків, кредитні спілки, фінансові компанії та ломбарди. Водночас документ не застосовується до надавачів платіжних та супровідних послуг, а також операторів поштового зв’язку, які мають право здійснювати діяльність з торгівлі валютними цінностями.
Перехід від «захисту систем» до «керування безпекою»
Ключова зміна, яку приносить постанова, – це перехід до ризик-орієнтованого підходу. У тексті постанови термін «ризик-орієнтований підхід» визначено як «прийняття управлінських рішень щодо впровадження заходів з інформаційної безпеки та кіберзахисту на підставі аналізу порівняння поточних ризиків інформаційної безпеки і кіберризиків з прийнятними». Тобто фінустанова повинна будувати систему захисту не за формальним або універсальним шаблоном, а з урахуванням реального рівня ризиків для своїх інформаційних активів, процесів і систем.
Фінустанова повинна визначити об’єкти захисту, серед яких:
- інформація, що становить таємницю фінансової послуги,
- інформація, що становить таємницю страхування,
- а також інформаційно-комунікаційні системи, що підтримують критичні бізнес-процеси або взаємодіють із системами НБУ.
Відтепер необхідно впроваджувати заходи безпеки на всіх стадіях життєвого циклу ІКС та сформувати повноцінний процес управління кіберризиками.
Відповідальність і організаційна модель
У розділі II Положення фіксується, що відповідальність за інформаційну безпеку лежить на керівництві.
Установа має призначити відповідальну особу за ІБ і кіберзахист, формалізувати її повноваження та забезпечити необхідний рівень підготовки. Водночас усі процеси безпеки повинні бути закріплені у внутрішніх документах і підлягати регулярному перегляду.
Внутрішня нормативна база як основа відповідності
Однією з ключових вимог є створення набору внутрішніх документів з урахуванням актуальних для фінансової установи ризиків та вимог Положення.
Важливо: ці документи мають регулярно переглядатися (щонайменше раз на рік) та оновлюватися при зміні умов функціонування ІКС. Ознайомлення користувачів із цими документами має бути підтверджене. Це формує основу для подальшого аудиту та перевірок.
Контроль активів і змін
Окремий акцент зроблено на інвентаризації активів. Фінустанова повинна підтримувати актуальний реєстр програмних і апаратних засобів ІКС та оновлювати його не рідше одного разу на рік.
Для цього можуть бути корисними рішення для керування IT активами, які допомагають вести облік активів, актуалізувати інформацію про них і контролювати зміни в ІКС.
Такі інструменти також можуть спростити виконання вимоги щодо контролю змін, оскільки дають змогу відстежувати використання програмних і апаратних засобів, не передбачених внутрішніми документами. Недозволені засоби мають бути виключені, а зміни – проходити погодження.
Керування доступом
Система доступу має бути чітко визначена: для кожного користувача або групи користувачів повинні бути встановлені ролі та відповідні права, які визначають, що саме вони можуть робити в системі – переглядати, створювати, змінювати або видаляти дані.
Ключовий принцип – мінімально необхідні привілеї, а права доступу повинні переглядатися щонайменше раз на рік.
Ці вимоги безпосередньо відображають функціональність таких класів рішень, як PAM та IGA.
Автентифікація та контроль облікових записів
Доступ до систем надається лише після успішної автентифікації за унікальним ідентифікатором. Для віддаленого доступу обов’язковою є багатофакторна автентифікація.
Встановлено чіткі правила блокування акаунтів, зокрема після кількох (до п’яти) невдалих спроб входу або тривалої неактивності (90 днів).
Ці вимоги доповнюються жорсткою політикою паролів: мінімальна довжина, обмеження повторного використання та регулярна зміна.
На практиці це зона застосування рішень для керування паролями та IGA.
Логування та контроль подій
У Положенні детально регламентуються вимоги до журналів подій: повинні фіксуватися всі критичні дії від спроб входу до змін конфігурації.
Логи мають бути захищені від модифікації, архівуватися не рідше одного разу на рік і зберігатися щонайменше один рік після архівації. Доступ до них обмежується відповідальною особою.
Тут можуть бути корисними рішення для централізованого збору, аналізу та контролю подій безпеки, зокрема рішення з функціоналом Centralized Log Management, XDR та рішення для аудиту IT-систем, залежно від архітектури середовища і конкретного завдання.
Мережевий захист і сегментація
Постанова вимагає чіткого розмежування ІКС (як на фізичному, так і на логічному рівнях). Взаємодія між сегментами повинна контролюватися, а доступ до зовнішніх мереж здійснюватися лише через контрольовані точки.
Окремо підкреслюється необхідність захисту від мережевих атак, включаючи DoS, а також ізоляції систем, доступних іззовні, у захищених зонах.
За своєю логікою ці вимоги наближені до підходу zero trust. У цьому блоці також можуть бути корисними рішення класу NDR (Network Detection and Response), які посилюють моніторинг мережевої активності та допомагають виявляти аномалії й підозрілі взаємодії між сегментами.
Програмне забезпечення та технічна база
Використовувати дозволяється лише підтримуване ПЗ або власні розробки з належною підтримкою.
У випадку використання застарілих рішень необхідно провести аналіз ризиків, впровадити компенсуючі заходи та розробити план переходу. Такий план має бути реалізований у строк, що не перевищує двох років.
Device Control
Використання змінних носіїв також підлягає регламентації: облік, ідентифікація, перевірка на шкідливе ПЗ та знищення інформації перед передачею або списанням.
Цей блок напряму перетинається з функціональністю DLP-рішень.
Управління інцидентами та взаємодія з підрядниками
Фінустанова повинна впровадити процес управління кіберінцидентами, включаючи план реагування, оцінку впливу, порядок взаємодії та документування.
Окремо регламентується взаємодія з підрядниками: договори повинні передбачати умови реагування, NDA та обмеження щодо залучення певних категорій контрагентів. У частині контролю підрядників і виконання договірних вимог цей блок перетинається з практиками управління ризиками третіх сторін (TPRM).
Висновок
Нові вимоги НБУ зводяться до того, що безпека має бути керованою, задокументованою та підтверджуваною на практиці. До 13.12.2026 необхідно привести у відповідність як внутрішні документи, так і ключові процеси та технічні механізми, що підтримують захист інформації та кіберстійкість.
З практичного погляду виконання цих вимог зазвичай потребує не одного універсального продукту, а поєднання кількох класів рішень (для інвентаризації активів, керування доступом, автентифікації, журналювання, моніторингу, контролю носіїв і роботи з контрагентами). Підготовку до нових вимог доцільно розглядати як комплексний процес, у якому важливі і технології, і внутрішні процедури, і доказова база.
