Оценка рисков в ИТ: от схемы данных до точек решений

Риск-менеджмент в ИТ становится всё более комплексным процессом, выходящим за рамки механического составления риск-матриц. Для российского рынка эти процессы регулируются не только стандартными подходами к оценке угроз, но и требованиями законодательства — например, Федерального закона №152-ФЗ «О персональных данных» и приказами ФСТЭК. Тем не менее, на практике такие оценочные процедуры часто остаются формальными: составляются ради отчётности, а не трансформации процессов, и в результате реальные ИБ-риски остаются неуправляемыми. Современный подход требует перехода от абстрактных формул к практической детализации процессов, интеграции оценки в бизнес-деятельность и внедрения культуры системного пересмотра рисков.

Переосмысление роли матрицы риска

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

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

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

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

Визуализация схемы обработки данных

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

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

Пути поступления данных: Графически выделяйте каналы взаимодействия — внешние клиентские интерфейсы, b2b API, внутренние корпоративные интеграции. Корректная фиксация всех путей — залог полноты анализа, особенно для облачных архитектур и микросервисов.
Механизмы верификации и промежуточной обработки: Здесь важно не только обозначить наличие контролей, но и их тип — ручные, полуавтоматические, полностью автоматизированные. Ошибки на этом этапе чреваты рассинхронизацией статусов и попаданием “грязных” данных на следующий уровень.
Точки бизнес-решений: Обычно на схемах прослеживаются развилки маршрутизации данных — здесь система или сотрудник принимают решение о дальнейших действиях (например, одобрение, отклонение, передача на дополнительную проверку).
Хранение и архивирование: На схеме важно разделять оперативное и долгосрочное хранение. Чаще всего именно на долгосрочных архивах появляются “серые зоны” слабого контроля, где могут накапливаться забытые или несвоевременно удалённые сведения.

Схема жизненного цикла данных помогает не только формализовать процессы, но и наглядно определить “хрупкие” места, где сбой или ошибка могут привести к наиболее опасным последствиям.

[ИЗОБРАЖЕНИЕ: пример схемы обработки данных с выделенными ключевыми точками принятия решений]

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

Идентификация точек принятия решений

Ошибки в логике обработки данных редко происходят “случайно”. Как правило, они — следствие неточного или нечеткого определения ролей и точек, где решение о судьбе данных принимает система или конкретный сотрудник. В этих точках зачастую наблюдается недостаток автоматизации контроля или противоречие в процедурах, что приводит к появлению уязвимых сценариев.

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

Проверка корректности и полноты данных на этапе ввода;
Выбор способов передачи информации между отделами — например, во внутреннюю CRM или на e-mail;
Расстановка приоритетов для передачи в очереди обработки (например, персональные данные vs. рабочие документы);
Запуск процедур удаления данных — ручной или автоматизированный запуск становится точкой риска, если возможен отказ от выполнения процедуры либо её намеренный обход.

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

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

Выделение рисков на схеме

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

Пример анализа рисков для конкретной схемы:

Узел / этап	Точка решения	Характерный риск
Сбор данных	Автоматическая классификация	Ошибочная категория — нарушение политики обработки данных
Обработка между отделами	Выбор способа передачи	Передача по открытым каналам — риск утечки
Архивное хранение	Определение срока хранения	Хранение дольше срока — риск несанкционированного доступа
Удаление данных	Ручной запуск процедуры	Несвоевременное или некорректное удаление — риск инцидента и штрафов
Передача во внешний сервис	Оценка уровня доверия	Отсутствие SLA по безопасности — риск разглашения или модификации данных

Для каждого риска фиксируются:

источник возникновения;
условия, при которых он актуализируется (например, ручной ввод без двойной проверки, отсутствие журнала операций);
механизмы отслеживания и реагирования;
пример потенциального влияния — от замедления процесса до разбирательства с регулятором.

Чем детальнее карта сценариев, тем проще соотносить реальные события с ожидаемыми и строить предикативные модели в дальнейшем.

Оценка вероятности и тяжести последствий

Механистические модели (формулы, автоматические подсчёты) подходят для вычисления рисков только при полной и достоверной статистике. В реальных ИТ-процессах, особенно связанных с персональными данными и уникальными бизнес-логиками, на первый план выходит качественная, основанная на знаниях экспертов и анализе инцидентов, оценка.

Вероятность: не просто “частота”, а оценка того, насколько контрольные механизмы эффективно минимизируют возникновение инцидента. Например, инцидент может быть “редким” в отрасли, но из-за специфики архитектуры системы — быть “потенциально частым” в конкретной компании.
Последствия: рассматриваются не только тяжащие юридически (штраф, судебные иски), но и операционно: простои, дополнительная нагрузка на технические департаменты, негатив в публичном поле.
Категории: часто используются градации “низкий / средний / высокий” с детализацией для специфики отрасли. Например, “высокий риск” — это шанс блокировки бизнес-процессов или потеря больших объёмов клиентских данных.

Обоснование присвоения категории всегда должно документироваться — этого требует и регулятор (ФСТЭК, Роскомнадзор), и внутренний аудит. Чёткая система аргументации автоматически выводит компанию на прозрачный уровень управления.

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

[ИЗОБРАЖЕНИЕ: карта рисков с распределением вероятностей и тяжести последствий для разных этапов обработки данных]

Регуляторные требования: 152-ФЗ и ФСТЭК

Закон №152-ФЗ предъявляет к компаниям чёткие требования по защите персональных данных, а регулятор ФСТЭК детализирует состав организационных и технических мер. Оценка рисков — неотъемлемый элемент как проекта построения системы защиты, так и её последующего аудита. Качественно выполненная оценка служит доказательством добросовестного отношения к безопасности и снижает вероятность применения санкций со стороны государства.

Наличие актуальной схемы обработки данных обязательно проверяется на любом выездном или камеральном аудите. Расхождение схемы и реальных ИТ-систем становится основанием для предписания.
Связь между точками риска, процессами и применяемыми мерами защиты — основной критерий “реальности” оценочного процесса. Формальные, оторванные от инфраструктуры и бизнес-задач сценарии отбраковываются как имитация выполнения требований.
Разработка технических мер должна быть аргументирована не только нормативом, но и наличием соответствующего зарегистрированного риска. Такая трассировка напрямую влияет на качество и “прозрачность” проекта.
Внедрение результатов оценки должно подтверждаться деталями — всё, что не фиксируется в процессах, считается “мерой на бумаге” и не засчитывается регулятором.

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

Также важно проводить внутреннюю сверку: любые новые изменения в обработке персональных данных (внедрение BI-аналитики, подключение внешних сервисов) должны автоматически сопровождаться обновлением схем и перечня рисков: регуляторы высоко ценят такие механизмы внутреннего контроля.

План управления: реагирование и снижение рисков

Оценка без внедрения мер — просто “балласт” в документации. Качественный план управления строится по принципу приоритетности: сначала устраняются/контролируются те инциденты, которые могут привести к простоям бизнеса или серьёзным санкциям. Для этого:

Технические меры:
- внедрение современных средств шифрования;
- разделение сред доступа для разных групп пользователей;
- отказ от устаревших протоколов передачи данных;
- автоматизация аудита действий в уязвимых точках;
- интеграция DLP-систем на этапах межотделочных обменов.
Организационные меры:
- выделение отдельных сотрудников, ответственных за оценку и пересмотр рисков;
- обязательные ручные согласования для нестандартных случаев;
- регулярное обновление инструкций, закрепление ответственности письменно и в ITSM-системах;
- обучение сотрудников особенностям рисков именно для их процессов.
Контрольные меры:
- разработка регламентов регулярной проверки схемы обработки;
- периодические тесты (вплоть до “тайных покупок” и инцидент-дриллов на практике);
- ведение заданного объёма журнальных событий для форензики;
- организация независимого аудита уязвимостей и мер реагирования.

План реален, только если каждое действие привязано к сроку, ответственному, методу обратной связи (метрики, контрольные “точки”). Крайне желательно использовать цифровые способы отслеживания выполнения мер — от чек-листов до автоматизации в сервис-десках. Это ускоряет прохождение проверок и существенно снижает нагрузку на ИБ-департамент при подготовке к аудиту.

Встраивание оценки в долгосрочные процессы

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

Организация процесса “живого” обновления схем (например, через регулярные ревью с ИТ и бизнесом);
Выделение регулярных контрольных точек при релизах новых функций — обязательная сверка рисков и внедрение процедур “быстрого реагирования” в случае выявления отклонений от процессов;
Автоматизация ведения базы рисков, использование специализированных решений GRC-класса для отслеживания изменений, сценарного анализа и построения историй реагирования (case-management);
Отдельное внедрение процедур мониторинга регуляторных изменений с последующей переоценкой рисков.

Таким образом, компания начинает воспринимать риски не как “страшную бумагу для аудитора”, а как ежемесячно обновляемую практическую карту, в которой всегда видно, где появились новые угрозы, есть ли устаревшие точки или непринятые решения.

[ИЗОБРАЖЕНИЕ: процессный цикл управления ИБ-рисками в компании]

Типичные ошибки и способы их избежать

Оценка формируется “для отчёта”, без проведения интервью и анализа реальных маршрутов движения информации. Избежать поможет организованная серия воркшопов с вовлечением исполнителей процессов, разработчиков и представителей юридического блока.
Точки принятия решений определяются номинально, без учёта специфики бизнес-процессов. Рекомендуется проводить кросс-функциональные ревью схем с обязательным “разбором полётов” типовых инцидентов и аномалий.
Последующий пересмотр рисков не проводится, даже если ИТ-системы и логика работы меняются каждый квартал. Для решения необходим формализованный регламент “инициирования пересмотра” при каждом крупном изменении архитектуры (реализация через Change Control Board).
Мероприятия привязываются к процессу формально, без выделения бюджета, контроля исполнения и обратной связи. Лучшей практикой является внедрение единого трекинга рисков на уровне бизнес-целей, включение их в KPI бизнес-подразделений и сквозной автоматизированный мониторинг выполнения мер.
Отсутствие обратной связи — когда никто не анализирует итоги внедрённых мер и не смотрит на новые сценарии появления угроз. Рекомендуется строить “петли обратной связи” через внутренние аудит-функции и регулярные аналитические сессии с вовлечением смежных отделов.

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

Пошаговый подход к риск-менеджменту в ИТ

Системность — единственный разумный путь для крупной и даже средней организации. Ниже — обобщённая последовательность шагов, которая позволяет внедрить процесс и поддерживать его эффективность на всём жизненном цикле ИТ-систем:

Построить наглядную визуальную схему процессов обработки и передачи данных: от поступления до удаления, с детализацией по ответственным лицам и автоматизированным системам;
Определить узлы, где принимаются ключевые решения — руками сотрудников или в автоматическом режиме. Для этого нужно провести диагностику маршрутов и четко закрепить “точки входа” и “точки выхода” информации;
Для каждой точки выявить возможные риски, не только по классическим моделям (несанкционированный доступ, удаление, подмена), но и по специфике бизнеса (ошибочные перемещения, двойная обработка, переработка без согласия);
Оценить их вероятность возникновения и тяжесть последствий, присвоить категорию приоритетности, обосновать критерии оценки с помощью анализа кейсов и экспертных опросов;
Сформировать для “красных зон” детальный и реализуемый план по устранению рисков, назначить ответственных, прописать контрольные точки и критерии успешности. Убедиться, что для каждого риска есть документированное решение — техническое или организационное;
Встроить процесс оценки и пересмотра рисков в регулярные (ежеквартальные/ежегодные) циклы управления изменениями, релизов ИТ-систем, организационные метрики и аудит;
Проводить внедрение и обновление мер только после реальной проверки на практике — на тестовом окружении, с последующим внесением необходимых корректировок, и с использованием обратной связи от пользователей.

Компании, включающие реальную оценку рисков и последовательное построение “карты решений”, выигрывают не только в части нормативного соответствия 152-ФЗ и стандартам ФСТЭК, но и достигают прозрачности процессов, укрепления защиты данных и снижения потерь от инцидентов. Такой подход способствует формированию единой культуры информационной безопасности и уверенности в управляемости инфраструктуры независимо от роста и изменений бизнеса.