НБУ 143 і ризик-менеджмент: як побудувати framework якого вимагає регулятор

13 грудня 2026 року — дедлайн за Постановою НБУ №143 для небанківських фінансових установ (НБФУ: страхові компанії, кредитні спілки, фінансові компанії, лізингові організації). До цієї дати вони зобов'язані впровадити систему управління інформаційною безпекою (ISMS). Залишилося менше семи місяців.

Питання не в тому, чи робити — питання в тому, як зробити це один раз і правильно. Щоб не переробляти через рік, коли регулятор посилить вимоги або бізнес вийде на нові ринки.

Ця стаття про те, який risk framework класти в основу під НБУ-регулювання, що шукатиме аудитор при перевірці, і які рішення прийняти зараз якщо ваші плани включають EU або US ринок.

НБУ Постанова №143 — що це означає на практиці

Постанова НБУ №143, ухвалена 2023 року, зобов'язує НБФУ побудувати ISMS відповідно до ISO/IEC 27001. Це не рекомендація — це регуляторна вимога з конкретними наслідками.

Що вимагає НБУ:

• Задокументований процес управління ризиками ІБ

• Реєстр інформаційних активів з оцінкою ризиків по кожному

• Набір контрольних заходів (controls) з планом їх впровадження

• Процес моніторингу і перегляду ризиків — щонайменше щорічно

• Відповідальні особи та розподіл ролей зафіксовані в документах

• Внутрішній аудит або самооцінка ISMS

За ISO/IEC 27001 (на якого посилається НБУ 143) основна методологія управління ризиками — це ISO/IEC 27005:2022. Це не теорія — це той стандарт, за яким сертифікаційні аудитори перевіряють якість risk assessment.

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

Тайм-лайн. Якщо ISMS ще не побудований, мінімальний реалістичний строк впровадження від нуля до стану «готовий до перевірки» — 6-9 місяців при активній роботі. З урахуванням дедлайну 13.12.2026 — старт треба було зробити вчора.

ISO/IEC 27005:2022 — базова методологія для UA фінансового сектору

ISO/IEC 27005:2022 — це міжнародний стандарт управління ризиками інформаційної безпеки. Редакція 2022 року реструктурована під ISO 31000 і дає організаціям гнучкість у виборі методів оцінки — якісний, кількісний або змішаний підхід.

Чому саме ISO 27005 для НБФУ:

• НБУ 143 вимагає ISMS за ISO 27001. ISO 27005 — це вбудована методологія ризик-менеджменту для ISO 27001. Аудитор очікуватиме побачити саме цю логіку.

• Стандарт міжнародно визнаний. Якщо завтра ваша компанія починає EU-роботу або проходить due diligence від іноземного інвестора — той самий процес залишається актуальним.

• Структура стандарту добре лягає на реальну роботу без зайвої бюрократії.

Що охоплює ISO 27005:

• Ідентифікація ризиків: активи, загрози, вразливості та зв'язки між ними

• Аналіз ризиків: оцінка ймовірності та потенційного впливу

• Оцінювання ризиків: порівняння з критеріями прийнятності, визначення пріоритетів

• Обробка ризиків: чотири варіанти — модифікувати (знизити), прийняти, уникнути, передати (страхування, аутсорсинг)

• Моніторинг і перегляд: безперервний процес, не разова вправа

• Комунікація із зацікавленими сторонами — включно з правлінням і наглядовою радою

Де ISO 27005 потребує доповнення:

Стандарт не закриває operational resilience як окрему дисципліну. Якщо НБФУ критично залежить від хмарних або аутсорсингових ICT-постачальників — потрібен окремий рівень управління ризиками третіх сторін. ISO 27001:2022 Annex A закриває частину цього, але не повністю.

Як будувати risk framework під НБУ — практичний підхід

Побудова з нуля під НБУ 143 — це не про те, щоб «зібрати документи». Це про те, щоб зробити процес, який реально функціонує і який можна довести регулятору.

Крок 1. Визначте scope ISMS

Що входить у периметр: які системи, дані, процеси, підрозділи. НБУ-аудитор першим питатиме — чому scope такий, а не інший. Scope має бути обгрунтований.

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

Реєстр інформаційних активів — обов'язковий артефакт. Активи: апаратне забезпечення, ПЗ, дані (бази клієнтів, транзакційні дані, внутрішня документація), ICT-послуги, персонал на критичних ролях. Кожен актив — власник, класифікація за конфіденційністю та критичністю.

Крок 3. Risk assessment

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

Крок 4. Risk treatment plan

По кожному ризику вище прийнятного рівня — рішення: знижуємо (впроваджуємо control), приймаємо (із задокументованим обгрунтуванням), уникаємо (змінюємо процес), передаємо (страхуємо або аутсорсимо). Для НБФУ особливо актуальне страхування кіберризиків як один зі сценаріїв «передати».

Крок 5. Statement of Applicability (SoA)

Це документ, в якому зазначено які контрольні заходи з ISO 27001 Annex A застосовуються, які — ні, і чому. НБУ-аудитор використовує SoA як карту для перевірки. Якщо цього документа немає — ISMS вважається незавершеним.

Контролі в UA-контексті. При виборі криптографічних заходів захисту НБФУ слід враховувати ДСТУ-сумісні алгоритми для захисту даних, що обробляються в межах України. Для систем, де потрібна акредитована КЗДІ (комплексна система захисту інформації) — з'ясуйте, чи вимагає НБУ або профільний регулятор (НБФУ — також під наглядом Нацкомісії з цінних паперів або НБУ залежно від виду ліцензії) наявності атестата відповідності.

Крок 6. Внутрішній аудит і management review

ISO 27001 і НБУ 143 вимагають задокументованого внутрішнього аудиту ISMS і перегляду на рівні керівництва. Це не опціональні кроки — це доказова база.

Що шукатиме НБУ-аудитор при перевірці:

• Чи існує затверджена методологія ризик-менеджменту (посилання на ISO 27005 або еквівалент)

• Чи є актуальний (не старший за рік) risk register

• Чи є задокументовані рішення по кожному ризику вище прийнятного рівня

• Чи є SoA з обгрунтуванням виключень

• Чи є доказ, що процес моніторингу реально виконується, а не задекларований

• Чи є розподіл ролей і відповідальності в документах (не тільки в словах)

Порівняльна матриця: вибір підходу для UA фінсектору

Для тих хто планує EU: DORA Articles 5–15

DORA (Regulation EU 2022/2554) набрав чинності 17 січня 2025 року. Якщо ваша компанія отримує EU-ліцензію, відкриває EU-«дочку» або надає послуги EU-регульованим клієнтам у спосіб, що потрапляє під scope DORA — вимоги обов'язкові незалежно від того, що каже НБУ.

Ключові вимоги DORA, яких немає в ISO 27001 і НБУ 143:

• Article 5 — Governance: рада директорів несе пряму відповідальність за ICT-ризик. Не може делегувати. Обов'язкове навчання членів ради.

• Article 8 — Реєстр інформаційних активів включає ICT-послуги третіх сторін. Бізнес-аналіз впливу прив'язаний до реєстру.

• Articles 11-12 — Recovery time objectives (RTOs) і recovery point objectives (RPOs) для критичних функцій, щорічне тестування резервного копіювання.

• Article 26 — Threat-Led Penetration Testing (TLPT) для значущих фінансових суб'єктів.

• Articles 28-44 — Управління ICT-постачальниками: реєстр, due diligence, договірні вимоги, концентраційний ризик.

Штрафи за DORA. До 2% загального річного обороту для фінансових суб'єктів. До 10 млн EUR для фізичних осіб на управлінських посадах. Наглядові перевірки ESAs (EBA, ESMA, EIOPA) вже активні з 2025 року.

Практична логіка. Якщо ви будуєте ISMS на ISO 27005 під НБУ 143 — більшість роботи переноситься на DORA. Реєстр активів, risk register, SoA, внутрішній аудит — це спільні артефакти. Потрібно додати DORA-специфічний шар: ICT third-party programme, TLPT-план, governance документи для ради.

Для тих хто орієнтується на US або SOC 2: NIST RMF / SP 800-37

NIST Risk Management Framework (SP 800-37 Rev 2, 2018) — стандарт, розроблений для федеральних систем США, що став основним orієнтиром для US фінансових установ і технологічних компаній.

Коли NIST RMF актуальний для українського бізнесу:

• У вас є корпоративні клієнти в США, які вимагають SOC 2 Type II або запитують про NIST-відповідність в security questionnaires

• Ваша компанія має US-«дочку» або US-інвесторів, що проводять due diligence

• Ви плануєте контракти з US-федеральними агентствами або оборонними підрядниками

NIST RMF — семикроковий процес (Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor) з опорою на NIST SP 800-53 як бібліотеку контролів. Категоризація систем відбувається за FIPS 199: низький / помірний / високий рівень впливу.

Для SOC 2. Trust Services Criteria добре відповідають контролям NIST SP 800-53. Якщо ваша ISMS побудована на ISO 27001/27005, більшість контролів Annex A мають NIST-еквіваленти — mapping-вправа дає артефакти, що задовольняють обидва аудити без подвійної роботи.

NIST RMF не закриває DORA. Якщо є EU-зобов'язання — NIST RMF недостатній. Потрібне окреме DORA-покриття.

Як обрати — 5 запитань для українського бізнесу

1. Ви НБФУ під НБУ 143? Якщо так — ISO 27005 в основі, старт невідкладно. Дедлайн 13.12.2026 і мінімум 6-9 місяців на впровадження.

2. Чи є в компанії EU-ліцензія або плани її отримати? Якщо так — додавайте DORA-шар зверху на ISO 27005. Спільних артефактів багато, але DORA потребує додаткових процесів: ICT third-party programme, board accountability documents, TLPT-план.

3. Чи плануєте SOC 2 або роботу з US enterprise-клієнтами? Якщо так — додайте mapping ISO 27001 Annex A на NIST SP 800-53. Не потрібно будувати окремий NIST RMF — потрібна мова контролів, яку впізнають US-аудитори.

4. Яка ваша залежність від ICT-постачальників? Хмарні провайдери, аутсорсингові IT-компанії, процесингові центри — це ризик третіх сторін. ISO 27001:2022 закриває базовий рівень. Для DORA-scope — потрібна окрема TPRM-програма (Third-Party Risk Management).

5. Чи залучене правління до управління ризиками ІБ? ISO 27001 і DORA однаково вимагають відповідальності на рівні керівництва. Якщо правління не затвердило risk appetite statement і не отримує регулярної звітності по ризиках ІБ — ця прогалина існує незалежно від якості технічних документів.

Як зробити це правильно і не переробляти

Типова помилка — сприймати ISMS як пакет документів для «здачі регулятору». Реєстр ризиків складений, SoA підписаний, аудит пройдений — папка закрита до наступного року.

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

ISO 27005 працює, коли оцінка ризиків живить рішення про контролі, рішення живлять впровадження, впровадження перевіряється аудитом. DORA працює, коли рада директорів реально отримує звітність по ICT-ризиках і може продемонструвати це ESA-наглядачу.

Другий ризик — будувати три окремі framework'и. ISO для НБУ, DORA-документи для EU-партнерів, NIST-артефакти для US-клієнтів. Це утричі більше роботи і утричі більше шансів на невідповідності між документами.

Правильна логіка: ISO 27005 — основний методологічний рівень. Risk register, SoA, контролі — один набір артефактів. Зверху — DORA-маппінг якщо є EU-зобов'язання, NIST-маппінг якщо є US-вимоги. Ризик оцінюється один раз. Контролі впроваджуються один раз. Докази організовані так, щоб задовольняти кілька аудиторських рамок одночасно.

Строк впровадження від нуля до готовності до НБУ-перевірки — 6-12 місяців залежно від зрілості організації. З урахуванням дедлайну 13.12.2026 — вікно вже вузьке.

Якщо ви визначаєте, з чого почати і як не переробити через рік — ми відкриті до розмови. Зв'яжіться з нами.