«Роль CISO — это не техническая должность, а политическая. Успех определяется не тем, насколько грамотно настроены правила в SIEM, а тем, удалось ли договориться с людьми, у которых нет в KPI строки ‘обеспечить безопасность’. Главный парадокс: те, кто создаёт риски и распределяет на них ресурсы, чаще всего не подчиняются CISO напрямую. Без понимания этой сети влияния любая защита остаётся декларативной.»
Кто принимает решения и распределяет ресурсы
Стейкхолдер в контексте информационной безопасности — это любой участник, чьи действия влияют на уровень риска компании или чьи интересы затрагиваются мерами защиты. CISO работает не с абстракцией, а с конкретными лицами, обладающими разной мотивацией и реальной властью. В российской корпоративной среде эта власть часто сосредоточена не в комитетах, а в руках нескольких ключевых фигур, действующих в рамках жёсткой вертикали управления.
Условно всех влияющих лиц можно разделить на четыре уровня, каждый из которых говорит на своём языке и оценивает риски через свою призму:
- Операционный уровень: руководители бизнес-направлений и проектов, для которых безопасность — это потенциальный тормоз для выручки.
- Финансовый уровень: CFO и планово-экономические отделы, рассматривающие ИБ как статью расходов без явной отдачи.
- Регуляторно-юридический уровень: юристы и специалисты по compliance, для которых главный риск — санкции со стороны ФСТЭК или Роскомнадзора по 152-ФЗ.
- Исполнительный уровень: технические команды (разработка, DevOps, администрирование), которые непосредственно внедряют решения и первыми сталкиваются с их сложностью.
Решение владельца бизнеса или генерального директора может перевесить любые аргументы, но он редко погружается в детали. Поэтому ключевая задача CISO — транслировать технические риски на язык, понятный каждому из этих уровней: язык денежных потерь, сроков, ответственности и операционных издержек.
[ИЗОБРАЖЕНИЕ: схема влияния стейкхолдеров в типичной российской компании с разделением по четырём уровням и указанием направлений давления]
Операционные стейкхолдеры: те, кто создаёт новые риски
Руководители продуктов, отделов продаж и маркетинга живут в метриках роста, оборота и скорости выхода на рынок. Их естественная реакция на требования безопасности — воспринимать их как бюрократию, убивающую agility. Вопрос «Почему мы не можем запустить это завтра?» для них абсолютно логичен.
Главная ошибка в диалоге с ними — начинать с политик и стандартов. Вместо этого разговор должен строиться вокруг бизнес-последствий:
- Связывать требования с конкретными бизнес-метриками: как повлияет на SLA, доступность сервиса или скорость обработки заявок.
- Предлагать не запреты, а варианты: «Если сделать так, срок сдвинется на два дня, но мы избежим риска, который в прошлом году привёл к простою сервиса на 8 часов».
- Встраивать процессы оценки безопасности в начало жизненного цикла проекта, а не на этапе приёмки, когда изменения стоят максимально дорого.
Эффективнее работает не инструкция, а соглашение: «Для проектов категории А (высокий риск) обязательны этапы X и Y, что увеличит общий срок на 10%. Для категории Б (низкий риск) достаточно этапа Z с увеличением на 2%». Это переводит обсуждение в плоскость управляемых договорённостей.
Финансовые стейкхолдеры: те, кто распределяет деньги
Для финансового директора и его команды безопасность — это строка в бюджете, которая не генерирует прямую прибыль. Любой запрос на финансирование новых инструментов или специалистов встречается вопросом о возврате на инвестиции (ROI) и анализе прошлых убытков.
Чтобы получить бюджет, нужно отказаться от языка «защиты от угроз» и перейти к языку управления финансовыми рисками:
- Количественно оценивать потенциальный ущерб от инцидентов: прямые штрафы по 152-ФЗ, стоимость восстановления данных, потери от простоя, репутационный ущерб, выраженный в оттоке клиентов.
- Сравнивать стоимость внедрения меры защиты со стоимостью потенциального инцидента. Иногда дешевле застраховать риск, чем предотвратить его.
- Демонстрировать, как инвестиции в автоматизацию (например, автоматическое сканирование кода) сокращают будущие операционные расходы на ручной аудит и исправление.
В российских реалиях дополнительным игроком часто выступает служба внутреннего аудита или контроллинга. Их интересует не только соблюдение регуляторных норм, но и целевое, документированное использование выделенных средств.
Как говорить с финансистами о рисках
Их язык — цифры и модели. Разговор должен строиться вокруг четырёх компонентов:
- Вероятность реализации угрозы для конкретного актива (например, 5% в год).
- Максимальный возможный финансовый ущерб (например, 10 млн рублей).
- Стоимость меры по снижению риска (разовые и ежегодные затраты).
- Остаточный риск после применения меры (новое значение вероятности и ущерба).
Такая модель превращает запрос на финансирование из эмоционального в расчётный и позволяет сравнивать инвестиции в безопасность с другими бизнес-инициативами.
Регуляторные и юридические стейкхолдеры
Влияние юристов и специалистов по compliance в российской практике часто недооценивается. Именно они интерпретируют требования 152-ФЗ, положений ФСТЭК и готовят компанию к проверкам. Они могут заблокировать проект, если увидят в нём неприемлемые юридические риски, например, связанные с обработкой персональных данных или использованием определённых технологий.
Ключевой запрос этой группы — минимизация вероятности санкций со стороны регулятора. Ошибка — приходить к ним с готовым техническим решением и просить «оформить». Правильный подход — вовлекать их на этапе проектирования мер защиты:
- Совместно разрабатывать политики, чтобы юридические формулировки не противоречили технической реализуемости.
- Запрашивать официальные заключения по спорным моментам (легальность использования конкретного облачного сервиса, соответствие методике ФСТЭК).
- Использовать их экспертизу при подготовке документов для аттестации информационных систем.
Отдельная категория — ответственные за взаимодействие с регуляторами внутри компании. Их поддержка критически важна, так как они выступают проводниками и переводчиками между формальными требованиями и внутренними процессами.
Исполнительные стейкхолдеры: те, кто реализует
Разработчики, DevOps-инженеры и системные администраторы — это те, кто воплощает решения в жизнь. Их главная цель — обеспечить работоспособность и развитие систем. Если требования безопасности воспринимаются как лишняя сложность, тормозящая работу, они будут искать способы их обойти, что создаст скрытые, неконтролируемые риски.
Задача CISO — интегрировать безопасность в естественный workflow этих команд, а не навязывать её сверху:
- Внедрять инструменты безопасности прямо в их контур: сканеры уязвимостей в CI/CD, политики доступа в IaC, мониторинг аномалий в их дашборды.
- Автоматизировать рутинные проверки и согласования, чтобы не отвлекать специалистов.
- Предоставлять не объёмные регламенты, а готовые код-шаблоны, безопасные конфигурации и чек-листы для типовых задач.
Когда технические специалисты видят, что безопасность решает их проблемы (например, помогает найти баг до продакшена или автоматизирует рутину), они становятся активными сторонниками. В противном случае — тихими саботажниками.
Скрытые стейкхолдеры: те, кто влияет неформально
В любой организации, особенно с долгой историей, существуют неформальные лидеры: технические архитекторы, ветераны компании, люди, пользующиеся личным доверием руководства. Их мнение, высказанное в курилке или личном чате, может перевесить все официальные протоколы.
Игнорировать эту группу — рисковать реализацией любого проекта. Их нельзя подчинить формально, но можно и нужно вовлекать:
- Выявлять через наблюдение за тем, к кому идут за советом в сложных технических вопросах.
- Привлекать в качестве экспертов при оценке новых технологий или расследовании сложных инцидентов.
- Учитывать их аргументацию при подготовке своих предложений, предвосхищая возможное «неформальное вето».
Часто именно через них можно донести свою позицию до высшего руководства быстрее и эффективнее, чем через официальные каналы.
Как строить карту влияния
Знания списка должностей недостаточно. Необходимо анализировать силу и область влияния каждого игрока. Простая таблица помогает визуализировать, на кого и в каком вопросе нужно воздействовать в первую очередь.
| Стейкхолдер | Влияние на бюджеты | Влияние на процессы | Влияние на регуляторику | Влияние на реализацию |
|---|---|---|---|---|
| Директор бизнес-подразделения | Среднее (может лоббировать) | Высокое (определяет сроки и приоритеты) | Низкое | Низкое |
| Финансовый директор (CFO) | Высокое (ключевое решение) | Среднее (косвенно, через финансирование) | Низкое | Низкое |
| Руководитель юридической службы | Низкое | Высокое (может наложить вето) | Высокое (интерпретация законов) | Низкое |
| Ведущий архитектор или тимлид разработки | Низкое | Среднее (влияет на выбор технологий) | Низкое | Высокое (определяет, как будет сделано) |
Эта карта определяет последовательность действий. Например, для запуска проекта по внедрению DLP-системы логично начать с юристов (обоснование регуляторной необходимостью), затем получить одобрение CFO (бюджет), после — согласовать с бизнес-подразделениями изменения в процессах, и только затем детально прорабатывать внедрение с техническими лидерами. Обратный порядок обречён на провал.
[ИЗОБРАЖЕНИЕ: диаграмма, показывающая оптимальный путь согласования типового проекта безопасности с разными стейкхолдерами]
Типичные конфликты интересов и как их разрешать
CISO постоянно находится в эпицентре противоречий: бизнес требует скорости, финансисты — экономии, юристы — абсолютного соответствия, разработчики — минимальной сложности. Прямое навязывание своего решения «в интересах безопасности» приводит к сопротивлению всех сторон.
Рассмотрим гипотетический сценарий: необходимость срочного выпуска нового онлайн-сервиса.
- Бизнес: Требует запуск через две недели для захвата рыночной ниши.
- Финансы: Не готовы выделять дополнительный бюджет на ускоренную безопасность.
- Юристы: Видят риски некорректной обработки персональных данных и нарушения 152-ФЗ.
- Разработка: Хочет использовать новые, но непроверенные фреймворки для ускорения.
Решение — не в поиске идеального, а в нахождении допустимого для всех компромисса, который снижает риски до приемлемого уровня:
- Для бизнеса: Запустить первую версию (MVP) с ограниченным функционалом, прошедшим усиленный security-аудит. Остальные модули выпустить позже, с полным циклом проверок.
- Для финансов: Показать, что модель MVP не требует сверхбюджета сейчас, но закладывает основу для будущих затрат.
- Для юристов: Подготовить дополнения к пользовательскому соглашению, явно ограничивающие ответственность компании в пилотный период, и запустить сервис для ограниченного круга тестовых пользователей.
- Для разработки: Разрешить использование новых библиотек при условии их автоматического сканирования на известные уязвимости и изоляции в контейнерах.
Такой подход сохраняет движение вперёд, не блокируя его полностью, но и не оставляя компанию беззащитной.
Что меняется с приходом регуляторных требований
Жёсткие требования ФСТЭК и 152-ФЗ формально усиливают позиции CISO, но на практике смещают баланс влияния. Юристы и compliance1-специалисты получают больше веса, так как их область — прямая защита от штрафов. Финансисты начинают воспринимать расходы на безопасность как страховку от регуляторных санкций. Бизнес вынужден вписывать сроки на compliance в свои планы.
Однако здесь кроется ловушка: безопасность может превратиться в «бумажную» функцию, где главное — собрать папку документов для проверки, а реальные технические меры останутся на втором плане. Чтобы этого не случилось, CISO должен использовать регуляторный импульс для внедрения практических механизмов.
Например, требование ФСТЭК о классификации информационных систем можно реализовать не как кабинетную работу, а как живой процесс оценки рисков для каждого нового сервиса с участием его владельца из бизнеса. Когда руководитель направления видит, что от присвоенного класса зависят не только требования защиты, но и бюджет и сроки ввода в эксплуатацию, он начинает относиться к безопасности как к части своей зоны ответственности.
Итог: безопасность как система договоров
Работа CISO — это постоянная работа по переводу. Перевод технических рисков на язык финансовых потерь, операционных сроков, юридической ответственности и инженерной реализуемости. Это создание сети взаимных договорённостей, где у каждой стороны своя «валюта»: для бизнеса — возможность, для финансов — деньги, для юристов — законность, для разработчиков — эффективность.
Успех приходит не к тому, кто лучше всех разбирается в атаках нулевого дня, а к тому, кто понимает, как устроена система принятия решений в его компании, и кто умеет находить компромиссы, переводящие безопасность из статуса контролёра в статус бизнес-партнёра. В конечном счёте, управление безопасностью — это управление людьми и их восприятием риска.