CISO и CRO: партнёры по риску или конкуренты за влияние

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

В корпоративном реестре всё это превращается в одну строку:

Cyber risk — высокий. Вероятность — 4. Влияние — 5.

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

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

Так возникает привычный конфликт.

CISO считает, что ERM чрезмерно упрощает киберриск. CRO считает, что информационная безопасность создаёт параллельную систему управления, понятную только самой ИБ.

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

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

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

В декабре 2025 года NIST выпустил финальную редакцию IR 8286 Rev. 1, прямо посвящённую интеграции cybersecurity risk management в ERM. Документ подчёркивает двустороннюю связь: руководители должны понимать состояние киберриска, а специалисты, оценивающие этот риск, — учитывать стратегические цели предприятия. NIST IR 8286C Rev. 1 развивает эту модель и описывает включение cybersecurity risk registers в общий портфель корпоративных рисков. (NIST Computer Security Resource Center)

Та же логика отражена в NIST CSF 2.0. Функция Govern была выделена отдельно, чтобы связать кибербезопасность с ERM, risk tolerance, ролями, ответственностью и юридическими обязательствами. (NIST)

Регуляторные требования также усиливают управленческий фокус. Правила SEC требуют от публичных компаний раскрывать процессы управления существенными киберрисками, роль менеджмента и порядок надзора со стороны совета директоров. DORA закрепляет за management body финансовой организации конечную ответственность за управление ICT risk, утверждение стратегии цифровой устойчивости и определение допустимого уровня риска. (SEC)

Направление очевидно: киберриск должен стать частью корпоративного управления. Но сама запись в enterprise risk register ещё не означает, что интеграция состоялась.

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

В результате возникают:

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

Руководство не может понять, почему модернизация IAM должна получить бюджет раньше проекта по устойчивости цепочки поставок, модернизации производства или снижению кредитного риска. Не потому, что cyber risk менее важен, а потому, что он представлен в другой системе координат.

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

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

Цвет и балл полезны для навигации. Но они не должны заменять содержание риска.

Одинаковый показатель «20» может скрывать совершенно разные ситуации:

Если два риска получили одинаковый балл, это ещё не означает, что они требуют одинакового решения.

CRO не нужен список CVE. Но ему также недостаточно формулировки «риск кибератаки высокий».

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

Например:

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

Хорошее описание должно отвечать как минимум на семь вопросов:

Именно за качество этой информации должен отвечать CISO.

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

Задача CRO — не переписать технический сценарий «на языке бизнеса» в одиночку.

Его роль заключается в том, чтобы встроить качественную risk information в корпоративную систему принятия решений.

CRO должен обеспечить:

Это важное различие.

CISO формирует содержание риска. CRO формирует условия, при которых этот риск можно сравнивать, агрегировать и использовать в управлении компанией.

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

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

Здесь находится ещё одна частая ошибка.

Спор CISO и CRO иногда строится так, будто один из них должен стать владельцем киберриска.

Но если сценарий угрожает доступности платёжной платформы, запуску цифрового продукта или выполнению обязательств перед клиентами, решение не может принадлежать только функции ИБ или ERM.

В зрелой модели:

Принятие риска — не подпись под формой security exception.

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

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

Из отчёта исчезают причинно-следственные связи, зависимости и неопределённость.

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

Целью становится не лучшее решение, а получение одинаковых значений из разных методов.

CISO показывает техническому комитету одну версию риска, CRO — риск-комитету другую, а совет директоров получает третью. Между ними нет управляемой связи.

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

Последний вариант особенно опасен. Если CISO и CRO по-разному оценивают риск, это не обязательно конфликт, который нужно скрыть.

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

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

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

Определить, что считается единицей риска:

Для executive-решений основной единицей должен быть сценарий, связанный с бизнес-целью или критичной услугой.

Зафиксировать, какие данные используются и кто подтверждает их качество:

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

Отдельно фиксировать степень неопределённости.

Связать технические сценарии с:

До кризиса определить:

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

Для ключевых рисков CISO и CRO должны представлять не две конкурирующие версии, а один согласованный пакет:

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

Компромиссный балл без анализа не является разрешением разногласия.

Я не поддерживаю создание отдельного «кибер-ERM», живущего параллельно корпоративному risk management.

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

CISO не должен конкурировать с CRO за право говорить с советом директоров.

Его задача — сделать информацию о риске достоверной.

Задача CRO — сделать её сопоставимой и встроенной в корпоративные решения.

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

CISO отвечает за достоверность риска. CRO — за его сопоставимость. Бизнес — за решение.

Главный признак зрелой интеграции киберрисков в ERM — не наличие строки Cyber Risk в корпоративном реестре.

Зрелость проявляется в другом:

CISO и CRO не должны бороться за влияние.

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

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