«Сопротивление между техническим директором и руководителем безопасности — это не личная неприязнь, а прямое следствие сломанной системы принятия решений в компании. Компромисс здесь работает против бизнеса. Нужна не медиация, а новая инженерная схема, которая превратит это трение в источник роста.»
Корень конфликта: не разные цели, а разная ответственность
Обвинения в адрес CTO, что он «гонится за фичами», и в адрес CISO, что он «всё блокирует», лишь маскируют настоящую проблему. Она заключается в фундаментальном различии их KPI и той реальной ответственности, которую они несут перед бизнесом.
CTO измеряет свой успех в положительных метриках: скорость вывода продукта на рынок, конверсия, производительность системы, удовлетворённость пользователей. Его главный риск — не успеть за конкурентами, упустить возможность. Его мышление строится вокруг возможностей и роста.
CISO измеряет свой успех в негативных метриках: количество предотвращённых инцидентов, снижение уровня уязвимостей, отсутствие штрафов. Его главный риск — допустить событие, которое уничтожит созданную ценность. Его мышление строится вокруг угроз и ограничений.
Оба правы со своей позиции. Катастрофа начинается там, где они пытаются сравнить несравнимое. Задержка релиза на две недели для CTO — это потерянная выручка и недовольные клиенты. Для CISO отказ от дополнительной проверки — это вероятность утечки данных с ущербом, который трудно предсказать. Эти риски измеряются в разных системах координат, и прямого перевода между ними нет.
[ИЗОБРАЖЕНИЕ: Диаграмма, иллюстрирующая два параллельных, не пересекающихся цикла принятия решений. Слева — цикл CTO: «Бизнес-цель → Техническая возможность → Реализация → Выручка/Рост». Справа — цикл CISO: «Угроза/Требование регулятора → Ограничение/Контроль → Внедрение → Избежание потерь/Штрафов». Между циклами — пропасть, подписанная «Разный язык оценки риска».]
Язык, который создаёт стену: техницизмы vs. регуляторика
Профессиональный жаргон превращает диалог в монологи. CTO говорит о деплоях, latency, техническом долге и scalability. CISO говорит о мерах защиты КИИ, классах ИСПДн, требованиях ФСТЭК и положениях 152-ФЗ.
Когда руководитель безопасности приходит с формулировкой «требуется обеспечить контроль целостности ПО в соответствии с положением…», разработчик слышит «мне нужно переписать механизм обновлений и сорвать сроки». CISO же искренне не понимает, почему базовое, по его мнению, требование вызывает такое сопротивление.
Это не просто недопонимание — это признак того, что безопасность воспринимается как внешний, навязанный регулятор, а не как неотъемлемое свойство качества продукта. Пока требования регуляторики не будут переведены на язык технических debt и user stories, стена останется.
Типичные сценарии сбоев и их последствия
Абстрактные разногласия материализуются в конкретных рабочих ситуациях, каждая из которых стоит компании времени, денег и репутации.
Сценарий 1: Срочный релиз против планового аудита
Команда разработки готовит критическое обновление, которое должно уйти сегодня. Служба безопасности в последний момент настаивает на проведении анализа защищённости, который займёт три дня. CTO видит срыв обязательств перед клиентами. CISO видит вопиющее игнорирование процедур. Итог — решение принимает генеральный директор под давлением, отношения между отделами отравлены, а процесс воспринимается как лотерея.
Сценарий 2: Новый инструмент против требований локализации
Разработчики нашли перспективный open-source инструмент, который кратно ускорит работу. CISO проверяет его и выясняет, что его зависимости тянутся из иностранных репозиториев, что напрямую конфликтует с требованиями по локализации критичных данных. Внедрение останавливается. Команда разработки видит в этом саботаж, служба безопасности — предотвращение риска.
Сценарий 3: Рефакторинг против устранения критических уязвимостей
CTO планирует квартал на рефакторинг устаревшего ядра системы (технический долг) для будущего масштабирования. CISO требует те же ресурсы для срочного устранения только что обнаруженных критических уязвимостей в используемых библиотеках. Оба проекта важны, ресурсы ограничены. Начинается битва за приоритет, где каждый апеллирует к разным, несопоставимым рискам.
Неработающие подходы: как ломают, а не чинят
Типичные организационные «решения» часто лишь усугубляют раскол.
- Жёсткое подчинение CISO отделу разработки. Безопасность превращается в сервисную функцию, чьи предупреждения всегда будут проигрывать давлению сроков. Конфликт не исчезает, он просто подавляется, накапливая риски.
- Создание многоуровневых «комитетов по рискам». Часто вырождается в формальность с громоздкими презентациями, где реальные решения принимаются вне рамок этих встреч, тем же конфликтным путём.
- Попытки «образовать» друг друга. CTO проводит для CISO ликбез по DevOps, CISO читает CTO лекцию о 152-ФЗ. Взаимопонимание растёт, но система принятия решений не меняется. Они начинают лучше понимать, «почему этот идиот всё тормозит», но механизма для совместного движения не появляется.
Механизм починки: от компромисса к синергии
Решение лежит не в сглаживании противоречий, а в создании новой процедуры, где эти противоречия становятся структурированными входными данными для принятия решений.
Шаг 1. Ввести общую единицу измерения — бизнес-риск
Нельзя напрямую сравнивать «дни задержки релиза» и «вероятность эксплуатации уязвимости». Нужна общая валюта — потенциальное финансовое или репутационное воздействие на бизнес. Для этого внедряется упрощённая, но рабочая модель совместной оценки.
| Фактор риска | Вопрос для CTO (Влияние на цели) | Вопрос для CISO (Влияние на безопасность) | Общая метрика влияния |
|---|---|---|---|
| Задержка релиза | Какая потеря выручки/клиентов за неделю задержки? | — | Финансовый эквивалент |
| Несоответствие нормам | — | Размер потенциального штрафа + стоимость устранения? | Финансовый эквивалент |
| Техническая уязвимость | Вероятность и стоимость простоя сервиса? | Вероятность эксплуатации и стоимость ликвидации инцидента? | Среднеожидаемые потери |
Цифры будут приблизительными, но сам процесс их совместного обсуждения и оценки заставляет стороны говорить на одном языке — языке денег и вероятностей.
Шаг 2. Встроить безопасность в цикл разработки на ранних этапах
Вместо роли «последнего контролёра» CISO должен стать участником процессов проектирования. Его команда (или архитектор по безопасности) должна быть вовлечена в design review новой функциональности или выбор технологического стека.
Например, решение о выборе СУБД принимается не только на основе производительности, но и с учётом возможности её сертификации для обработки персональных данных или развёртывания в необходимой изолированной конфигурации.
[ИЗОБРАЖЕНИЕ: Схема DevSecOps-цикла: Идея → Планирование (Security & Compliance Review) → Разработка (Security Guidelines) → Тестирование (SAST/DAST, Compliance Checks) → Деплой (Security Gates) → Мониторинг. Акцент на точках раннего вовлечения безопасности.]
Шаг 3. Установить прозрачные правила и SLA
Неопределённость порождает конфликт. Чёткие договорённости снимают напряжение.
- Предварительная проверка инструментов: любой новый инструмент или библиотека проходят проверку по упрощённому чек-листу (уязвимости, лицензия, вопросы локализации). Ответ службы безопасности — в течение 2 рабочих дней.
- Ускоренная процедура для критических обновлений: для срочных релизов существует fast-track security review (проверка по критическим векторам), который занимает не более 1 дня. Это внутреннее SLA.
- Совместные сессии по приоритизации: регулярные (раз в квартал) встречи CTO и CISO для совместной оценки технического долга и долга безопасности. Задачи приоритизируются на основе общей модели риска, а не ведомственных интересов.
Это превращает безопасность из непредсказуемого барьера в понятный, планируемый процесс с известными издержками.
Кто должен управлять этим процессом?
Ни CTO, ни CISO. Эта роль требует понимания технологий, рисков и бизнеса одновременно. В успешных практиках её часто называют Product Security Officer или Технический директор по рискам.
Этот человек или команда работает между разработкой и безопасностью, переводя требования регуляторики в конкретные технические задачи (например, «обеспечить контроль целостности» → «реализовать механизм подписи пакетов обновлений») и, наоборот, переводя технологические ограничения в понятные оценки риска для бизнеса. Его задача — не выносить вердикт, а обеспечивать работу описанного механизма, чтобы итоговое решение было оптимальным для компании, а не для отдела.
Итог: конфликт — это ресурс
Напряжение между скоростью и безопасностью — не патология, а показатель роста компании. Проблема возникает, когда для этого напряжения нет конструктивного выхода.
Конечная цель — не добиться, чтобы CTO и CISO всегда соглашались. Цель — создать систему, в которой их профессиональное несогласие на этапе проектирования приводит к созданию более устойчивых, инновационных и соответствующих требованиям продуктов. Когда безопасность перестаёт быть галочкой для аудитора и становится фактором, позволяющим выходить на новые регулируемые рынки или повышать доверие клиентов, — интересы CTO и CISO наконец-то сходятся.
Починка отношений — это задача инженерии процессов. Нужно спроектировать и внедрить механизм, который преобразует энергию конфликта в движущую силу для бизнеса.