Модель зрелости управления рисками контрагентов (VRMMM)

Каждый подрядчик, которому вы дали доступ к своим данным, каждый партнёр, обрабатывающий персональные данные ваших клиентов, — это чужой риск, который стал частью вашей компании. Проблема в том, что этот риск редко управляется системно: обычно контрагентов проверяют один раз при подписании договора и больше не возвращаются к вопросу.

Хрестоматийный реальный кейс, ставший эталонным примером для всей индустрии управления рисками контрагентов, — взлом ритейлера Target в 2013 году. Компания предоставила стороннему подрядчику по отоплению и вентиляции, пенсильванской фирме Fazio Mechanical Services, удалённый сетевой доступ исключительно для электронного биллинга, оформления контрактов и управления проектами — то есть ограниченный, формально безобидный доступ. Но эта сеть не была должным образом отделена от платёжной инфраструктуры Target. 15 ноября 2013 года злоумышленники, похитившие учётные данные Fazio, проникли через этот доступ во внутреннюю сеть Target; к 30 ноября вредоносное ПО, ворующее данные карт прямо из оперативной памяти POS-терминалов (RAM-scraping), было развёрнуто на большинстве кассовых устройств сети. С 27 ноября по 15 декабря 2013 года было похищено порядка 40 миллионов номеров кредитных и дебетовых карт, а также персональные данные до 70 миллионов покупателей. Ключевой урок для модели зрелости: формально ограниченный, «второстепенный» доступ контрагента (биллинг, а не управление системами) не означает низкий риск — реальный риск определяется тем, насколько этот доступ технически изолирован от критичных систем компании, а не декларируемым назначением доступа.

VRMMM (Vendor Risk Management Maturity Model) от организации Shared Assessments — признанный отраслевой ориентир, позволяющий оценить, насколько системно выстроена работа именно с рисками, которые контрагенты приносят в компанию, а не с самими отношениями (для этого есть отдельная модель SRM).

Контрагент, проверенный один раз при подписании договора, — это фотография риска на тот момент, а не управление им.

Происхождение и исследовательская база

VRMMM разработан и поддерживается организацией Shared Assessments — отраслевым консорциумом, специализирующимся на управлении рисками третьих сторон, широко признанным ориентиром в этой узкой, но критически важной области, особенно в финансовой и технологической отраслях, где регуляторы прямо требуют управления такими рисками. Регуляторная логика опирается на конкретные стандарты: американский NIST требует от организаций управления рисками цепочки поставщиков через Cybersecurity Framework, документ SP 800-53 Rev. 5 (где в последней редакции появилась отдельная группа контролей «SR — Supply Chain Risk Management», требующая формальных планов и прозрачности) и SP 800-161 Rev. 1. Цена игнорирования этих требований бывает измерима напрямую: когда в 2021 году через уязвимость в файлообменном сервере Accellion File Transfer Appliance пострадали десятки клиентских организаций поставщика, одному лишь Резервному банку Новой Зеландии (Reserve Bank of New Zealand) ликвидация последствий обошлась в 3,5 миллиона долларов прямых расходов и потребовала 17 500 часов внутренних трудозатрат — на устранение проблемы, возникшей не в собственной инфраструктуре банка, а у его подрядчика. Сама Shared Assessments основана в 2005 году (основатель и первый исполнительный директор — Кэтрин А. Аллен, Catherine A. Allen) как ответ финансовой отрасли на необходимость единого, стандартизированного подхода к оценке подрядчиков вместо того, чтобы каждый банк заново придумывал собственную анкету для каждого поставщика. В мае 2021 года организация была приобретена платформой OneTrust — показательный сигнал того, что управление рисками контрагентов окончательно перестало быть нишевой темой для узкого круга комплаенс-специалистов и превратилось в стандартный модуль корпоративного GRC-инструментария.

Ключевые идеи и принципы

1. Принцип: три раздела оценки.

   Основы (Foundations — есть ли вообще политики, распределение ответственности и понимание масштаба риска контрагентов), операционная деятельность (Operations — как на практике проверяются и отслеживаются контрагенты: due diligence при подписании, регулярный пересмотр, реакция на инциденты), измерение (Measurements — отслеживается ли эффективность самой программы управления рисками контрагентов).

2. Принцип: шкала от 0 до 5.

   От полного отсутствия программы управления рисками контрагентов (уровень 0) до состояния непрерывного совершенствования, где программа регулярно пересматривается и адаптируется на основе новых данных (уровень 5) — та же логика возрастающей зрелости, что и в других моделях, применённая конкретно к внешним контрагентам.

3. Принцип: риск контрагента — это риск компании.

   Модель исходит из простого принципа: ответственность за последствия (утечка данных, срыв поставки, репутационный ущерб) несёт ваша компания, даже если формальная причина — действия или бездействие внешнего контрагента.

Ограничения, слепые зоны и критика

Типовые ошибки

1. Ошибка 1: проверяют контрагента один раз при подписании договора.

   Due diligence проводится на входе, но контрагент никогда не пересматривается повторно — его реальный уровень риска мог измениться за это время.

   Как избежать

   закладывать периодический пересмотр хотя бы для контрагентов с доступом к критичным данным или процессам.

2. Ошибка 2: не различают уровень риска разных контрагентов.

   Ко всем подрядчикам применяется одинаковый (часто минимальный) уровень проверки, хотя контрагент с доступом к персональным данным клиентов и контрагент, поставляющий канцтовары, несут принципиально разный риск.

   Как избежать

   классифицировать контрагентов по уровню риска и применять более глубокую проверку только к действительно критичным.

3. Ошибка 3: нет плана на случай инцидента у контрагента.

   Компания не задумывалась, что делать, если у ключевого контрагента произойдёт утечка данных или сбой — реакция придумывается на ходу в момент кризиса.

   Как избежать

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

4. Ошибка 4: оценивают риск контрагента только по декларируемому назначению доступа.

   Контрагент с формально ограниченным, «второстепенным» доступом (как Fazio Mechanical с доступом только для биллинга) автоматически считается низкорисковым, хотя реальный риск определяется тем, насколько технически изолирована его сеть от критичных систем, а не декларируемой целью доступа. Похожая история произошла и с Uber: в декабре 2022 года компания объявила об утечке через подрядчика Teqtivity, отвечавшего за отслеживание IT-активов Uber и Uber Eats — казалось бы, сугубо вспомогательную, второстепенную функцию. Атакующие получили и опубликовали адреса электронной почты сотрудников, данные об IT-активах и материалы корпоративной отчётности; эксперты отмечали, что утечки такого рода достаточно, чтобы организовать прицельные фишинговые атаки на сотрудников Uber. И здесь ущерб вызвал не «важный» контрагент с доступом к платёжным данным, а вспомогательный сервис учёта техники — ровно та категория, которую due diligence чаще всего пропускает как малозначимую.

   Как избежать

   оценивать риск контрагента по реальной технической архитектуре доступа (сегментация сети, изоляция от критичных систем), а не только по формально заявленному назначению этого доступа.

5. Ошибка 5: не проверяют собственную сетевую сегментацию, полагаясь на безопасность контрагента.

   Компания фокусирует все усилия на проверке безопасности самого контрагента, не проверяя собственную внутреннюю архитектуру — достаточно ли изолирована сеть, к которой контрагент получает доступ, от остальных критичных систем компании, как это не было сделано у Target в 2013 году.

   Как избежать

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

План внедрения

1. Неделя 1: инвентаризация контрагентов.

   Составить список внешних контрагентов с доступом к данным, системам или критичным процессам компании.

2. Неделя 2: классификация по риску.

   Разделить контрагентов на группы по уровню риска, который они несут.

3. Неделя 3: базовая проверка критичных контрагентов.

   Провести хотя бы базовую проверку для контрагентов с наивысшим риском.

4. Неделя 4: план реагирования.

   Продумать, что компания будет делать при инциденте у ключевого контрагента. Далее: пересматривать список раз в полгода.

Как реализовать этот план с помощью фрейма VRMMM в OrgDevTools

Фрейм «VRMMM» построен как горизонтальный ряд из трёх карточек, соответствующих трём разделам модели: «Основы» (есть ли вообще политики, распределение ответственности и понимание масштаба риска контрагентов), «Операционная деятельность» (как реально ведётся проверка и отслеживание контрагентов — включая техническую изоляцию их доступа, а не только формальную due diligence), «Измерение» (как оценивается эффективность самой программы управления рисками).

Каждая карточка — свободный список конкретных наблюдений по соответствующему разделу. Вердикт фрейма устроен последовательно: пока не заданы «Основы» — подсказка начать именно с политик и распределения ответственности; когда основы есть, но операционная деятельность не описана — отдельное предупреждение; когда операционная деятельность ведётся, но эффективность программы не измеряется — явный сигнал, что без метрик нельзя понять, реально ли работает управление рисками (ровно тот пробел, который позволил случиться истории с Target и Fazio Mechanical); и только когда заполнены все три раздела — итоговый положительный вердикт.

Книги по теме

Материалы и отчёты Shared Assessments (открытый обзор методологии VRMMM, полная версия — по подписке для членов организации).