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

Представим типичную ситуацию.

Руководитель принимает residual risk, чтобы не переносить запуск. Продукт выходит вовремя. Бизнес-показатели выполнены. Руководитель получает бонус.

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

Проходит год. Исключение продлевалось четыре раза. Меры не профинансированы. Exposure вырос. Но в performance review это никак не отражается.

Можно ли в такой модели говорить о настоящем risk ownership?

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

Инцидент можно позже эскалировать. Severity — занизить. Near miss — не регистрировать. Негативную информацию — придержать до окончания отчётного периода.

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

Поэтому cyber-компонент мотивации должен оценивать не отсутствие атак, а качество исполнения решений, находившихся в зоне полномочий руководителя:

— выполнен ли согласованный risk treatment; — устранены ли просроченные исключения; — работают ли компенсирующие меры; — готов ли критичный процесс к восстановлению; — своевременно ли эскалируются отклонения; — выполнены ли corrective actions после инцидента или учений.

Но здесь есть принципиальное условие: KPI должен следовать за полномочиями.

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

Ответственность без authority превращается в поиск виновного.

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

Часть — коллективной для executive team: устойчивость критичных сервисов, результаты кризисных учений, системные зависимости и готовность к восстановлению.

Регуляторный вектор движется именно к содержательной ответственности руководства. DORA закрепляет ответственность management body за ICT risk framework; SEC требует раскрывать роль совета и менеджмента в управлении существенными киберрисками; NIST CSF 2.0 связывает governance с ролями, полномочиями и performance assessment. Но ни один из этих подходов не означает, что руководителя нужно штрафовать за каждую атаку. (eur-lex.europa.eu)

Мой тезис простой:

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

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

Какой показатель был бы справедливым в вашей компании: выполнение treatment plans, просроченные exceptions, готовность к восстановлению или качество эскалации?