На мой взгляд, не обязательно.

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

Гораздо важнее другое: способен ли корпоративный центр понять, сопоставить и объединить результаты этих оценок.

Часто холдинг пытается решить проблему самым очевидным способом: — вводит единую пятибалльную шкалу; — утверждает общий шаблон risk register; — собирает показатели; — рассчитывает средний уровень риска; — строит общую heatmap.

Получается красивый отчёт. Но реальная картина может исчезнуть.

Одна компания считает риск по статистике. Другая — по экспертной оценке.

Третья измеряет зрелость контролей. Четвёртая использует количество уязвимостей.

Все ставят оценку «4».

Но это четыре разных результата.

Ещё опаснее усреднение.

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

Низкие оценки большинства компаний не компенсируют критичную точку входа в инфраструктуру группы.

Я бы не начинал с полной унификации методики. Я бы установил единый минимальный data model.

Каждая компания должна понятно описывать: — конкретный сценарий; — затронутый бизнес-процесс; — возможное последствие; — owner; — общие зависимости; — остаточный риск; — требуемое решение; — качество исходных данных.

На уровне группы риски нужно анализировать через четыре дополнительных признака:

Concentration. Сколько критичных процессов зависит от одного сервиса или поставщика?

Correlation. Какие сценарии могут реализоваться одновременно?

Propagation. Через какие связи инцидент перейдёт из одной компании в другую?

Decision level. Может ли риск быть обработан локально или требуется групповая инвестиция, ограничение либо принятие риска?

NIST IR 8286C Rev. 1 прямо рассматривает интеграцию информации из cybersecurity risk registers в enterprise risk register и enterprise risk profile. Но наличие общего реестра само по себе не гарантирует качественного управления. Важно, какую информацию он делает видимой для руководства. (NIST Computer Security Resource Center)

Корпоративный центр должен стандартизировать язык и правила принятия решений, но не уничтожать локальный контекст ради одинаковых цифр.

Enterprise view — это не средняя оценка риска.

Это способность показать: — системные точки отказа; — критичные outliers; — общие зависимости; — концентрацию; — просроченные решения; — возможный blast radius.

Какой подход работает у вас лучше: единая методика для всех компаний или общий минимум данных при сохранении локальной автономии?