ERM-система управления рисками: реестр, оценки, планы и KPI

С чего начать: какую проблему решает ERM

ERM нужна не для того, чтобы «собрать все угрозы в таблицу». Ее задача - сделать риски видимыми, сопоставимыми и управляемыми: что важнее, кто отвечает, что уже сделано и где нужно решение руководства.

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

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

Дальше задайте границы первого этапа. Лучше стартовать с рисков, которые реально контролировать и измерять, и расширяться постепенно. В организациях с критичными ИТ-сервисами (госучреждение, банк, клиника) логично начать с операционных и ИТ-рисков: простои сервисов, киберугрозы, сбои поставок оборудования, ошибки изменений.

Для пилота удобно зафиксировать простое правило включения: берете 1-2 подразделения, 10-20 ключевых процессов и только те риски, у которых есть владелец и понятное последствие (деньги, доступность, безопасность, соответствие требованиям). Стратегические и репутационные темы лучше добавить позже, когда появится дисциплина обновления и отчетности.

Роли, циклы и уровни управления рисками

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

Роли: кто за что отвечает

В карточке риска обычно достаточно 3-4 ролей, но их нужно назначить поименно:

• Владелец риска - руководитель, который принимает риск и решает, что делать дальше.
• Ответственный (исполнитель) - ведет риск в системе, собирает данные, обновляет статус действий.
• Согласующий - проверяет корректность оценки и плана (например, ИБ, финансы, юристы, комплаенс).
• Наблюдатель - получает уведомления и использует данные (PMO, служба качества, аудит).

Владельца и исполнителя важно разделять. Например, риск простоя серверной инфраструктуры может принадлежать ИТ-директору, а конкретные действия по резервированию и тестам выполняет руководитель эксплуатации.

Циклы: как часто обновлять

Слишком частые пересмотры утомляют, слишком редкие делают реестр мертвым. Базовый рабочий ритм обычно такой:

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

Уровни и правила эскалации

Держите риски разными слоями: корпоративные, процессные, проектные, ИТ и ИБ. Эскалация нужна, когда риск выходит за рамки команды: ожидаемый ущерб превышает лимит, затрагивает несколько подразделений (например, производство, интеграция, поддержка 24/7) или требует решения по приоритетам и бюджету. В таких случаях риск поднимается на комитет по рискам, а при критичности и публичных последствиях - к CEO.

Структура реестра рисков: поля карточки риска

Карточка риска должна быть короткой и одинаковой для всех. Важнее сопоставимость, чем «идеальное описание».

Минимальный набор полей

Начните с того, без чего риск нельзя найти, назначить и пересмотреть:

• ID риска (уникальный и неизменный) и короткое название
• описание простыми словами: что может случиться и где
• контекст: процесс, подразделение, актив или сервис, география, ключевые контрагенты
• владельцы: владелец риска и владелец контроля (если контроль есть)
• дата следующего пересмотра и статус (активен, закрыт, на пересмотре)

Дальше добавьте причины и последствия, но держите их в пределах 2-3 пунктов. Причина отвечает на «почему это возможно», последствие - на «что будет болеть». Например: «отказ СХД в серверной» (причина) и «простой критичного сервиса для филиалов» (последствие).

Поля для фильтрации и отчетов

Чтобы реестр работал в ежедневной практике, сразу заложите классификацию и теги:

• категория (финансовый, комплаенс, ИТ, кадровый и т.д.)
• тип (стратегический, операционный, ИТ, проектный)
• критичность или приоритет (для сортировки)
• связанные активы или сервисы (одинаковые наименования из справочника)
• теги (например: «поставщик», «ДЦ», «госзакупки») для быстрых выборок

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

Оценка рисков: шкалы, матрица и аппетит

Чтобы оценки не превращались в набор мнений, договоритесь о единых шкалах и правилах расчета. Самый понятный вариант - шкалы 1-5 для вероятности и влияния плюс матрица, которая переводит баллы в приоритет.

Шкалы 1-5: как их описать

Вероятность лучше привязывать к частоте за период (например, за год), а не к словам вроде «редко»:

• 1: почти невероятно (раз в 5+ лет)
• 2: маловероятно (раз в 2-5 лет)
• 3: возможно (примерно раз в год)
• 4: вероятно (несколько раз в год)
• 5: почти неизбежно (ежемесячно и чаще)

Влияние фиксируйте не одним числом «в целом», а через измеримые категории. Удобно хранить отдельные оценки для финансов, простоев (SLA/часы), комплаенса (штрафы, нарушения), репутации (публичность, охват), безопасности (травмы, критичность).

Присущий и остаточный риск

Считайте два значения: присущий риск (до контролей) и остаточный (после действующих контролей). Формула может быть простой: вероятность x влияние. Смысл не в «умножении ради умножения», а в том, чтобы было видно, какие контроли реально снижают балл и почему.

Аппетит к риску задает пороги матрицы и правила эскалации. Часто используют светофор:

• Зеленый: принимаем, контролируем на уровне владельца
• Желтый: нужен план реагирования и срок пересмотра
• Красный: обязательная эскалация и решение руководства

Пороги и право утверждения (владелец процесса, риск-комитет, правление) фиксируйте в методологии.

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

Контроли и их связь с рисками

Контроль - это конкретное действие или правило, которое снижает вероятность риска или его ущерб. Важно отделять риск (что может случиться) от контроля (что мы делаем, чтобы этого не случилось или чтобы заметить вовремя).

Контроли удобно делить по назначению: профилактические (не дают проблеме возникнуть), детективные (быстро обнаруживают отклонение) и корректирующие (уменьшают последствия и ускоряют восстановление).

Чтобы контроль можно было проверять и улучшать, обычно хватает таких полей:

• ID и название (коротко и однозначно)
• описание: что делают и для какого процесса
• владелец: кто отвечает за выполнение
• периодичность: ежедневно, еженедельно, по событию
• доказательства выполнения: что считается подтверждением

Связь рисков и контролей почти всегда многие-ко-многим. Один контроль может снижать сразу несколько рисков (например, управление изменениями уменьшает риск простоя, риск нарушений безопасности и риск несоответствия требованиям). И наоборот, один риск обычно покрывается набором контролей: один предупреждает, другой обнаруживает, третий помогает восстановиться.

Эффективность контроля лучше оценивать в нескольких плоскостях, иначе реестр быстро становится формальностью: покрывает ли контроль сценарий (дизайн), выполняют ли его по графику (исполнение), есть ли следы выполнения (доказуемость), не держится ли он на одном человеке (устойчивость).

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

Планы реагирования: как описывать действия и ответственность

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

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

В карточке плана обычно достаточно:

• действия: короткие шаги, привязанные к причине риска (не к симптомам)
• ответственные: владелец действия и согласующий
• сроки и бюджет: дата, трудозатраты, закупки, внешний подряд
• ожидаемый эффект: как изменятся вероятность или ущерб после выполнения
• доказательства: что приложить (акт, протокол теста, приказ, отчет), чтобы принять работу

Отдельно фиксируйте зависимости и блокеры: закупочные процедуры, готовность подрядчика, окна изменений, согласование ИБ, доступ к данным. Если зависимость не отмечена, план почти всегда срывается «внезапно».

Критерии завершения делайте проверяемыми. «Настроено резервное копирование» - плохо. «Ежедневный бэкап выполняется 14 дней подряд, есть отчеты, проведено восстановление на тестовом стенде» - хорошо.

Статусы держите простыми: запланировано, в работе, просрочено, завершено, отменено (с причиной). Если задачу отменили, укажите, чем ее заменили или почему риск теперь принят.

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

Связь с инцидентами: чтобы реестр был живым

Реестр часто «замирает», если живет отдельно от реальных сбоев и потерь. Поэтому важно фиксировать инциденты и связывать их с рисками, контролями и ответственными.

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

Практичная связка выглядит так: инцидент привязан к конкретному риску (что реализовалось), к контролю (что должно было предотвратить или быстро обнаружить) и к владельцу риска (кто отвечает за решение). Например, если у интегратора остановилась критичная система в дата-центре, инцидент связывают с риском «Простой критичного сервиса», с контролем «Мониторинг и резервирование» и с владельцем сервиса.

В карточке инцидента держите только то, что помогает принимать решения:

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

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

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

Связь с KPI и KRI: измеримость вместо общих слов

Система перестает быть «таблицей про опасности», когда у каждого риска появляются измеримые сигналы и понятная динамика. Для этого нужны две группы метрик: KRI (ранние индикаторы риска) и KPI (показатели результата или выполнения действий).

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

Привязка обычно строится так: риск -> KRI (что растет перед событием), контроль -> KPI выполнения (делаем ли контроль вовремя), план реагирования -> KPI прогресса (успеваем ли по срокам и эффекту). Тогда карточка показывает не только оценку, но и «пульс».

Примеры метрик, которые часто работают в ИТ и операциях:

• SLA критичных сервисов: доля времени в пределах SLA и среднее время восстановления (MTTR)
• время реакции на инцидент: медиана до начала работ и доля инцидентов с эскалацией по регламенту
• патчи: процент систем, обновленных в срок, и доля просроченных критичных уязвимостей
• резервное копирование: доля успешных бэкапов с регулярной проверкой восстановления
• планы: доля задач плана реагирования, закрытых в срок, и число просрочек по владельцам

У каждой метрики должен быть владелец и источник данных: мониторинг и Service Desk, отчеты по уязвимостям, журналы резервного копирования, системы учета задач, либо ручной ввод с обязательной проверкой. Иначе KPI и KRI быстро превращаются в «красивые числа», которым не доверяют.

Пошагово: как спроектировать ERM-систему с нуля

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

1. Сформулируйте основу: цели, категории рисков (финансы, ИТ, операционные, комплаенс), шкалы вероятности и влияния, пороги аппетита и триггеры эскалации.

2. Опишите данные и связи. Обычно достаточно пяти сущностей: риск, контроль, план реагирования, инцидент, метрика (KPI/KRI). Сразу решите, как они связываются: один риск может иметь несколько контролей и планов, а инцидент - относиться к одному или нескольким рискам.

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

4. Определите роли и права доступа: владелец риска, риск-координатор, контролер, утверждающий. Полезны журнал изменений, комментарии к переоценкам и история решений.

Запускайте пилот на 1-2 процессах, где риски уже ощутимы (например, поддержка критичного ИТ-сервиса или закупки). Через 3-4 недели соберите факты: какие поля не заполняют, где тормозит согласование, какие уведомления реально нужны, и донастройте модель под реальную работу.

Частые ошибки при внедрении ERM

Одна из самых частых ошибок - путать риск с уже случившейся проблемой. В реестр попадают записи вроде «сервер упал» или «поставка задержалась», но без условий повторения, причин и мер. Такой список превращается в журнал жалоб.

Вторая причина споров - оценки без четких критериев. Когда один руководитель ставит «4» за вероятность, потому что «кажется часто», а другой - «2», потому что «в прошлом году не было», матрица становится игрой в угадайку. Нужны понятные шкалы, примеры и единые пороги аппетита.

Третья ошибка - планы без владельца и сроков. Если в карточке нет ответственного и контрольной даты, действия годами висят «в работе».

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

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

Короткий чек-лист качества реестра и процессов

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

5 проверок за 10 минут

Пройдитесь по реестру за последний квартал:

• у каждой карточки указан владелец (по должности), дата следующего пересмотра и текущий статус
• для «красных» рисков есть план с датами и ответственными или письменное решение о принятии риска
• на каждый существенный риск назначен хотя бы один контроль и отмечено, насколько он работает
• инциденты привязаны к рискам и реально меняют данные в карточке (уровень, вероятность, ущерб, статус плана)
• есть небольшой набор метрик (обычно 5-10) и расписание обновления

Признак, что процесс работает

Возьмите один недавний инцидент (например, простой критичного сервиса на 2 часа). Если нельзя быстро ответить, какой риск сработал, какие контроли не сдержали, какой KPI/KRI изменился и что делаем дальше, значит реестр не связан с реальностью.

Хорошая цель на старт: раз в месяц руководитель открывает 10 главных рисков и видит владельцев, действия, факты (инциденты) и цифры (метрики) без дополнительных созвонов.

Пример сценария: простой критичного сервиса и как это отражается в ERM

Представим ситуацию: в организации есть критичный сервис (например, электронная запись пациентов или система приема платежей). Он работает на сервере в серверной. Из-за отказа блока питания или дисковой подсистемы сервис останавливается на 2 часа.

В системе это отражается сначала как риск, а затем как инцидент, который уточняет оценку и планы.

Как это выглядит в карточке риска

Карточка описывает возможное событие, даже если оно еще не случилось:

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

Контроли связываются с риском как «что снижает вероятность/ущерб»: мониторинг состояния (температура, диски, питание), резервирование (RAID, второй блок питания, кластер), регламент обновлений и замены, тест восстановления по расписанию.

Инцидент и связь с KPI/KRI

Когда простой случился, создается запись инцидента, привязанная к риску: факт и длительность простоя, прямой ущерб, затронутые процессы, первопричина (например, отказ БП и отсутствие запасного), корректирующие действия (закупить ЗИП, изменить схему резервирования, усилить контроль температуры) и ответственные со сроками.

Чтобы реестр оставался «живым», метрики обновляются регулярно:

• KPI: доступность сервиса (%), среднее время восстановления (MTTR)
• KRI: число критичных предупреждений мониторинга, доля успешных тестов восстановления, процент просроченных обновлений

Если KRI ухудшаются, риск пересматривают, а планы реагирования делают конкретнее.

Следующие шаги: пилот, отчетность и поддержка внедрения

Первые 4-6 недель ведите как пилот: цель не «внедрить все», а доказать, что система дает понятные решения руководству и помогает командам действовать быстрее.

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

Дальше все решает отчетность. Сделайте один понятный пакет на 1-2 страницы и выпускайте его по расписанию (например, раз в месяц): топ-10 рисков по остаточному уровню и что изменилось, просроченные планы с причинами задержек, тренды по ключевым KRI и превышения порогов, 3-5 инцидентов периода и какие риски они подтвердили.

Если для ERM нужны платформа, права, интеграции и аналитические отчеты, это часто упирается в инфраструктуру и поддержку. В таких задачах может помочь GSE.kz (gse.kz) как системный интегратор: они проектируют и поддерживают ИТ-среду, а серверы и рабочие станции можно подобрать из локально произведенных линеек под требования по надежности и закупкам.