Управление рисками

Поверхность риска состоит из трёх страниц — Risk Register и его матрицы 5×5, представления детали/обработки конкретного риска и очереди Remediation (POA&M), — плюс мультисигнальный движок риска, который оценивает активы и системы за ними.

4.1. Работа со списками GRC

Каждая GRC-страница-список (assets, risks, systems, assessments, policies, audits, exceptions, compliance) использует одну панель:

• Фильтры и пагинация записываются в URL — перезагрузка, кнопка Back или скопированная ссылка сохраняют ваш вид.
• Columns — выбор отображаемых опциональных колонок.
• Views — сохранение именованных видов (Save current view…) и переключение между ними; Reset to default сбрасывает.
• Массовые действия — выбор строк для действия над многими (см. заметки по страницам).

4.2. Реестр рисков

Страница: Risk → Risk Register (/grc/risks). Права: grc_risks.view для чтения; grc_risks.manage для создания/правки/связи рисков и промоушена инцидентов; grc_risks.approve для управляемых переходов accept/transfer/close; grc_reports.export для CSV. (grc_risks.manage не может перевести риск в accepted/transferred/closed — см. 4.5.)

Колонки: Title, Category, L×I (присущая оценка likelihood × impact), Residual, Due date, Review, Status. Действия строки: Edit, Link assets, Delete. Панель: New risk, Export CSV и фильтры — Filter by status, Category, Owner, Overdue only.

Создайте или отредактируйте риск через модальное окно. Поля: Title, Category, Status, Likelihood (1–5), Impact (1–5), Residual likelihood/impact (1–5), Treatment plan, Description, Owner, Due date и Review date. Даты — только дата; очистка поля убирает дату. Риск также можно промоутить из инцидента или находки аудита.

Overdue означает активный риск (статус open / mitigating), чья дата due или review строго раньше сегодня (полночь UTC — дата сегодня ещё не просрочена). Просроченные строки подсвечиваются полупрозрачно-красным, фильтр Overdue only изолирует их, а дашборд показывает счётчик Overdue reviews/treatments, работающий ровно по тому же предикату.

4.3. Матрица 5×5

В реестре показана Risk matrix (impact × likelihood). Каждая ячейка — присущая оценка (likelihood × impact); число в ячейке — сколько рисков в неё попадает. Клик по ячейке фильтрует таблицу по этой комбинации likelihood×impact (Matrix filter: L{l}×I{i}); клик снова или закрытие тега сбрасывает. Компактная матрица на GRC-дашборде ведёт в реестр, предварительно отфильтрованный по ячейке.

4.4. Мультисигнальный движок риска

Оценка риска актива вычисляется, а не вводится вручную:

Asset.riskScore = clamp(0..100, round(criticalityMultiplier × Σ factorScores))

С тех пор как движок стал мультисигнальным, сумма берётся по именованным факторам, у каждого свой настраиваемый вес (grc.risk_weights.factors):

Фактор	Что измеряет
Open incidents	Severity открытого кейса × source multiplier (актив, являющийся source инцидента, весит больше)
Failing controls	Реализации контролей в области актива, чей последний вердикт проверки — fail
Incident recurrence	Связанные кейсы актива, открытые в окне повторяемости (первое вхождение исключается)
Breached SLAs	Нарушенные SLA на открытых кейсах актива

Все веса, source multiplier, таблицы severity/criticality и окно повторяемости настраиваются в Settings → GRC (см. раздел 10). Ночная свёртка пересчитывает каждый живой актив и пишет не более одной базовой точки на актив в день для графика тренда риска.

4.5. Обработка риска — управляемый рабочий процесс

Откройте страницу детали риска (/grc/risks/:id) и его вкладку Treatment. Здесь живут две вещи:

1. Treatment type — классификация того, как вы обрабатываете риск: Mitigate, Accept, Transfer или Avoid.
2. Treatment actions — небольшие рабочие элементы, у каждого владелец, дата due и статус (Planned → In progress → Done или Cancelled). Просроченные открытые действия всплывают в ежедневной свёртке напоминаний. Добавляйте их через Add action.

Перевод самого риска в Accepted, Transferred или Closed — это управляемое решение, достижимое только через кнопки Accept risk / Transfer risk / Close risk, но никогда обычной правкой (правка, пытающаяся прыгнуть в управляемый статус, отклоняется). Каждое требует:

• права grc_risks.approve (Approve risk treatment);
• письменного rationale, записываемого в выделенное действие аудита; и
• разделения обязанностей (SoD) — когда grc.risk_approval_sod включён (по умолчанию) и у риска есть владелец, утверждающий должен быть кем-то, кроме владельца (иначе 403).

Модальное окно rationale напоминает: «A decision rationale is recorded in the audit log. Note: the risk owner cannot approve their own transition when Separation of Duties is enabled.» Управляемые статусы также исключены из массовой правки (см. 4.6).

4.6. Массовые действия над рисками

В Risk Register можно массово задать owner и category. Статус риска намеренно не редактируется массово — принятие, передача или закрытие риска остаётся управляемым решением по одному. Массовое обновление также пропускает любой риск, уже находящийся в управляемом статусе (accepted / transferred / closed) и сообщает счётчик как «{n} governed risk(s) skipped — change those individually». Требует grc_risks.manage; пакет ограничен 100.

4.7. Почему такая оценка

У каждой страницы детали актива и системы есть кнопка Why this score? рядом с оценкой риска. Она открывает выдвижную панель, которая разбирает число в понятных терминах:

• Для актива: именованные факторы риска, питающие оценку (Open incidents, Failing controls, Incident recurrence, Breached SLAs — каждый со своим вкладом), участвующие открытые кейсы (с severity и весом), criticality multiplier и сумма (Sum {sum} × criticality {mult}), а также сдвинулась ли оценка с прошлой недели (▲ вверх / ▼ вниз / без изменений).
• Для системы: её топ-члены по вкладу (сначала высший риск), число членов и режим rollup.

Разбор всегда вычисляется на сервере и показывается даже без настроенного AI (бейдж Template). Если ваша инсталляция включила GRC AI explainer и подключила провайдера, письменный абзац формулируется моделью из тех же чисел (бейдж AI) — она никогда не изобретает и не пересчитывает число, а панель откатывается к детерминированному шаблону при любом сбое AI. См. раздел 9.2.

4.8. Очередь ремедиации (POA&M)

Страница: Risk → Remediation (/grc/remediation). Права: grc_remediation.view для чтения; grc_remediation.manage для создания/переходов; grc_remediation.verify для закрытия.

Страница Remediation — единый реестр корректирующих рабочих элементов, план действий и вех по всей поверхности GRC. Каждый элемент поднимается из ровно одного источника — Risk, Control, Assessment item, Audit finding или Exception — и каждая из этих поверхностей несёт небольшое действие Create remediation, открывающее предсвязанную форму. У элемента есть Title, Owner, Due date и опциональный SLA (days).

Машина состояний. Элемент проходит:

Open → In progress → Blocked → Verification → Closed   (или Cancelled; переоткрытие разрешено)

• Закрытие достижимо только из Verification, через собственное действие Close (verify) под правом grc_remediation.verify — так роль только с verify может закрывать без полных прав manage. Обычный переход Move to (tier manage) отказывает в Closed.
• Закрытие требует owner ≠ verifier (SoD) и rationale («Reason (recorded in the audit trail)»); первое закрытие фиксирует, кто проверил.
• Отмена тоже требует rationale. Жёсткое удаление разрешено только для уже отменённого элемента.

Фильтруйте очередь по Status, Source, Owner или Overdue only; заголовок показывает живые счётчики (Overdue, Open, In progress, Verification, Closed). Просроченные открытые элементы (включая в Verification) преследуются ежедневной свёрткой напоминаний, и к любому элементу можно прикрепить доказательства.

---