Какие киберриски бизнес действительно готов принять

Во многих компаниях можно найти документ, в котором написано, что организация обладает «низким аппетитом к киберриску».

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

Можно ли выпустить продукт с известной уязвимостью?

Допустимо ли предоставить подрядчику привилегированный доступ на три месяца?

Можно ли подключить облачный AI-сервис к корпоративным данным?

Какой простой клиентской системы компания способна выдержать?

Кто должен согласовать исключение, если устранение риска задержит запуск продукта на полгода?

Фраза «у нас низкий risk appetite» не отвечает ни на один из этих вопросов.

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

Нулевого киберриска не существует.

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

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

Поэтому компания постоянно выбирает между:

Каждое такое решение уже является решением о risk appetite — даже если компания никогда не называла его этим термином.

Если организация годами продлевает исключение по критической уязвимости, она фактически принимает риск.

Если компания разрешает бизнес-подразделениям использовать несогласованные AI-сервисы, не имея технического контроля, она фактически принимает риск.

Если резервная инфраструктура существует только в презентации, а восстановление ни разу не проверялось, руководство фактически принимает риск длительного простоя.

Неформально принятый риск не перестаёт быть риском. Он просто становится менее прозрачным и хуже управляемым.

Risk appetite описывает характер и объём риска, который организация готова принять ради достижения своих целей.

Risk tolerance переводит эту позицию в конкретные границы.

Например:

Risk appetite:

Компания готова принимать ограниченные риски доступности ради быстрого вывода цифровых продуктов на рынок.

Эта фраза задаёт направление, но её недостаточно для решения.

Risk tolerance:

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

Теперь появляется измеримая граница.

NIST Cybersecurity Framework 2.0 прямо включает в функцию Govern требование устанавливать, сообщать и поддерживать заявления о risk appetite и risk tolerance. В примерах реализации отдельно указано, что общие заявления об аппетите необходимо переводить в конкретные, измеримые и понятные пределы. (csrc.nist.gov)

Именно в этом месте многие корпоративные модели перестают работать.

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

Руководителю бизнеса сложно осмысленно принять формулировку:

Сохраняется критический риск эксплуатации уязвимости с оценкой 20 по CVSS.

Это важная техническая информация, но она ещё не описывает бизнес-решение.

Нужно показать сценарий:

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

Теперь можно обсуждать:

Обновлённый NIST IR 8286A Rev. 1, опубликованный в декабре 2025 года, также связывает risk appetite и tolerance со сценарным описанием угроз, вероятностью, последствиями и ведением интегрированных реестров рисков. В марте 2026 года NIST дополнительно выпустил руководство, направленное на улучшение коммуникации между cybersecurity risk management и enterprise risk management. (csrc.nist.gov)

Это важный сдвиг: разговор начинается не с цвета риска, а со сценария ущерба.

Для каждого существенного сценария руководству нужно ответить как минимум на пять вопросов.

Не «компрометация инфраструктуры», а конкретное развитие событий:

Последствия должны быть описаны в понятных бизнесу единицах:

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

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

Например:

ИБ может оценить риск, предложить меры и объяснить последствия.

Но владелец бизнес-риска не всегда находится в ИБ.

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

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

Принятие риска не должно превращаться в бессрочное разрешение ничего не делать.

У решения должны быть:

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

СценарийБизнес-показательДопустимый уровеньПорог эскалацииВозможное решениеНедоступность клиентской платформыПродолжительность и число затронутых клиентовДо 30 минут, не более двух раз в кварталБолее двух часов или более 50 000 клиентовНемедленная эскалация операционному руководствуУтечка клиентских данныхКатегория и количество записейМинимальный объём нечувствительных данных в контролируемом инцидентеЧувствительные данные или массовое раскрытиеРиск не принимается на уровне продуктаКритическая уязвимость перед релизомЭксплуатируемость и потенциальный ущербДопустима только при изоляции и компенсирующих мерахДоступ из интернета, наличие эксплуатации или риск привилегированного доступаПеренос релиза либо решение уполномоченного комитетаИспользование GenAIТип передаваемых данных и автономность системыОткрытые и внутренние данные низкой чувствительностиКонфиденциальные данные, действия от имени компании, доступ к productionДополнительная оценка AI security и бизнес-владельцаДоступ подрядчикаПривилегии, срок и охват системОграниченный доступ по заявке и на фиксированный периодПостоянные привилегии или доступ к критическим системамPAM, усиленный мониторинг либо отказ

Это не универсальные нормативы. Каждая компания должна установить собственные значения с учётом бизнес-модели, обязательств и способности восстанавливаться.

Ценность матрицы в другом: она превращает разговор о риске в разговор о решении.

Некоторые организации пытаются определить appetite только через деньги:

Компания принимает киберриски с потенциальным ущербом до 10 миллионов рублей.

Такой лимит удобен, но недостаточен.

Два сценария с одинаковой финансовой оценкой могут иметь совершенно разное значение.

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

В другом — раскроет медицинские данные нескольких тысяч клиентов.

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

Поэтому mature risk appetite должен быть многомерным. Для существенных сценариев стоит учитывать:

Принятие риска — это осознанное решение после анализа альтернатив.

Отсутствие бюджета, владельца или времени не является полноценным решением о принятии риска.

Фраза «мы пока ничего не можем сделать» должна быть преобразована в понятную позицию:

Отдельное исключение может выглядеть допустимым.

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

Risk appetite должен учитывать агрегацию и концентрацию риска.

Нельзя принять двадцать «небольших» рисков и считать, что общий риск тоже остаётся небольшим.

ИБ не должна единолично разрешать бизнесу рисковать.

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

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

Appetite зависит от контекста.

Риск, который был допустим для внутреннего пилота на 50 пользователей, может стать неприемлемым после запуска на миллион клиентов.

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

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

Не пытайтесь сразу описать все возможные киберриски.

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

Используйте цепочку:

угроза → событие → затронутый актив или процесс → бизнес-последствие.

Для каждого сценария установите границы по наиболее значимым параметрам:

Определите, какие риски может принимать:

Risk appetite должен влиять на:

Каждое исключение должно иметь дату завершения и условия досрочного пересмотра.

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

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

Руководство может считать четырёхчасовой простой допустимым — пока не увидит, какие операции остановятся через 40 минут.

Я считаю, что формулировка «у компании низкий аппетит к киберриску» без сценариев и порогов создаёт ложное ощущение управляемости.

Она позволяет заявить осторожную позицию, не принимая ни одного сложного решения.

Зрелый подход начинается тогда, когда руководство готово прямо ответить:

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

Бизнесу не нужен ещё один документ с зелёными, жёлтыми и красными зонами.

Ему нужен механизм, позволяющий принимать сложные цифровые решения быстрее и осознаннее.

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

Только тогда risk appetite перестаёт быть декларацией и становится частью управления компанией.

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

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