«Коллега, подключили облако в десять раз быстрее, чем строили бы свой ЦОД, но теперь мы открываем почту и на каждое второе письмо отвечаем «да, мы не поставляем ваши данные в Африку». Вот этим, третьим сторонкам, вы и занимаетесь». Поймём, что такое third-party risk management — не просто красивая англицизация, а то, что определяет, какой регулятор придёт первым: ЦБ с отзывом лицензии или ФСТЭК с запретом обработки данных. Как работает управление рисками поставщиков в российском ИТ, и почему, отдав что-то на аутсорс, вы берёте на себя не меньше обязательств.
Что на самом деле стоит за термином
Third-party risk management (TPRM) — управление рисками третьих сторон. Под «третьими сторонами» подразумеваются любые внешние организации, предоставляющие компании продукты, услуги или доступ к своим системам. Это не только классический IT-аутсорсинг, но и облачные платформы, разработчики ПО по договору, операторы платежей, дата-центры, консультанты, службы доставки, использующие ваши базы адресов, и даже клининговые компании, чьи сотрудники имеют физический доступ к серверным.
Суть TPRM не в том, чтобы запретить работу с внешними подрядчиками, это невозможно в современной экономике. Его задача — сделать эту работу управляемой и безопасной. Основная мысль, которую часто упускают: передавая функцию на сторону, вы передаёте исполнение, но не ответственность. С точки зрения закона, особенно в рамках 152-ФЗ о персональных данных или требований ФСТЭК, оператор данных или владелец критической информационной инфраструктуры (КИИ) остаётся ответственным за их сохранность, даже если обработку ведёт подрядчик.
Почему российские регуляторы давят именно на поставщиков
Традиционная модель информационной безопасности была сфокусирована на периметре: защищали свою сеть, свои серверы, своих сотрудников. Однако цифровая трансформация и экономическая целесообразность разрушили этот периметр. Данные теперь обрабатываются в «облаке» одного вендора, часть логики выполняется скриптами другого, а для аналитики используется SaaS-сервис третьего.
Регуляторы — ФСТЭК, ФСБ, Роскомнадзор — видят в этой цепочке самое слабое звено. У них нет ресурсов для тотального контроля над всеми компаниями, поэтому давление идёт на крупных операторов и субъектов КИИ, требуя от них контроля над своей экосистемой. ФСТЭК в своих приказах прямо указывает на необходимость оценки защищённости информационных систем третьих лиц. 152-ФЗ обязывает заключать с обработчиками соглашение, где прописаны все обязательства по защите данных.
TPRM из западной бизнес-практики превратился в России в обязательное условие соответствия регуляторным требованиям. Это не вопрос «хорошего тона», а механизм, без которого невозможно получить положительное заключение по модели угроз или пройти проверку.
Слои рисков: не только кибербезопасность
Когда говорят о рисках третьих сторон, первым делом вспоминают утечки данных. Это ключевой, но не единственный слой. Управление рисками поставщиков охватывает несколько взаимосвязанных областей.
Операционные и репутационные риски
Отказ сервиса у облачного провайдера парализует ваши бизнес-процессы. Задержка поставки «железа» срывает проект по модернизации. Это операционный риск — риск срыва или ухудшения выполнения внутренних процессов из-за проблем у поставщика. Репутационный риск возникает вслед за ним: клиенты и партнёры видят неработающий сервис и винят в этом вас, а не вашего подрядчика. В российском контексте сюда же добавляется риск попасть в реестр нарушителей РКН или стать фигурантом новости об утечке, что напрямую бьёт по доверию.
Правовые и регуляторные риски
Поставщик может нарушать лицензионные соглашения с другими вендорами, использовать пиратское ПО в рамках оказания вам услуг. При проверке ФСТЭК может быть оштрафована ваша компания как конечный пользователь. Если подрядчик, обрабатывающий персональные данные, не обеспечил их защиту в соответствии с 152-ФЗ, штраф от Роскомнадзора также придёт вам. Этот слой рисков наиболее формализован и требует скрупулёзной работы с договорами и проверкой соответствия подрядчика нормативным актам.
Финансовые риски
Внезапное банкротство ключевого поставщика технологий или резкий рост тарифов создают прямую финансовую угрозу. Для субъектов КИИ, чья деятельность должна быть бесперебойной, наличие единственного поставщика без готового плана миграции на альтернативное решение рассматривается как серьёзная уязвимость.
Цикл управления рисками поставщика: от выбора до расставания
TPRM, это не разовая проверка перед подписанием договора, а непрерывный процесс, который можно разбить на ключевые стадии.
1. Предварительная оценка и категоризация
Прежде чем начинать детальную проверку, нужно понять, с кем имеете дело и насколько это рискованно. Всех поставщиков делят на категории, обычно по двум осям: критичность предоставляемой услуги (насколько её отказ повлияет на бизнес) и уровень доступа к данным/системам (имеет ли поставщик доступ к конфиденциальной информации). Компания, оказывающая услуги хостинга для публичного сайта-визитки, и компания, хранящая и обрабатывающая базу паспортных данных клиентов, попадут в разные категории риска. Для каждой категоции определяется глубина due diligence.
2. Due Diligence и аудит
На этом этапе собирается информация о поставщике. Для низкорисковых категорий может хватить заполненной анкеты. Для критически важных поставщиков с доступом к конфиденциальным данным процесс глубже: анализ политик безопасности, запрос отчётов о независимом аудите (например, по стандартам PCI DSS, если речь о платежах), проверка наличия необходимых лицензий ФСТЭК и ФСБ (для средств криптозащиты, средств защиты информации). В идеале — выездной аудит силами собственной службы безопасности или привлечённых экспертов.
[КОД: пример структуры JSON-анкеты для оценки поставщика, включающей разделы "Общая информация", "Безопасность инфраструктуры", "Соответствие 152-ФЗ", "Политика ИБ"]3. Договорное закрепление
Все требования по безопасности должны быть отражены в договоре или отдельном соглашении об обработке данных (для 152-ФЗ). Это включает SLA по информационной безопасности, право на проведение аудитов, обязанность поставщика уведомлять о инцидентах, порядок возврата или уничтожения данных по окончании сотрудничества. Без юридически значимого документа все предыдущие проверки теряют силу.
4. Постоянный мониторинг
Ситуация у поставщика меняется: он может сменить владельца, переехать в другой ЦОД, обновить ПО с уязвимостями. Мониторинг включает отслеживание его финансового состояния, новостного фона (не было ли публичных инцидентов), регулярный пересмотр предоставленных им отчётов (например, новых заключений ФСТЭК). Для субъектов КИИ ФСТЭК прямо предписывает проводить периодический контроль эффективности мер защиты у третьих лиц.
5. Завершение отношений и вывод
Этап, который часто игнорируют. При прекращении работы с поставщиком, особенно хранящим ваши данные, должен быть выполнен гарантированный процесс их уничтожения или возврата с предоставлением подтверждающего акта. Необходимо также убедиться, что у него не осталось резервных копий, а все учётные записи и доступы отозваны. «Забытый» аккаунт в админ-панели бывшего облачного провайдера — типичная брешь.
Особенности российской практики и как их обходить
Теория TPRM, описанная в западных учебниках, сталкивается с российской реальностью, где многие поставщики, особенно средние и малые, не имеют формализованных политик безопасности и смотрят на анкеты как на бюрократическую помеху.
- Нехватка экспертизы у поставщика. Часто подрядчик технически силён в своей области (например, в разработке), но не имеет выделенного специалиста по ИБ. Выход — не отказываться от сотрудничества, а включать в договор пункт о его обязанности привести процессы в соответствие с вашими требованиями в оговоренные сроки, либо оказывать ему консультативную поддержку (что создаёт дополнительные риски).
- «Серые» зоны с облаками. Крупные облачные провайдеры имеют всю необходимую инфраструктуру соответствия. Сложнее с нишевыми SaaS-сервисами. Здесь работает принцип категоризации: не размещайте критичные и чувствительные данные в сервисах, которые не могут предоставить внятный отчёт о мерах защиты и не имеют юрлица в РФ для предъявления претензий.
- Требования ФСТЭК к СЗИ. Если в цепочке обработки используются средства защиты информации (СКЗИ, VPN, DLP), они должны быть сертифицированы ФСТЭК. Нельзя требовать от поставщика-разработчика купить конкретную дорогую систему, но можно в договоре прописать требование о применении СЗИ, имеющих необходимые сертификаты, и предоставить право проверить это.
Инструменты и интеграция в процессы компании
Управление сотнями поставщиков вручную, через Excel-таблицы и почту, неэффективно. На рынке существуют как крупные GRC-платформы, так и более узкоспециализированные решения для TPRM, которые автоматизируют сбор анкет, отслеживание сроков действия документов, оценку рисков.
Однако главная задача — не купить софт, а встроить процессы TPRM в существующие бизнес-процессы компании. Служба ИБ должна работать в связке с юридическим департаментом (при согласовании договоров), департаментом закупок (на стадии тендера) и бизнес-заказчиками. Идеальная точка входа — регламент закупок, где прописано, что любой новый контракт с IT-поставщиком проходит обязательную проверку безопасности в соответствии с его категорией риска.
Что будет, если этого не делать
Отсутствие внятного TPRM, это игра в русскую рулетку с регуляторами. Последствия структурированы по нарастающей:
- Регуляторные штрафы. От Роскомнадзора по 152-ФЗ (до 500 тыс. руб. для юрлиц, а по новым поправкам — кратно обороту), от ФСТЭК за нарушение порядка защиты информации в КИИ (сотни тысяч рублей).
- Предписания об устранении нарушений. Часто более болезненные, чем штрафы. ФСТЭК может обязать приостановить обработку данных с использованием систем подрядчика до устранения недостатков, что означает остановку бизнес-процессов.
- Репутационный ущерб и потеря клиентов. Особенно критично для финансового сектора и госсектора.
- Операционные потери. Отказ непроверенного поставщика, на котором «держится» ключевой сервис.
- Кибер-инцидент. Проникновение к вам через уязвимость в системе подрядчика с последующей утечкой данных или шифровальщиком. Здесь финансовые потери умножаются на репутационные.
third-party risk management, это не абстрактная «лучшая практика», а практическая необходимость для выживания и устойчивого ведения бизнеса в условиях цифровой экономики и жёсткого регулирования. Это работа не службы ИБ в изоляции, а всей компании, осознавшей, что её безопасность заканчивается там, где начинается самый слабый из её партнёров.