Инцидент ИБ: что это, чем отличается от события и как им управлять

Инцидент информационной безопасности — одно или несколько событий ИБ, которые с высокой вероятностью приведут к нарушению конфиденциальности, целостности или доступности информации и нанесут ущерб организации. Событие становится инцидентом в момент квалификации ответственным сотрудником, а не в момент срабатывания датчика. Для субъектов КИИ понятие задано законом: пункт 5 статьи 2 Федерального закона № 187-ФЗ определяет компьютерный инцидент через факт нарушения функционирования объекта КИИ или безопасности обрабатываемой им информации.

Управление инцидентами информационной безопасности — процесс, от зрелости которого зависит, обойдётся ли кибератака организации в часы простоя или в миллионы рублей ущерба. По данным Positive Technologies, в 2025 году среднее время обнаружения компрометации в российских компаниях составило 37 дней, а средний ущерб от одного критического инцидента достиг 27 млн рублей. При этом организации с выстроенным процессом управления инцидентами сокращали время обнаружения до 2–4 часов и ущерб — в 5–8 раз.

В этой статье разберём полный цикл управления инцидентами ИБ: от подготовки и обнаружения до расследования и извлечения уроков. Привяжем каждый этап к стандартам ISO 27035, NIST SP 800-61, требованиям ГосСОПКА и российской нормативной базе. Покажем, как автоматизировать процесс через SGRC.

Что такое инцидент информационной безопасности

Определение: событие vs инцидент

Стандарт ISO 27000 разделяет два понятия:

• Событие ИБ (security event) — любое наблюдаемое явление в информационной системе, которое может иметь отношение к безопасности. Пример: неудачная попытка входа в систему, срабатывание правила МЭ, подключение USB-носителя.
• Инцидент ИБ (security incident) — одно или несколько событий ИБ, которые с высокой вероятностью приведут к нарушению конфиденциальности, целостности или доступности информации и нанесут ущерб организации.

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

Определение в законе: компьютерный инцидент по 187-ФЗ

Для субъектов КИИ определение задано законом, а не стандартом. Статья 2 Федерального закона № 187-ФЗ:

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

Там же закон определяет компьютерную атаку: целенаправленное воздействие программных и (или) программно-аппаратных средств на объекты КИИ в целях нарушения их функционирования или создания угрозы безопасности информации. Разница практическая. Атака может не перерасти в инцидент, если сработали меры защиты. Инцидент может случиться без атаки: из-за сбоя оборудования или ошибки администратора. Информировать НКЦКИ нужно и об атаке, и об инциденте, сроки различаются (см. раздел о регуляторах).

Какое событие классифицируется как инцидент: критерии и кто решает

Событие становится инцидентом в момент квалификации, а не в момент срабатывания датчика. Квалифицирует его сотрудник, назначенный регламентом: дежурный аналитик SOC, администратор ИБ или ответственный за защиту информации. Он сверяет событие с критериями из политики управления инцидентами.

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

Решение о квалификации фиксируется в журнале с указанием, кто и когда его принял. Для субъекта КИИ с момента обнаружения идёт отсчёт срока информирования НКЦКИ, для оператора ПДн при утечке отсчёт 24 часов по статье 21 152-ФЗ.

Типы инцидентов: классификация по вектору атаки

Как выявить инцидент ИБ: признаки, которые нельзя пропускать

Большинство инцидентов проявляется косвенно. Признаки, которые в регламенте стоит закрепить как повод для обязательной проверки:

• вход под учётной записью в нерабочее время, с нового устройства или из другой страны;
• всплеск исходящего трафика с сервера, который обычно только принимает запросы;
• массовое переименование файлов на файловом сервере, появление файлов с требованием выкупа;
• новые учётные записи с правами администратора, изменение состава привилегированных групп;
• остановка антивируса, EDR или агента мониторинга сразу на нескольких машинах;
• письмо от «руководителя» с просьбой срочно оплатить счёт или сменить реквизиты;
• уведомление от НКЦКИ, банка или контрагента, появление данных компании на теневых площадках.

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

Статистика инцидентов ИБ в России

По данным НКЦКИ, в 2025 году зафиксировано более 200 000 компьютерных инцидентов на объектах КИИ. По данным Роскомнадзора, число утечек персональных данных превысило 700 случаев. Отраслевая структура инцидентов: госсектор (24%), финансы (18%), промышленность (15%), здравоохранение (12%), образование (9%), остальные (22%).

Ransomware остаётся главной угрозой. В 2025 году средний размер выкупа за расшифровку данных в России достиг 10 млн рублей, а время восстановления после атаки без резервных копий — от 14 до 30 дней.

Что делать при инциденте ИБ: первые 24 часа

Порядок действий на случай, когда регламента ещё нет, а инцидент уже есть. Часы считаются от момента обнаружения.

1. Первые 15 минут. Изолировать затронутый узел от сети: отключить кабель или перевести порт коммутатора в изолированный VLAN. Питание не выключать. Сменить пароль скомпрометированной учётной записи и завершить её сеансы.
2. До 1 часа. Назначить координатора и завести запись в журнале инцидентов: время обнаружения, кто обнаружил, затронутые активы, предварительный приоритет. Уведомить руководителя ИБ и владельца системы.
3. До 3 часов. Субъект КИИ при инциденте на значимом объекте направляет сведения в НКЦКИ (приказ ФСБ № 547). Снять образ оперативной памяти, сохранить логи SIEM, EDR, межсетевого экрана и прокси за период инцидента до того, как их перезапишет ротация.
4. До 8 часов. Определить вектор: фишинг, уязвимость, украденный пароль, доступ подрядчика. Проверить соседние узлы на те же индикаторы. Выбрать долгосрочное сдерживание: усиленный мониторинг сегмента, временные правила межсетевого экрана, принудительная смена паролей.
5. До 24 часов. Иные объекты КИИ: сведения в НКЦКИ. Оператор ПДн при утечке: уведомление Роскомнадзора по части 3.1 статьи 21 152-ФЗ. Первая сводка для руководства: что известно, что сделано, что дальше.
6. До 72 часов. Оператор ПДн направляет в Роскомнадзор результаты внутреннего расследования. Восстановление начинается только после закрытия вектора.

📋 Первые сутки как список задач с дедлайнами В КиберОснова каждый пункт заводится как задача с ответственным и сроком в модуле «Задачи ИБ», а затронутые узлы подтягиваются из реестра активов вместе с владельцами и связями. SIEM это не заменяет, зато снимает вопрос «кто и что должен сделать к третьему часу».

Стандарты и фреймворки управления инцидентами

ISO/IEC 27035: международный стандарт

ISO 27035:2023 — основной международный стандарт управления инцидентами ИБ. Состоит из трёх частей:

• Часть 1: Принципы — терминология, общая модель, взаимосвязь с другими процессами СУИБ.
• Часть 2: Планирование и подготовка — политика управления инцидентами, создание команды реагирования, разработка процедур.
• Часть 3: Операции — обнаружение, оценка, реагирование, извлечение уроков.

ISO 27035 определяет пять фаз: планирование и подготовка, обнаружение и оповещение, оценка и принятие решения, реагирование, извлечение уроков.

NIST SP 800-61: фреймворк реагирования

NIST SP 800-61 Rev. 2 (Computer Security Incident Handling Guide) — практическое руководство, широко используемое как в США, так и в международной практике. NIST определяет четыре фазы:

1. Preparation — подготовка: политика, команда, инструменты, обучение.
2. Detection & Analysis — обнаружение и анализ: источники данных, индикаторы, приоритизация.
3. Containment, Eradication & Recovery — сдерживание, устранение, восстановление.
4. Post-Incident Activity — деятельность после инцидента: lessons learned, метрики.

Требования ФСБ: ГосСОПКА, приказы № 547 и № 367

Субъекты КИИ обязаны взаимодействовать с ГосСОПКА (Государственная система обнаружения, предупреждения и ликвидации последствий компьютерных атак) и информировать НКЦКИ о компьютерных инцидентах. Порядок информирования установлен приказом ФСБ России № 547 от 25.12.2025 (действует с 30.01.2026, заменил приказ № 282), состав сведений — перечнем по приказу № 367 от 24.07.2018:

• значимый объект КИИ: сведения о компьютерном инциденте направляются в НКЦКИ не позднее 3 часов с момента обнаружения;
• иные объекты КИИ и информационные ресурсы органов (организаций): не позднее 24 часов;
• сведения о компьютерной атаке на объект КИИ: не позднее 24 часов с момента обнаружения атаки;
• канал передачи: техническая инфраструктура НКЦКИ, при её недоступности почтовая или электронная связь по адресам НКЦКИ (п. 2 приказа № 547).

С 1 сентября 2026 года обязанность взаимодействовать с ГосСОПКА распространена на операторов ГИС и иных информационных систем государственных органов, ГУП и госучреждений (Федеральный закон № 568-ФЗ от 29.12.2025, приказ ФСБ № 297 от 06.08.2026): они информируют ФСБ о компьютерных инцидентах, повлёкших неправомерную передачу содержащейся в системах информации.

Сравнительная таблица стандартов

Этап 1. Подготовка к управлению инцидентами

Создание команды реагирования (CSIRT)

CSIRT (Computer Security Incident Response Team) — команда, ответственная за координацию реагирования на инциденты. Состав зависит от размера организации:

Выделенная CSIRT (для крупных организаций, субъектов КИИ):

• Руководитель CSIRT — координация, принятие решений, эскалация.
• Аналитики ИБ — обнаружение, классификация, расследование.
• Инженеры ИБ — сдерживание, устранение, восстановление.
• Форензик-специалист — сбор и анализ цифровых доказательств.
• Юрист — правовые аспекты, взаимодействие с регуляторами.
• PR-специалист — коммуникации при публичных инцидентах.

Виртуальная CSIRT (для средних организаций): сотрудники разных подразделений, привлекаемые по заранее определённым ролям при возникновении инцидента.

Разработка политики управления инцидентами

Политика определяет:

• Что считается инцидентом в данной организации (критерии квалификации).
• Роли и ответственности участников процесса.
• Порядок эскалации по уровням критичности.
• Требования к документированию и хранению информации об инцидентах.
• Обязательства по уведомлению регуляторов (НКЦКИ, Роскомнадзор, ФинЦЕРТ).

Playbook: сценарии реагирования

Playbook — пошаговый сценарий реагирования на конкретный тип инцидента. Наличие playbook сокращает время реагирования в 3–5 раз, поскольку устраняет необходимость принимать решения в стрессовой ситуации.

Пример playbook: заражение ransomware

1. Сдерживание (немедленно): Изолировать заражённый хост от сети. НЕ выключать питание — это уничтожит ключи расшифровки в оперативной памяти.
2. Оповещение: Уведомить CSIRT, CISO. Для субъектов КИИ — запустить процедуру уведомления НКЦКИ.
3. Оценка масштаба: Определить количество заражённых хостов, тип шифровальщика, затронутые данные.
4. Сбор доказательств: Образ оперативной памяти (Volatility), логи EDR/SIEM, сетевые соединения.
5. Устранение: Идентифицировать и устранить вектор заражения (фишинг, уязвимость, RDP) до восстановления.
6. Восстановление: Восстановить данные из резервных копий, проверить целостность.
7. Post-Incident Review: Разбор, обновление мер защиты, дообучение персонала.

Инструменты обнаружения

Обнаружение инцидентов обеспечивается комплексом инструментов:

• SIEM — сбор, нормализация и корреляция событий из различных источников. Обнаружение аномалий по правилам корреляции.
• IDS/IPS — обнаружение и предотвращение вторжений на сетевом уровне.
• EDR/XDR — мониторинг конечных точек, обнаружение поведенческих аномалий, автоматическое реагирование.
• DLP — обнаружение попыток утечки данных через каналы коммуникации.
• Honeypots — ловушки для обнаружения несанкционированной активности.

Этап 2. Обнаружение и регистрация

Источники информации

Инциденты обнаруживаются через три канала:

Автоматическое обнаружение. SIEM-система генерирует алерт на основе правила корреляции: множественные неудачные попытки аутентификации с последующим успешным входом → возможный brute-force. EDR обнаруживает подозрительный процесс, запущенный из временной директории.

Обращения пользователей. Сотрудник сообщает о подозрительном письме, недоступности сервиса, странном поведении рабочей станции. Важно обеспечить простой канал для обращений (e-mail security@, горячая линия, чат-бот).

Внешние источники. Уведомление от НКЦКИ/CERT о компрометации, сообщение от партнёра об утечке данных, обнаружение данных организации на теневых форумах.

Регистрация инцидента

Каждый инцидент фиксируется в системе учёта с обязательными полями:

• Уникальный идентификатор инцидента.
• Дата и время обнаружения.
• Источник информации (кто/что обнаружил).
• Краткое описание инцидента.
• Затронутые активы и системы.
• Первичная оценка критичности.
• Назначенный ответственный.

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

Этап 3. Классификация и приоритизация

Уровни критичности: P1–P4

🗂 Где хранить критерии, матрицу и журнал Критерии квалификации и матрица эскалации живут в регламенте, а журнал инцидентов должен быть под рукой при проверке. В КиберОснова документы процесса ведутся в модуле документов ИБ, а связь инцидента с активами и их владельцами даёт реестр активов. Обзор подхода к автоматизации — на странице автоматизации ИБ.

Эскалация

Матрица эскалации определяет, кто уведомляется при каждом приоритете:

Этап 4. Реагирование и сдерживание

Сдерживание: краткосрочное и долгосрочное

Краткосрочное сдерживание — немедленные действия для предотвращения распространения инцидента:

• Изоляция заражённого хоста от сети (не выключение!).
• Блокировка скомпрометированной учётной записи.
• Блокировка IP-адреса атакующего на МЭ.
• Перенаправление DNS для фишингового домена.

Долгосрочное сдерживание — меры, позволяющие продолжить работу до полного устранения:

• Переключение на резервные системы.
• Усиление мониторинга затронутого сегмента сети.
• Временные правила WAF/IPS.
• Принудительная смена паролей для затронутых учётных записей.

Сбор и сохранение доказательств

При расследовании необходимо обеспечить юридическую значимость доказательств: образ оперативной памяти (Volatility, WinPmem), образ диска (dd, FTK Imager), сетевой трафик (pcap), логи SIEM/EDR, скриншоты. Каждое доказательство фиксируется в журнале с указанием: что, кто, когда, как собрал. Нарушение цепочки хранения (chain of custody) делает доказательства непригодными для правоохранительных органов.

Коммуникация во время инцидента

Коммуникация — часто недооценённый аспект реагирования:

• Внутренняя: Регулярные обновления статуса для руководства (каждые 2–4 часа для P1). Чёткий канал коммуникации (выделенный чат, конференц-линия).
• Регуляторы: НКЦКИ (3 часа для значимых объектов КИИ, 24 часа для иных), Роскомнадзор (24 и 72 часа при утечке ПДн), ФинЦЕРТ (для финансовых организаций).
• Внешняя: Клиенты и партнёры (при утечке их данных), СМИ (при публичных инцидентах — только через пресс-службу).

Этап 5. Расследование и восстановление

Установление причин и масштаба

Расследование отвечает на четыре вопроса:

1. Что произошло? Хронология событий: первичный вектор атаки, последовательность действий злоумышленника, достигнутые цели.
2. Как произошло? Использованная уязвимость, метод проникновения, инструменты атакующего.
3. Каков масштаб? Затронутые системы, скомпрометированные данные, длительность компрометации.
4. Кто стоит за атакой? Внешний злоумышленник, инсайдер, APT-группа (атрибуция — если возможна).

Для расследования используются данные из БДУ ФСТЭК (идентификация эксплуатируемых уязвимостей), MITRE ATT&CK (классификация техник атакующего), Threat Intelligence (индикаторы компрометации).

Устранение вектора атаки

До восстановления необходимо устранить причину инцидента:

• Закрыть эксплуатируемую уязвимость (установить патч).
• Удалить вредоносное ПО и бэкдоры со всех затронутых хостов.
• Отозвать скомпрометированные сертификаты и ключи.
• Пересмотреть права доступа.
• Обновить правила МЭ/IPS.

Критическая ошибка: восстановление из резервной копии без устранения вектора. Если уязвимость не закрыта, а вектор не заблокирован — повторная компрометация произойдёт в течение часов.

Восстановление систем

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

1. Восстановление из чистой резервной копии — предпочтительный вариант для заражений ВПО и ransomware. Копия должна быть от даты до компрометации.
2. Переустановка системы — если нет уверенности в целостности резервной копии.
3. Очистка системы — допустима только для незначительных инцидентов, когда масштаб достоверно установлен.
4. Постепенный ввод в эксплуатацию — восстановленные системы вводятся поэтапно с усиленным мониторингом.

Этап 6. Извлечение уроков (Post-Incident Review)

Формат проведения PIR

Post-Incident Review (PIR) — самый недооценённый этап. Без него организация повторяет одни и те же ошибки. PIR проводится в течение 5–10 рабочих дней после закрытия инцидента.

Участники: все, кто участвовал в реагировании — CSIRT, ИТ, владельцы затронутых систем, руководство (для P1/P2).

Формат: структурированная встреча (60–120 минут) с фиксацией выводов. Атмосфера — «blameless»: фокус на процессах и системах, не на поиске виноватых.

Вопросы для обсуждения:

• Что сработало хорошо?
• Что можно было сделать лучше?
• Где процедуры оказались неэффективными?
• Какие инструменты отсутствовали или не сработали?
• Какие корректирующие действия необходимы?

Отчёт об инциденте

Итоговый отчёт содержит:

• Краткое описание инцидента (executive summary).
• Хронология событий (timeline).
• Масштаб: затронутые системы, данные, пользователи.
• Причина (root cause).
• Предпринятые действия и их результат.
• Финансовый ущерб (если оценён).
• Корректирующие действия с ответственными и сроками.
• Рекомендации по предотвращению аналогичных инцидентов.

Метрики эффективности

Информирование регуляторов

ГосСОПКА / НКЦКИ: субъекты КИИ и операторы ГИС

Субъект КИИ направляет в НКЦКИ (Национальный координационный центр по компьютерным инцидентам, подразделение ФСБ) сведения о компьютерном инциденте на значимом объекте не позднее 3 часов с момента обнаружения, на иных объектах КИИ не позднее 24 часов, о компьютерной атаке не позднее 24 часов (приказ ФСБ № 547 от 25.12.2025). Обязанность распространяется на все объекты КИИ, а не только на значимые.

Сведения передаются через техническую инфраструктуру НКЦКИ, при её недоступности по почтовой или электронной связи на адреса НКЦКИ (п. 2 приказа № 547). С 1 сентября 2026 года операторы ГИС и иных информационных систем госорганов информируют ФСБ об инцидентах, повлёкших неправомерную передачу информации, не позднее 24 часов с момента обнаружения (568-ФЗ, п. 5 Порядка, утверждённого приказом ФСБ № 297).

Роскомнадзор: утечки ПДн

С 1 сентября 2022 года (часть 3.1 статьи 21 152-ФЗ, введена Федеральным законом № 266-ФЗ) оператор персональных данных при неправомерной или случайной передаче ПДн, повлёкшей нарушение прав субъектов, обязан:

• В течение 24 часов уведомить Роскомнадзор об инциденте: предполагаемые причины, предполагаемый вред, принятые меры, сведения об уполномоченном на взаимодействие лице.
• В течение 72 часов представить результаты внутреннего расследования и сведения о лицах, действия которых стали причиной инцидента.

Уведомление подаётся через портал Роскомнадзора. За невыполнение или просрочку уведомления об утечке предусмотрен штраф по части 11 статьи 13.11 КоАП: должностные лица 400–800 тыс. рублей, юридические лица 1–3 млн рублей. За саму утечку отвечают части 12–14 (юридические лица 3–15 млн рублей), при повторной утечке часть 15 вводит оборотный штраф 1–3% выручки, но не менее 20 млн и не более 500 млн рублей.

ФинЦЕРТ: финансовые организации

Финансовые организации уведомляют ФинЦЕРТ (подразделение Банка России) об инцидентах ИБ в соответствии с Положением ЦБ. Формат и сроки уведомления определяются нормативными актами ЦБ для конкретной категории организации.

⏱ Сроки 3, 24 и 72 часа как задачи с дедлайнами Уведомление в НКЦКИ или Роскомнадзор направляет уполномоченный сотрудник, а не система. Задача КиберОснова другая: сроки заводятся как задачи с ответственным в модуле «Задачи ИБ», обязанности по 187-ФЗ и 152-ФЗ отслеживаются в контуре соответствия требованиям, и в момент проверки видно, кто, когда и что направил регулятору.

Автоматизация управления инцидентами

Скорость реагирования как KPI

В управлении инцидентами время — критический ресурс. Каждый час задержки в обнаружении и сдерживании увеличивает ущерб. Автоматизация сокращает:

• MTTD — автоматическая корреляция событий вместо ручного анализа.
• MTTR — автоматический запуск playbook по типу инцидента.
• Время эскалации — автоматическое уведомление по матрице эскалации.
• Время формирования отчётов — шаблоны для регуляторов заполняются автоматически.

КиберОснова: организационная часть цикла

Обнаружение остаётся за SIEM и EDR. SGRC-система закрывает то, что при инциденте обычно живёт в почте и таблицах:

• Реестр активов с владельцами. Первый вопрос при инциденте: что затронуто и кто отвечает. Реестр активов отвечает на него сразу, включая связи между системами и признак объекта КИИ или ГИС.
• Задачи с дедлайнами. Шаги реагирования, сроки 3, 24 и 72 часа и корректирующие действия после PIR ведутся как задачи с ответственными и контролем исполнения в модуле «Задачи ИБ».
• Устранение вектора. Если причина в уязвимости, она привязывается к записи БДУ ФСТЭК с расчётом критичности и сроком устранения.
• Риски. По итогам инцидента риск пересматривается в модуле управления рисками, а не остаётся в отчёте PIR.
• Документы. Политика, регламент, playbook и журнал инцидентов хранятся и версионируются в модуле документов ИБ, история действий доступна для аудита ИБ.

Типичные ошибки управления инцидентами

1. Отсутствие подготовки

Организация не имеет политики управления инцидентами, playbook и CSIRT. При возникновении инцидента — хаотичные действия, потеря времени на выяснение «кто что делает», уничтожение доказательств. Подготовка — этап, который окупается при первом серьёзном инциденте.

2. Отключение питания заражённого хоста

Рефлекторная реакция — выключить компьютер. Результат: потеря оперативной памяти (ключи шифрования, сетевые соединения, вредоносные процессы). Правильно: изолировать от сети, но не выключать.

3. Игнорирование PIR и отрыв от рисков

Без Post-Incident Review те же ошибки повторяются. А если управление инцидентами существует отдельно от управления рисками, уроки не транслируются в меры защиты и цикл PDCA остаётся разорванным.

Заключение

Управление инцидентами ИБ — процесс, от которого зависит устойчивость организации к кибератакам. Шесть этапов — подготовка, обнаружение, классификация, реагирование, расследование, извлечение уроков — формируют замкнутый цикл, соответствующий требованиям ISO 27035, NIST SP 800-61, ГосСОПКА и российской нормативной базы.

Ключевые факторы успеха: подготовленная CSIRT, playbook для типовых инцидентов, автоматизация обнаружения и реагирования, соблюдение сроков уведомления регуляторов и — самое важное — систематическое извлечение уроков. Без Post-Incident Review процесс остаётся реактивным.

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