Используя данный сайт, вы даете согласие на использование файлов cookie
Согласен
Расширяем географию: открыли новый офис для поддержки клиентов в СНГ

Расширяем географию: открыли новый офис для поддержки клиентов в СНГ

Компания увеличила присутствие на международном рынке

Меры обеспечения информационной безопасности: комплексный подход и практические решения

Меры обеспечения информационной безопасности: комплексный подход и практические решения

Как обеспечить информационную безопасность организации?

Процессы управления IT-проектом: методологии, этапы и инструменты

Процессы управления IT-проектом: методологии, этапы и инструменты

Что такое управление IT-проектами

Жизненный цикл и структура ИТ проекта

Жизненный цикл и структура ИТ проекта

Что такое жизненный цикл проекта и зачем он нужен?

Как составить план IT-проекта: методологии, этапы и управление

Как составить план IT-проекта: методологии, этапы и управление

Стратегическое планирование IT-проекта - это не формальность и не бюрократическая процедура

Создание IT-проекта: Пошаговый гайд от идеи до успешного запуска

Создание IT-проекта: Пошаговый гайд от идеи до успешного запуска

Создание ИТ-системы - это не линейный процесс, а многослойный путь, на котором каждый неверный шаг способен отбросить проект назад на несколько недель

1С Документооборот: зачем нужен, возможности и как внедрить

1С Документооборот: зачем нужен, возможности и как внедрить

1С Документооборот - это полноценная ECM-система, созданная для автоматизации управления корпоративным контентом и внутренними процессами организации

Завершили внедрение IT-аутсорсинга для федеральной розничной сети

Завершили внедрение IT-аутсорсинга для федеральной розничной сети

Наша команда успешно завершила комплексный проект по поддержке IT-систем крупной торговой сети

Запустили круглосуточный центр мониторинга инфраструктуры

Запустили круглосуточный центр мониторинга инфраструктуры

Мы расширили возможности нашей службы поддержки - теперь мониторинг IT-инфраструктуры клиентов доступен 24/7

  • /
  • /
статья блога
Эффективное управление рисками IT-проекта: анализ и стратегии

Автор: Команда LAN8 | Обновлено: 23.01.2024 | Время чтения: 8 мин
Содержание статьи
Введение: Что такое управление рисками IT-проекта и почему это необходимость
Классификация и виды рисков в IT-проектах
Как выстроить процесс управления рисками IT-проекта: пошаговый подход
Стандарты и нормативы, применимые в России для управления IT-рисками
Практические советы и лучшие практики управления IT-рисками
Итоги и заключение: Управление рисками IT-проекта как непрерывный процесс
Часто задаваемые вопросы
Введение: Что такое управление рисками IT-проекта и почему это необходимость
Управление рисками IT-проекта — это системный, непрерывный процесс выявления, анализа, оценки и контроля факторов, способных негативно повлиять на достижение целей проекта или всей организации в сфере информационных технологий. Речь идет не о разовой проверке безопасности и не о формальном чек-листе перед запуском системы. Это полноценная дисциплина, встроенная в жизненный цикл каждого IT-проекта и охватывающая технические, организационные, финансовые и правовые аспекты.
В современной деловой среде управление рисками в IT-проектах приобретает стратегическое значение. Для российских компаний эта тема стоит особенно остро: с одной стороны, регуляторный ландшафт становится всё более требовательным — ФСТЭК, ЦБ РФ, Роскомнадзор формируют жёсткие требования к защите информации. С другой стороны, после ухода ряда зарубежных вендоров обострились вопросы импортозамещения и надёжности IT-инфраструктуры. Одновременно растёт число киберугроз: по данным ведущих российских компаний в сфере информационной безопасности, количество успешных атак на корпоративные сети ежегодно увеличивается.
Управление рисками IT-проекта помогает организациям не просто реагировать на уже случившиеся инциденты, но выстраивать проактивную защиту. Каждый инцидент — будь то утечка данных, сбой критической системы или задержка в разработке — несёт вполне конкретную цену: прямые финансовые потери, затраты на восстановление, штрафы от регуляторов и долгосрочный репутационный ущерб. Именно поэтому грамотный риск-менеджмент в IT сегодня — это не опция, а базовое требование к любому серьёзному проекту.
Чем грозит игнорирование IT-рисков
Отсутствие выстроенной системы управления рисками проекта в сфере IT порождает целый спектр последствий — от операционных сбоев до полной остановки бизнеса. Прямые финансовые потери возникают из-за простоев систем, затрат на экстренное восстановление данных, выплаты штрафов регуляторам и компенсаций пострадавшим клиентам. По оценкам аналитиков, средняя стоимость одного инцидента в сфере информационной безопасности для российской компании среднего размера составляет десятки миллионов рублей, если учитывать все косвенные потери.
Репутационные издержки зачастую оказываются ещё более разрушительными: клиенты, узнавшие об утечке персональных данных или сбое в обслуживании, уходят к конкурентам, а восстановление доверия занимает годы. Для IT-проектов с внешними заказчиками срыв сроков или потеря данных нередко означает расторжение контрактов и судебные разбирательства. Игнорирование рисков — это не экономия ресурсов, а накопление скрытых долгов, которые рано или поздно предъявляются к оплате в самый неподходящий момент.
Классификация и виды рисков в IT-проектах
Грамотное управление рисками в IT-проектах начинается с понимания природы и разнообразия угроз, с которыми сталкиваются современные организации. Риски в IT не сводятся исключительно к хакерским атакам — их спектр значительно шире и охватывает множество измерений деятельности компании.
Риски информационной безопасности — наиболее очевидная категория. Сюда относятся утечки конфиденциальных данных, несанкционированный доступ к корпоративным системам, атаки с использованием программ-вымогателей (ransomware), фишинг, DDoS-атаки на инфраструктуру. Особую угрозу представляют APT-атаки (Advanced Persistent Threats) — сложные, длительные кампании, нацеленные на проникновение во внутренние сети и кражу ценной информации. Характерно, что точкой входа для таких атак нередко служат внутренние уязвимости, а не внешние периметры.
Операционные риски связаны с перебоями в работе IT-систем и процессов. Это отказы серверного оборудования, проблемы с сетевой инфраструктурой, сбои в программном обеспечении, ошибки конфигурации, потеря или повреждение данных. Операционные инциденты могут возникать как по техническим причинам, так и вследствие человеческого фактора.
Проектные риски специфичны для разработки и внедрения IT-решений. К ним относятся: изменение требований в ходе проекта, недооценка объёма работ и сроков, нехватка квалифицированных специалистов, технический долг, проблемы интеграции новых систем с существующей инфраструктурой, ошибки в архитектурных решениях. Управление рисками IT-проекта в этой части пересекается с классическим проектным менеджментом.
Организационные риски включают проблемы с персоналом: уход ключевых сотрудников, недостаточная компетентность команды, конфликты между подразделениями, сопротивление изменениям при внедрении новых систем. Нередко именно организационные факторы становятся причиной провала технически грамотно спланированных проектов.
Финансовые риски охватывают превышение бюджета проекта, изменение стоимости лицензий и оборудования, валютные колебания при закупках импортных решений, а также финансовые потери от простоев и инцидентов.
Юридические и регуляторные риски в российских реалиях приобретают всё большее значение. Несоответствие требованиям 152-ФЗ о персональных данных, 187-ФЗ о критической информационной инфраструктуре, требованиям ФСТЭК и ЦБ РФ влечёт административную и уголовную ответственность, значительные штрафы и предписания об устранении нарушений.
Внешние риски — это факторы, находящиеся вне контроля организации: действия регуляторов, санкционные ограничения, уход иностранных вендоров с рынка, изменение конкурентной среды, природные и техногенные катастрофы, влияющие на инфраструктуру.
Внутренние риски, связанные с действиями собственных сотрудников, часто недооцениваются. Между тем инсайдерские угрозы — намеренные или случайные — составляют значительную долю инцидентов. Именно внутренние уязвимости зачастую становятся отправной точкой для APT-атак: злоумышленники компрометируют учётные данные сотрудников и действуют от их имени, оставаясь незамеченными месяцами.

Как IT-риски влияют на российские компании
Специфика российского рынка формирует особый профиль IT-рисков. По данным аудитов, проводимых ведущими отечественными компаниями в сфере информационной безопасности — такими как Positive Technologies, BI.ZONE, «Ростелеком-Солар» — внутренние уязвимости встречаются в подавляющем большинстве обследованных организаций.

Среди наиболее распространённых проблем: отсутствие блокировки при переборе паролей (обнаруживается примерно в 80% компаний), недостаточное использование двухфакторной аутентификации для доступа к критическим системам, слабая политика управления паролями (использование стандартных или простых паролей), ошибки в настройках безопасности сетевого оборудования и серверов, отсутствие сегментации внутренних сетей. Эти, казалось бы, базовые недостатки открывают злоумышленникам широкие возможности для горизонтального перемещения внутри инфраструктуры.
Управление ИТ-рисками в российских компаниях дополнительно осложняется процессами импортозамещения: переход на отечественное программное обеспечение сам по себе создаёт временные уязвимости и требует тщательного управления рисками в IT-проектах по миграции. Необходимость постоянного мониторинга и регулярного пересмотра карты рисков в таких условиях становится не рекомендацией, а жёстким требованием.
Как выстроить процесс управления рисками IT-проекта: пошаговый подход
Управление рисками IT-проекта — это не единовременное мероприятие, а непрерывный цикл, встроенный в повседневную деятельность организации. Процесс включает несколько взаимосвязанных этапов: идентификацию угроз, их анализ и оценку, приоритизацию, выработку стратегий реагирования, планирование и реализацию защитных мер, мониторинг и корректировку, а также документирование и интеграцию в бизнес-процессы. Каждый из этих этапов критически важен — пропуск любого из них снижает эффективность всей системы управления рисками в IT-проектах.
Ключевое отличие зрелого подхода от формального — понимание того, что управление рисками проекта начинается ещё на стадии инициации, а не после того, как проблемы уже дали о себе знать. Чем раньше выявлена угроза, тем дешевле и проще с ней работать.
Идентификация рисков: где искать уязвимые места
Первый и во многом определяющий этап — выявление всех потенциальных угроз и уязвимостей, которые могут повлиять на IT-проект или информационную систему. Качество этого этапа напрямую определяет полноту последующего анализа рисков: невыявленный риск не попадёт ни в одну матрицу и не получит стратегии реагирования.
Существует несколько практически проверенных методов идентификации рисков:
Интервью с ключевыми сотрудниками. Технические специалисты, менеджеры проектов, представители бизнес-подразделений и службы информационной безопасности видят угрозы с разных ракурсов. Разговор с каждым из них позволяет собрать разнородную, но ценную информацию об уязвимых местах.
Мозговой штурм с участием межфункциональной команды. Совместная сессия с представителями IT, ИБ и бизнес-подразделений нередко выявляет риски на стыке зон ответственности — именно там, где они чаще всего остаются незамеченными.
Аудит инфраструктуры и проектной документации. Технический аудит позволяет выявить уязвимости конфигурации, устаревшие компоненты, отсутствующие патчи и архитектурные слабые места. Аудит проектной документации — обнаружить пробелы в требованиях, нереалистичные допущения и зоны неопределённости.
Использование чек-листов и отраслевых методик. Готовые перечни типовых угроз (в том числе методики ФСТЭК по моделированию угроз) позволяют систематически пройтись по всем категориям рисков и не упустить распространённые проблемы.
Анализ прошлых инцидентов. История собственных инцидентов и публичные кейсы из отрасли — ценнейший источник информации о реальных угрозах. Если инцидент уже происходил однажды, вероятность его повторения необходимо учитывать при управлении рисками в IT-проектах.
Результатом идентификации становится карта рисков — структурированный перечень потенциальных угроз, который служит основой для дальнейшего анализа. Важно, чтобы в создании этой карты участвовали представители разных подразделений: монопольный взгляд одного специалиста неизбежно создаёт слепые пятна.
Анализ и оценка рисков
После того как угрозы выявлены, необходимо определить их реальную опасность для проекта и организации. Анализ рисков позволяет перейти от интуитивных ощущений к измеримым показателям, на основе которых принимаются управленческие решения.
В практике управления IT-рисками применяются два основных подхода.
Количественная оценка опирается на числовые показатели. Базовая формула выглядит следующим образом:
> Риск = Вероятность наступления события × Величина ущерба
Например, если вероятность успешной атаки с использованием уязвимости в веб-приложении составляет 30% в год, а потенциальный ущерб от утечки клиентских данных оценивается в 5 000 000 рублей (прямые потери + штрафы + восстановление), то количественная оценка риска составит 1 500 000 рублей в год. Эта цифра позволяет сравнивать стоимость риска со стоимостью защитных мер и принимать экономически обоснованные решения.
Количественная оценка требует достаточной статистической базы и экспертной экспертизы, поэтому в чистом виде применяется преимущественно в крупных организациях с развитой системой управления рисками проекта.
Качественная оценка использует шкалы и категории вместо точных цифр. Вероятность наступления инцидента оценивается как «высокая / средняя / низкая», ущерб — как «критический / значительный / умеренный / незначительный». Такой подход быстрее в применении и доступен командам без обширной статистики, хотя и менее точен.
На практике большинство организаций применяет комбинированный подход: качественная оценка используется для первичной сортировки и приоритизации, количественная — для наиболее критических рисков, требующих детального анализа.
Для систематизации результатов анализа рисков применяются следующие инструменты:
- Матрица рисков (Heat Map) — двумерная таблица, где по одной оси откладывается вероятность, по другой — ущерб. Каждый риск помещается в соответствующую ячейку, что позволяет визуально выделить наиболее опасные угрозы.
- Системы скоринга — присвоение каждому риску числового балла на основе нескольких параметров (вероятность, ущерб, скорость реализации, детектируемость), позволяющее ранжировать угрозы в единой шкале.
- Реестр рисков — структурированный документ, объединяющий все выявленные угрозы с их оценками, ответственными и статусом работы по ним.
Анализ рисков — это не разовая процедура. По мере развития IT-проекта, изменения инфраструктуры или появления новых угроз оценка должна пересматриваться. Управление рисками в IT-проектах предполагает регулярное обновление данных, а не работу с устаревшей картиной.
Где проходит граница допустимого: Risk Appetite и Risk Capacity
Прежде чем переходить к приоритизации рисков и выбору стратегий реагирования, организации необходимо определить два фундаментальных параметра: Risk Appetite (риск-аппетит) и Risk Capacity (риск-потенциал).
Risk Appetite — риск-аппетит — это уровень риска, который организация осознанно готова принять в процессе достижения своих целей. Это не абстрактная концепция, а вполне конкретный показатель, выраженный в измеримых единицах. Например:
- Компания готова принять финансовые потери от IT-инцидентов в размере не более 2 000 000 рублей в квартал.
- Допустимое время простоя критической системы — не более 4 часов в месяц (SLA 99,4%).
- Максимально допустимое число инцидентов с утечкой данных — ноль (нулевая толерантность к нарушениям 152-ФЗ).
Риск-аппетит определяется на уровне руководства и совета директоров, поскольку отражает стратегические приоритеты и ценности организации. В IT-контексте он задаёт рамки для всех последующих решений по управлению рисками IT-проекта.
Risk Capacity — риск-потенциал — это максимальный уровень риска, который организация объективно способна выдержать без необратимых последствий для своей деятельности. Это верхняя граница, за которой риски становятся экзистенциальными. Риск-потенциал определяется на основе:
- Финансовых резервов и страховых покрытий: если инцидент нанесёт ущерб свыше имеющихся ресурсов на восстановление, компания не сможет оправиться.
- Юридических последствий: некоторые нарушения (например, в сфере КИИ по 187-ФЗ) влекут уголовную ответственность, что является абсолютным ограничителем.
- Репутационных последствий: потеря ключевых клиентов или партнёров может поставить под угрозу само существование бизнеса.
Разрыв между риск-аппетитом и риск-потенциалом формирует «буферную зону» — область, в которой риски требуют особого внимания и активных защитных мер. Риски, превышающие риск-потенциал, недопустимы в принципе и должны быть устранены или переданы (например, через страхование) в первую очередь.
Эти два параметра — обязательная часть системы управления IT-рисками в зрелых организациях. Без их определения приоритизация рисков превращается в субъективное упражнение.
Приоритизация рисков
Когда список выявленных и оценённых угроз сформирован, следующий шаг — расставить приоритеты. В реальных IT-проектах ресурсы всегда ограничены: нельзя одновременно и с одинаковой интенсивностью работать со всеми рисками. Задача приоритизации — направить усилия туда, где они принесут максимальный эффект.
Базовый принцип: риски из «красной зоны» матрицы (высокая вероятность + значительный ущерб) требуют немедленного внимания и активных мер. Это могут быть, например, уязвимости в публично доступных веб-приложениях, отсутствие резервного копирования для критических баз данных или неконтролируемый привилегированный доступ сотрудников.
Вместе с тем приоритизация не должна сводиться только к работе с «красной зоной». Риски с низкой вероятностью, но катастрофическими последствиями (например, полное уничтожение данных вследствие атаки или природной катастрофы) также требуют проработки — даже если их вероятность невелика, потенциальный ущерб делает их критически важными для управления рисками IT-проекта.
Факторы, формирующие итоговую приоритизацию:
- Risk Appetite и Risk Capacity организации — риски, превышающие допустимые пороги, получают наивысший приоритет.
- Влияние на ключевые бизнес-сервисы и стратегические цели — угрозы для систем, обеспечивающих основной доход или клиентский сервис, приоритетнее угроз для вспомогательных процессов.
- Скорость реализации угрозы — риски, способные материализоваться быстро и без предупреждения, требуют более срочного реагирования.
- Стоимость защитных мер — иногда дешевле немедленно устранить риск среднего уровня, чем откладывать работу с ним.
Для формализации приоритизации применяются методы весового ранжирования и экспертной оценки с участием представителей IT, ИБ и бизнеса. Итоговый ранжированный список рисков становится основой для планирования ресурсов и бюджета на управление рисками в IT.
Разработка стратегий реагирования на риски
После того как риски идентифицированы, оценены и расставлены по приоритетам, необходимо определить, что именно с ними делать. В теории и практике управления рисками IT-проекта выделяют четыре базовые стратегии реагирования.
1. Предотвращение (Avoidance)
Полное устранение риска путём отказа от деятельности или технического решения, его порождающего. Например:
- Отказ от использования нестабильного или небезопасного стороннего сервиса в пользу внутреннего решения.
- Исключение из архитектуры проекта компонентов с известными, неустранимыми уязвимостями.
- Отказ от хранения избыточных персональных данных, снижающий риски в контексте 152-ФЗ.
Стратегия предотвращения применяется, когда риск слишком высок, а альтернативные подходы недоступны или нецелесообразны. Её ограничение — возможная потеря функциональности или бизнес-возможностей.
2. Снижение (Mitigation)
Уменьшение вероятности наступления инцидента и/или величины возможного ущерба. Это наиболее распространённая стратегия в управлении рисками в IT-проектах. Примеры:
- Внедрение многофакторной аутентификации для снижения риска компрометации учётных данных.
- Настройка регулярного резервного копирования и тестирование восстановления данных.
- Патч-менеджмент и своевременное обновление программного обеспечения.
- Сегментация сети для ограничения горизонтального распространения атак.
- Обучение сотрудников основам информационной безопасности.
3. Передача (Transfer)
Перенос финансовых последствий риска на третью сторону. В IT-контексте это:
- Страхование киберрисков — рынок таких продуктов в России активно развивается.
- Заключение SLA с облачными провайдерами или подрядчиками, предусматривающих финансовую ответственность за инциденты.
- Аутсорсинг отдельных функций (например, SOC — Security Operations Center) специализированным компаниям.
Важно понимать: передача риска не означает передачу ответственности. Регуляторная ответственность, как правило, остаётся за организацией.
4. Принятие (Acceptance)
Осознанное решение не предпринимать активных мер по отношению к риску — как правило, в случае, когда вероятность и ущерб невелики, а стоимость защитных мер превышает возможные потери. Принятие риска должно быть задокументированным решением, а не следствием бездействия.
Выбор стратегии определяется совокупностью факторов: влиянием на бизнес, критичностью затронутого ресурса, доступными финансовыми и техническими возможностями, а также риск-аппетитом организации. Каждое решение должно быть осознанным, согласованным с руководством и зафиксированным в документации по управлению рисками проекта.
Планирование и реализация плана реагирования
Выбор стратегии — это ещё не действие. Следующий шаг — разработка конкретного плана реагирования на риски, определяющего, кто, что и когда делает для реализации выбранной стратегии.
Качественный план обработки угроз включает:
- Конкретные меры по снижению риска или устранению уязвимости (например: «Настроить блокировку учётной записи после 5 неудачных попыток входа»).
- Сроки выполнения — чёткие даты, а не расплывчатые «в ближайшее время».
- Ответственных лиц — конкретный сотрудник или роль, несущие ответственность за выполнение каждой меры.
- Необходимые ресурсы — бюджет, инструменты, привлекаемые специалисты.
- Критерии успеха — как будет проверено, что мера реализована и эффективна.
В соответствии с ГОСТ Р ИСО/МЭК 27005, план обработки рисков является обязательным документом системы менеджмента информационной безопасности. Его наличие и актуальность проверяются в ходе сертификационных аудитов.
Реализация плана включает два типа мер:
- Превентивные меры — действия, предпринимаемые до наступления инцидента с целью снижения его вероятности или последствий (внедрение технических средств защиты, обучение персонала, изменение бизнес-процессов).
- Корректирующие меры — действия по устранению уже реализовавшихся рисков и их последствий, а также по предотвращению повторения.
Фиксация хода выполнения плана и результатов принятых мер критически важна для последующего контроля. Управление рисками IT-проекта без систематической фиксации данных превращается в набор разрозненных действий без возможности оценить их совокупный эффект.
Мониторинг и корректировка рисков
Реализация плана реагирования — не финальная точка, а очередной этап непрерывного цикла. Управление рисками в IT предполагает постоянное отслеживание двух ключевых вопросов: насколько актуальна угроза сегодня и насколько эффективны принятые меры защиты?
Ландшафт угроз меняется постоянно. Появляются новые уязвимости в программном обеспечении, злоумышленники совершенствуют методы атак, меняется состав IT-систем организации, вводятся новые регуляторные требования. Риск, который год назад был оценён как «средний», сегодня может оказаться критическим — или, напротив, утратить актуальность.
Инструменты мониторинга рисков в IT-проектах:
- SIEM-системы (Security Information and Event Management) — автоматизированный сбор и анализ событий безопасности из множества источников в режиме реального времени. Позволяют оперативно обнаруживать аномалии и потенциальные инциденты.
- DLP-системы (Data Loss Prevention) — контроль перемещения конфиденциальных данных и предотвращение их утечки через различные каналы.
- Журналы инцидентов — систематическая фиксация всех инцидентов, их параметров и результатов реагирования. Служат основой для анализа трендов и совершенствования стратегий.
- Плановые проверки и аудиты — регулярные (например, квартальные или годовые) технические и организационные аудиты, позволяющие оценить текущее состояние защиты.
- Автоматические отчёты из систем мониторинга инфраструктуры, систем управления уязвимостями, антивирусных решений.
Корректировка стратегий управления рисками проводится в двух случаях: по регулярному расписанию (например, ежеквартально или ежегодно) и внепланово — после серьёзных инцидентов, значимых изменений в инфраструктуре или появления новых существенных угроз. Корректировка может включать переоценку уровня рисков, обновление стратегий реагирования, перераспределение ответственности и пересмотр бюджетов на защитные меры.
Управление рисками — это живой, постоянно обновляемый процесс, а не документ, написанный однажды и забытый в папке. Только регулярный мониторинг и готовность к корректировке обеспечивают реальную, а не декларативную защиту IT-проекта.
Документирование и интеграция в процессы
Все решения, принятые в ходе управления рисками IT-проекта, должны быть задокументированы. Это требование не бюрократического характера — документация выполняет функцию управленческого контроля и обеспечивает преемственность знаний.
Ключевые документы системы управления рисками:
- Реестр рисков — актуальный перечень всех выявленных угроз с оценками, приоритетами и статусами.
- План обработки угроз — детализированный перечень мер с ответственными, сроками и ресурсами.
- Матрица ответственности — распределение ролей в процессе управления рисками между подразделениями и конкретными сотрудниками.
- Журнал инцидентов — история всех зафиксированных инцидентов с описанием реагирования и результатов.
- Политика управления рисками — документ верхнего уровня, определяющий принципы, подходы и ответственность в сфере управления IT-рисками.
Документация должна быть актуальной, доступной для всех участников процесса и регулярно пересматриваемой. Хранение всех материалов в едином месте — будь то специализированная GRC-платформа или корпоративная система документооборота — существенно облегчает координацию работы команды, ускоряет реагирование на инциденты и упрощает прохождение регуляторных проверок.
Интеграция управления рисками в повседневные процессы организации означает, что риск-менеджмент становится частью стандартных процедур: запуска новых проектов, изменений в инфраструктуре, найма сотрудников, заключения договоров с подрядчиками. Только при такой интеграции управление рисками в IT-проектах перестаёт быть периодическим упражнением и становится реальным инструментом защиты бизнеса.
Стандарты и нормативы, применимые в России для управления IT-рисками
Эффективное управление рисками в IT-проектах невозможно без опоры на признанные стандарты и соблюдения действующих нормативных требований. В России применяется ряд международных стандартов в их адаптированных версиях, а также специфические национальные нормативные акты.
ГОСТ Р ИСО/МЭК 27001 — адаптированная российская версия международного стандарта ISO/IEC 27001, определяющего требования к системе менеджмента информационной безопасности (СМИБ). Стандарт задаёт общую рамку для построения, внедрения, поддержания и постоянного совершенствования СМИБ. Сертификация по этому стандарту признаётся как свидетельство зрелости системы управления ИТ-рисками.
ГОСТ Р ИСО/МЭК 27005 — стандарт, посвящённый непосредственно менеджменту риска информационной безопасности. Он содержит детальные рекомендации по процессу управления рисками: идентификации, оценке, обработке, принятию, коммуникации и мониторингу. Именно этот стандарт служит методологической основой для практического управления рисками IT-проекта.
ГОСТ Р ИСО 31000 — стандарт по общим принципам и руководству по менеджменту риска, применимый к организациям любого типа и масштаба. Он формирует универсальный язык и подход к управлению рисками, который интегрируется с отраслевыми стандартами.
Требования ФСТЭК России занимают особое место в регулировании IT-рисков для российских организаций. Для объектов критической информационной инфраструктуры (КИИ) — а это банки, энергетика, транспорт, здравоохранение, телекоммуникации и другие стратегические отрасли — обязательны требования Приказа ФСТЭК № 239 «Об утверждении требований по обеспечению безопасности значимых объектов КИИ». Методики ФСТЭК по оценке угроз и построению моделей нарушителей де-факто стали стандартом для государственных информационных систем и КИИ. 187-ФЗ «О безопасности критической информационной инфраструктуры» вводит уголовную ответственность за нарушения в этой сфере, что делает управление рисками в IT для организаций из затронутых отраслей вопросом не только бизнеса, но и личной ответственности руководителей.
Требования ЦБ РФ регулируют управление IT-рисками в финансовом секторе. Положение № 683-П устанавливает обязательные требования к защите информации для кредитных организаций при осуществлении банковской деятельности. Положение № 757-П распространяет аналогичные требования на некредитные финансовые организации. Оба документа содержат конкретные технические и организационные требования к системам защиты информации и управлению инцидентами.
152-ФЗ «О персональных данных» обязывает все организации, обрабатывающие персональные данные граждан России, обеспечивать их защиту и уведомлять регулятора (Роскомнадзор) об инцидентах. Нарушения влекут административную ответственность и репутационный ущерб, а с учётом планируемого ужесточения санкций — и весьма значительные финансовые потери.
Соблюдение этих стандартов и нормативов не только обеспечивает регуляторную чистоту, но и позволяет организациям опираться на проверенные, методологически обоснованные модели управления IT-рисками. Управление ИТ-рисками в соответствии с признанными стандартами — это одновременно защита бизнеса и демонстрация ответственного подхода партнёрам, клиентам и регуляторам.
Практические советы и лучшие практики управления IT-рисками
Устойчивость организации к IT-угрозам формируется не только за счёт технологий. Не менее важны подход к делу, организационная культура и дисциплина в выполнении базовых требований. Ниже — практические рекомендации, применимые независимо от размера компании и отрасли.
Инвестируйте в обучение сотрудников. По статистике, значительная доля успешных кибератак начинается с человеческого фактора — фишинга, случайного раскрытия паролей, ошибок конфигурации. Регулярные тренинги по информационной безопасности, симуляции фишинговых атак и понятные инструкции по действиям при инцидентах существенно снижают этот риск. Управление рисками в IT-проектах начинается с грамотного персонала.
Формируйте культуру осознанного отношения к безопасности. Сотрудники должны понимать, зачем нужны те или иные требования безопасности, а не воспринимать их как бюрократические препятствия. Когда каждый член команды осознаёт свою роль в защите IT-систем, эффективность управления рисками кратно возрастает.
Держите документацию живой и актуальной. Политики безопасности, написанные три года назад и с тех пор не обновлявшиеся, не защищают от актуальных угроз. Особую важность имеет план реагирования на инциденты (Incident Response Plan): он должен быть понятным, доступным и регулярно проверяться в ходе учебных учений. Когда инцидент уже происходит — не время разрабатывать план с нуля.
Придерживайтесь системного подхода. Управление рисками в IT-проектах даёт результат только при условии системности. Разовые аудиты, проводимые раз в год «для галочки», не заменяют непрерывного мониторинга. Встраивайте риск-менеджмент в стандартные процессы: запуск новых проектов, изменения инфраструктуры, онбординг сотрудников.
Избегайте типичных ошибок:
- Неполное выявление рисков — когда в идентификации участвует только IT-отдел, а бизнес-риски и организационные факторы остаются за кадром.
- Отсутствие обмена информацией — когда данные об инцидентах и угрозах не передаются между подразделениями, и каждый «решает свои проблемы».
- Формальная оценка — когда матрица рисков заполняется ради отчётности, а не реального анализа.
- Игнорирование маловероятных, но катастрофических угроз — низкая вероятность не означает низкий приоритет, если последствия могут быть необратимыми.
- Отсутствие тестирования защитных мер — резервное копирование, которое никогда не проверялось на восстановление, может оказаться нерабочим в критический момент.
Используйте доступные инструменты и отечественные решения. Рынок российских решений для управления IT-рисками активно развивается: SIEM-системы (MaxPatrol SIEM от Positive Technologies, RuSIEM), DLP-решения (InfoWatch, SearchInform), GRC-платформы, сканеры уязвимостей. Многие базовые практики управления рисками — ведение реестра угроз, регулярные аудиты, обучение персонала — не требуют значительных бюджетов. Они требуют внимания, дисциплины и регулярности.
Привлекайте внешних экспертов там, где это оправданно. Для проведения тестирования на проникновение, независимого аудита или разработки модели угроз иногда целесообразно привлечь специализированные компании: их свежий взгляд и накопленная экспертиза позволяют выявить уязвимости, которые внутренняя команда могла не заметить.
Лучшие практики управления рисками IT-проекта — это не набор дорогостоящих технологий. Это прежде всего культура, дисциплина и понимание того, что инвестиции в управление рисками сегодня — это предотвращённые потери завтра.
Итоги и заключение: Управление рисками IT-проекта как непрерывный процесс
Управление рисками IT-проекта — это не разовая задача и не формальность перед запуском системы. Это ежедневная, непрерывная часть работы любой организации, которая всерьёз рассчитывает на устойчивость в условиях современных вызовов. Статья охватила ключевые аспекты этой дисциплины: от классификации угроз и методов их оценки до конкретных стратегий реагирования и применимых в России стандартов.
Главный вывод, который необходимо сделать: IT-риски — это бизнес-риски. Сбой в информационной системе, утечка данных или задержка IT-проекта не остаются в технической плоскости — они немедленно отражаются на финансовых результатах, репутации и конкурентоспособности компании. Управление рисками в IT-проектах — это управление устойчивостью бизнеса.
Эффективная система управления рисками в IT-проектах строится на нескольких принципах:
- Системность — риск-менеджмент встроен в процессы, а не существует параллельно с ними.
- Непрерывность — угрозы меняются, и оценка рисков должна меняться вместе с ними.
- Командная работа — управление рисками проекта — это не функция одного подразделения, а совместная ответственность IT, ИБ и бизнеса.
- Приоритизация — ресурсы направляются на наиболее критические угрозы, а не распыляются равномерно.
- Внутренняя культура — сотрудники понимают и разделяют ответственность за безопасность.
Отечественный рынок предоставляет достаточный инструментарий для построения зрелой системы управления ИТ-рисками: от SIEM и DLP-решений до GRC-платформ и специализированных консалтинговых услуг. Нормативная база — ГОСТ, требования ФСТЭК и ЦБ РФ — задаёт чёткие ориентиры для организаций, работающих в регулируемых отраслях.
Управление рисками IT-проекта, выстроенное как живой, постоянно обновляемый процесс, — это не статья расходов, а стратегическая инвестиция в будущее компании. Организации, которые это понимают и действуют соответственно, значительно лучше справляются с кризисными ситуациями, быстрее восстанавливаются после инцидентов и сохраняют доверие клиентов и партнёров даже в самых сложных обстоятельствах.
 Источники и литература

1. ГОСТ Р ИСО/МЭК 27001 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования».
2. ГОСТ Р ИСО/МЭК 27005 «Информационная технология. Методы и средства обеспечения безопасности. Менеджмент риска информационной безопасности».
3. ГОСТ Р ИСО 31000 «Менеджмент риска. Принципы и руководство».
4. Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных».
5. Федеральный закон от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации».
6. Приказ ФСТЭК России № 239 «Об утверждении требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации».
7. Положение Банка России от 17.04.2019 № 683-П «Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента».
8. Положение Банка России от 11.01.2021 № 757-П «Об установлении обязательных для некредитных финансовых организаций требований к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков в целях противодействия осуществлению переводов денежных средств без согласия клиента».
9. PMBOK (Project Management Body of Knowledge) Guide — свод знаний по управлению проектами, применимый к общим принципам управления проектами и рисками.
10. Аналитические материалы и методические рекомендации российских компаний в сфере информационной безопасности: BI.ZONE, Solar (бывший «Ростелеком-Солар»), Positive Technologies, InfoWatch.
Часто задаваемые вопросы
Начните с трёх базовых шагов: составьте простой реестр рисков в таблице (Excel или Google Sheets), внедрите бесплатные или недорогие защитные меры — двухфакторную аутентификацию, регулярное резервное копирование, обновление ПО — и проведите короткий инструктаж сотрудников по фишингу. Большинство критических инцидентов в малом бизнесе предотвращается именно этими базовыми мерами, не требующими серьёзных вложений.
Реализованнные проекты по управлению ИТ проектами
SITA/Аэрофлот — Организация услуги "Сервис управляемого рабочего места"
Обеспечены сервисы по поддержке пользователей и инфраструктуры, поставке оборудования, управлению подменным фондом
30 складов в РФ
8 складов в Европе
Аудит Wi-Fi сети и техническая поддержка офисов для AMWAY
Провели обследование Wi-Fi сети с использованием Ekahau: выявили зоны слабого сигнала и помехи, предложили рекомендации по оптимизации покрытия
Соблюдение SLA
ABB — ИТ-поддержка офисов в 7 странах
Оказываем сервис поддержки офисов ABB в России, Казахстане, Азербайджане, Узбекистане, Эстонии, Латвии и Литве
onsite сопровождение
Читайте также в нашем блоге
Связанные услуги