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

Во многих компаниях существует документ, в котором описан допустимый уровень киберриска.

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

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

Именно в этих решениях, а не в политике, проявляется настоящий risk appetite организации.

NIST Cybersecurity Framework 2.0 прямо связывает заявления о risk appetite и risk tolerance с операционными решениями: они должны быть установлены, доведены до участников процессов, поддерживаться в актуальном состоянии и использоваться при выборе способов реагирования на риск. (NIST Publications)

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

Risk appetite нередко описывают слишком абстрактно:

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

Такая формулировка практически бесполезна.

Что считать существенным ущербом? Какой простой допустим? Можно ли выпустить продукт с критичной уязвимостью, если эксплуатация затруднена? Допустимо ли передавать внутренние документы внешней AI-платформе? Может ли AI-агент самостоятельно отправлять письма, изменять код или выполнять операции в корпоративных системах?

Пока ответы на эти вопросы не определены, risk appetite остаётся корпоративной декларацией.

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

Risk appetite должен не описывать отношение компании к риску в целом, а помогать принимать повторяемые решения в конкретных ситуациях.

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

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

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

Тогда организация не принимает риск осознанно. Она просто надеется, что он не реализуется.

Утверждённые бюджеты говорят о risk appetite больше, чем презентации комитетов.

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

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

Большинство компаний умеют утверждать требования. Значительно меньше компаний умеют управлять исключениями.

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

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

Реальный risk appetite становится особенно заметен после первого серьёзного события.

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

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

GenAI сделал проблему особенно заметной.

Бизнес хочет получить выгоду от ИИ быстрее конкурентов. Сотрудники уже используют внешние сервисы. Продуктовые команды интегрируют модели через API. Разработка применяет AI coding assistants. Появляются агенты, способные обращаться к документам, выполнять запросы и инициировать действия.

При этом формальный risk appetite обычно не отвечает на практические вопросы:

NIST AI RMF подчёркивает, что приемлемость AI-риска зависит от контекста и конкретного сценария использования, а попытка исключить все риски может привести к неэффективному расходованию ресурсов. Остаточный риск должен оцениваться относительно определённой организацией границы, а не относительно абстрактного требования «сделать ИИ безопасным». (NIST Publications)

Это важное различие. Нельзя установить единый аппетит ко всему ИИ.

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

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

Бизнес может осознанно принимать риски, если они обладают несколькими свойствами.

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

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

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

Кто-то с достаточными полномочиями принимает решение не только о выгоде, но и о потенциальных последствиях.

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

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

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

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

Это не отказ от безопасности. Это управление остаточным риском.

Существуют ситуации, в которых формулировка «бизнес принял риск» лишь маскирует отсутствие управления.

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

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

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

Такие риски нельзя оценивать как локальные.

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

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

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

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

NIST GenAI Profile рекомендует документировать компромиссы и логику решений, принимать риски ниже установленной границы и снижать, передавать или избегать рисков, которые её превышают. Отдельное внимание уделяется prompt injection, утечкам данных, автономным агентам и зависимости от внешних AI-поставщиков. (NIST Publications)

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

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

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

Иначе возникает удобная, но незрелая модель:

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

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

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

Не «риск утечки», а, например:

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

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

Для разных классов рисков нужны свои показатели:

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

Чем выше потенциальное влияние, тем выше должен быть уровень принимающего решение.

В решении должны быть зафиксированы:

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

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

Risk appetite должен работать при:

Пока он существует отдельно от этих процессов, он остаётся презентацией.

Риск нельзя считать принятым только потому, что под ним появилась подпись.

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

Всё остальное — отложенное решение, которое организация называет risk acceptance, чтобы не признавать отсутствие ресурсов, приоритетов или ответственности.

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

Достаточно посмотреть:

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

Потому что risk appetite — это не фраза о том, сколько риска компания готова выдержать.

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

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