Управління ризиками третіх сторін: що бізнес повинен мати готовим у 2026

До 2022 року третіх сторін в Україні перевіряли за залишковим принципом. Підписав договір, отримав ISO-сертифікат постачальника в PDF, поклав у папку. Виконали.

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

У 2026 році це вже не просто бізнес-ризик. Це питання регуляторної відповідності, аудиторських перевірок і — для деяких — умова для роботи з EU-клієнтами.

Чому TPRM став больовою точкою саме зараз

Три речі зійшлися одночасно.

Хмарна міграція після 2022 прискорилась — разом з ризиками. Бізнес масово перейшов на хмарні рішення: Azure, AWS, Google Cloud, десятки SaaS-інструментів. Це правильне рішення з точки зору resilience. Але кожен новий cloud-vendor — це новий вектор атаки, нова залежність, нова точка відмови. Реєстр постачальників, який не оновлювався з 2021 року, вже не відображає реальну картину ризиків.

Supply chain атаки стали системними. SolarWinds, Kaseya, 3CX — це не виключення, це нова нормальність. Атакувати великий банк напряму важко. Атакувати його через довіреного IT-вендора — значно простіше. Компанії, які вважали, що купують захищений продукт, отримували компрометований оновлення. Ефект доміно: один постачальник, десятки жертв.

Регуляторний тиск зростає — і в Україні, і для тих, хто працює з EU. НБУ підсилює вимоги щодо операційної стійкості фінансових установ. Закон про захист персональних даних зобов'язує перевіряти обробників персональних даних. Для операторів критичної інфраструктури — окрема система вимог. А якщо у вас є EU-клієнти або плануєте вихід на ринок ЄС — на горизонті DORA і NIS 2 з власними зобов'язаннями щодо третіх сторін.

Один з українських фінтехів, з якими ми працювали, виявив під час аудиту, що 40% їхніх активних SaaS-підписок не фігурували ні в одному реєстрі ризиків. Частина з них обробляла персональні дані клієнтів. Жодного DPA (Data Processing Agreement) підписано не було.

Що вимагає українське регулювання від третіх сторін

Фінансовий сектор: вимоги НБУ

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

• Ідентифікувати всіх критичних постачальників послуг

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

• Мати процедури на випадок відмови або виходу постачальника

• Документувати SLA та вимоги до безперервності в договорах

Аутсорсинг критичних функцій — окрема категорія з підвищеними вимогами до Due diligence і договірного захисту.

Захист персональних даних: обробники і субобробники

Закон України про захист персональних даних (у редакції, що наближається до GDPR) встановлює відповідальність контролера за дії обробника. Якщо ваш CRM-постачальник, хмарна платформа або аутсорсингова компанія обробляє персональні дані ваших клієнтів — вам потрібен підписаний договір про обробку персональних даних (аналог DPA) з чітким переліком обов'язків.

Це стосується і субобробників: якщо ваш SaaS-вендор передає дані третій стороні — ви маєте про це знати і мати відповідне підтвердження.

Оператори критичної інфраструктури

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

TPRM як методологія: 8 кроків з UA-адаптацією

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

Крок 1: Зберіть реальний реєстр постачальників. Не той, що лежить у фіндепі з 2020 року. Реальний — з усіма активними SaaS-підписками, хмарними сервісами, IT-аутсорсером, провайдером SOC, бухгалтерською системою в хмарі. Пройдіться по IT-відділу, фінансах, операційному менеджменту — кожен тримає свій шматок. Зведіть в одне місце.

Крок 2: Класифікуйте за функцією і критичністю. Для кожного постачальника: що станеться з бізнесом, якщо він відмовить завтра? Якщо відповідь "зупиниться критичний процес" — це критичний постачальник. Якщо "незручно, але переживемо" — важливий. Якщо нічого — периферійний. Не занижуйте: легше потім перекласифікувати донизу, ніж пояснювати аудитору, чому критичний процес не мав жодної оцінки ризику.

Крок 3: Заповніть реєстр договорів. Для кожного постачальника зафіксуйте: назва, тип послуги, класифікація критичності, дата початку і закінчення договору, дата наступного review. Це живий документ — призначте власника і дату наступного перегляду одразу.

Крок 4: Проведіть Due diligence для критичних і важливих постачальників. Методологія оцінки має бути задокументована до початку: які питання задаємо, як оцінюємо відповіді, хто приймає рішення. Результати — зберігаємо. Один з українських фінтехів, з якими ми працювали, роками "оцінював" постачальників усно на зустрічах. Коли аудитор попросив показати докази — нічого не знайшлося. З точки зору регулятора, оцінки не існувало.

Крок 5: Перевірте договори на наявність ключових положень. Для критичних постачальників договір має містити: SLA з конкретними метриками, право на аудит або доступ до незалежних атестацій (SOC 2, ISO 27001), умови розірвання без штрафу при порушенні безпеки, повідомлення про субпідряд. Якщо провайдер відмовляється включати ці пункти — це ризик, який ескалює до менеджменту, а не вирішується заміною пункту на "ми довіряємо провайдеру".

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

Крок 7: Розробіть exit strategies. Для кожного критичного постачальника — документ з реальним сценарієм виходу. Скільки часу займе міграція? Чи є технічна можливість вивантажити дані? Хто в команді може це зробити? "Перейдемо на інший хмарний сервіс" — не стратегія, якщо ніколи не тестувалась. Особливо актуально для cloud-вендорів із нестандартними форматами зберігання або прив'язкою до власного API.

Крок 8: Вбудуйте моніторинг на постійній основі. Щорічна анкета — мінімальна гігієна, не достатня для критичних провайдерів. Визначте тригери для позапланового review: суттєва зміна субпідряду, інцидент у провайдера, зміна власника, погіршення фінансового стану, поновлення договору. Призначте відповідального.

Документація для UA-аудиту

Незалежно від того, хто вас перевіряє — НБУ, ДССЗЗІ або зовнішній аудитор за міжнародним стандартом — набір документів схожий. Функціональна TPRM-програма має продукувати і зберігати:

• Реєстр постачальників — повний, актуальний, з класифікацією критичності та датами перегляду

• Методологію класифікації — задокументована логіка, а не просто таблиця з оцінками

• Результати Due diligence — заповнені опитувальники, рейтинги ризику, записи про ескалацію, докази опрацювання виявлених прогалин

• Аналіз договірних прогалин — порівняння чинних договорів з вимогами, план усунення з термінами

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

• Exit strategies — окремий документ для кожного критичного постачальника, включно з перевіреними припущеннями

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

• Записи про інциденти у постачальників — що трапилося, як вплинуло на ваші операції, яка була ваша реакція

Доказова база — не формальність. Без неї програма вважається такою, що не існувала.

Типові помилки: UA-реалії

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

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

Надмірна залежність від одного хмарного провайдера без exit strategy. Концентрація ризику у одного vendor — це ризик системного рівня. Якщо провайдер виходить з ринку, змінює умови або потрапляє під санкції — у вас є план?

Exit strategies на папері, але нереалістичні. "Перейдемо до альтернативи за 30 днів" — хто конкретно це зробить, є у вас ліцензія на альтернативний продукт, чи вивантажуються дані у портативному форматі?

Due diligence проведено раз, при підписанні договору. Постачальник міг змінити субпідрядників, власника, юрисдикцію. Оцінка має оновлюватись — мінімум при поновленні договору, плюс по тригерам.

Якщо у вас є EU-клієнти або ви плануєте вихід на ринок ЄС

Тоді до вищезазначеного додається окремий регуляторний пласт.

DORA (Regulation (EU) 2022/2554) набрала чинності 17 січня 2025 року. Вона поширюється на фінансові установи, зареєстровані в ЄС, та їхніх ICT-постачальників. Якщо ваша компанія є ICT-провайдером для EU-фінансової установи — ви вже у сфері дії DORA.

Article 28 DORA — найчастіший предмет зауважень на наглядових перевірках у 2026 році. Він встановлює вимоги до реєстру договірних відносин з ICT TPPs, до Due diligence перед укладенням договору, до exit strategies і до картографування субаутсорсингу. Більшість вимог перетинається з тим, що описано в розділі про 8 кроків вище — різниця у формалізації та конкретних шаблонах ESA.

Article 30 DORA встановлює обов'язкові положення для договорів з ICT-постачальниками, що підтримують критичні або важливі функції: деталізовані SLA, права на аудит, умови виходу, повідомлення про суттєві зміни субаутсорсингу.

NIS 2 (Directive (EU) 2022/2555), Article 21(2)(d) вимагає від суттєвих та важливих суб'єктів забезпечення безпеки ланцюга постачань. Сфера ширша ніж DORA: стосується не тільки ICT-послуг, а й фізичних і програмних ланцюгів постачань.

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

Якщо ви оператор критичної інфраструктури

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

Для тих, хто має операції в ЄС або підпадає під NIS 2 як "важливий суб'єкт", вимоги Article 21(2)(d) NIS 2 щодо supply chain security стосуються безпосередньо. Обидва режими стягуються до одного висновку: перевірка постачальників, документування ризиків і наявність exit plans — не опціональні.

Підготовка до аудиту

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

Перший — реєстр постачальників. Актуальний, з класифікацією, з датами перегляду. Він дає аудитору відповідь на питання "чи знає ця організація, від кого вона залежить" протягом перших п'ятнадцяти хвилин перевірки.

Другий — методологія класифікації. Аудитор обере три-п'ять постачальників з реєстру і запитає: чому цей критичний, а цей — ні? Відповідь має бути задокументована, а не триматися в голові у CTO.

Якщо жодного з цих двох немає — звідси і починайте.

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