© «Директор по безопасности», №09-2026, Сентябрь, 2026 г.
Материал подготовлен на основе исследования, проведенного в ЦУП ВШБ НИУ ВШЭ. Автор - Ю.С. Калягин, кандидат психологических наук, доцент. Научный руководитель – А.С. Колесников, кандидат технических наук, CTO HR, член Экспертного совета ЦУП ВШБ НИУ ВШЭ.
«Все прожекты зело добрыми быть должны, дабы казну зряшно не разорять и Отечеству ущерба не чинить.
Ежели кто прожекты начнёт абы как ляпать, того чина лишу и кнутом драть велю».
Петр I
Мировые тренды экономики указывают на возрастающую роль проектного подхода в деятельности компаний. На сегодняшний день проектное управление накопило серьезный потенциал успешной деятельности в условиях, основной характеристикой которых является неопределенность.
На примере IT-проектов мы видим, доля провальных проектов снизилась с 31% до 19%, при этом доля проектов, остающихся на плаву, но вываливающихся за первоначальные параметры, снизилась не сильно, 53% и 46% соответственно. Безусловно главным аргументом здесь будет являться динамика успешных проектов, с 16% она достигла уровня 35% (данные за 1994-2020 гг., The Standish Group CHAOS Chronicles).
Несмотря н успехи проектного управления нельзя игнорировать и провалы, которые становятся обучающими кейсами для новых поколений проектных менеджеров. Наиболее ярким таким примером стало строительство «Зенит Арены», которую планировали построить за три года с бюджетом 6, 7 млрд. руб. В итоге стройка длилась 10 лет с бюджетом 43,8 млрд руб. (см. П.Алферов «Проектное управление», 2025).
При всей активности развития проектной деятельности в мире, следует отметить дефицит изучения процесса защиты этой специфической деятельности. Сам объект защиты в литературе идентифицирован недостаточно.
Создавая новый продукт, запуская масштабную трансформацию или строя инфраструктурный объект, мы опираемся на проверенные методологии, стандартизированные на уровне международного сообщества проектного управления. Мы успешно используем все инструменты, строим диаграммы Ганта, рассчитываем сетевые графики, декомпозируем работы и еженедельно проводим статусные встречи и делаем многие другие правильные вещи. Но есть одна слепая зона, которая выпадает из фокуса мировых стандартов (PMI, IPMA и др.).
В основных стандартах проектного управления вопрос комплексной безопасности если и упоминается, то лишь вскользь. Более того, тренд последних лет настораживает: в новых редакциях международных стандартов разделы, касающиеся безопасности, имеют тенденцию к сокращению или к размытию. Создается впечатление, что проект защищен «по умолчанию», а вопросы безопасности, это удел штатной службы безопасности (СБ) материнской компании.
Опыт показывает обратное. Проект – это идеальная мишень. Временная структура, где в одной точке пересекаются огромные финансовые потоки, конфиденциальные данные, новые не проверенные подрядчики и амбиции людей. Без четкого понимания того, что именно мы защищаем и как выстроить периметр, даже самый блестящий проектный план рискует рухнуть под давлением внешних и внутренних угроз.
В этой статье мы предлагаем дорожную карту для директоров по безопасности и руководителей проектов. Разберем проект как уникальный объект защиты, выявим четыре критические точки приложения сил СБ и предложим готовую типологию моделей защиты в зависимости от структуры участников.
Проект - мишень №1: Почему традиционная СБ здесь не работает
Чтобы защитить объект, нужно понять его природу. И здесь нас ждет парадокс: проект – это «неудобный» объект для классической службы безопасности.
Штатная СБ привыкла работать со статичными объектами. У предприятия есть стены, пропускной режим, устоявшиеся бизнес-процессы, постоянный штат и четкая иерархия. Проект же по своей природе временный, уникальный и ограниченный во времени. Он функционирует в условиях перманентной неопределенности. Участники проектной команды часто представляют разные организации, а сам проект может не иметь отдельного юридического лица.
Традиционная СБ, пытаясь «наложить» свои корпоративные регламенты на проектную среду, либо душит инициативу бюрократией, либо оказывается бессильной, потому что ее полномочия заканчиваются там, где начинается зона ответственности внешнего подрядчика или партнера.
Определение: проект как объект защиты – это совокупность уникальных бизнес-процессов и временной организационной структуры, функционирующих в условиях высокой неопределенности, направленных на достижение конкретных целей в установленные сроки и бюджет, и требующих обеспечения комплексной безопасности в отношении человеческих ресурсов, финансовых потоков и логистических цепочек.
Если на старте проекта не идентифицировать объект защиты и не выбрать правильную модель его «охраны», компания столкнется с классическим эффектом «театра безопасности»: меры будут приниматься, бюджеты освоены, но реальный уровень защищенности останется нулевым.
Где искать угрозы: Четыре точки приложения сил СБ
Стандарты сводят безопасность проекта к защите коммерческой тайны и отчасти физической безопасности. Это фатальная ошибка – охрана офиса и настройка режима конфиденциальности – это лишь вершина айсберга. Реальная работа по защите проектной деятельности лежит в четырех функциональных областях управления проектами.
1. Управление стоимостью: Невидимые утечки бюджета
Проект всегда связан с освоением средств. СБ не должна ждать аудита постфактум. Задача выстроить превентивный контроль смет, контрактов и финансовых потоков.
Риски: откаты при закупках, нецелевое использование бюджета, создание фиктивных актов выполненных работ, завышение объемов выполненных работ.
Действие СБ: внедрение процедур проверки контрагентов на аффилированность с сотрудниками проектной команды, мониторинг ценовых отклонений от рынка, анализ бенефициарных цепочек владельцев подрядчиков.
2. Управление рисками: Тандем СБ и риск-менеджмента
Это зона наиболее плотного взаимодействия. Традиционно риск-менеджмент оперирует субъективными вероятностями и финансовыми моделями, тогда как СБ работает с объективными данными и фактами угроз.
Риски: рейдерские захваты, промышленный шпионаж, саботаж со стороны конкурентов, компрометация ключевых фигур проекта.
Действие СБ: поставка «твердых» разведданных (OSINT, HUMINT) о контрагентах и конкурентах. Риск-менеджмент переводит эти угрозы в финансовую плоскость, рассчитывая вероятности стоимости. На основе этого формируется либо наблюдательная позиция, либо активные действия по устранению угроз.
3. Управление персоналом: «Троянские кони» в команде
Проекты требуют быстрого найма (комплектования). В спешке формирования команды проверки бэкграунда часто откладываются «на потом».
Риски: внедрение конкурентами своих людей, токсичные сотрудники, разрушающие команду изнутри, инсайдеры, продающие данные.
Действие СБ: экспресс-проверки на этапе найма, мониторинг лояльности и неформальных связей в команде, использование DLP-систем для контроля утечек, предотвращение выгорания ключевых специалистов, мониторинг уровня вербовочной уязвимости членов команды.
4. Управление поставками: Битва за тендер
Логистика и закупки - традиционная точка приложения усилий корпоративных «разведчиков».
Риски: сговор на тендерах, поставка неликвидной продукции, срыв сроков из-за недобросовестности подрядчика.
Действие СБ: глубокая due diligence поставщиков до момента заключения контракта, мониторинг их финансового состояния и репутации на протяжении всего жизненного цикла проекта.
Четыре модели защиты: От «тепличной» до «консорциума»
Как только мы поняли, от чего защищать проект, встает главный вопрос: как выстроить периметр? Выбор модели защиты напрямую зависит от организационной структуры проекта. Ошибка в выборе модели ведет либо к неоправданным затратам, либо к фатальным дырам в безопасности.
В матрице представлено четыре базовые модели защиты проекта.
Модель 1. Одно юридическое лицо (проект внутри компании)
Самый простой и предсказуемый случай. Проектная команда набрана из штатных сотрудников, бюджет компании един, информационная инфраструктура общая.
Формула: СБ компании = СБ проекта
Действия: применяются все стандартные регламенты СБ материнской компании. Проект находится в «контролируемой зоне». Руководитель проекта может назначить куратора от СБ, который будет работать в режиме, не тормозя процессы бюрократией.
Модель 2. Холдинговая структура
Проект реализуется силами «дочек» или зависимых обществ. У каждой компании-участника есть своя СБ, свои регламенты и, что важно, свои интересы.
Формула: СБ участников ≈ СБ проекта
Действия: главная задача – преодолеть организационно-административные барьеры. СБ материнской компании должна выступить методологическим интегратором.
Модель 3. Вовлечение физических лиц и независимых подрядчиков
Проектная команда формируется из фрилансеров, ИП и внешних консультантов.
Формула: СБ компании ≠ СБ проекта
Действия: равенства прав и зон ответственности нет. Внешние исполнители не связаны корпоративной этикой и лояльностью. Требуется жесткий контроль: NDA, ограничение доступов по принципу Zero Trust (нулевое доверие), тщательная проверка каждого «внешнего» игрока.
Модель 4. Совместный проект нескольких независимых юридических лиц (консорциум).
Самая сложная и уязвимая модель. Несколько независимых компаний (часто являющихся конкурентами в других сегментах) объединяют ресурсы для реализации мегапроекта (например, государственное частное партнерство, строительство завода, совместная R&D и тп).
Формула: СБ участника А + СБ участника Б + СБ участника В ≠ СБ проекта
Действия: здесь нет «главного». Требуется синхронизация систем безопасности. Именно здесь рождается «Зона синхронизации» или другими словами это пространство максимального риска для всех участников проекта данного типа.
Зона синхронизации: Как защитить «стык» интересов
В консорциумах главная опасность кроется не на периметре, а на «стыке».
Зона синхронизации - это место пересечения систем безопасности нескольких независимых участников. Здесь происходит обмен информацией, совместная работа персонала, пересекаются логистические потоки. Здесь же периметр размывается, а юрисдикция одной СБ заканчивается и начинается зона ответственности другой. В этой зоне происходят самые опасные инциденты.
Как выстроить защиту здесь? Синхронизация должна проходить на трех уровнях:
Кадры и доступы. Кто имеет право подписи? Кто допускается к «ядру» проекта? Необходимо создать единый реестр доверенных лиц и унифицировать процедуры проверки.
Информация. Определение перечня защищаемой информации. Какие данные являются коммерческой тайной конкретного участника, а какие — тайной совместного проекта? Настройка защищенных каналов обмена.
Логистика и физическая безопасность. Контроль на стыке территорий, если проект имеет физическое воплощение.
Будущее синхронизации: AI-защитник
Ручная синхронизация трех и более корпоративных систем безопасности - колоссальные трудозатраты и постоянные конфликты интересов.
На сегодняшний день профессиональные стандарты в сфере корпоративной безопасности отсутствуют, каждый бизнес строит свою методологию защиты. Поэтому перспективным направлением выступает использование AI-агента («AI-защитника») в составе проектной команды.
Нейросеть, обученная на стандартах, политиках и регламентах безопасности всех компаний-участниц, может выступать в роли нейтрального арбитра или медиатора. Такой помощник сможет в автоматическом режиме проверять контрагентов, мониторить транзакции на предмет аномалий, контролировать доступ к данным и сигнализировать о рисках, не подверженных человеческому фактору и корпоративным интригам.
Выводы и рекомендации для практиков
Анализ российских и международных практик показывает: вопрос защиты проектной деятельности системно не раскрыт. Службы безопасности часто приходят в проект постфактум, когда «пожар» уже случился, или работают вслепую, не понимая специфики проектной деятельности. Критичность этой ситуации возрастает по мере роста количества участников проекта.
Чтобы ваш проект не остался без «щита», рекомендуем внедрить следующие практики:
Идентификация на старте. Правильная идентификация объекта защиты и выбор модели безопасности на инициации проекта позволяет сэкономить, сразу отсекая неэффективные меры и фокусируясь на реальных угрозах.
Безопасность в Уставе проекта. Уже на стадии формирования Устава инициатор или руководитель проекта обязан определить модель защиты и заложить в бюджет мероприятия по синхронизации систем безопасности. Если безопасности нет в Уставе, ее нет и в проекте.
Разделение ролей. СБ поставляет факты и угрозы, риск-менеджмент считает деньги. Заставьте их работать в одной связке.
Особый контроль для участников извне. Если в проекте участвуют физические лица или независимые юридические лица, откажитесь от иллюзии, что их СБ работает так же хорошо, как ваша. Выстраивайте тотальный контроль и Zero Trust.
Готовьтесь к AI-трансформации. Если вы управляете сложным консорциумом, начните изучать возможности внедрения AI-агентов для нейтральной синхронизации политик безопасности участников.
В современном мире безопасность, это не «тормоз» для проекта и не статья расходов, которую пытаются оптимизировать. Комплексная безопасность проектной деятельности, это критический фактор успеха, гарантия того, что ваши инновации дойдут до релиза, а бюджет будет потрачен на создание ценности, а не на ликвидацию внутренних кризисов.
Защитите свой проект сегодня, чтобы завтра он не стал чьим-то успешным кейсом.
Автор гарантирует, что обладает всеми необходимыми правами на предоставленные фото-, видео- и графические материалы, включая, но не ограничиваясь, авторским правом и правами на изображения третьих лиц, и несет полную ответственность за нарушение интеллектуальных прав правообладателей.
Редакция публикует указанные материалы на условиях информационного посредничества (ст. 1253.1 ГК РФ) и не осуществляет проверку правомочности их использования до момента получения соответствующего требования от правообладателя. Редакция обязуется принять меры по удалению материалов при получении мотивированного заявления.
Делитесь с коллегами!
Мы делаем сложное понятным!
ИД Советник, ж-л Директор по безопасности, ж-л Безопасность компании
Присоединяйтесь к нам:
Telegram| MAX | Наш сайт www.sec-company.ru
Для связи: info@sec-company.ru
+7(967) 119-00-42 - Подписка, +7(499) 404-21-71 - Сотрудничество
