Кому должен подчиняться CISO: CEO, CIO, CRO или совету директоров

Компании часто пытаются решить проблему влияния CISO перестановкой одного блока на организационной схеме.

Переподчинили CISO от CIO к CEO — повысили независимость. Добавили регулярный доклад совету директоров — усилили контроль. Перенесли функцию в блок CRO — встроили киберриски в enterprise risk management.

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

Организационная позиция важна. Но сама по себе она не создаёт ни полномочий, ни доступа, ни влияния.

На мой взгляд, вопрос «кому должен подчиняться CISO?» сформулирован слишком узко. Правильнее спрашивать:

Какая организационная модель позволит CISO участвовать в ключевых решениях, независимо оценивать риск и эскалировать несогласие, не теряя при этом связи с IT, продуктами и операционной деятельностью?

Кибербезопасность всё сложнее рассматривать как отдельную техническую функцию.

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

Поэтому governance-фреймворки и регуляторы всё сильнее акцентируют внимание не только на контролях, но и на распределении ответственности.

NIST CSF 2.0 выделяет Govern в самостоятельную функцию и связывает её с ролями, полномочиями, ресурсами, риск-аппетитом, oversight и интеграцией киберриска в ERM. При этом NIST намеренно не предписывает конкретный способ достижения этих результатов. (NIST Publications)

SEC разделяет oversight совета директоров и роль менеджмента в оценке и управлении существенными киберрисками, но также не устанавливает универсальную reporting line для CISO. (SEC)

DORA, применяемая в финансовом секторе ЕС с 17 января 2025 года, закрепляет ответственность management body за определение, утверждение и контроль реализации ICT risk management framework. Это усиливает требования к качеству управления, но не превращает совет директоров в операционного руководителя службы ИБ. (Eur-Lex)

Даже более конкретные требования NYDFS обязывают CISO регулярно докладывать senior governing body, а руководство — контролировать киберриски и достаточность ресурсов. Однако и они разделяют право доклада и административное подчинение. (Department of Financial Services)

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

Подчинение CIO часто объявляют заведомо неправильным. Я не согласен с такой категоричностью.

У этой модели есть сильные стороны:

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

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

Например, CIO заинтересован:

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

Подчинение CIO допустимо, когда одновременно существуют:

Без этих механизмов CISO оказывается ответственным за риск, уровень которого определяет не он.

Прямое подчинение CEO выглядит наиболее сильной моделью.

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

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

В результате CISO формально подчиняется первому лицу, но:

Высокая reporting line может повысить статус функции и одновременно увеличить её изоляцию.

Подчинение CEO работает, когда CISO входит не только в список direct reports, но и в реальный контур управления:

Без этого прямое подчинение становится декоративным.

Размещение CISO в структуре CRO помогает встроить киберриск в общую систему enterprise risk management.

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

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

Но у неё есть обратная сторона.

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

Подчинение CRO эффективно, когда:

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

Но совет директоров должен осуществлять oversight, а не управлять ежедневной работой службы ИБ.

Он может:

Но совет не должен управлять SOC, утверждать архитектурные исключения, распределять задачи AppSec или разрешать рабочие конфликты между CISO и CIO.

Именно поэтому более зрелой обычно является модель, в которой CISO административно находится внутри management structure, но имеет независимый и регулярный доступ к совету директоров или профильному комитету.

Универсальной reporting line не существует. Модель нужно тестировать на реальных сценариях конфликта.

Продукт готов к выводу на рынок, но критический security control не реализован.

Кто может принять риск? Может ли CISO остановить запуск или только описать последствия? Кто рассматривает несогласие между CISO и владельцем продукта?

CIO предлагает отложить замену устаревшей инфраструктуры, создающей значимый риск.

Может ли CISO эскалировать вопрос за пределы блока CIO? Кто сопоставляет экономию и потенциальное воздействие на бизнес?

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

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

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

Может ли CISO вынести решение на риск-комитет? Кто формально принимает исключение и отвечает за последствия?

CISO сообщает совету директоров, что решения менеджмента создают неприемлемый риск.

Может ли он сделать это без согласования формулировок с руководителем, чьи решения оценивает?

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

МодельОсновное преимуществоГлавный рискКогда работаетCIOБлизость к технологиям и ресурсамОграничение независимой оценки решений CIOЕсть прямой канал в риск-комитет и к CEO или советуCEOСтатус и доступ к бизнес-повесткеИзоляция от IT и недостаток внимания CEOCISO участвует в executive- и инвестиционных решенияхCROИнтеграция с ERM и риск-аппетитомДистанция от разработки и эксплуатацииСохраняется сильная связь с IT и security engineeringСовет директоровМаксимальный уровень эскалацииСмешение oversight и операционного управленияИспользуется как канал oversight, а не ежедневная reporting lineHybridБаланс локальной интеграции и функциональной независимостиДвойные приоритеты и размытая ответственностьЧётко разделены административные и функциональные полномочия

Независимо от reporting line у CISO должны быть зафиксированы как минимум семь элементов.

1. Доступ к решениям до их принятия

CISO должен участвовать в продуктовых, архитектурных и инвестиционных процессах, а не получать готовое решение для последующего согласования.

2. Независимый канал эскалации

CISO должен иметь право напрямую обратиться к CEO, риск-комитету или комитету совета директоров по существенному риску.

3. Ясная модель принятия риска

ИБ оценивает риск и предлагает варианты обработки. Остаточный бизнес-риск принимает уполномоченный владелец, а не специалист или руководитель ИБ.

4. Соответствие полномочий ответственности

Нельзя требовать от CISO результата в областях, где он не контролирует бюджет, сроки, людей или технические решения.

5. Защищённый бюджетный процесс

Бюджет безопасности не обязательно должен полностью принадлежать CISO. Но существенное сокращение критических инициатив должно проходить прозрачную оценку риска.

6. Регулярный доступ к совету директоров

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

7. Механизм разрешения конфликтов

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

Я не считаю подчинение CISO CIO автоматически неправильным.

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

Точно так же подчинение CEO не является автоматически зрелой моделью. CISO, который находится рядом с CEO на организационной схеме, но не участвует в продуктовых и инвестиционных решениях, может иметь меньше влияния, чем CISO в структуре CIO с прямым доступом к риск-комитету.

Независимость CISO — это не расстояние от IT. Это способность профессионально не согласиться, довести риск до нужного уровня и сохранить право говорить правду после такого несогласия.

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

Нужно определить:

Лучшая reporting line — не та, которая выглядит наиболее убедительно на организационной схеме.

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

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