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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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