Кібербезпека на аутсорсі — можна, відповідальність — ні: НБУ про вимоги №143

До 13 грудня 2026 року надавачі фінансових послуг повинні привести свою діяльність у відповідність до Положення НБУ №143 про інформаційну безпеку та кіберзахист. Постанова набрала чинності 13 грудня 2025-го, тож на підготовку відвели рівно рік. На практиці навколо нових вимог виникає чимало питань: чи обов'язковий власний CISO, що можна віддати підрядникам, скільки документів розробляти і чи є послаблення для малих компаній.

Одна з ключових відповідей регулятора: залучати зовнішніх виконавців для заходів з інформаційної безпеки та реагування на кіберінциденти — можна. На аутсорс реально передати моніторинг подій безпеки, реагування на інциденти та окремі технічні заходи захисту. Для невеликої компанії це часто вигідніше, ніж тримати повноцінну внутрішню команду. Але є принципове обмеження: функцію відповідальної особи за впровадження вимог №143 зовнішньому підряднику не передати. Її має виконувати або штатний працівник, призначений керівником, або сам керівник. Операційну роботу можна віддати, управлінську відповідальність — ні.

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

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

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

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

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

Якщо спростити №143 до управлінського рівня, керівнику варто отримати відповіді на п'ять запитань: хто персонально відповідає за інформаційну безпеку (не «ІТ-відділ», а конкретна людина з повноваженнями); чи розуміє компанія свої основні кіберризики щодо конкретних систем і даних; чи зможе діяти, якщо інцидент станеться завтра; чи відповідають документи реальності; і чим можна підтвердити виконання вимог — рішеннями, журналами, реєстрами, процедурами. Головне питання зараз не в тому, скільки політик уже написано, а в тому, чи може компанія сьогодні показати, що розуміє свої кіберризики, управляє ними та здатна діяти під час реального інциденту.