13 грудня 2025 року набула чинності Постанова НБУ № 143, що затвердила Положення про організацію заходів із забезпечення інформаційної безпеки та кіберзахисту надавачами фінансових послуг (далі за текстом — Положення). Регулятор надав компаніям 12 місяців, щоб адаптувати свої системи та процеси до нових стандартів.

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

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

Зміст:

• Що таке Постанова НБУ № 143 і кого вона стосується
• Сім ключових блоків вимог Постанови НБУ № 143
• Як оцінити поточний стан: модель PPT
• Виклики самостійного впровадження: ресурси, експертиза та час
• Дорожня карта досягнення комплаєнсу: з чого почати підготовку

Що таке Постанова НБУ № 143 і кого вона стосується

Постанова Правління НБУ № 143 — це ключовий документ, який установлює єдині й досить суворі вимоги до кібербезпеки для небанківського фінансового сектору. Якщо раніше фокус регулятора був переважно на банках та платіжних установах, то ця Постанова фактично поширює аналогічні (хоч і адаптовані) стандарти на весь фінансовий ринок України. До слова, документ є частиною наближення українського регулювання до європейських підходів, зокрема з урахуванням DORA.

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

Попри те, що Постанова № 143 не містить переліку санкцій, невиконання її вимог може розглядатися як порушення нормативно-правових актів НБУ та створювати підстави для застосування заходів впливу відповідно до законодавства.

Сім ключових блоків вимог Постанови НБУ № 143

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

1. Управління ІБ і документація.

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

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

Керівник зобов’язаний призначити особу, відповідальну за ІБ, або виконувати ці функції особисто. Ця людина має забезпечувати виконання вимог Положення, розробляти внутрішні документи, вести реєстр програмних та апаратних засобів, виконувати моніторинг інцидентів, контролювати засоби захисту й погоджувати будь-які зміни в ІКС. У страховій компанії на 50 осіб чи кредитній спілці навряд чи знайдеться штатний фахівець із таким набором компетенцій.

Внутрішні документи — політики, положення, стандарти — мають покривати весь спектр питань ІБ, переглядатися щорічно та бути доведеними до працівників під підпис. Шаблони з інтернету не врятують: регулятор перевірятиме не лише наявність файлу, а й ступінь його впровадження та відповідність реальним процесам.

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

2. Контроль доступу.

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

Технічні вимоги Положення є дуже конкретними: паролі — від 12 символів для звичайних користувачів, від 15 — для привілейованих; зміна — не рідше ніж раз на 90 днів. Крім того, запроваджується вимога щодо автоматичного блокування екрана після 15 хвилин бездіяльності й обов’язкова багатофакторна автентифікація (MFA) для віддаленого доступу.Вручну відстежувати ротацію паролів, складні рівні доступу та вчасне блокування акаунтів для десятків користувачів — завдання, яке без автоматизації швидко стає некерованим і ризикованим. Тож на практиці реалізація цих вимог — це зона відповідальності рішень класу IGA (Identity Governance and Administration — управління ідентифікацією та правами доступу) і PAM (Privileged Access Management — управління привілейованим доступом).

3. Мережевий захист.

Окремий пласт вимог Положення стосується того, як має бути організована мережа фінансової установи. Ключовий принцип: мережа не може бути «пласкою». Постанова зобов’язує розмежувати інформаційно-комунікаційні системи на фізичному та/або логічному рівні та обмежити доступ між сегментами за допомогою міжмережевих екранів. Усі сервери, відкриті для клієнтів із зовнішніх мереж, мають розміщуватися в окремій зоні з підвищеним рівнем безпеки, так званій DMZ.

Взаємодія із зовнішніми мережами має відбуватися лише через мінімальну кількість контрольованих точок доступу. Невикористані фізичні порти потрібно відключити. У разі збою засобів захисту — передачу інформації за межі системи заборонено. Обов’язковим є використання захисту від шкідливого коду з актуальними сигнатурами та захист від DDoS і мережевих атак. 

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

4. Вимоги до ПЗ та управління змінами.

Технічна стійкість мережі тісно пов’язана з тим, як установа керує програмним забезпеченням. Постанова вимагає використовувати лише ОС і прикладне ПЗ з актуальною підтримкою оновлень безпеки. Windows Server 2012 без підтримки або стара облікова система, яку «ніхто не чіпає, бо працює», — це вже зона невідповідності.

Якщо установа використовує ПЗ без підтримки виробника (EOL-софт), Постанова зобовʼязує: провести аналіз ризиків, упровадити компенсаційні заходи, задокументувати результати й розробити план переходу на підтримуване ПЗ. Цей план затверджується Наглядовою Радою і має бути реалізований упродовж двох років. 

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

5. Моніторинг і логування.

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

Положення формально не вимагає аналізу подій у реальному часі. Але відповідальна особа зобов’язана проводити моніторинг інцидентів, а інциденти виявляються саме через аналіз логів. Тому на практиці ефективне виконання цього блоку вимог передбачає наявність рішення для централізованого збору й аналізу подій безпеки. Це може бути SIEM, XDR або навіть простіші інструменти — залежно від масштабу установи та її ризик-профілю.

6. Реагування на інциденти.

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

План реагування має бути інтегрований у загальну систему безперервності діяльності — кіберінцидент розглядається не як ізольована IT-проблема, а як подія, що може зупинити бізнес. 

У договорах із підрядниками — системними інтеграторами, розробниками ПЗ, компаніями техпідтримки — мають бути передбачені умови взаємодії під час інцидентів. А НБУ залишає за собою право вимагати від установи інформацію щодо реагування в будь-якому обсязі та форматі.

7. Вимоги до підрядників і програмного забезпечення

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

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

Як оцінити поточний стан: модель PPT

Щоб не загубитися в детальних вимогах регулятора та структурувати процес підготовки, ми рекомендуємо використовувати міжнародно визнану модель PPT (People, Process, Technology). Вона дає змогу провести комплексний GAP-аналіз і побачити реальний стан захищеності установи через три взаємозалежні призми.

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

Виклики самостійного впровадження: ресурси, експертиза та час

Розбудова системи управління інформаційною безпекою (СУІБ) — це комплексний проєкт, який виходить далеко за межі стандартної технічної підтримки. Більшість небанківських фінустанов під час самостійної реалізації вимог стикаються з трьома критичними бар’єрами.

1. Брак ресурсів.

У типовій фінустанові IT-команда (зазвичай 1–5 фахівців) повністю завантажена підтримкою поточної інфраструктури та забезпеченням безперервності бізнес-процесів. Постанова № 143 охоплює одночасно організаційний, документальний і технічний рівні. Реалізувати такий масштабний перехід «з нуля», не зупиняючи операційної діяльності, внутрішніми ресурсами майже неможливо — команда просто не має вільного часу на стратегічне проєктування безпеки.

2. Дефіцит вузької експертизи.

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

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

Навіть підготовка парольної політики — це не просто створення інструкції, а розроблення регуляторного документа, що має бути узгодженим із загальною архітектурою СУІБ та придатним для аудиту НБУ. 

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

3. Фактор часу й ризик «паперового» комплаєнсу.

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

Дорожня карта досягнення комплаєнсу: з чого почати підготовку

Побудова системи захисту згідно з вимогами НБУ не повинна перетворюватися на хаотичне закриття «дірок» — це має бути послідовний процес.

Щоб встигнути до встановлених строків, ми рекомендуємо розділити підготовку на три базові етапи.

Крок 1. Легітимізація процесів.

Навіть якщо ви лише на старті, призначте особу, відповідальну за ІБ. Згідно з пунктом 12 Постанови, це може бути навіть керівник установи (тимчасово), але таке рішення має бути зафіксоване офіційно. Без цього кроку будь-які подальші дії не матимуть формальної основи для регулятора.

Крок 2. Інвентаризація активів.

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

Крок 3. GAP-аналіз як фундамент стратегії.

Це систематична перевірка поточного стану установи на відповідність кожній нормі Постанови № 143. Саме на цьому етапі загальні вимоги перетворюються на конкретний план дій із чіткими пріоритетами.

Від оцінки до впровадження: важливість цілісного підходу

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

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

Наприклад, у Netwave ми пропонуємо небанківським фінустановам допомогу на всьому шляху — від первинного GAP-аналізу до супроводу процесу впровадження розроблених документів та фінального налаштування систем. Такий підхід дає змогу уникнути дублювання функцій і гарантує, що побудована система захисту буде справді цілісною.

Хочете впевнено пройти перевірку НБУ?

Експерти Netwave допоможуть вам пройти шлях від первинного GAP-аналізу до повного впровадження технічних засобів захисту згідно з Постановою № 143.

Висновок

Постанова № 143 — це виклик, який змушує небанківський фінансовий сектор вийти на новий рівень зрілості. Проте комплаєнс не варто сприймати лише як регуляторний тягар. Це інвестиція в життєздатність бізнесу: у цифровій економіці реальна кіберстійкість стає такою само важливою умовою, як і наявність капіталу.

Головна порада для тих, хто прагне пройти цей шлях без втрат, — уникати «гасіння пожеж» в останній момент. Своєчасний початок підготовки дає можливість не просто виконати вимоги НБУ, а побудувати систему, що стане фундаментом довіри клієнтів та стабільної роботи установи на роки вперед.

FAQ

На які компанії поширюється дія Постанови НБУ № 143?

Документ стосується всіх надавачів фінансових послуг, крім банків (які мають власне регулювання), а саме:

• страхових компаній;
• кредитних спілок;
• фінансових компаній;
• ломбардів.

Яка головна мета нових вимог?

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

Які ризики невиконання Постанови № 143?

Постанова № 143 не містить власних санкцій, але її невиконання — це порушення нормативних вимог НБУ. А це вже підстава для застосування загальних санкцій регулятора залежно від критичності порушення.

Починаючи з 2027 року НБУ застосовуватиме стандартні заходи впливу:

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

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

Чи відрізняються вимоги НБУ для малих і середніх небанківських фінансових установ?

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