Команда ИБ. Что делать, когда ресурс ограничен?

Когда становится очевидно, что один человек не может закрыть все направления информационной безопасности, возникает следующий вопрос:

"Как собрать команду, если ресурсов на это нет или их очень мало?"

На мой взгляд здесь можно выделить 4 пути:

1️⃣ Путь первый - масштабирование.

Команда ИБ далеко не всегда начинается с большого подразделения или отдельного департамента.

Чаще всего всё начинается с одного человека, который становится точкой сборки функции ИБ. Важно понимать, что он не "закрывает всю ИБ" в полном смысле. Он помогает увидеть реальные риски, навести базовый порядок, договориться со смежными подразделениями, расставить приоритеты и показать первые результаты.

Если у этого человека есть поддержка руководства, понятные полномочия и возможность опираться на ИТ, HR, юридический блок и владельцев процессов - функция начинает расти не на героизме, а на результате.

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

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

2️⃣ Путь второй - делегирование.

Команда ИБ не всегда состоит только из людей, у которых в должности написано "информационная (кибер-) безопасность".

Часть потребностей можно закрывать за счет смежных подразделений, если внутри компании вообще есть с кем работать. Например: 🔹 ИТ может закрывать Хардинг, патч-менеджмент, базовую дисциплину доступа и техническую реализацию требований. 🔹 HR может помочь с онбордингом, обучением и закреплением базовых правил, встраиванием культуры ИБ в корпоративную культуру. 🔹 Юристы - с договорными обязательствами, персональными данными и нормализацией требований к подрядчикам. 🔹 Владельцы процессов - с определением критичности систем, данных и последствий инцидентов.

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

Но и у этого пути есть свои ограничения.

3️⃣****Путь третий - совмещение

При ограниченных ресурсах не все роли необходимо разделять сразу. Часть функций можно совмещать, но только там, где это действительно логично.

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

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

4️⃣ Путь четвертый - аутсорсинг

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

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

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

P.S. Самая дорогая ошибка - делать вид, что функция ИБ уже собрана, когда по факту её нет. До первого серьёзного инцидента это может выглядеть убедительно. После первого инцидента - нет.