Обучение сотрудников по ИБ не должно становиться для ИТ отдельным тяжелым проектом. Лишняя нагрузка обычно возникает не из-за самой идеи обучения, а из-за ручной схемы запуска: списки, согласования, рассылки, сводка результатов и повторные циклы собираются вручную. Если заранее зафиксировать роли, сценарий запуска и минимально необходимое участие ИТ, процесс можно сделать повторяемым без постоянного аврала.
Обычно разговор про обучение сотрудников встаёт не на вопросе «нужно или не нужно». Он ломается чуть позже — когда ИТ-руководитель улавливает между строк уже не раз знакомый ему сценарий: снова выгрузки, снова ручные согласования, снова чужая инициатива, которая незаметно станет его операционной задачей. И если это ощущение не снять в первые минуты разговора, проект вызовет сопротивление еще до того, как дойдет до сути.
Хорошая новость в том, что ИТ обычно сопротивляется не самому обучению, а хаосу вокруг него. Когда ИБ-отдел приходит не с очередным "давайте внедрим инструмент", а с понятной логикой процесса, границами участия и нормальным сценарием пилота, тон разговора меняется. Где у ИТ появляется лишняя нагрузка, как ее снять и почему в этой теме важен не список функций — рассказываем в статье.
Кому полезно: ИБ-руководителю, который продвигает тему перед ИТ-руководителем, и самому ИТ-руководителю, который не хочет получить ещё один бесконечный "головняк".
Почему обучать сотрудников кибербезопасности важно
Прежде чем говорить о запуске проектов в этом направлении, полезно понять — почему тема вообще значима для ИТ и ИБ.
- По данным Kaspersky, за последние 2 года 77% компаний столкнулись как минимум с одним киберинцидентом. 38% инцидентов в бизнесе были вызваны человеческой ошибкой, а еще 26% — нарушениями политики ИБ.
- В исследовании Proofpoint State of the Phish 2024 71% работающих сотрудников признались, что совершали рискованные действия, а 96% из них понимали риск (?!)
- Та же статья у "Касперов" подчеркивает, что обучение сотрудников должно начинаться на этапе адаптации (онбординга), а затем поддерживаться через регулярное повторное обучение.
Как говорится: «Знать, что делать, и делать это — две разные вещи.»
Почему ИТ обычно сопротивляется инициативам "давайте запустим обучение"
С точки зрения ИТ-руководителя практически все инициативы по обучению сотрудников выглядят одинаково: кто-то придумал полезную программу, а сопровождать ее потом придется ИТ. На старте почти всегда обещают "минимальное участие", но в реальности быстро всплывают — выгрузки списков адресов, согласования, вопросы по каналам рассылок, помощь со статусами и просьбы "еще немного помочь с отчетом". "Гладко было на бумаге, а поехали — овраги", как в известной поговорке.
Такое сопротивление часто трактуют как консерватизм. На деле это рациональная реакция на прошлый опыт. IT-команда уже видела, как временные решения превращаются в ИХ постоянные обязанности. Поэтому главный вопрос у айтишников в данном случае — не "нужно ли обучать сотрудников", а "докажите, что это не станет еще одним процессом, который повиснет на нас".
Если ИБ-руководитель приходит в ИТ с формулировкой «нам нужен новый инструмент», он почти неизбежно сталкивается с защитной реакцией. Если же разговор начинается с тем нагрузки, границ участия и повторяемости процесса, диалог становится гораздо предметнее.
Где появляется лишняя нагрузка на ИТ
Самый большой объем нагрузки возникает на стыках между ролями и системами. Сначала нужно собрать и очистить списки сотрудников для фишинг-симуляций. Затем кто-то должен согласовать сценарии и каналы отправки. Потом нужно понять, где фиксировать результаты, кто готовит сводку для руководства и что делать с группами риска после первой проверки.
Пока компания проводит одну разовую активность, все эти действия могут выглядеть терпимо. Но как только обучение нужно повторять, действия начинают множиться. Каждая новая волна требует заново собирать одни и те же куски: актуализировать базу, проверять статусы, сводить результаты, объяснять различия между волнами и готовить новую коммуникацию.
Именно поэтому для ИТ проблема звучит не как «нам тяжело провести один запуск», а как «мы не хотим оказаться владельцем бесконечной задачи». Если эту логику не признать прямо, любой разговор про обучение сотрудников будет упираться в недоверие.
Что отличает легкий сценарий запуска от тяжелого
Лёгкий сценарий начинается с понятного владельца процесса. ИБ отвечает за логику программы и за то, что именно измеряется. HR помогает с встраиванием в коммуникации и ритм обучения. ИТ участвует там, где действительно нужен доступ к инфраструктурному контуру, а не там, где "непонятно, кому это отдать".
Второй признак лёгкого сценария: фиксируется ограниченный объём участия ИТ. Не абстрактное «поможете на старте», а конкретный список: что нужно до пилота, что делается в момент запуска и что не возвращается к ИТ каждый месяц.
Третий признак: процесс можно повторить без пересборки с нуля. Если вторая волна требует почти тех же ручных усилий, что и первая, значит ИБ не выстроили цикл, а просто провели разовую кампанию.
Что должен проверить ИТ-руководитель до старта
Перед стартом ИТ-руководителю полезно проверить четыре вещи.
- Во-первых, кто является реальным владельцем процесса. Если ответ размыт, нагрузка потом наверняка расползется по смежным функциям.
- Во-вторых, что именно нужно от ИТ: на запуске, на поддержке и в период отчетности. Это должны быть не общие слова, а список действий, метрик, задач.
- В-третьих, какие неавтоматизируемые, ручные действия останутся даже после запуска. Многие инициативы проваливаются не потому, что технология плохая, а потому что задачи "сделать руками" никто не проговорил заранее.
- В-четвертых, как будет выглядеть пилот по объемам, датам и ролям. Плохой пилот начинается как "маленькая проверка", а заканчивается тем, что ИТ внезапно сопровождает уже почти полноценный процесс.
Если эти четыре вопроса не закрыты, сопротивление ИТ не только нормально, но и полезно для компании: оно сигнализирует, что процесс еще не собран.
Как ИБ и ИТ договориться о нормальном процессе
На практике лучший сценарий начинается не с выбора инструмента, а с короткой рабочей договоренности между ИБ и ИТ. В ней должно быть зафиксировано, кто за что отвечает, какие шаги входят в пилот, какие метрики действительно нужны и что считается успешным запуском.
Здесь полезно убрать соблазн "предусмотреть все еще перед стартом". На этом этапе важнее не полнота, а управляемость. ИТ легче поддерживать проект, если видно, что ИБ не пытается навесить на команду "идеальную архитектуру" будущего. Минимально достаточный сценарий: ограниченный контур, понятная логика участия ИТ и ясный критерий, по которому пилот либо продолжается, либо тормозится.
.
Такое соглашение снижает не только нагрузку, но и недоверие. ИТ перестает ощущать, что его втягивают в бесконечный процесс, а ИБ получает шанс показать, что речь идет не об очередном хаотичном проекте.
Читайте также: Как запустить фишинг-рассылку в компании: сценарий симуляции, метрики и отчеты
Какой результат считать успешным
Успешным результатом обучения по ИБ для ИТ нельзя считать сам факт запуска. Для ИТ-отделов хороший итог выглядит иначе: команда не стала вторым владельцем программы, запуск не создал резкого (непрогнозируемого) всплеска ручной работы, а следующую волну можно провести без нового организационного аврала.
Это важный сдвиг в критериях. Если ИБ-функция оценивает успех по принципу "мы что-то провели", а ИТ оценивает по принципу "нам теперь стало сложнее жить", проект быстро теряет поддержку. Если же обе стороны смотрят на повторяемость, ясные роли и снижение ручной нагрузки, появляется общая база для нормального продолжения.
На что смотреть при выборе решения
С точки зрения ИТ-руководителя ценность решения (автоматизированной платформы или отдельного ПО) — не в наборе функций, а в том, что несколько разрозненных шагов собираются в один контур. Имеет смысл оценивать, связаны ли симуляции, обучение и отчётность в единый процесс: тогда ИТ не придётся каждый раз помогать с ручной склейкой. Полезно заранее уточнить варианты развёртывания (облако или on-premise), интеграции с каталогами (LDAP/AD), единым входом (SSO), почтой (SMTP), логированием (Syslog) и API — это снижает ручную нагрузку при запуске и поддержке.
Разговор о внедрении продуктов по ИБ с ИТ должен начинаться не с самого продукта, а с уважения к операционной реальности команды: вы понимаете цену "лишних телодвижений" и предлагаете не ещё один "проект", а собранный процесс. Следующий шаг — разобрать текущий сценарий: где именно возникают лишние выгрузки, согласования и ручные склейки, и как их можно сократить за счёт единого контура симуляций, обучения и отчётности.
FAQ
Правда ли, что обучение сотрудников по ИБ почти всегда нагружает ИТ?
Не обязательно. Обычно ИТ перегружается там, где процесс собран вручную и на каждой волне требует новых согласований, выгрузок и склеек.
Что больше всего раздражает ИТ в таких инициативах?
Не сама тема обучения, а неясные роли, ручные операции и риск получить еще один постоянно поддерживаемый контур.
Когда ИТ стоит подключаться глубоко, а когда достаточно минимального участия?
Если процесс понятен, роли зафиксированы, а запуск ограничен пилотом, участие ИТ можно держать минимальным. Глубокое вовлечение требуется там, где процесс не определен и все решения откладываются на потом.
Что дает платформа фишинг-симуляций
Платформа помогает собрать в один контур симуляции, реакцию сотрудников, дообучение, повторную проверку и отчетность. Это делает процесс повторяемым и снижает объем ручной работы.
Записаться на демо платформы Avareange
