Что лучше: 20 управляемых рисков или полный реестр из 300 записей?

Я всё чаще вижу реестры киберрисков, которые выглядят значительно зрелее, чем сама система управления.

В них есть: — утверждённая методика; — матрица вероятности и ущерба; — владельцы; — treatment plans; — сроки; — цветовые статусы.

Но когда нужно решить, переносить ли запуск продукта, финансировать ли модернизацию защиты или принимать ли security exception, обсуждение начинается почти с нуля.

Реестр в этом решении не участвует.

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

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

Отдельный вопрос — risk owner.

Владельцем часто назначают сотрудника ИБ или GRC, поскольку он выявил проблему и способен её описать.

Но owner должен владеть не карточкой, а решением.

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

ИБ может оценивать, консультировать, контролировать и эскалировать. Но она не должна автоматически владеть рисками, возникающими из чужих бизнес-решений.

То же самое относится к treatment plan.

«Мероприятия запланированы» звучит убедительно, пока не выясняется, что: — бюджет не выделен; — проект не создан; — команда не назначена; — срок не согласован; — ожидаемый residual risk не определён.

Такая запись создаёт иллюзию движения.

Я считаю, что статус treatment должен отражать не наличие идеи, а наличие организационного обязательства.

Есть owner, ресурс, срок и механизм исполнения — риск обрабатывается.

Нет хотя бы одного из этих элементов — решение ещё не принято.

Современные подходы к cyber risk management всё явнее связывают risk register с корпоративными целями и ERM. NIST IR 8286 Rev. 1 рассматривает его как механизм передачи риск-информации руководителям, а IR 8286A Rev. 1 связывает сценарии, likelihood, impact, appetite и tolerance с дальнейшей приоритизацией реакции. (NIST Computer Security Resource Center)зрелость реестра я бы оценивал не количеством записей и заполненных полей.

Более полезные вопросы: — сколько решений было принято на основании реестра; — сколько treatment plans реально обеспечены ресурсами; — как быстро определяется настоящий owner; — сколько рисков пересмотрено после существенных изменений; — снижается ли residual risk; — видит ли руководство концентрацию риска вокруг критичных услуг и зависимостей.

Реестр киберрисков — это система решений, а не хранилище документации.

Я предпочту 20 сценариев, каждый из которых связан с owner, ресурсом, сроком и остаточным риском, вместо 300 опасений, которые регулярно переоценивают, но никогда не используют.

А что чаще всего отсутствует в карточке риска именно тогда, когда руководству нужно принять решение: настоящий owner, бюджет, deadline или trigger для пересмотра?