Оценка рисков в IT почти всегда работает плохо не потому что реестр ведётся небрежно, а потому что применяется универсальная методология без поправки на IT-специфику.

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

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

Собственник по оргструктуре здесь бесполезен: он видит только свой периметр, а риск живёт на стыке. Работает другой принцип: владельцем считается команда, которая управляет интерфейсом, архитектурным решением или точкой интеграции, где риск материализуется - то есть тот, кто может его создать или устранить своим решением.

Когда решение принимается несколькими командами сразу, владельцем становится тот, кто утверждает финальную конфигурацию: архитектор или владелец платформы. Статус «коллективная ответственность» здесь не работает - на практике это способ не иметь владельца вообще.

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

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

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

Проверить себя можно одним вопросом: реестр рисков используется при принятии решений или существует отдельно от них. Если отдельно - методология обслуживает не риск, а отчётность.