Регуляторные риски и нарушения: инциденты с согласованием по ролям

Карточка инцидента

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

• 12вкладок карточки
• 16статусов маршрута
• 29переходов
• 24из них — с обязательным комментарием

Списки — базовые и пользовательские представления, с корзиной удалённых записей (мягкое удаление, не физическое) и копированием карточки. Запись можно создать по шаблону, а список — выгрузить в Excel одной кнопкой.

Маршрут статусов и переходов

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

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

Ветки согласования ИБ и ИТ

Два признака записи — incidentIb и incidentIt — включают дополнительные шаги согласования сами, без ручной настройки маршрута под каждую карточку. Из статуса «Верифицировано» доступны переходы на согласование риск-менеджеру, менеджеру по ИБ и менеджеру по ИТ; если признак ИБ или ИТ установлен, прямой переход в согласование риск-менеджеру скрывается — запись обязана пройти профильную ветку.

Отметьте признаки слева, чтобы увидеть, какие ветки согласования становятся доступны — состав веток соответствует условию в карточке инцидента.

Журнал статусов и история изменений

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

Отдельно ведётся история изменений значений индикаторов записи — поле, старое и новое значение, сотрудник, дата — для инцидента и связанных с ним последствий, возмещений и оценок.

Что это даёт ИТ-директору

• Переход статуса — только у роли с правом EXECUTE на целевой статусРазделение полномочий проверяется на уровне модели, а не инструкцией.
• Журнал статусов пишется для каждого переходаdm.incident_status_log: статус, дата, сотрудник, комментарий.
• Уведомления рассылаются ролям по статусуСостав получателей задаётся файлом настроек при внедрении.

Записаться на демонстрацию