Постачальник відновив роботу. А чи відновився ваш бізнес?
Чому надійність критичного постачальника ще не гарантує операційної стійкості компанії
Коли надійність постачальника перестає бути гарантією
20 жовтня 2026 року порушення роботи хмарних сервісів Google Cloud стало черговим нагадуванням про те, наскільки глибоко сучасні фінансові установи залежать від зовнішньої технологічної інфраструктури. За повідомленнями, які стали предметом професійного обговорення, перебої торкнулися низки фінансових організацій, зокрема Revolut, Lloyds та HSBC, а їхні клієнти зіткнулися з труднощами під час використання цифрових банківських послуг. Незалежно від конкретних технічних причин інциденту, які потребують окремого документального підтвердження, ця ситуація продемонструвала характерну особливість сучасного цифрового бізнесу: порушення роботи одного інфраструктурного компонента може спричинити ланцюгові наслідки для організацій, які безпосередньо ним не управляють, але критично залежать від його доступності.
Цей інцидент став приводом для цікавої професійної дискусії, започаткованої Linda Tuck Chapman, керівницею Third Party Risk Institute, яка у своєму дописі в LinkedIn сформулювала проблему через промовисте твердження: «Your vendor’s SLA is not your customers’ recovery plan». Його зміст виходить далеко за межі договірних відносин із технологічними постачальниками, оскільки порушує фундаментальне питання відповідальності за операційну стійкість компанії. Організація може ретельно перевіряти постачальників, аналізувати їхні сертифікати, погоджувати показники доступності сервісів, отримувати результати тестування планів відновлення та передбачати договірні санкції за порушення зобов’язань, але жоден із цих інструментів окремо не доводить, що вона зможе продовжувати виконання критичних бізнес-функцій у разі фактичної недоступності зовнішнього сервісу.
У дискусії учасники звернули увагу на характерну суперечність між формальною якістю договору та реальними наслідками технологічного збою. Показник доступності на рівні 99,9%, який у багатьох випадках сприймається як достатньо високий, може відповідати договірним вимогам постачальника, але не обов’язково задовольняти потреби конкретного бізнес-процесу, для якого навіть короткочасне переривання створює неприйнятні наслідки. Лінда підтримала цю позицію, наголосивши на необхідності співвідносити SLA з допустимими межами порушення діяльності, планами реагування та перевіреними альтернативними процедурами. Це важливе уточнення, адже договірний показник доступності зазвичай характеризує роботу сервісу протягом визначеного періоду, тоді як бізнес цікавить насамперед тривалість конкретного переривання, момент його виникнення, масштаб порушених операцій і здатність організації виконувати свої зобов’язання перед клієнтами.
Відмінність між відновленням постачальника та відновленням бізнесу має і практичний, і управлінський вимір. Постачальник може відновити технологічну платформу в межах погодженого часу, але компанії після цього ще доведеться перевірити цілісність даних, відновити прикладні системи, завершити перервані операції, усунути накопичені затримки та переконатися, що критичні послуги знову доступні клієнтам. Навіть формальне виконання всіх договірних зобов’язань не гарантує, що втрати компанії залишаться в межах її ризик-апетиту, а наслідки для клієнтів будуть прийнятними. Отже, оцінювання ризиків третіх сторін не може обмежуватися надійністю постачальника, оскільки його кінцевою метою має бути забезпечення стійкості організації, яка користується відповідними послугами.
Концентрація залежностей і межі операційної стійкості
Однією з найбільш недооцінених проблем управління ризиками третіх сторін залишається концентрація технологічних та операційних залежностей. Традиційний підхід до Third-Party Risk Management (TPRM) передбачає оцінювання окремих контрагентів за встановленими критеріями, серед яких фінансова стійкість, інформаційна безпека, надійність інфраструктури, якість послуг, наявність планів безперервності діяльності та результати їхнього тестування. Така перевірка необхідна, але її результати можуть створювати хибне відчуття диверсифікації, якщо компанія не досліджує взаємозв’язки між постачальниками, субпідрядниками та власними бізнес-процесами. Декілька формально незалежних програмних продуктів можуть використовувати одну хмарну платформу, спільного провайдера ідентифікації користувачів, однакові канали зв’язку або інші критичні компоненти, відмова яких одночасно порушить роботу різних систем.
У коментарі від Української асоціації ризик-менеджерів увагу було звернуто на те, що концентрація ризиків і взаємопов’язані залежності здатні зробити відмову одного постачальника значно небезпечнішою, ніж передбачають результати індивідуального оцінювання третіх сторін. Лінда підтримала цю думку, зазначивши, що спільні залежності можуть створювати вразливості, які залишаються невиявленими під час перевірки окремих контрагентів, а розуміння таких взаємозв’язків і регулярне тестування заходів безперервності необхідні для підтримання критичних послуг. Ця позиція має принципове значення для корпоративного ризик-менеджменту, оскільки переводить увагу від сукупності окремих договорів до цілісної архітектури залежностей організації та можливого спільного впливу їхньої відмови на бізнес.
Водночас професійна дискусія продемонструвала, що операційну стійкість не слід ототожнювати з абсолютною безперервністю діяльності. Один із учасників навів приклад міжнародної системи фінансових повідомлень SWIFT, порушення роботи якої може спричинити затримки в обробленні транзакцій навіть за наявності альтернативних маршрутів. Лінда погодилася з цим аргументом, підкресливши, що організація не здатна повністю контролювати всі зовнішні залежності або усунути будь-які переривання, а отже, її завдання полягає в розумінні можливих наслідків, визначенні допустимої тривалості порушення та підготовці реалістичних заходів реагування. Такий підхід дозволяє уникнути двох крайнощів: необґрунтованого прагнення забезпечити безперервність будь-якою ціною та формального прийняття ризиків, наслідки яких залишаються недостатньо дослідженими.
Для практичного застосування цього принципу компанії необхідно визначити критичні бізнес-процеси, встановити максимально допустиму тривалість їхнього порушення та оцінити можливі фінансові, операційні, регуляторні й репутаційні наслідки різних сценаріїв. Таке оцінювання повинно ґрунтуватися на результатах аналізу впливу на бізнес (Business Impact Analysis, BIA), враховувати вимоги до часу відновлення (Recovery Time Objective, RTO), допустимої втрати даних (Recovery Point Objective, RPO) та відповідність цих параметрів установленому ризик-апетиту. Важливо також розуміти, що допустима тривалість порушення не завжди збігається з технічним часом відновлення окремої системи, оскільки критичний бізнес-процес може залежати від декількох технологічних компонентів, працівників, зовнішніх контрагентів і доступності необхідної інформації.
Резервний постачальник і плани відновлення: від документа до реальної готовності
Наявність альтернативного постачальника часто розглядається як один із ключових заходів зниження ризику концентрації, але практична цінність такого рішення залежить від можливості своєчасно й безпечно перейти до використання резервного сервісу. У професійному обговоренні один із учасників зауважив, що компанії недостатньо часто перевіряють здатність фактично переключитися на альтернативного провайдера. Розвиваючи цю думку, Лінда звернула увагу на перенесення даних, технологічну інтеграцію, договірні обмеження та строки переходу, які можуть зробити формально передбачену альтернативу практично недоступною в момент виникнення інциденту. Для фінансової установи така ситуація особливо небезпечна, оскільки перехід на іншу платформу може вимагати не лише технічного переналаштування, а й перевірки цілісності інформації, відновлення взаємодії із суміжними системами, виконання вимог інформаційної безпеки та забезпечення контролю за фінансовими операціями.
Відповідно, оцінювання альтернативних постачальників повинно включати перевірку реальної можливості їхнього використання в умовах обмеженого часу, недоступності основної інфраструктури та підвищеного операційного навантаження. Якщо для переходу необхідно декілька днів, а критичний бізнес-процес може залишатися недоступним лише кілька годин, наявність резервного договору не забезпечує потрібного рівня стійкості. Аналогічна проблема виникає, коли резервна система використовує ті самі критичні технологічні компоненти, що й основна, або коли для її активації потрібні дані та облікові записи, доступ до яких залежить від постачальника, що припинив роботу. У таких випадках формальна диверсифікація може не лише не зменшувати ризик, а й приховувати його справжній масштаб.
Звідси випливає необхідність принципово іншого підходу до тестування Business Continuity Plan (BCP) і Disaster Recovery Plan (DRP). Перевірка результатів навчань постачальника дозволяє отримати інформацію про його технологічну готовність, але не дає достатніх підстав оцінити здатність компанії продовжувати власні операції. У дискусії Лінда наголосила, що сценарні навчання з моделюванням недоступності критичного постачальника допомагають виявляти приховані залежності, нереалістичні припущення щодо часу відновлення та недоліки резервних процедур ще до виникнення реального порушення. Для організації це означає необхідність перевіряти не лише відновлення окремих інформаційних систем, а й виконання критичних бізнес-функцій, включаючи взаємодію працівників, ухвалення рішень, доступність необхідних даних, інформування клієнтів та завершення перерваних операцій.
Практичне тестування повинно відповідати характеру залежностей компанії та можливим сценаріям їхньої відмови. Доцільно моделювати не тільки короткочасну недоступність одного сервісу, а й тривале порушення роботи постачальника, одночасну відмову декількох залежних систем, неможливість швидкого перенесення даних або ситуацію, коли резервний провайдер не здатний прийняти необхідне навантаження. Особливу увагу слід приділяти повноваженням щодо активації альтернативних процедур, оскільки навіть технічно підготовлене рішення може виявитися неефективним, якщо відповідальні особи не мають чітких критеріїв його застосування або необхідні погодження займають більше часу, ніж допускає критичний бізнес-процес. Результати таких навчань мають ставати підставою для перегляду процедур, уточнення лімітів, удосконалення договірних умов та повторного тестування виявлених недоліків.
Український досвід: від вимушеної адаптації до системного управління стійкістю
Для українських компаній питання залежності від критичних постачальників має особливе значення, оскільки повномасштабна війна перетворила забезпечення безперервності діяльності з переважно планового завдання на постійну управлінську практику. Організації змушені враховувати можливість тривалих відключень електроенергії, пошкодження телекомунікаційної інфраструктури, обмеження фізичного доступу до приміщень, вимушеного переміщення працівників та одночасного порушення роботи декількох зовнішніх сервісів. За таких обставин резервні канали зв’язку, альтернативні джерела живлення, віддалені робочі місця, хмарні технології та дублювання інформаційних ресурсів стали важливими елементами забезпечення операційної стійкості, хоча їхня наявність не усуває необхідності системного оцінювання взаємозалежностей і можливих спільних точок відмови.
У відповіді на коментар Української асоціації ризик-менеджерів Лінда окремо відзначила український досвід як переконливе нагадування про те, що операційна стійкість повинна підтверджуватися в реальних умовах. Вона також підтримала тезу про концентрацію ризиків і спільні залежності, які можуть залишатися невиявленими під час індивідуального оцінювання постачальників. Ця оцінка важлива не лише як професійне визнання досвіду українських компаній, а й як підстава для ширшого висновку: робота в умовах тривалих зовнішніх порушень дозволяє накопичувати практичні знання про ефективність резервних процедур, але не замінює необхідності їхнього документування, систематичного аналізу та включення до корпоративної системи управління ризиками.
Для українських страховиків особливу увагу необхідно приділяти безперервності укладення договорів страхування, врегулювання збитків, здійснення страхових виплат, обміну інформацією з партнерами та виконання регуляторних зобов’язань. Наприклад, страхова компанія може використовувати різні зовнішні сервіси для основної облікової системи, електронного документообігу, комунікації з клієнтами та здійснення платежів, але частина цих сервісів може залежати від спільної хмарної платформи або телекомунікаційної інфраструктури. У разі її відмови порушення роботи окремих систем здатне одночасно вплинути на декілька критичних процесів, хоча кожен постачальник формально виконує власні договірні зобов’язання в межах передбачених умов. За таких обставин функція управління ризиками повинна оцінювати не лише ймовірність відмови окремого сервісу, а й можливий сукупний вплив на ліквідність, виконання зобов’язань перед страхувальниками, операційну діяльність та репутацію компанії.
Регуляторний аспект цієї проблеми також заслуговує на увагу, оскільки передавання окремих функцій зовнішнім постачальникам не усуває відповідальності страховика за належне управління ризиками та виконання встановлених вимог. У контексті нормативних вимог НБУ до системи управління ризиками, внутрішнього контролю та організації діяльності страховиків оцінювання критичних зовнішніх залежностей повинно бути інтегроване в загальну систему управління компанією. Це передбачає визначення відповідальних за відповідні ризики, встановлення критеріїв їхньої прийнятності, оцінювання концентрації, організацію моніторингу та своєчасну ескалацію суттєвих відхилень. Важливо, щоб результати TPRM використовувалися не лише під час укладення або перегляду договорів, а й у процесі оновлення ризикового профілю, розроблення сценаріїв стрес-тестування, перегляду BCP/DRP та підготовки управлінської звітності.
Від контролю постачальника до відповідальності за власний бізнес
Ще один важливий аспект професійного обговорення стосувався сприйняття наслідків технологічного збою кінцевими клієнтами. Один із учасників звернув увагу на те, що навіть належно оформлений договір не компенсує втрату довіри, коли клієнт фактично залишається без необхідної послуги. Лінда підтримала цю позицію, наголосивши, що клієнти оцінюють стійкість компанії за власним досвідом, а не за формальним виконанням постачальником договірних зобов’язань. Для фінансових установ це означає необхідність доповнювати технічні показники доступності сервісів оцінюванням фактичної безперервності клієнтських операцій, тривалості обмежень та здатності організації підтримувати прийнятний рівень обслуговування під час інциденту. Страхувальник, який не може повідомити про страхову подію або своєчасно отримати виплату, навряд чи вважатиме достатнім пояснення про те, що технологічний постачальник дотримався погодженого SLA.
Відповідно, розвиток TPRM повинен супроводжуватися зміною управлінських пріоритетів. Перевірка фінансової стійкості постачальника, його інформаційної безпеки, договірних гарантій і планів відновлення залишається необхідною складовою належного управління ризиками, але ці інструменти мають розглядатися як засоби забезпечення ширшої мети — здатності компанії виконувати критичні функції в умовах порушення зовнішніх залежностей. Такий підхід потребує тіснішої взаємодії функції управління ризиками з ІТ-підрозділами, власниками бізнес-процесів, функцією комплаєнсу, підрозділами інформаційної безпеки та керівництвом компанії, оскільки жоден із цих учасників окремо не володіє повною інформацією про сукупні наслідки відмови критичного постачальника.
Для Правління та Наглядової ради ключовим результатом такої роботи має бути не кількість перевірених контрагентів або наявність формально погоджених планів безперервності, а обґрунтоване розуміння того, які критичні послуги компанія здатна підтримувати за різних сценаріїв порушення, скільки часу вона може працювати в обмеженому режимі, які втрати при цьому можливі та чи залишаються вони в межах установленого ризик-апетиту. Важливо також, щоб керівництво отримувало інформацію про спільні технологічні залежності, результати практичних тестувань, невирішені проблеми резервування та реальну готовність до переходу на альтернативні механізми виконання операцій. Лише за таких умов управління ризиками третіх сторін перестає бути переважно процедурою перевірки постачальників і стає повноцінним інструментом забезпечення операційної стійкості.
Дискусія, започаткована Ліндою Так Чепмен, переконливо демонструє необхідність зміни самого підходу до оцінювання ефективності TPRM. Компанія може мати надійних постачальників, належно оформлені договори, високі показники доступності сервісів і позитивні результати зовнішніх перевірок, але все це ще не означає, що її критичні бізнес-процеси витримають відмову одного з ключових елементів технологічної інфраструктури. Справжня перевірка операційної стійкості починається там, де закінчуються договірні гарантії постачальника і виникає необхідність самостійно забезпечувати виконання зобов’язань перед клієнтами, використовуючи власні ресурси, резервні процедури та заздалегідь перевірені альтернативні рішення.
Постачальник відповідає за відновлення свого сервісу, тоді як компанія повинна забезпечити прийнятний рівень безперервності власної діяльності. Різниця між цими двома завданнями і визначає, наскільки ефективною є система управління ризиками третіх сторін, адже відновлення технологічної інфраструктури ще не означає відновлення бізнесу, а формальне виконання SLA не гарантує виконання зобов’язань перед клієнтами.
Матеріал підготовлено за мотивами публікації Linda Tuck Chapman «Your vendor’s SLA is not your customers’ recovery plan» у LinkedIn та професійної дискусії, що відбулася під нею. Приклади щодо українських страховиків наведено як аналітичні сценарії, а не як опис підтверджених інцидентів у конкретних компаніях.
Джерела:
Сергій БАБИЧ