Я с осторожностью отношусь к корпоративным заявлениям о risk appetite.

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

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

Можно заявлять о низкой терпимости к простоям — и не инвестировать в резервирование.

Можно считать утечку конфиденциальных данных недопустимой — и разрешать использование внешних GenAI-сервисов без классификации информации.

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

Поэтому настоящий risk appetite я бы искал не в политике, а в четырёх местах:

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

Бюджет. За снижение каких рисков она действительно готова платить?

Исключения. Какие отклонения становятся постоянной частью архитектуры?

Полномочия. Кто принимает решение и отвечает за последствия?

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

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

Не «мы принимаем риск использования ИИ», а: — какой сценарий использования разрешён; — какие данные допустимы; — какие действия может выполнять модель; — где требуется подтверждение человека; — как ограничен ущерб; — при каких событиях система отключается.

AI-помощник для подготовки публичного текста и AI-агент с доступом к почте, CRM и внутренним документам не могут находиться в одной категории риска.

Мой главный тезис: решение должен принимать владелец бизнес-результата.

ИБ обязана оценить сценарий, объяснить возможные последствия, предложить меры и показать остаточный риск. Но CISO не должен единолично принимать потери выручки, остановку продукта или изменение клиентского процесса.

Иначе получается незрелая конструкция:

бизнес получает выгоду,

ИБ принимает риск,

при инциденте ответственность становится общей.

Бизнес не может оставить себе upside, а downside передать функции ИБ.

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

Если этого нет, организация не управляет risk appetite. Она просто оформляет накопление технического и управленческого долга.

Интересно, кто, по вашему опыту, должен ставить финальную подпись под принятием существенного киберриска: CISO, владелец продукта, руководитель бизнес-направления или коллегиальный риск-комитет?