Логічний перехід після встановлення контексту

Після того, як компанія виконала перший крок ISO 31000 — встановила контекст управління ризиками, — у неї нарешті з’являється відповідь на запитання «хто ми є як організація і що для нас важливо?». Контекст визначає рамку: бізнес-модель, структуру процесів, регуляторні обмеження, технічні залежності, ризикові припущення, зовнішнє середовище. Саме у цій рамці й повинно відбуватися подальше управління ризиками.

Але далі постає головне питання: що конкретно може піти не так? Саме в цей момент починається ідентифікація ризиків — другий ключовий крок побудови RM-системи. Згідно з ISO 31000:2018, ідентифікація ризиків є складовою частиною процесу Risk Assessment. Однак у практиці управління ризиками, включно з вимогами регуляторів, її часто розглядають як самостійний етап, який потребує окремих процедур, артефактів і відповідальних осіб. Це нормально і відповідає логіці впровадження RM: у компанії спочатку треба зрозуміти ризики, а вже потім — переходити до їх аналізу та оцінювання.

На відміну від контексту, який описує середовище, ідентифікація фокусується на конкретних джерелах, подіях, причинах і можливих наслідках, які можуть вплинути на здатність компанії досягти своїх цілей. Це перехід від загального до конкретного — від рамки до змісту. Саме тут формується те, що згодом стане ризик-профілем компанії, а отже — основою ризик-апетиту, KRI, лімітів, звітності та ORSA. Якщо компанія помиляється на етапі ідентифікації, жодна складна методологія зважування чи ранжування ризиків уже не врятує ситуацію: система просто працюватиме з неправильними даними.

Як ISO 31000 визначає ідентифікацію ризиків

У структурі ISO 31000:2018 ідентифікація ризиків є першим підпроцесом у межах Risk Assessment, тобто оцінювання ризиків. Стандарт не розглядає її як самостійну фазу, але дає чітке розуміння того, що саме компанія повинна зробити на цьому етапі.

Суть цього кроку зводиться до трьох ключових завдань:

1. Виявити усі можливі ризики, що можуть вплинути на досягнення цілей.
   Йдеться не про гіпотетичні «страшилки», а про реальні події, які випливають із процесів, технологій, зовнішнього середовища, регуляторних вимог чи взаємозалежностей всередині компанії. Стандарт підкреслює необхідність дивитися на ризики як на потенційні відхилення від очікуваного — як у бік збитків, так і можливостей. У нашому циклі ми фокусуємося на негативних сторона ризиків, оскільки це відповідає логіці регуляторних вимог у страхуванні.
2. Встановити причини, джерела та події, здатні створити ризикову ситуацію.
   ISO 31000 наголошує, що ризик не існує у вакуумі. Він виникає через певну подію, яка спричинена конкретними причинами, що походять із визначених джерел. Ідентифікація повинна розкрити цю логічну послідовність. Стандарт не деталізує методів (це робиться в ISO 31010), але наголошує на необхідності структурованого підходу.
3. Зібрати інформацію, достатню для подальшого аналізу та оцінки ризику.
   На цьому етапі не потрібно вирішувати, наскільки ризик значний чи неприйнятний — це вже наступні підпроцеси. ISO наголошує: головне завдання ідентифікації — зібрати і зафіксувати інформацію так, щоб вона дозволила якісно провести аналіз причин, наслідків, імовірності та існуючих контролів.

У стандарті також підкреслено, що ідентифікація повинна бути:

• всеохопною, тобто не обмежуватися окремими процесами чи підрозділами;
• структурованою, щоб уникати хаотичності та суб’єктивізму;
• систематичною, тобто повторюваною у часі, а не одноразовою;
• орієнтованою на контекст, щоб уникнути універсальних, відірваних від реальності «списків ризиків».

Фактично ISO каже просту річ: не можна керувати тим, що не було виявлено. І якщо компанія не виконує ідентифікацію ретельно, далі весь процес Risk Assessment втрачає сенс. Саме тому в практиці ризик-менеджменту ідентифікація часто виділяється в окрему фазу — вона є не просто початком, а фундаментом.

Вимоги НБУ №64 та НБУ №194: системність, документування, відповідальність

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

1. НБУ №64: вимоги до системності та структурованості процесу

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

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

✔ Ідентифікація є регулярним та безперервним процесом.
Постанова підкреслює необхідність постійного моніторингу та оновлення ризиків. Це відповідає принципу ISO 31000 про систематичність та повторюваність.

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

✔ Ролі та відповідальність мають бути визначені.
У постанові чітко зазначено, що компанія повинна визначати функції та обов’язки органів управління, керівництва, власників процесів і підрозділів у частині управління ризиками. Для етапу ідентифікації це означає:
– хто збирає інформацію;
– хто проводить аналіз;
– хто відповідає за достовірність даних;
– хто затверджує результати.

Тобто НБУ очікує не просто проведення ідентифікації, а розподіленої системи відповідальності.

2. НБУ №194: вимоги до управління специфічними ризиками

Постанова №194 деталізує вимоги до управління ризиками за видами діяльності та окремими ризиками. Вона не описує ідентифікацію методологічно, але встановлює вимоги, що без якісної ідентифікації виконати неможливо.

У контексті цієї статті важливими є такі аспекти:

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

✔ Необхідність документального підтвердження того, як компанія визначає ризики.
Для різних напрямів (майно, відповідальність, технічні ризики, ОСЦПВ, неплатежі тощо) Постанова 194 прямо говорить про «процедури», «підходи» та «критерії», які використовуються компанією. Без формалізованої ідентифікації ці вимоги виконати неможливо.

✔ Зв’язок ідентифікації з побудовою технічних резервів.
Ідентифікація подій, що впливають на формування резервів, а також ризиків, що можуть призвести до їх недостатності — це прямий обов’язок страховика відповідно до Постанови №194.

✔ Посилений акцент на операційних ризиках і ІТ-ризиках.
У документі містяться вимоги щодо виявлення ризиків, пов’язаних із:
– інформаційними системами;
– порушенням внутрішніх процедур;
– діями персоналу;
– залежністю від постачальників.

Ці вимоги повністю узгоджуються з ISO 31000, де джерела ризиків поділяються на внутрішні, зовнішні та такі, що стосуються подій і драйверів.

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

3. Загальний висновок щодо НБУ №64 і №194

Обидва документи вимагають, щоб страховик мав:

• формалізований, структурований процес ідентифікації ризиків;
• достатню документацію, яка підтверджує, як саме компанія виявляє ризики;
• системність і регулярність у цьому процесі;
• розподіл відповідальності, що охоплює всі рівні управління;
• зв’язок ідентифікації з конкретними ризиковими напрямами (технічні резерви, операційні ризики, ІТ-ризики, андеррайтинг, ОСЦПВ, майнові та технічні ризики, зміни в середовищі).

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

Чому «неправильна ідентифікація = неправильний ризик-профіль»

Ідентифікація ризиків — це точка, у якій починається формування ризик-профілю компанії. Усі подальші етапи — аналіз, оцінювання, встановлення лімітів, KRI, моніторинг, звітність, ORSA — працюють лише з тим, що було виявлено на старті. Тому якість ідентифікації визначає якість усієї системи управління ризиками.

Є три ключові причини, чому саме цей етап критичний.

1. Якщо ризик не ідентифіковано — він не існує для системи управління ризиками

У практиці ISO 31000 і підходах європейських регуляторів діє простий принцип:

ризик, який не потрапив у ризик-профіль, не аналізується, не контролюється і не моніториться.

Це означає, що:

• не буде оцінки імовірності та впливу;
• не будуть застосовані контролі;
• не буде KRI;
• не буде ліміту або тригера;
• не буде звітності до правління чи наглядової ради.

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

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

ISO 31000 прямо говорить, що ідентифікація є вхідними даними для аналізу ризиків. Якщо вхідні дані зібрано неправильно, весь процес розрахунково-аналітичного оцінювання втрачає сенс.

Приклади типових збоїв, які виникають через некоректну ідентифікацію:

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

Усі ці проблеми виникають не на етапі аналізу — вони закладаються саме на етапі ідентифікації.

3. Помилки ідентифікації руйнують логіку Risk Appetite, лімітів і KRI

Ризик-апетит формується на підставі істотних ризиків, визначених у ризик-профілі.
Якщо профіль неякісний:

• Risk Appetite буде встановлений на абстрактні або неправильні ризики;
• ліміти не відповідатимуть реальним джерелам загроз;
• KRI не відображатимуть справжніх драйверів подій;
• ORSA аналізуватиме не ті сценарії, які можуть реально відбутися.

Тобто вся система управління ризиками — від політик до звітності — починає працювати на хибному фундаменті.

У підсумку компанія ризикує:

• приймати стратегію з невірним урахуванням ризиків;
• порушувати вимоги НБУ щодо істотних ризиків;
• отримувати несподівані збитки через «невидимі» ризики;
• мати некоректну оцінку капітальних потреб під час ORSA.

4. Висновок: якість ризик-профілю завжди дорівнює якості ідентифікації

Управління ризиками — це система, яка працює лише тоді, коли вхідні дані достовірні.
Саме тому ідентифікація — це не технічний крок, а методологічно та управлінськи найважливіший етап RM-процесу. Якщо компанія помиляється тут, далі починається низка похибок, що множаться від етапу до етапу. Тому не випадково ISO 31000, НБУ №64, НБУ №194 та європейські вимоги до системи управління ризиками фактично збігаються в одному:
ризик-менеджмент починається там, де компанія правильно визначила ризики.

Що таке «джерело ризику», «подія», «причина», «наслідок» відповідно до ISO-логіки

У професійному ризик-менеджменті правильне розмежування цих понять є критично важливим. ISO 31000 та підтримуючі стандарти (зокрема ISO 31010) використовують єдину логіку: ризик завжди складається з джерела, події, причин і потенційних наслідків. Помилки саме тут найчастіше руйнують якість ризик-профілю.

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

1. Джерело ризику (risk source)

Це елемент, здатний породжувати ризик.

Джерелом може бути будь-що, що має потенціал створити відхилення від очікуваного результату:

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

Ключове: джерело — це те, з чого ризик «виростає», а не сам ризик і не його прояв. ISO розглядає джерела як складові структури ризику, які в поєднанні з конкретними подіями формують фактичну загрозу.

2. Подія (event)

Подія — це конкретний випадок або зміна стану, яка може вплинути на досягнення цілей. Подія — це те, що відбувається (або потенційно може відбутися).
Це центральний елемент моделі ризику: саме подія пов’язує джерело та наслідки. Важливо: подія — не причина і не наслідок. Це момент змін, який запускає ризикову ситуацію.

3. Причина (cause)

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

4. Наслідок (consequence)

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

5. Чому важливо чітко розмежовувати ці категорії

Без джерела неможливо визначити драйвери ризику.
Компанія не зможе правильно встановити KRI чи контрольні точки, якщо не розуміє, що саме породжує ризик.

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

Без причин неможливо побудувати контролі.
Контролі завжди спрямовані на причини (preventive controls) або на обмеження наслідків (mitigating controls). Якщо причини не визначені, контролі будуть випадковими.

Без наслідків неможливо встановити істотність.
Саме наслідки визначають, чи є ризик суттєвим відповідно до вимог НБУ  та внутрішніх критеріїв компанії.

6. Підсумок

ISO-логіка говорить про ризик як про структуру, де: джерело → причина → подія → наслідок.  Якщо компанія плутає ці елементи — ризики стають занадто загальними, абстрактними, дубльованими або ж такими, що неможливо аналізувати та контролювати. Саме тому цей розділ — фундаментальний: він визначає, як саме компанія повинна описувати ризики, щоб далі працювати з ними коректно відповідно до вимог ISO 31000, НБУ №64 і НБУ №194.

Що входить у scope ідентифікації ризиків і що не входить

Правильне визначення scope (обсягу) ідентифікації — це один із найважливіших моментів, на якому компанії часто помиляються. ISO 31000 прямо не надає списку «що входить», але логіка стандарту, а також вимоги НБУ №64 і №194 дозволяють чітко окреслити межі цього етапу.

1. Що входить у scope ідентифікації ризиків

✔ 1.1. Уся діяльність компанії, яка може вплинути на досягнення цілей

Scope охоплює всі процеси, продукти, проєкти, операційні цикли, залежності, які можуть стати джерелом ризику. Ідентифікація має бути всеохопною — не лише фінанси, не лише операційні процеси, не лише ІТ. Вона повинна охоплювати повну матрицю діяльності страховика.

✔ 1.2. Ідентифікація ризиків на рівні процесів

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

✔ 1.3. Ідентифікація на рівні продуктів і страхових напрямів

Це ключова вимога для страховиків згідно з вимогами НБУ. Продукт може створювати специфічні ризики: андеррайтингові, операційні, резерваційні, юридичні, ризик недостатності премій.

✔ 1.4. Ідентифікація ризиків, пов’язаних зі змінами

Всі зміни — продукти, ІТ-системи, бізнес-процеси, організаційна структура, регуляторні вимоги — є потенційними джерелами ризиків. Це прямо відображено в ISO 31000 та логіці НБУ.

✔ 1.5. Операційні залежності

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

✔ 1.6. Аналіз історії інцидентів, аудиту, скарг, порушень

Ці дані є важливим вхідним матеріалом для визначення ризиків. ISO 31010 прямо підкреслює важливість використання історичних даних.

2. Що НЕ входить у scope ідентифікації ризиків

✘ 2.1. Оцінювання імовірності та впливу

Оцінка — це інший підпроцес. Ідентифікація лише визначає події, причини, наслідки та джерела ризику. Жодної рейтингової шкали, жодних ранжувань — це пізніше.

✘ 2.2. Розробка контролів

Контролі визначаються після аналізу причин і наслідків. На етапі ідентифікації їх не створюють і не оцінюють.

✘ 2.3. Побудова KRI, лімітів та risk appetite

Усі ці елементи залежать від аналізу й оцінювання ризиків. Якщо компанія переходить до них одразу — вона перескочила половину RM-процесу.

✘ 2.4. «Збір універсальних списків ризиків»

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

✘ 2.5. Абстрактні формулювання, що не описують подію чи джерело

Фрази на кшталт «ринковий ризик», «регуляторний ризик», «економічна ситуація» — це не ідентифікація. Це категорії ризиків, а не події чи джерела.

3. Підсумок

Scope ідентифікації — це вся діяльність компанії, що може вплинути на її цілі, але без елементів оцінювання, контролю чи ранжування. Ідентифікація — це процес виявлення, а не аналізу, не пріоритезації і не управління. Вона має бути чіткою, структурованою, процесно-орієнтованою і заснованою на контексті, а не на універсальних списках.

Висновки + місток до статті №2

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

Цей етап завжди вимагає внутрішньої дисципліни. Тому що дуже хочеться «одразу перейти до справи» — поставити оцінки, пріоритети, кольори матриць. Але ISO 31000 говорить абсолютно недвозначно: якщо ви не визначили ризики правильно, усе інше буде неправильним. Управління ризиками — не про інтуїцію і не про колірні коди.
Це про якісну роботу з фактами, структурою і логікою.

На практиці ідентифікація ризиків — це не просто створення списку, а формування картини світу компанії, де видно:

• звідки можуть прийти загрози;
• які події можуть порушити роботу;
• що саме запускає ці події;
• які наслідки можуть зруйнувати цілі.

Це — фундамент ризик-профілю. І якщо фундамент кривий, жодна надбудова не встоїть. Ніякі формули, ніякі KRI, ніякі процедури не виправлять ситуацію, якщо на старті ви не побачили те, що лежить перед очима — або, що ще гірше, те, що сховане глибше. Більш того — ідентифікація ризиків це ще й тест на зрілість компанії. Зріла організація не боїться визнавати власні вразливості. Незріла — намагається приховати їх навіть від себе. ISO 31000, НБУ №64 і НБУ №194 тут абсолютно одностайні: система може працювати лише там, де компанія вміє чесно назвати свої ризики.

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

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

І якщо сьогодні ми відповіли на запитання «що таке ідентифікація і навіщо вона потрібна?», то наступна стаття відповість на інше — набагато складніше: «Як знайти те, що не лежить на поверхні?»

Сергій БАБИЧ