14 июля 2026 года в Dark Reading вышла колонка основателя и executive chairman HITRUST Дэниела Наткиса о том, как компании должны считать риски подрядчиков. Главная мысль неприятно проста: анкеты, сертификаты и согласованные исключения сами по себе не дают управления, если бизнес не умеет в цифрах показать, какой остаточный риск он реально держит на балансе. Для русскоязычной IT-аудитории это особенно актуально: у любой команды, которая живет на облаках, SaaS, интеграторах и аутсорсе, цепочка зависимостей давно длиннее, чем хотелось бы признать.
Как пишет Dark Reading, речь идет не только о классической кибербезопасности. Сбой у внешнего поставщика может ударить по операционной устойчивости, приватности, регуляторным обязательствам, контрактам, непрерывности бизнеса, репутации и клиентскому опыту. Наткис формулирует проблему так: совет директоров и топ-менеджмент должны понимать не набор активностей службы безопасности, а реальную экспозицию компании, возникающую потому, что данные, процессы и системы находятся вне прямого контроля организации. И вот здесь у многих начинается привычная подмена: вместо ответа на вопрос «какой риск мы несем» бизнес показывает количество проверок, заполненных опросников и согласованных remediation-планов.
Автор предлагает последовательность из восьми шагов: измерить риск, проверить полноту покрытия и уверенность в данных, сравнить результат с допустимым уровнем, объяснить отклонения, агрегировать риск по портфелю поставщиков, сопоставить себя с рынком, решить вопрос обработки и передачи риска, а затем вынести это на уровень управления. Самый важный тезис в этой цепочке: считать нужно именно остаточную экспозицию, а не просто inherent risk на входе. В расчет, по его логике, должны попадать чувствительность данных, критичность поставщика для бизнеса, качество assurance-материалов, эффективность контролей, статус исправлений, условия договора, страхование и компенсирующие меры. Иначе у компании получается знакомый корпоративный фокус: папка с артефактами толстая, а понимание реального ущерба в случае проблем у подрядчика тонкое до прозрачности.
Отдельный акцент Наткис делает на покрытии и достоверности. Менеджмент должен уметь ответить не только на вопрос, сколько подрядчиков попало в программу third-party risk management, но и какую долю совокупной экспозиции эти проверки вообще закрывают. Если важнейшие вендоры формально «проверены», но доказательства устарели, собраны со слов самого поставщика или охватывают слишком узкий кусок его процессов, уверенность в оценке резко падает. Для разработчиков и продуктовых команд из этого следует довольно приземленный вывод: зависимость от API-провайдера, облачной платформы, внешнего контакт-центра или SaaS-сервиса нельзя описывать в терминах «прошли аудит год назад». Нужен ответ, насколько свежи доказательства, что именно было проверено и где остаются слепые зоны.
Следующий болезненный момент — сравнение с risk appetite и объяснение исключений. По Наткису, если компания идет в сделку или продолжает работу с поставщиком вне обычного порога терпимости к риску, это решение должно быть не кулуарным, а явным: с измеренной экспозицией, бизнес-обоснованием, сроком, ответственным владельцем, планом снижения риска и пониманием, что именно будет передано через договор или страховку. Это важная поправка к любимой корпоративной практике, когда срочность бизнеса побеждает службу безопасности без бумажного следа, а через полгода никто уже не помнит, кто именно решил жить с этим исключением. В заметке отдельно подчеркивается: одиночное исключение может выглядеть терпимо, но группа похожих исключений превращается в существенный портфельный риск, если они завязаны на один и тот же критичный процесс, облачного провайдера, тип данных, платформу, географию, субподрядчика или договорной разрыв.
Именно здесь тема выходит за рамки комплаенса и упирается в архитектуру бизнеса. Для IT-директора или CISO недостаточно знать, что конкретный вендор «желтый», а другой «красный». Нужно видеть концентрацию: не сидит ли половина ключевых сервисов на одной платформе, не завязаны ли несколько внешних продуктов на одну и ту же уязвимую цепочку поставки, не дублируются ли слабые места в контрактах и страховом покрытии. В российском и русскоязычном контуре это особенно чувствительно еще и потому, что многие компании одновременно решают задачи импортозамещения, мультиоблачности, перехода на локальных подрядчиков и ускоренного запуска новых цифровых сервисов. На таком фоне соблазн закрыть глаза на совокупный риск очень велик: каждый отдельный компромисс кажется мелким, пока они не складываются в систему.
Еще один важный слой — бенчмаркинг и роль совета директоров. Наткис предлагает сравнивать собственные нормы и пороги не в вакууме, а с сопоставимыми организациями. Если компания сознательно принимает больший риск ради скорости, цены или конкурентного преимущества, это уже управленческая стратегия. Если же отклонение возникло просто потому, что измерение слабое, процессы расползлись, а исключения согласовывались по ситуации, речь идет уже не о смелости, а о дрейфе. Для совета директоров, по версии автора, нужен короткий количественный и трендовый отчет, ориентированный на решения, а не на операционную текучку. В нем должны быть обзор экспозиции, соответствие допускам, финансовая часть retained и transferred risk, исключения, рыночный контекст и список действий менеджмента. И это, пожалуй, самое точное место всей колонки: борду обычно не нужен двадцатистраничный каталог проверок подрядчиков, ему нужен внятный ответ, где компания выходит за собственные лимиты и сколько это может стоить.
Отдельно автор предупреждает против ложного чувства безопасности вокруг передачи риска. Наличие страхового сертификата, indemnity в договоре, завершенного ревью или согласованного исключения еще не означает, что финансовый удар действительно ушел с баланса компании. Управление начинает работать только тогда, когда бизнес может по-человечески описать остаточную экспозицию, вероятный денежный эффект, какую часть риска он оставляет у себя, какую передает и насколько надежен сам механизм передачи. Для стартапов и быстрорастущих продуктовых компаний здесь плохая новость в том, что «страховка есть» больше не считается ответом. Хорошая — в том, что дисциплинированная модель дает право двигаться быстрее там, где риск понятен и находится в допустимых рамках.
На практике колонка Dark Reading хорошо ложится на общий тренд: рынок устал от безопасности как набора процедур и все чаще требует безопасности как языка управленческих решений. Вопрос теперь не в том, есть ли у компании программа работы с подрядчиками, а в том, может ли она доказать, что понимает совокупный риск своей зависимости от внешних поставщиков. Для тех, кто строит продукты на чужой инфраструктуре и чужом софте, это уже не академическая дискуссия, а проверка зрелости бизнеса на цифрах.