О чем материал
Как безопасности правильно разговаривать с бизнесом, чтобы ее услышали
Информационная безопасность часто приходит к руководству с правильными лозунгами, но абсолютно беспомощной аргументацией:
- «Нужно минимизировать риски».
- «Необходимо повысить уровень защищенности».
- «Этого требуют регуляторы».
- «Атаки становятся сложнее, угрозы растут, надо покупать решение».
Внутри ИБ-тусовки эти фразы — как родные. CISO, архитекторы, руководители SOC или инженеры по защите инфраструктуры сразу видят за ними конкретную боль: угнанные учетки, зашифрованные серверы, уплывшие базы клиентов, «легшие» кассы, сорванные поставки и парализованное производство. Но топ-менеджмент в этот момент слышит классическое: «Еще один прожорливый центр затрат пришел просить денег».
И дело не в том, что директора чего-то не понимают. Наоборот, они прекрасно понимают свой бизнес. Они каждый день крутятся в жестких условиях: дефицит бюджетов, конфликтующие цели, куча ограничений. Им приходится выбирать, куда вложить условный миллион: в развитие продаж, новые продукты, логистику, маркетинг, ремонт оборудования или в ИТ. И когда ИБ заявляет: «Дайте денег, иначе все умрет», — она сама загоняет себя в глухой угол.
Бизнесу может стать плохо от сотни вещей. От кассовых разрывов, ухода ключевого клиента, факапа в ценообразовании, санкций, налоговых проверок, сырого продукта или аварии на складе. Киберриски для генерального директора — лишь одна из строчек в огромном списке проблем. Чтобы ИБ вообще начали слушать, мало просто пугать. Нужно четко показать: какой именно бизнес-сценарий мы меняем, где возникает экономический эффект и почему платить нужно прямо сейчас.
Ловушка слова «инвестиция»
Концепция «ИБ как инвестиция» звучит красиво, но в ней кроется подвох. В бизнесе инвестиция — это когда вложили рубль, а получили полтора за счет роста продаж, экономии или выхода на новый рынок. В безопасности все работает не так прямолинейно.
Часть затрат на ИБ — это просто санитарный минимум. Компания держит бухгалтерию не для того, чтобы захватить новый рынок. Пожарную сигнализацию ставят не ради роста продаж. Юристы не генерируют выручку напрямую. Но без этих функций бизнес становится хрупким и юридически уязвимым.
С безопасностью та же история. Базовые вещи просто обязаны быть. Наведение порядка в правах доступа, резервное копирование, патч-менеджмент, защита хостов и серверов, контроль админов, мониторинг критичных событий и обкатанные процедуры реагирования — это не инвестиции. Это цифровая гигиена, без которой компания живет на чистом авось.
Если называть инвестицией покупку любого софта или железки, топ-менеджмент быстро раскусит эту хитрость: «Ребята просто манипулируют терминами, чтобы выбить бюджет». Давайте быть честнее.
В зависимости от контекста ИБ может играть разные экономические роли. Иногда это страховка, иногда — операционная гигиена или обязательное условие для выхода на рынок. Иногда — способ ускорить продажи, защитить маржу или сохранить управляемость компании в условиях жесткого кризиса.
Зрелый разговор с бизнесом начинается не с попыток натянуть сову на глобус и посчитать ROI безопасности. Он начинается с вопроса: «Какой именно денежный сценарий меняет эта конкретная мера?» Если никакой — грош ей цена. Если меняет — покажите это без профессионального тумана и мистики, которой так любит окружать себя наше сообщество.
Четыре денежных эффекта ИБ
Для защиты ИБ-бюджетов отлично подходит простая и циничная рамка: Less money, Still money, More money, New money. На русский это переводится так:
- Меньше денег уходит из компании.
- Деньги продолжают поступать в компанию, несмотря на кризис.
- Текущий бизнес зарабатывает больше или быстрее.
- Появляются новые источники дохода, которые раньше были недоступны.
Эта модель хороша тем, что вытаскивает ИБ из вечной роли «предотвращателей апокалипсиса». Бизнес думает не только о глобальных катастрофах. Ему важно, где компания ежедневно теряет деньги на ровном месте, где буксуют процессы и где слабая защита мешает клиентам доверять компании.
- Less money: оптимизируем регулярные потери
Самый очевидный аргумент: ИБ снижает убытки. Но безопасники часто сводят все к кибертриллерам: шифровальщики, громкие утечки, уголовка, штрафы регуляторов. Истории сильные, но руководство часто воспринимает их как обычные страшилки:
- «Да, у конкурентов случилось. Но с чего вы взяли, что придут именно к нам?»
- «Откуда вы взяли эти астрономические цифры ущерба?»
- «Почему этот конкретный софт нас спасет?»
- «Может, нам проще принять этот риск?»
На эти вопросы нельзя отвечать эмоциями. Нужна конкретика. Эффект Less money — это не только про предотвращение катастроф. Это про сокращение рутины и скрытых повседневных расходов. Посчитайте, сколько ручного труда уходит на бесконечные согласования доступов, обработку исключений, ручные ответы на ИБ-опросники от крупных клиентов, разбор однотипных инцидентов и разгребание последствий «теневого ИТ» или бесконтрольного использования сотрудниками ИИ-ассистентов. Это не выглядит как великий хакерский взлом, но это реальные деньги: сожженные часы дорогих специалистов, задержки проектов, простои сервисов и нервная переписка между департаментами.
Нормально выстроенный процесс ИБ эти затраты срезает. Автоматизировали проверку прав, убрали лишние звенья в цепочке согласований, навели порядок в активах, дали бизнесу готовые шаблоны ответов для аудиторов — вот вам и чистая экономия.
Сюда же относятся и вполне осязаемые прямые потери: мошенничество, подмена реквизитов в платежках (BEC-атаки), «слив» данных через подрядчиков, неработающие бэкапы, экстренные аварийные закупки в режиме пожара и привлечение дорогих форензик-консультантов на ночные смены.
Поэтому заходить к руководству с тезисом «Нам нужен контроль почты и антифишинг, потому что фишинг — это опасно» — бессмысленно. Это плохой заход.
Нормальный заход: «За последние пару кварталов нас несколько раз пытались развести на подмену реквизитов в переписке с контрагентами. Если хоть один такой платеж уйдет, мы потеряем сумму X, сорвем поставку и пойдем судиться. Мы предлагаем закрыть этот сценарий: закрутить гайки на почтовых шлюзах, включить MFA, внедрить жесткий регламент подтверждения изменений в реквизитах и прогнать бухгалтерию через практические симуляции. Результат оценим по количеству заблокированных попыток и времени реакции».
В первом случае вы продаете абстрактную «защиту от фишинга». Во втором — меняете конкретный денежный сценарий.
- Still money: гарантируем непрерывность
Есть деньги, которые можно заработать дополнительно, а есть базовый денежный поток, который просто не должен прерываться. Для ретейла это бесперебойная работа касс, складов, мобильного приложения и сайта. Для банка — доступность ДБО и процессинга. Для завода — стабильность технологического контура (АСУ ТП) и отгрузок. Для SaaS-сервисов — время непрерывной работы платформы и сохранность клиентских данных.
Still money означает, что в случае атаки бизнес не встанет колом. Здесь ИБ работает в жесткой сцепке с ИТ, операционкой и юристами. Безопасность не может в одиночку гарантировать непрерывность, но она обязана вовремя задать руководству неудобные вопросы:
- Какие бизнес-процессы нельзя останавливать дольше чем на час?
- На каких системах эти процессы держатся?
- Чьи учетные записи позволяют одной кнопкой выключить половину компании?
- У нас бэкапы реально работают или существуют только на бумаге?
- Что мы делаем, если из-за шифрования серверов финдепартамента мы вовремя не сдадим отчетность и ФНС заблокирует счета?
- Как менеджеры будут общаться с клиентами, если упадет CRM или корпоративная почта?
- Кто имеет право принять решение об отключении сегмента сети или остановке конвейера во время атаки?
Для операционного (COO) и финансового директора (CFO) такие вопросы гораздо понятнее, чем абстрактные разговоры об «уровне защищенности». CFO видит кассовые разрывы и стоимость простоя, COO — смены, склады и SLA.
Плохой заход: «Нам нужно купить EDR, SIEM и обновить систему резервного копирования, потому что кругом шифровальщики».
Нормальный заход: «Если нас зашифруют, встанет отгрузка и поддержка клиентов. Мы не обещаем, что атаки не будет, — это нереально. Но мы можем сократить время ее обнаружения с недели до пары часов, локализовать очаг, быстро поднять критичные системы из проверенных копий и заранее обкатать с бизнесом регламент работы “на бумаге” в первые сутки. Мы защищаем не инфраструктуру, а наш ежедневный денежный поток».
Бизнес оценит, если вы не будете обещать 100%-ную безопасность, а честно покажете, как ИБ влияет на скорость обнаружения, масштабы бедствия и способность компании работать в деградированном режиме.
- More money: убираем трение из текущих продаж
Самая слабая сторона большинства безопасников — это связь с продажами. ИБ исторически загнала себя в роль «департамента запретов». Бизнес торопится выкатить фичу, подключить партнера или подписать контракт, а ИБ приходит под конец и включает красный свет: «Нельзя. Риск. Переделывайте». В итоге бизнес начинает обходить безопасность стороной, прятать проекты и согласовывать все задним числом через колено.
При этом зрелая ИБ способна выступать акселератором. Яркий пример — работа в B2B-сегменте с крупными корпоративными клиентами. Они все чаще заставляют проходить жесткий Security Due Diligence: присылают огромные опросники, требуют показать политики, доказать контроль доступов и уязвимостей. Если у вас бардак, сделка зависает. Продавцы собирают ответы вручную, юристы спорят с ИБ, сроки плывут, а конкурент с готовым пакетом документов забирает контракт.
Здесь ИБ может принести More money, просто убрав трение из продаж. Подготовьте стандартный Whitepaper по безопасности, соберите готовый пакет документов для клиентов, заранее согласуйте спорные формулировки в договорах с юристами.
Этот эффект вполне измерим:
- Сколько времени прохождение ИБ-комплаенса занимало раньше и сколько занимает теперь?
- Сколько крупных сделок буксовало на этапе проверки безопасности?
- Где ИБ помогла снять возражения клиента и закрыть контракт быстрее?
То же самое в разработке. Методология Shift Left (безопасность на ранних этапах) нужна не для того, чтобы мучить разработчиков. Она снижает стоимость исправления ошибок. Найти архитектурную уязвимость на этапе проектирования — условно бесплатно. Переделывать готовый продукт перед самым релизом — дорого и больно для бизнеса.
Плохой заход: «ИБ должна согласовывать все проекты компании, иначе мы погрязнем в рисках».
Нормальный заход: «Мы разделим проекты по уровню критичности. Мелкие и низкорисковые пойдут по фаст-треку вообще без нашего участия, по типовым чек-листам. В сложные и важные мы зайдем на этапе архитектуры, чтобы бизнесу не пришлось переписывать код перед запуском. Наша цель — ускорить Time to market и уберечь компанию от дорогих переделок».
- New money: открываем двери на новые рынки
Иногда без определенного уровня ИБ бизнеса просто не будет. Вы хотите продавать софт банкам, выйти в госсектор, работать с персональными данными на международном рынке или интегрироваться по API с финтех-гигантами? Без соответствия жестким стандартам безопасности вас туда даже не пустят. Не из-за плохого маркетинга — просто крупные игроки не готовы брать на себя ваши риски. Вспомните, как взлетели облачные провайдеры, которые первыми аттестовали свои платформы по требованиям ФЗ-152. Для них ИБ стала не статьей расходов, а главным коммерческим преимуществом.
New money — это история про новые возможности:
- Выход в Enterprise-сегмент с высокими требованиями.
- Позиционирование продукта как Ready for Enterprise.
- Сложные партнерские интеграции, где ключевое условие — прозрачное управление рисками.
- Запуск сервисов, где безопасность — ключевая фича (например, защищенный мессенджер или приватное облако).
Здесь логика абсолютно понятна любому топ-менеджеру: есть перспективная ниша, стоимость входа (включая затраты на ИБ) и ожидаемая прибыль. Если ИБ понимает эти цели, она не станет просить бюджет «на абстрактную зрелость», а соберет понятную карту требований для конкретного рынка.
Четыре типа ценности ИБ
Чтобы раз и навсегда приземлить дискуссию о бюджетах, разложите все ваши ИБ-активности по четырем корзинам:
| Тип ценности | Что делает для бизнеса | Примеры в ИБ |
| Защитная | Снижает вероятность и масштаб ущерба | Реагирование на инциденты, защита периметра, бэкапы, SOC |
| Операционная | Снижает стоимость внутренних процессов, убирает хаос | Автоматизация доступов (IdM/IGA), понятные регламенты, автоматический комплаенс |
| Коммерческая | Помогает продавать и удерживать клиентов | Быстрое прохождение проверок, готовые Security-пакеты для сделок |
| Стратегическая | Открывает новые рынки, партнерства и продукты | Сертификация для Enterprise, безопасная архитектура под новые рынки |
Один и тот же инструмент может работать на несколько корзин. Например, внедрение централизованного управления доступами (IdM) снижает риск компрометации (защитная), убирает ручной труд админов при увольнении сотрудников (операционная), помогает закрывать требования ИБ-аудитов от клиентов (коммерческая) и позволяет быстрее подключать внешних партнеров к экосистеме (стратегическая). Покажите бизнесу всю картину — и он увидит в ИБ не закупку софта, а решение комплексной управленческой задачи.
Безопасность зависит от того, как компания зарабатывает
Универсальной ИБ не существует. Нельзя одинаково защищать банк, завод, маркетплейс, SaaS-платформу или клинику. У них кардинально разные бизнес-модели и точки боли. Для банка критичны непрерывность ДБО, антифрод и регуляторный комплаенс. Для ретейла — кассы, склады и цепочки поставок. Для завода — стабильность АСУ ТП и физическая безопасность. Для SaaS — аптайм облака и защита интеллектуальной собственности.
Поэтому забудьте про универсальные презентации. Разговор с руководством нужно начинать с бизнес-модели компании:
- Где и как мы генерируем основную прибыль?
- В каких точках мы теряем больше всего при сбоях?
- Какие процессы нельзя останавливать ни при каких условиях?
- Кто наши самые требовательные клиенты?
- Какие цифровые проекты должны обеспечить нам рост в ближайшие годы?
Без этого понимания ваша презентация на инвесткомитете будет выглядеть блекло. К слову, она и на профильной конференции вроде PHDays не пройдет: программный комитет там хоть и не финансисты, но банальный пересказ учебников от реальной практики отличают мгновенно.
Денежные сценарии вместо списков угроз
Руководству не нужен ваш каталог угроз из 100 пунктов. Ему нужны 3–5 понятных сценариев, привязанных к их реальности. Хороший сценарий отвечает на вопросы: что происходит? какой процесс страдает? как быстро технический сбой превращается в кассовый разрыв? каковы прямые и косвенные убытки? какие решения придется принимать директорам в процессе? как наши меры снижают вероятность и ускоряют восстановление? сколько это стоит и как мы проверим результат? Хотите, называйте это недопустимыми событиями, киберкатастрофами или системными рисками. Суть от этого не меняется.
Возьмем двухфакторную аутентификацию (MFA):
- Плохо: «MFA снижает риск компрометации учетных записей на 99%».
- Нормально: «У нас есть админы и менеджеры с доступом к платежкам и CRM. Если их учетки угонят, атакующие могут подменить реквизиты или слить базу. MFA не панацея, но она закроет сценарий со входом по утекшим паролям. Мы внедрим ее в первую очередь на тех ролях, где возможны прямой ущерб или остановка отгрузок».
Или управление уязвимостями (VM):
- Плохо: «У нас на периметре висит 500 критических уязвимостей, срочно нужен сканер».
- Нормально: «Часть уязвимостей находится на серверах, которые держат наш интернет-магазин. Мы перестраиваем процесс: приоритизируем обновления не по их техническому рейтингу в вакууме, а по критичности систем для бизнеса. Первым делом закрываем то, через что можно уронить продажи или украсть деньги».
Или киберучения:
- Плохо: «Нам нужно провести киберучения, потому что этого требует 117-й приказ регулятора».
- Нормально: «Мы не знаем, кто в первые два часа тяжелой атаки имеет право отключить критичный сервис, как уведомлять клиентов и когда разворачивать бэкапы. Учения нужны, чтобы топ-менеджмент и ИТ-команда не спорили во время реального инцидента, теряя миллионы на простое».
Убирайте лишнюю драму. Не надо пугать топов цифровым концом света — покажите им, в какой именно момент технический инцидент превращается в бизнес-событие.
Управляйте ИБ как портфелем, а не как выставкой технологий
Не грузите руководство аббревиатурами: EDR, SIEM, PAM, DLP, NGFW, SAST, DAST. Для CFO это просто куча непонятных и конкурирующих между собой за бюджет строчек. Разложите свои инициативы по трем понятным корзинам:
- Обязательный минимум (гигиена). То, без чего компания рискует закрыться завтра или гарантированно получит отзыв лицензии. Здесь не нужно высасывать из пальца ROI. Это фиксированная плата за право оставаться в бизнесе и сохранять управляемость.
- Снижение бизнес-рисков. Каждая строчка здесь жестко привязана к денежному сценарию. Не «купить инструмент», а «сократить время простоя фабрики», «уменьшить объем доступных подрядчикам данных», «заблокировать фрод в логистике».
- Развитие бизнеса (ускорение). Проекты, где ИБ помогает продавцам быстрее закрывать сделки, разработчикам — не плодить баги, а компании — безопасно использовать ИИ и запускать партнерские API.
В такой парадигме диалог становится конструктивным. Бизнес получает возможность выбирать и приоритизировать: что делаем прямо сейчас, что — по минимально приемлемому уровню, что масштабируем, а какие риски осознанно принимаем и откладываем проект на следующий год.
Честно признайте: не вся ИБ одинаково полезна
Давайте снимем розовые очки: далеко не все, что делает департамент ИБ, приносит пользу компании. В нашей сфере очень легко скатиться в имитацию бурной деятельности. Можно писать тонны отчетов, которые никто не читает, собирать бессмысленные метрики, проводить формальное обучение для галочки (после которого сотрудники все так же кликают по фишинговым ссылкам), покупать дорогие лицензии, которые годами лежат на полке, или требовать десять согласований там, где достаточно одного автоматического правила.
Бизнес отлично чувствует эту фальшь и начинает воспринимать ИБ как чистое бюрократическое зло. Чтобы этого не происходило, регулярно устраивайте своим процессам жесткий аудит. Спрашивайте себя: что реально меняется в бизнес-сценарии от этой меры? сокращается время? падает вероятность? снижается ущерб? ускоряются продажи? меньше ручного труда?
Если честного ответа нет, а проект нужен чисто ради выполнения требований закона, так и скажите руководству. Назовите это обязательным расходом на комплаенс. Топ-менеджмент нормально относится к обязательным расходам, но он терпеть не может, когда банальное прикрытие тылов пытаются продать как «стратегическую ценность для роста капитализации».
Шпаргалка по переводу с ИБ-шного на человеческий
Вам не нужно получать диплом экономиста, но научиться переводить технические задачи на язык управленческих решений придется.
- Вместо «Надо закрыть уязвимости» говорите: «У нас есть бреши в системах, через которые можно остановить отгрузку товара или утащить базу клиентов».
- Вместо «Нам необходим EDR» говорите: «Нам нужно вовремя замечать активность шифровальщиков на компьютерах сотрудников, пока они не зашифровали центральный сервер и не привели к недельным простоям компании».
- Вместо «Мы внедряем SOC для круглосуточного мониторинга» говорите: «Нам нужно поймать хакеров на ранней стадии, пока они осматриваются внутри сети, а не когда у нас лягут все сервисы».
- Вместо «Нам нужен PAM» говорите: «Нам необходимо контролировать и записывать действия системных администраторов и внешних подрядчиков, которые имеют полный доступ к критичной инфраструктуре».
- Вместо «Внедряем DevSecOps / безопасную разработку» говорите: «Мы встраиваем проверки безопасности в процесс создания софта, чтобы не переписывать архитектуру приложения за неделю до релиза и не срывать сроки запуска».
Пять вопросов для защиты любой ИБ-инициативы
Когда вы в следующий раз пойдете защищать бюджет или стратегию, постройте свой доклад вокруг пяти простых тезисов:
- Какой денежный поток или бизнес-процесс мы защищаем? (Не сервер, не сеть, а конкретную функцию бизнеса.)
- Какой реалистичный сценарий может этот поток нарушить? (Без абстрактных каталогов угроз — только живые, понятные примеры.)
- Как именно предлагаемая мера меняет этот сценарий? (Снижает вероятность, уменьшает масштаб ущерба, сокращает время восстановления или ускоряет процессы?)
- Как мы поймем, что ситуация улучшилась? (Метрики могут быть неидеальными, но они должны показывать динамику: время реагирования, доля контролируемых критичных доступов, скорость прохождения аудитов от клиентов.)
- Что бизнес сможет делать после этого быстрее, дешевле или надежнее? Этот подход не гарантирует автоматического одобрения всех ваших заявок. У бизнеса всегда есть куда потратить деньги, и это нормально. Но такой формат переводит ИБ из статуса назойливых просителей в статус вменяемых бизнес-партнеров, которые предлагают понятные управленческие изменения за прозрачную цену.
Такие формулировки меняют тон разговора. ИБ больше не просит денег на аббревиатуры. ИБ показывает, какие денежные эффекты хочет получить или защитить компания.
Где проходит граница
Есть риск увлечься и начать доказывать, что ИБ приносит деньги всегда и везде. Это будет неправдой. ИБ не обязана каждую неделю демонстрировать прирост выручки. Некоторые меры нужны, чтобы компания не развалилась при первом серьезном ударе. Некоторые — нужны из-за законов. Некоторые — защищают от редких, но тяжелых по своим последствиям событий (я знал, что вы ждете, когда же я вновь упомяну про недопустимые события). Некоторые — создают условия для будущего роста, который зависит не только от ИБ. Некоторые — вообще не стоит реализовывать, если цена выше эффекта.
Зрелая позиция не в том, чтобы объявить ИБ «новым центром прибыли». Она в том, чтобы перестать говорить о безопасности отдельно от бизнеса. Лучше сказать:
- «Эта мера снижает потери».
- «Эта мера помогает не остановиться».
- «Эта мера ускоряет текущие продажи или процессы».
- «Эта мера открывает новый сегмент».
- «Эта мера обязательна, но прямого финансового эффекта мы не обещаем».
- «Эта мера сейчас не приоритетна, потому что не связана с ключевыми сценариями».
- «Этот риск можно принять, но решить должно руководство, понимая последствия».
Такая честность повышает доверие к ИБ сильнее, чем очередная презентация про рост угроз.
Почему это важно именно для специалистов по ИБ
Многие безопасники ждут, что бизнес наконец начнет понимать их язык. Это понятное желание, но бизнес не обязан думать категориями MITRE ATT&CK, CVSS, корреляционных правил, классов СЗИ, kill chain, lateral movement и privilege escalation. Бизнес обязан понимать, как компания зарабатывает, где рискует и растет, как может потерять управление. Если ИБ хочет участвовать в управленческих решениях, ей придется делать перевод самой.
Это не означает отказа от профессиональной глубины. Наоборот, без глубины перевод будет фальшивым. Нельзя честно объяснить ценность EDR, если не понимаешь, как атака распространяется по инфраструктуре. Нельзя связать управление уязвимостями с бизнесом, если не знаешь активы и процессы. Нельзя говорить о непрерывности, если не понимаешь зависимость систем друг от друга. Нельзя помогать продажам, если не знаешь, какие вопросы задают клиенты и какие обязательства компания готова брать.
Но техническая глубина должна выходить наружу в форме управленческого смысла. Топ-менеджеру не нужно знать все детали атаки. Ему нужно понять, какой процесс под угрозой, как быстро техническая проблема станет денежной, какие варианты есть у компании, сколько стоят меры, какие остаточные риски остаются и какое решение требуется от руководства.
Когда ИБ говорит так, она становится понятной. Не потому, что упрощает реальность до красивых лозунгов. А потому, что показывает связь между защитными мерами и бизнесом. ИБ как инвестиция — это не волшебная формула ROI. Это дисциплина перевода: от угроз к сценариям, от сценариев к деньгам, от денег к решениям, от решений к измеримым изменениям.
- Компания тратит меньше, когда ИБ перекрывает утечки денег и снижает стоимость хаоса.
- Компания продолжает зарабатывать, когда ИБ помогает сохранить работу процессов в кризисе.
- Компания зарабатывает больше на текущем бизнесе, когда ИБ убирает трение, повышает доверие и ускоряет сделки.
- Компания получает новые деньги, когда ИБ открывает доступ к клиентам, рынкам, данным, продуктам и партнерствам, куда без доверия ее не пустят.
Так ИБ перестает быть расходом и центром затрат, который приходится защищать перед бизнесом только с помощью страха. Она становится частью разговора о том, как бизнес зарабатывает, теряет, растет и выживает под давлением. И этот разговор начинается не с бюджета. Он начинается с простого вопроса: какой денежный сценарий мы меняем?
Инвестиции в кибербез в России
- 29% — средний рост инвестиций в ИБ в отечественных компаниях в 2025 г.
- 294 млн руб. — средний ИБ-бюджет крупной компании (от 102 млн руб. в госсекторе до 507 млн в финансах и ИТ)
- Только 9% организаций отметили существенное влияние ИБ-инцидентов на подход к финансированию
- 89% компаний формализуют критические риски, но лишь 5% используют эту оценку при формировании ИБ-бюджета
- 93% российских компаний финансируют ИБ из ИТ-бюджета
- < 0,5% дохода тратят на ИБ большинство российских компаний
Чего боятся российские компании
- 100% — остановка ключевого бизнес-процесса
- 99% — прямые финансовые потери
- 81% — репутационный ущерб
- 74% — раскрытие персональных данных



