Меня периодически спрашивают: «Как начать процесс управления рисками?» И всякий раз после паузы я ловлю себя на мысли, что мой ответ будет не про то, как начать, а про то, почему большинство компаний останавливается, даже толком не запустившись.
За годы работы с организациями разного уровня — от небольших финансовых структур до крупных промышленных холдингов — я убедился: главная проблема риск-менеджмента не в методологиях и не в математике. Главная проблема — в ручном подходе. Он в любом случае всё сломает. Вопрос лишь во времени.
Когда риски становятся невидимыми
Если спросить любую службу ИБ, откуда они начинают управление рисками, ответ, как правило, одинаков: с Excel. Это вполне логично — таблица под рукой, структура простая, идея понятная. Но дальше происходит неизбежное: мир бизнеса меняется быстрее, чем таблица.
Инфраструктура развивается, появляются новые сервисы, изменяются процессы, появляются новые угрозы. А таблица остаётся прежней. Через неделю она перестаёт быть актуальной. Ещё через месяц полностью теряет смысл. Ну, а потом в ней уже никто не может разобраться.
Именно здесь возникают «невидимые зоны». Компания может считать, что она контролирует риски, пока внезапно не сталкивается с реальным инцидентом. Тогда выясняется, что многое прошло через решето в ручном управлении.
Парадоксально, но факт: даже до Excel доходит только 15–20% служб безопасности. Остальные бросают идею ещё на старте, столкнувшись с объёмом ручной работы и отсутствием структуры.

Два пути — и оба тяжелы вручную
В риск-менеджменте есть два базовых подхода. Первый — снизу вверх, от инфраструктуры и технических активов. Второй — сверху вниз, от бизнес-процессов и недопустимых событий.
Первый требует детального описания уязвимостей, угроз и зависимостей. Например, нужно понимать, какие сервисы критичны, где хранятся персональные данные, какие сегменты сети связаны между собой. Уже на этом этапе становится ясно: у крупных компаний — десятки систем, сотни серверов, тысячи прав доступа. Всё это нужно описать, связать, обновлять.
Второй подход логичен для зрелых организаций: начинаем с вопроса, какие события компания не может допустить. Остановка процессинга, компрометация клиентских данных, потеря транзакционного сервиса. Но чтобы дойти от этих событий до конкретных уязвимостей, нужно собрать десятки интервью, согласовать модель оценки, увязать риски с ИТ-ландшафтом и бизнес-процессами. И повторять это регулярно.
Оба пути верные — и оба нереалистичны при ручном исполнении.
Типичные ошибки ручного риск-менеджмента
Здесь важно сказать честно: проблема не в людях. Люди умные, мотивированные, часто высококвалифицированные. Проблема — в ограничениях ручных инструментов. Самые частые сценарии выглядят так:
Служба ИБ садится и пытается описать все технические риски «с нуля». Через несколько дней становится ясно: их слишком много, и они постоянно обновляются.
Потом команда решает пойти сверху вниз и поговорить с бизнесом. Но без методологии и шаблонов эти интервью превращаются в размытую фантазию о гипотетических угрозах.
В какой-то момент появляется понимание, что процесс должен быть непрерывным. Но Excel не умеет динамически отражать изменения. Таблица превращается в кладбище забытых рисков.
А иногда случается ещё хуже: компания пытается сразу внедрить сложную модель оценки, математические формулы, матрицы вероятности и ущерба. Это похвально, но на первых шагах приводит к перегрузке и отказу от идеи.
И еще один важный момент. Многие начинают вести риски в вакууме, отдельно от остальной работы службы ИБ. Внедряется защита, настраивается процесс, закупается решение, но нигде не фиксируется, что это действие закрывает конкретный риск. В итоге учёт рисков живёт сам по себе, а практическая работа — сама по себе. Это удваивает трудозатраты и убивает мотивацию.

Где ломается логика Excel
Excel — замечательный инструмент, но он не предназначен для динамических систем. В нём нет нормализованных связей между активами, угрозами, мероприятиями и инцидентами. Когда компания ведёт риски вручную, они начинают дублироваться, пересекаться, терять контекст.
Один и тот же риск может фигурировать под разными названиями — «утечка данных», «компрометация персональной информации», «доступ третьих лиц». Формально это три разных записи, фактически повторяющиеся элементы.
Второй типичный сбой — отсутствие актуализации. Вручную никто не обновляет связи между активами, не фиксирует изменения прав или установку новых защитных мер. В результате при проверке выясняется, что часть информации устарела на квартал.
И третий момент — риск-аппетит. Вручную компании часто не устанавливают границы допустимого риска, пытаясь обработать всё подряд. Это приводит к распылению ресурсов. Классический пример — резервные копии. Если восстановление занимает 15 минут и бизнес не страдает, это допустимо. Но если речь о банке, где каждая минута простоя оборачивается в потерянные деньги, приоритет должен быть совсем другим.
Ручной подход редко учитывает такие нюансы.
Когда ручное управление убивает контекст
Главная беда ручного подхода — изоляция. Риски часто ведутся отдельно от остальной работы службы ИБ. Внедряются меры защиты, настраиваются системы мониторинга, обновляются политики, но нигде не фиксируется, какие конкретные риски эти действия закрывают.
В итоге процесс управления рисками живёт сам по себе, а операционная работа — сама по себе. Вся логика разрывается: невозможно связать инцидент с риском, риск с активом, актив с бизнес-процессом. На практике это получается отсутствие управляемости.
Добавьте сюда дублирование данных и человеческий фактор, и вы получите систему, где каждое изменение оборачивается часами сверок, перепроверок и пересылок писем.
Почему нужна динамика
Риск — живая сущность. Он меняется вместе с инфраструктурой, людьми и бизнесом. Появился новый подрядчик — вырос риск нарушения требований 152-ФЗ. Вышло обновление ОС — изменилась уязвимость. Увеличился объём данных в хранилище — изменился уровень воздействия.
Регулярная оценка даёт лишь срез момента, но не отражает реальное состояние. Чтобы управлять рисками эффективно, нужна непрерывная динамика. Изменения должны фиксироваться автоматически, связи между объектами обновляются, а метрики реагируют в реальном времени.
В SECURITM мы как раз строим систему именно на этом принципе. Модуль управления рисками связан с каталогом активов, угроз, мер защиты и метрик зрелости. Каждое изменение в одном из элементов автоматически отражается на уровне риска.
Если в системе появился новый сервер, то он сразу включается в контур оценки. Если внедрено новое средство защиты — риск снижается. Если в отчётах VM-модуля (управления уязвимостями) появились критичные проблемы, уровень риска повышается.
Эта связность позволяет не просто фиксировать риски, а управлять ими в реальном времени


Что показала практика
Один из наших клиентов пришёл с задачей за неделю выстроить процесс управления рисками, собрать реестр, сформировать годовой план и защитить его перед руководством.
Без готовой базы рисков и защитных мер это было бы невозможно. Но за счёт автоматизации, шаблонов и встроенных методик процесс заработал. Руководство увидело, как мероприятия ИБ связаны с конкретными рисками, и утвердило бюджет.
Это важный момент. Риск — это язык общения с бизнесом. Он позволяет безопаснику не просто просить средства на новые меры защиты, а обосновывать необходимость, показывая, какие именно угрозы уменьшаются и насколько.
Ручное управление рисками — это как вести бухгалтерию на бумаге. Вроде бы можно. Но только до первого серьёзного изменения или аудита.
Современный риск-менеджмент — живой, динамичный процесс, встроенный в ежедневную работу службы ИБ, связанный с инфраструктурой, метриками и мероприятиями, и говорящий с бизнесом на одном языке.
Автоматизация не заменяет человека, но освобождает его от рутины. Служба ИБ перестаёт тратить время на поддержание таблиц и начинает заниматься анализом и прогнозом.
Начинать нужно не с огромных матриц, а с простого, но структурированного подхода. С готовых баз, с понятных формулировок, с механизма сбора информации от бизнеса. А дальше постепенно усложнять модель. Главное — не пытаться делать это вручную. Мир меняется слишком быстро.