Що таке управління ризиками третіх сторін (TPRM)?

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

Ключові висновки

• TPRM охоплює весь життєвий цикл відносин з постачальником: перевірку перед підписанням, оцінку ризику, усунення недоліків, постійний моніторинг і завершення співпраці — а не одну галочку при онбордингу.
• Ризик не обмежується кібербезпекою. Операційна, фінансова, комплаєнс, репутаційна, стратегічна й геополітична експозиція — усе це проходить через відносини з постачальником.
• Деякі з найруйнівніших зламів в історії почалися не з мережі самої жертви — вони почалися з облікових даних постачальника, оновлення програмного забезпечення чи непропатченої системи.
• Регулятори дедалі частіше розглядають нагляд за третіми сторонами як юридичну вимогу, а не найкращу практику — GDPR, HIPAA, DORA та NIS2 покладають відповідальність за збій постачальника на компанію, що його обрала.
• Автоматична оцінка постачальника — вже стандарт, а не перевага. Програму, що ловить реальну експозицію, відрізняє аналіз, застосований тоді, коли самого лише балу вже недостатньо для відповіді.

Що таке TPRM?

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

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

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

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

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

Чому TPRM важливий

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

Ця закономірність — точка входу поза власним периметром компанії, а збиток приземляється точно всередині нього — і є причиною, чому ризик третіх сторін розглядають як питання рівня правління, а не примітку відділу закупівель. Це також причина, чому регулювання рішуче рухається в тому самому напрямку останні кілька років. GDPR покладає на контролера даних відповідальність за те, як його процесори обробляють персональні дані, незалежно від того, чиї системи насправді припустилися помилки. HIPAA поширює відповідальність на бізнес-партнерів, що працюють із захищеною медичною інформацією, закриваючи лазівку, через яку постачальник лікарні міг би неналежно поводитися з записами пацієнтів без того, щоб лікарня розділяла цю експозицію. Регламент DORA в ЄС вимагає від фінансових установ картографувати, класифікувати та стрес-тестувати залежність від ІКТ-постачальників третіх сторін як формальне, підзвітне зобов'язання, а не факультативну вправу. NIS2 поширює еквівалентну вимогу на значно ширший перелік секторів критичної інфраструктури по всьому ЄС. PCI DSS вимагає від торговців надавати докази — не просто запевнення, — що будь-який сервіс-провайдер, який працює з даними карток, відповідає тому самому стандарту безпеки, якому підпорядкований сам торговець.

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

Варто також чітко зрозуміти, що насправді означає "задокументувати" в цьому контексті, бо саме ця деталь підводить програми, що на папері виглядають цілком розумно. Недостатньо оцінити постачальника один раз; регулятор, що розслідує інцидент, зазвичай захоче побачити історію оцінок, рівень критичності, присвоєний постачальнику, і чому саме, що було виявлено, яке усунення недоліків вимагалося, чи справді перевірено, що воно завершене, і яким був ритм моніторингу між оцінкою та інцидентом. Програма, що може надати такий слід, проходить через регуляторне розслідування зовсім інакше, ніж та, що може сказати лише "ми провели анкетування, коли онбордили їх у 2021 році".

Життєвий цикл TPRM

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

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

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

3. Усунення недоліків і мітигація. Коли оцінка виявляє прогалину — прострочений сертифікат, відсутню вимогу багатофакторної автентифікації, непропатчену систему, недекларованого субпідрядника, — виправлення працює найкраще як спільний процес із чітким дедлайном і визначеним відповідальним, а не як односторонній ультиматум електронною поштою. Впроваджують технічні контролі (обов'язкова MFA, шифрування даних у стані спокою й під час передавання, задокументований графік патчингу), а дедлайн відстежують так само, як і внутрішній пункт усунення недоліків. Більшість відносин з постачальниками переживають цикл усунення недоліків неушкодженими; ті, що ні, зазвичай — це ті, де прогалину позначили, а потім проігнорували обидві сторони, а не виправили.

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

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

Ключові категорії ризику

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

• Кібербезпека — витоки даних, фішингова інфраструктура, розміщена на скомпрометованих системах постачальника, програми-вимагачі та потужність для DDoS, яку скомпрометований постачальник може обернути проти власних клієнтів, а не лише проти себе.
• Операційна — збій сервісу через стихійне лихо, політичну нестабільність, трудову акцію чи кібератаку на постачальника, від якого компанія залежить для підтримки власних операцій, де план безперервності компанії настільки хороший, наскільки хороша її найслабша критична залежність.
• Фінансова — проблеми постачальника з грошовим потоком, нестабільність цін чи погане управління ланцюгом постачання, що стають проблемою покупця в момент, коли відносини стають опорними, а вартість переходу до іншого постачальника робить вихід дорогим.
• Комплаєнс і регуляторна — невідповідність постачальника вимогам HIPAA, PCI DSS, GDPR чи CCPA, що стає експозицією компанії-замовника так само, як і самого постачальника, — саме те, що покликана випереджати робота з управління регуляторними та комплаєнс-ризиками, оскільки більшість цих регуляторних режимів покладають відповідальність на сторону, яка обрала постачальника.
• Репутаційна — інцидент безпеки, трудова практика чи етичне порушення постачальника, що позначаються на профілі репутаційного ризику покупця через висвітлення в пресі та сприйняття клієнтів, незалежно від того, чиї системи чи політики насправді підвели.
• Стратегічна — відносини з постачальником, що більше не відповідають напрямку розвитку бізнесу, надто концентрують операційну залежність в одного постачальника або ускладнюють майбутнє придбання чи продаж активу, коли команда перевірки покупця це виявляє.
• Геополітична — санкційна експозиція, порушення експортного контролю чи регіональний конфлікт, що заважають постачальнику працювати або його власникам залишатися легітимним контрагентом, — категорія, що стала різко актуальнішою за останні кілька років у міру розширення санкційних режимів і ускладнення ручного відстеження.

Хто відповідає за TPRM

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

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

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

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

Ціна помилки в TPRM

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

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

Фреймворки та стандарти

Кілька референсних фреймворків утримують програми TPRM від того, щоб кожна компанія винаходила все з нуля, і використання правильного економить реальний час обом сторонам відносин. ISO 27036 встановлює вимоги інформаційної безпеки спеціально для відносин з постачальниками, даючи і покупцю, і постачальнику спільну точку відліку. NIST SP 800-161 дає детальний посібник з управління ризиками ланцюга постачання в кіберпросторі, спочатку написаний для федеральних підрядників США, але тепер широко застосовується далеко за межами цієї початкової аудиторії просто тому, що він ретельно опрацьований. Звіти SOC 2, підготовлені незалежним аудитором за критеріями довірчих послуг AICPA, стали близько до базового очікування для будь-якого постачальника, що працює з чутливими даними, — і якщо постачальник не може його надати, варто запитати чому.

З боку анкетування стандартизована анкета Standardized Information Gathering (SIG) і CAIQ від Cloud Security Alliance дають оцінювачам спільний, порівнюваний формат замість того, щоб кожна компанія писала власну з нуля, — корисно для оцінювача, і так само часто полегшення для постачальника, що заповнює вже п'яту майже ідентичну спеціальну анкету за квартал. Програма Shared Assessments, яка підтримує SIG, також веде ширшу спільноту учасників, побудовану саме навколо цієї проблеми — забагато покупців ставлять одному постачальнику трохи різні версії тих самих питань. NIST Cybersecurity Framework (CSF), хоч і написаний не спеціально для третіх сторін, постійно використовується як спільна таксономія, що дозволяє внутрішнім категоріям ризику покупця й власній програмі безпеки постачальника описувати ті самі контролі сумісною мовою. Дедалі більше програм тепер доповнюють або замінюють частину цього ручного процесу перевіркою анкет за допомогою ШІ, що прискорює перший прохід, не замінюючи судження, потрібне там, де автоматичне прочитання позначає щось як неоднозначне.

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

Рівні критичності постачальників

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

Типова структура виглядає приблизно так: Рівень 1 (критичний) охоплює постачальників із доступом до чутливих даних, основних систем чи операцій, без яких компанія не може функціонувати, — провайдер хмарної інфраструктури, платіжний процесор, основна банківська платформа. Вони отримують повний цикл: глибоку перевірку, постійний моніторинг, щорічну повторну оцінку як мінімум і видимість на рівні правління, якщо відносини достатньо критичні. Рівень 2 (значний) охоплює постачальників зі значущим, але обмеженим доступом — маркетингову платформу з адресами електронної пошти клієнтів, HR-систему з записами співробітників. Вони заслуговують на реальну оцінку й періодичний моніторинг, але не з тією ж інтенсивністю, що й Рівень 1. Рівень 3 (обмежений) охоплює постачальників з мінімальним або відсутнім доступом до систем — постачальника офісного приладдя, кейтеринг-сервіс, — де легкої перевірки при онбордингу зазвичай достатньо, а постійний моніторинг лише додає витрат без суттєвого захисту.

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

Анкети TPRM і незалежна верифікація

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

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

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

Побудова програми TPRM з нуля

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

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

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

Звітність TPRM для правління

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

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

Найкращі практики

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

Де закінчується автоматична оцінка

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

Показова закономірність, що нерідко трапляється в нашій власній роботі: компанія проводить стандартну анкету TPRM і автоматичний рейтинг нового логістичного постачальника перед продовженням контракту, і постачальник виходить чистим — сертифікати актуальні, жодних негативних висновків з безпеки, нічого не позначено. Але структура власності постачальника простежується через дві холдингові компанії до кінцевого бенефіціара, який також контролює окрему юридичну особу, що з'являлася під іншою назвою в санкційній справі два роки тому. Жодна анкета безпеки ніколи не мала шансів це виявити; це лежить у корпоративних реєстрах і судових записах, а не в сканері вразливостей. Розплутати цей ланцюг власності — перевірити, чи проміжна холдингова компанія — реальний діючий бізнес, чи фіктивна компанія (shell company), зареєстрована саме для приховування кінцевого бенефіціарного власника, перевірити цього власника за санкційними списками й негативними згадками в медіа та підтвердити, чи цей зв'язок випадковий, чи дискваліфікаційний, — саме той тип роботи, яку наші команди перевірки третіх сторін і санкційної перевірки виконують у таких випадках: виходячи за межі рейтингу й реєстру у відкриті джерела, куди звичайний робочий процес TPRM не сягає. Особливо гостро це питання постає для постачальників в оборонно-промисловому секторі чи критичній інфраструктурі: зв'язок власності з рф чи з підсанкційною структурою — дискваліфікаційний висновок незалежно від того, наскільки чистою виглядає технічна позиція безпеки постачальника, а стандартні інструменти TPRM самі по собі рідко відповідають на питання про власність у таких випадках. Наша послуга управління кіберризиками покриває паралельну технічну сторону: картографування реальної зовнішньої поверхні атаки постачальника тим самим методом відкритих джерел, а не прийняття автоматичного бала як остаточного слова.

Що змінюється в TPRM

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

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

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

Галузеві особливості TPRM

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

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

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

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

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

Типові помилки програм TPRM

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

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

П'ятий патерн проявляється конкретно навколо власності: пункт про зміну контролю поширений у контрактах з постачальниками, але мало які програми реально моніторять подію, яку він мав запускати. Постачальник може змінити власника — новий мажоритарний власник, злиття, придбання компанією в зовсім іншій юрисдикції — без проактивного повідомлення кожного клієнта, а програма, що перевіряє власність лише при онбордингу, не має механізму, щоб зловити зміну, що сталася через вісімнадцять місяців відносин. Це та сама сліпа зона, яку покликаний ловити чекліст due diligence для M&A на стороні покупця в угоді, застосована тут до відносин з постачальником замість цілі придбання. Пункт існує в контракті; моніторинг, що зробив би його реально корисним, зазвичай не існує в процесі.

Часті запитання

Чим TPRM відрізняється від управління ризиками постачальників (VRM)?

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

Чим TPRM відрізняється від управління ризиками ланцюга постачання?

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

Як часто потрібно повторно оцінювати постачальника?

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

Що таке ризик четвертих і п'ятих сторін?

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

Чи потрібна малим і середнім компаніям формальна програма TPRM?

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

Які інструменти компанії зазвичай використовують для TPRM?

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

Що станеться, якщо компанія повністю пропустить TPRM?

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

Хто має проводити оцінку безпеки постачальника — внутрішній персонал чи третя сторона?

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

Чи рахується підписаний контракт з пунктом про безпеку як TPRM?

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