Управление проектами в области информационной безопасности в России: нормативные требования, риски и новые технологические факторы

Введение

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

В этих условиях проектное управление становится одним из ключевых инструментов развития системы защиты информации. Внедрение средств защиты, создание центра мониторинга, переход на отечественное программное обеспечение, сертификация процессов безопасной разработки, построение модели угроз, обучение персонала и внедрение DevSecOps имеют признаки проекта: ограниченные сроки, ресурсы, уникальный результат и необходимость координации нескольких участников [1, 2].

Актуальность темы определяется несколькими факторами. Во-первых, государственная политика в сфере цифровой трансформации связывает развитие экономики данных с кибербезопасностью, отечественными цифровыми платформами, подготовкой ИТ-кадров и внедрением искусственного интеллекта [9]. Во-вторых, Указ Президента Российской Федерации от 30.03.2022 № 166 усилил требования к технологической независимости и безопасности критической информационной инфраструктуры [5]. В-третьих, стандарты безопасной разработки и риск-ориентированного управления требуют от проектных команд не разового внедрения средств защиты, а документально подтверждаемого процесса [6, 8]. Наконец, российский рынок кибербезопасности продолжает расти, но его динамика становится более умеренной: по оценке SecPost, объем рынка в 2025 году составил 365 млрд рублей при росте около 12% к 2024 году [10].

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

1. ИБ-проект как особый объект управления

В классической теории проект рассматривается как временная деятельность, направленная на создание уникального результата при ограничениях по срокам, бюджету, ресурсам и качеству [1]. Это определение применимо и к сфере информационной безопасности, однако в ИБ-проектах каждый из указанных параметров получает дополнительное содержание. Результат должен быть не только внедрен, но и проверен с точки зрения защищенности. Сроки зависят не только от команды, но и от согласований, испытаний, аудитов и сертификации. Качество оценивается не только функциональностью решения, но и тем, насколько оно снижает реальные риски.

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

На этапе планирования ИБ-проект включает работы, которые редко встречаются в обычных ИТ-проектах: построение модели угроз, подготовку организационно-распорядительной документации, настройку средств защиты, проведение тестирования на проникновение, обучение пользователей, подготовку к аттестации или сертификации, разработку регламентов реагирования на инциденты [3]. План должен предусматривать не только последовательность действий, но и возможность пересмотра решений при выявлении новых уязвимостей.

Исполнение ИБ-проекта почти всегда затрагивает поведение сотрудников. Внедрение DLP-систем, средств контроля доступа, SIEM-платформ, EDR/XDR-решений или процедур безопасной разработки меняет привычные рабочие практики. Поэтому проектная команда сталкивается не только с техническими задачами, но и с сопротивлением персонала. Успешное внедрение требует коммуникаций, обучения и объяснения управленческого смысла мер безопасности.

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

2. Нормативная среда как фактор проектного управления

Российская практика управления ИБ-проектами в значительной степени определяется нормативной средой. Указ Президента Российской Федерации от 30.03.2022 № 166 закрепил меры по обеспечению технологической независимости и безопасности критической информационной инфраструктуры. Для проектных команд это означает необходимость заранее оценивать происхождение программного обеспечения, возможность поддержки, зависимость от иностранных компонентов и условия использования решений на значимых объектах КИИ [5].

Серьезное влияние на проекты оказывает развитие стандартов безопасной разработки. ГОСТ Р 56939-2024 направлен на предотвращение появления, выявление и устранение недостатков, включая уязвимости программного обеспечения. Стандарт устанавливает требования к содержанию и порядку выполнения работ, связанных с созданием безопасного ПО, а также подчеркивает значение артефактов, по которым можно подтвердить выполнение требований [6]. Для руководителя проекта это означает, что безопасность должна быть встроена в жизненный цикл разработки, а не добавлена на финальной стадии.

Приказ ФСТЭК России от 01.12.2023 № 240 утвердил порядок проведения сертификации процессов безопасной разработки программного обеспечения средств защиты информации. Документ вступил в силу с 1 июня 2024 года и усилил значение процессной зрелости разработчика [7]. В проектном управлении это приводит к росту роли доказательной базы: отчетов, журналов, результатов проверок, описаний процессов, матриц соответствия и реестров рисков.

Для финансового сектора показательным является ГОСТ Р 57580.3-2022, посвященный управлению риском реализации информационных угроз и обеспечению операционной надежности. Стандарт устанавливает требования к составу и содержанию мер управления риском, применяемых финансовыми организациями при планировании, реализации, контроле и совершенствовании системы управления таким риском [8]. Хотя данный стандарт ориентирован на финансовые организации, сама логика планирования, контроля и постоянного совершенствования применима и к другим ИБ-проектам.

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

3. Выбор методологии: каскадный, гибкий и гибридный подходы

Методология управления определяет, как команда планирует работу, контролирует результат и реагирует на изменения. В ИБ-проектах выбор методологии особенно важен, поскольку сфера сочетает высокую неопределенность угроз и жесткие требования к документированию.

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

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

Agile, Scrum и Kanban позволяют уточнять приоритеты, быстрее получать промежуточный результат и адаптировать команду к изменяющимся условиям. Но прямой перенос гибких методологий в ИБ-проекты рискован. Нужны дополнительные артефакты: модель угроз, backlog требований безопасности, журнал уязвимостей, security user stories, критерии приемки по защищенности и реестр решений по рискам [4, с. 103-107].

Наиболее практичной для российских условий является гибридная модель. В ней нормативные требования, сертификационные процедуры, обязательная документация и ключевые контрольные точки управляются в логике Waterfall, а разработка, настройка, обучение и реагирование на новые угрозы ведутся итерационно. Такой подход позволяет одновременно сохранить управляемость и обеспечить адаптивность проекта.

4. Риск-ориентированное управление

Риск-ориентированный подход является центральным принципом современных ИБ-проектов. Его смысл состоит в том, что меры защиты выбираются не формально, а на основе значимости активов, вероятности угроз, уязвимостей и возможного ущерба. Такой подход помогает избежать двух крайностей: недостаточной защиты критичных процессов и избыточных затрат на второстепенные активы [8].

В проектном контуре управление рисками начинается с идентификации активов и построения модели угроз. Далее проводится оценка рисков, выбираются способы реагирования: снижение, принятие, передача или избегание. После этого меры защиты включаются в план проекта, а их выполнение контролируется через ответственных, сроки, критерии приемки и показатели эффективности.

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

Риск-ориентированное управление также помогает согласовать язык технических специалистов и руководства. Для бизнеса важна не сама по себе уязвимость, а ее последствия: простой сервиса, утечка данных, штраф, потеря доверия или нарушение непрерывности деятельности. Руководитель ИБ-проекта должен переводить технические факты в управленческие решения: кто владелец риска, каков срок устранения, какой остаточный риск сохраняется после внедрения мер.

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

5. Импортозамещение и технологическая независимость

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

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

По данным SecPost, среди движущих факторов российского рынка кибербезопасности в 2025-2026 годах названы рост числа и сложности атак, ужесточение регулирования, продолжающееся импортозамещение и проникновение ИИ в ИБ-процессы [10]. Следовательно, импортозамещение нельзя рассматривать как завершенную кампанию. Оно превращается в постоянное направление проектной деятельности.

Практическим решением становится мультивендорная модель. Она снижает зависимость от одного поставщика, но усложняет управление: требуется проверять совместимость решений, выстраивать единый мониторинг, распределять ответственность между подрядчиками и поддерживать целостную архитектуру безопасности. Для руководителя проекта это означает необходимость сочетать техническое обследование, пилотирование, поэтапную миграцию и план отката.

6. Искусственный интеллект в ИБ-проектах

Искусственный интеллект становится новым фактором проектного управления в сфере информационной безопасности. Национальный проект «Экономика данных и цифровая трансформация государства» прямо связывает цифровую трансформацию с развитием кибербезопасности, отечественного программного обеспечения, перспективных разработок и искусственного интеллекта [9].

В ИБ-проектах ИИ может применяться для анализа больших массивов данных об уязвимостях, приоритизации задач, подготовки отчетности, прогнозирования сроков, автоматизации обработки инцидентов и поддержки безопасной разработки. Российские компании уже предлагают решения для автоматизации создания программного обеспечения на основе больших языковых моделей. Например, Bell Integrator представила платформу «Алькод», ориентированную на автоматизацию рутинных операций аналитиков, разработчиков и тестировщиков [12].

Отдельное направление связано с безопасным использованием ИИ в закрытых цифровых контурах. По данным ТАСС, в СПбГЭТУ «ЛЭТИ» разработана платформа для защищенного внедрения ИИ-сервисов в государственные и корпоративные системы. Важным свойством такой модели является работа в изолированном сегменте сети, при которой информация не покидает ведомственный цифровой контур [13].

Использование ИИ в ИБ-проектах открывает новые возможности, но создает и новые риски. К ним относятся ошибки модели, зависимость от качества исходных данных, утечка конфиденциальной информации, непрозрачность рекомендаций и снижение контроля со стороны человека. Поэтому ИИ должен рассматриваться как инструмент поддержки решений, а не как замена ответственности руководителя проекта.

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

7. Проектные офисы и государственные ИТ-проекты

Для государственных ИТ-проектов важным трендом становится централизация методического и архитектурного управления. В 2025 году была представлена обновленная модель создания ИТ-решений для государства, предполагающая четкое разделение зон ответственности. Согласно опубликованной информации, Центр экспертизы и координации информатизации помогает ведомствам формировать функциональные требования, а «Гостех» отвечает за архитектуру, техническую реализацию, закупки, разработку и внедрение ИТ-решений [11].

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

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

8. Кадровый фактор и роль руководителя ИБ-проекта

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

Руководитель ИБ-проекта должен владеть несколькими группами компетенций. Первая группа - классические навыки управления проектами: планирование, работа со сроками, бюджетом, качеством, командой и коммуникациями [1, 2]. Вторая - понимание основ информационной безопасности: моделей угроз, уязвимостей, средств защиты, мониторинга и реагирования. Третья - знание регуляторной среды. Четвертая - управление изменениями и сопротивлением персонала.

Особое значение имеет коммуникационная роль руководителя. Специалисты ИБ часто говорят языком технических рисков, а бизнес-подразделения - языком сроков, затрат и влияния на процессы. Руководитель должен связывать эти позиции и показывать, каким образом меры защиты поддерживают устойчивость организации. Без такого перевода безопасность воспринимается как внешнее ограничение, а не как элемент управляемого развития.

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

Заключение

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

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

Наиболее устойчивой методологической моделью является гибридный подход. Waterfall целесообразен для обязательных процедур, документации и сертификационных этапов. Agile и Kanban полезны при разработке, настройке, обучении и реагировании на новые угрозы. Риск-ориентированное управление должно связывать технические решения с реальными последствиями для организации.

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

Главным условием успешности остается человеческий капитал. Руководитель ИБ-проекта должен работать на пересечении менеджмента, информационной безопасности, права и организационных изменений. Развитие таких компетенций является не менее важным направлением, чем внедрение новых технологических решений.