Киберриск часто создаётся до того, как CISO приглашают на встречу

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

Сделка проходит юридическую и финансовую проверку. Команда оценивает выручку, клиентскую базу, интеллектуальную собственность и возможные синергии.

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

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

Сделку, скорее всего, уже не остановят.

Киберриск был создан не тогда, когда специалисты нашли уязвимости. Он возник раньше — в момент, когда бизнес принял решение, не понимая всей будущей цифровой зависимости.

На мой взгляд, если CISO подключается после подписания сделки или утверждения архитектуры, он уже не управляет риском. Он управляет последствиями принятого решения.

Мы привыкли связывать работу информационной безопасности с уже существующей технологической средой:

Но значительная часть будущего киберриска создаётся за пределами классических процессов ИБ.

Он появляется, когда компания:

Каждое из этих решений создаёт обязательства, зависимости и ограничения.

После подписания контракта заменить поставщика становится дорого. После запуска продукта переделать модель идентификации сложно. После объединения компаний быстро разделить сети и данные невозможно. После выхода на рынок внезапно появляются новые требования к хранению информации, реагированию на инциденты и управлению поставщиками.

Поэтому кибербезопасность должна присутствовать там, где эти зависимости только формируются.

Это соответствует более широкому изменению подхода к управлению киберриском. В NIST Cybersecurity Framework 2.0 функция Govern была выделена отдельно, чтобы связать кибербезопасность с корпоративным риск-менеджментом, распределением ответственности, требованиями законодательства и допустимым уровнем риска. В марте 2026 года NIST дополнительно выпустил руководство, связывающее cybersecurity risk management с enterprise risk management и решениями высшего руководства. (NIST)

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

Он также наследует:

Финансовый due diligence показывает, сколько бизнес зарабатывает сегодня.

Cybersecurity due diligence должен показать, сколько будет стоить безопасно владеть этим бизнесом завтра.

Это разные вопросы.

Компания может демонстрировать хорошие финансовые показатели и одновременно требовать существенных инвестиций в сегментацию, IAM, управление привилегированными доступами, журналирование, резервирование, Secure SDLC и перестройку процессов эксплуатации.

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

Но он может изменить:

Именно так ИБ становится частью инвестиционного решения, а не технической проверкой после него.

Похожая ситуация возникает при запуске цифровых продуктов.

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

Но к этому моменту многие ключевые решения уже приняты:

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

Например, продукт может предполагать сбор данных, которые компании в действительности не нужны. Облачная платформа может не поддерживать необходимую изоляцию клиентов. Используемый AI-сервис может создавать неприемлемую зависимость от внешней модели. Архитектура обновлений может не позволять быстро закрывать критические уязвимости без остановки сервиса.

Поэтому зрелая безопасность продукта начинается не с финальной проверки, а с вопросов на этапе концепции:

Регуляторное направление также движется в эту сторону. Европейский Cyber Resilience Act распространяет требования к кибербезопасности на планирование, проектирование, разработку и сопровождение цифровых продуктов. Производитель должен проводить оценку киберриска до вывода продукта на рынок и управлять уязвимостями в течение заявленного периода поддержки. Основные требования закона начнут применяться с 11 декабря 2027 года, а обязанности по уведомлению об активно эксплуатируемых уязвимостях и серьёзных инцидентах — уже с 11 сентября 2026 года. (Digital Strategy)

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

Ещё одна зона, где CISO должен участвовать заранее, — выбор стратегических поставщиков.

Каждая отдельная закупка может выглядеть приемлемо. Но на уровне всей компании постепенно формируется концентрация:

Проблема возникает не только в вероятности компрометации конкретного поставщика.

Вопрос в том, сможет ли бизнес продолжать работу, если поставщик:

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

Поэтому оценивать нужно не только безопасность поставщика, но и стоимость собственной зависимости от него.

Обычно причины не технические, а организационные.

Во-первых, CISO продолжают воспринимать как владельца защитных средств и соответствия требованиям, а не как участника корпоративного риск-менеджмента.

Во-вторых, бизнес опасается, что раннее подключение безопасности замедлит инициативу или приведёт к запрету.

В-третьих, сама функция ИБ иногда говорит только языком угроз, контролей и несоответствий. Руководителю инвестиционного комитета сложно использовать формулировку «отсутствует зрелый PAM» при принятии решения о покупке компании.

Ему нужно понимать другое:

Зрелый CISO не просто перечисляет недостатки.

Он переводит их в последствия для стоимости, сроков, стратегии и управляемости бизнеса.

Участие CISO в стратегических решениях не означает, что он должен посещать каждую встречу или получать право вето на любую инициативу.

Такой подход быстро превратит безопасность в бюрократический барьер.

Нужны понятные критерии подключения ИБ. Например:

Задача CISO — не сказать бизнесу: «Это опасно, делать нельзя».

Задача — представить несколько вариантов:

Решение остаётся за бизнесом. Но оно становится осознанным.

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

От каких технологий, поставщиков, специалистов, данных и инфраструктуры будет зависеть результат инициативы?

Есть ли неустранённые уязвимости, устаревшие компоненты, инциденты, технический долг, неподдерживаемое ПО или слабые процессы управления доступом?

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

Действительно ли они нужны? Где они будут храниться? Кто получит доступ? Можно ли их удалить, перенести или изолировать?

Возникнут ли новые требования к отчётности, локализации, уведомлению об инцидентах, сертификации или защите цепочки поставок?

Что необходимо сделать в первые 30, 100 и 365 дней? Какой бюджет и какие команды для этого потребуются?

Нужны ли гарантии, удержание части платежа, обязательства по устранению недостатков, право аудита, требования к уведомлению или план выхода?

Можно ли заменить поставщика, отключить компонент, вывести продукт из эксплуатации или разделить инфраструктуру без остановки бизнеса?

Каков максимальный реалистичный ущерб: простой, потеря данных, влияние на клиентов, нарушение обязательств, репутационные последствия?

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

Практическая модель может состоять из четырёх этапов.

ИБ получает краткую информацию об инициативе и определяет, требуется ли углублённая оценка.

Команда изучает архитектуру, данные, зависимости, историю инцидентов, процессы разработки, поставщиков, доступы и требования рынка.

Руководство получает не технический отчёт на сотню страниц, а краткий документ:

После одобрения инициативы выводы оценки превращаются в план интеграции, продуктовый backlog, договорные обязательства и контрольные точки.

Без четвёртого этапа даже качественный due diligence быстро становится архивным документом.

Я не считаю, что CISO должен контролировать каждое бизнес-решение.

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

ИБ должна оценивать не только готовые системы. Она должна оценивать решения, из которых появятся будущие системы, данные, зависимости и риски.

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

Это не управление риском. Это финансирование последствий.

Роль CISO меняется не потому, что информационная безопасность стремится получить больше влияния.

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

Покупка компании означает покупку её цифрового долга. Запуск продукта создаёт обязательства по его защите и сопровождению. Выбор поставщика формирует долгосрочную зависимость. Выход на рынок меняет регуляторный профиль.

Если киберриск способен повлиять на стоимость сделки, сроки запуска, доверие клиентов или устойчивость бизнеса, он должен обсуждаться до принятия решения.

После подписания договора CISO ещё может снизить риск.

Но изменить саму логику решения он уже не сможет.

Подписывайтесь на мой ТГ канал: @ib_decisions