Термины и сокращения

RCSA — Risk and Control Self-Assessment — самооценка рисков и контролей.

KRI — Key Risk Indicator — ключевой индикатор риска.

KCI — Key Control Indicator — ключевой индикатор контроля.

KPI — Key Performance Indicator — ключевой показатель эффективности.

ORMF — Operational Risk Management Framework — система управления операционным риском.

CRO — Chief Risk Officer — руководитель функции управления рисками.

HR — Human Resources — управление персоналом.

IOR — Institute of Operational Risk — Институт операционного риска.

IRM — Institute of Risk Management — Институт управления рисками.

SMART — Specific Measurable Achievable Relevant Time-bound — конкретность, измеримость, достижимость, значимость и ограниченность сроком.

SWIFT — Structured What-If Technique — структурированный анализ вопросов что если.

GRC — Корпоративное управление Risk and Compliance — корпоративное управление, риски и соответствие требованиям.

Самооценка рисков и контролей (RCSA)

[picture]

Ключевая схема по теме руководства (русская адаптация по материалам IOR/IRM).

Практическое руководство по управлению операционным риском

Institute of Operational Risk (IOR), компания группы IRM

Русское электронное издание подготовлено по предоставленному пользователем оригиналу. Термин RCSA (Risk and Control Self Assessment) сохранён, поскольку широко используется в профессиональной практике.

Предисловие

RCSA — один из центральных инструментов большинства ORMF. Его задача — не просто поставить баллы в матрице, а создать структурированный процесс обсуждения операционных рисков, качества контролей и необходимых действий.

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

Содержание

Введение

Основы RCSA

scope

фокус на событиях или процессах

роли

частота

Проектирование RCSA

матрица вероятность × impact

inherent risk

residual risk

controls и их эффективность

план мероприятийs

risk appetite/tolerance

шаблон

сверху вниз/снизу вверх

Проведение RCSA

рабочая сессия

questionnaires

Интеграция RCSA в ORMF

Выводы

Примеры шаблонов и heatmap

1. Введение

RCSA предоставляет структурированный механизм для:

оценки экспозиции операционного риска;

оценки эффективности контролей;

приоритизации рисков;

выявления слабостей и пробелов контроля;

отслеживания мероприятий.

Хорошо спроектированная RCSA помогает встроить управление операционным риском в организацию и улучшить risk culture.

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

RCSA — не только техническая оценка. Её ключевая ценность — открытый разговор о риске и контролях.

Многие операционные риски трудно количественно оценить из-за:

нехватки данные о потерях;

появления новых рисков;

сложности объективной оценки control effectiveness.

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

RCSA также поддерживает:

корпоративное управление;

соблюдение требований;

независимое подтверждение для совета и регулятора;

планирование internal/external audit.

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

2. Основы RCSA

2.1. Scope

Первый вопрос — какие риски должны проходить RCSA.

Вариант 1. Все выявленные риски

Плюс — максимальная полнота.

Минус — в крупной организации число экспозиций может исчисляться сотнями и тысячами, что делает процесс дорогим и трудоёмким.

Вариант 2. Только верхний уровень категорий

Например, проводить RCSA только для Level 1 корпоративной таксономии.

Плюс — охвачены все основные классы риска при небольшом числе оценок.

Минус — может не хватить деталей подразделениям и внутренний аудит.

Вариант 3. Только значимые риски уровня организации

Фокус на рисках, угрожающих корпоративным целям.

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

Вариант 4. Только существенные локальные риски подразделений

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

На практике можно сочетать подходы, например:

Level 1 для enterprise RCSA;

Level 2 для подразделений.

Основной принцип — cost-benefit. Максимальная полнота не автоматически означает лучшую систему. RCSA должна создавать больше ценности, чем потреблять ресурсов.

2.2. Фокус на событии или процессе

Event-based RCSA

Наиболее распространена. Оценка привязана к конкретным событиям:

пожар;

мошенничество;

травма;

hacking attack;

потеря питания и т. д.

Преимущество — простой и понятный объект оценки.

Process-based RCSA

Организация картирует процесс и ищет потенциальные точки отказа:

human error;

system failure;

process breakdown.

Процессный подход лучше связывает риск-менеджмент с ежедневной деятельностью и может напрямую поддерживать улучшение процесса.

Главный минус — стоимость картирования.

Если хорошие process maps уже существуют, IOR рекомендует использовать их. Создавать детальные карты только ради RCSA может быть экономически неоправданно.

2.3. Роли и ответственность

Обычно владельцем процесса RCSA является operational функция управления рисками.

Она отвечает за:

дизайн;

методологию;

документирование;

обучение и coaching;

oversight корректного применения;

фасилитацию рабочая сессияs.

Governing body

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

Senior management / CRO

Поддерживает работу совета и обеспечивает наличие эффективного подхода. При наличии CRO он обычно курирует конструкция и внедрение.

Владелец риска

Отвечает за:

выполнение RCSA;

нахождение экспозиции в appetite/tolerance;

отсутствие неприемлемых control gaps;

выполнение мероприятий.

Он может делегировать заполнение, но не конечную ответственность.

Control owner

Отвечает за:

конструкция контроля;

внедрение;

maintenance;

сообщение владелец риска о слабостях;

устранение выявленных проблем.

Data owner

Предоставляет данные, необходимые для качественной оценки.

Названия ролей могут отличаться. Важно не название, а чтобы были ясно назначены люди, отвечающие за:

своевременную, точную и полную RCSA;

выявление control gaps;

предоставление данных;

контроль план мероприятийs.

2.4. Частота

Самая распространённая частота полного пересмотра — раз в год, но нормальный диапазон — от месяца до года.

Частота должна зависеть от динамики риска: чем быстрее он меняется, тем чаще требуется review.

Практичный подход:

ежегодная полная RCSA;

ad-hoc update при значимом изменении между циклами.

Желательно обновлять RCSA до годового пересмотра целей и бюджета, чтобы её результаты влияли на performance и resource allocation.

3. Проектирование RCSA

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

3.1. Матрица вероятность × impact

Большинство RCSA используют качественную порядковую шкалу вероятности и последствий и объединяют её в risk matrix.

Обычные варианты:

3×3;

4×4;

5×5;

иные диапазоны также допустимы.

Критически важно понимать: это ordinal scale.

Если балл 2 выше 1, это не означает, что риск «в два раза больше». Расстояние между категориями не является математически равномерным.

Поэтому произведение баллов — это индекс приоритета, а не точная математическая величина риска.

Пример простой 3×3:

Probability | Low impact | Medium impact | High impact
Rare (1) | 1 | 2 | 3
Possible (2) | 2 | 4 | 6
Frequent (3) | 3 | 6 | 9

Пользователям нужны калибровочные ориентиры для вероятность и impact.

Impact обязательно должен соответствовать масштабу организации. Потеря £1 млн может быть катастрофичной для небольшой компании и малозначимой для крупной.

Probability обычно привязывают к:

диапазону вероятности; или

временной частоте — раз в N лет/событий в год.

Многие пользователи предпочитают временную шкалу, поскольку она интуитивнее.

Пример 3-уровневой калибровки IOR

Probability:

Rare — не чаще примерно одного события в 5–10 лет;

Possible — примерно одно событие в 1–5 лет;

Frequent — более одного раза в год.

Financial impact:

Low — не более 1% денежный поток и легко поглощается обычными расходами;

Medium — 1–5% денежный поток и может потребовать умеренного сокращения затрат;

High — более 5% денежный поток и может потребовать крупных сокращений или отмены стратегических проектов.

3.1.2. Inherent risk

Inherent/gross risk — экспозиция без учёта контролей.

Он даёт baseline и показывает потенциальную значимость риска до mitigation.

Если inherent risk низкий, полный анализ контролей может быть экономически нецелесообразен. Если высокий — риск заслуживает серьёзного внимания.

Главная сложность: реальная деятельность почти никогда не существует «без контролей». Поэтому inherent assessment часто концептуален и сильно зависит от экспертного суждения.

3.1.3. Остаточный риск

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

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

3.1.4. Причины

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

Поэтому в RCSA полезно фиксировать причины. Это помогает:

точнее оценивать вероятность события;

привязывать конкретные контроли к конкретным причинам;

находить причины, для которых защитных мер нет;

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

Связка «причина → событие → последствия → контроль» делает RCSA более предупреждающим, а не только описательным инструментом.

3.1.5. Последствия

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

Часть контролей направлена не на предотвращение события, а на уменьшение последствий. Спринклерная система не устраняет саму возможность возгорания, но ограничивает ущерб. Резервная ИТ-площадка снижает последствия отказа основной системы — если резерв действительно поддерживается и регулярно тестируется.

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

3.1.6. Эффективность отдельного контроля

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

Субъективно — по порядковой шкале, опираясь на управленческое суждение и подтверждающие данные.

Объективно — через тестирование и показатели эффективности контроля (KCI).

Пример простой трёхуровневой шкалы:

Балл | Оценка | Смысл
3 | Существенно эффективен | Работает полностью и так, как задумано
2 | Достаточен | В основном работает, есть небольшие недостатки
1 | Требует улучшения | Есть существенные дефекты в работе

Субъективную оценку желательно подтверждать фактами: инцидентами и событие без последствий, результатами внутренних аудитов, тестов и проверок.

Примеры объективных KCI:

как часто тестируется и обновляется план непрерывности бизнеса и нет ли просроченных тестов;

результаты тестов на проникновение;

результаты проверок электробезопасности оборудования и просрочка таких проверок;

зарегистрированные нарушения политик и процедур.

3.1.7. Общая эффективность среды контроля

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

IOR рекомендует отдельно оценивать не только каждый контроль, но и среду в целом. Простейшая шкала:

Недостаточный контроль — есть пробелы, которые необходимо закрыть.

Адекватный контроль — набор мер соответствует уровню риска.

Избыточный контроль — часть мер не нужна и может быть удалена без неприемлемого роста риска.

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

3.1.8. План мероприятий

В RCSA обычно предусмотрен блок согласованных действий. Они могут касаться:

устранения недостатков существующего контроля;

внедрения нового контроля;

закрытия пробела в среде контроля;

удаления устаревшей или избыточной меры.

Действия рекомендуется формулировать по SMART:

Принцип | Требование
Specific | Конкретная цель
Measurable | Результат можно объективно проверить
Achievable | Действие выполнимо
Realistic | Уровень улучшения оправдан и реалистичен
Time-bound | Установлен срок завершения

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

3.1.9. Дополнительные элементы RCSA

Организация может добавлять:

связь с целями бизнеса;

подробное описание риска;

KRI, KCI и KPI;

сведения об инцидентах и событие без последствий;

замечания внутреннего аудита и связанные мероприятия.

Но каждый новый элемент увеличивает трудоёмкость. RCSA должен оставаться инструментом принятия решений, а не превращаться в анкету ради анкеты.

3.2. Проектирование шаблона

Два распространённых варианта — электронная таблица и специализированная ИТ-система. IOR рекомендует новым системам RCSA несколько лет поработать в таблицах: это позволяет отладить логику, поля и шкалы до автоматизации.

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

3.3. Top-down и снизу вверх

Top-down RCSA обычно выполняется старшим руководством и фокусируется на стратегически значимых операционных рисках, способных повлиять на цели всей организации.

Bottom-up RCSA выполняется на уровне подразделений и процессов и помогает местным руководителям управлять конкретными рисками, контролями, потерями и эффективностью процессов.

Наиболее зрелая система использует оба направления:

стратегические риски каскадируются вниз и связываются с локальными рисками и контролями;

существенные локальные риски и корреляции между подразделениями эскалируются вверх.

Термины и основные элементы шаблонов должны быть совместимы. Для высшего руководства допустим более короткий и менее детализированный вариант.

4. Как проводить RCSA

IOR не рекомендует, чтобы RCSA единолично заполнял владелец риска или один назначенный сотрудник. Из-за субъективности это усиливает риск систематической ошибки. Групповая работа увеличивает разнообразие опыта и позволяет участникам оспаривать оценки друг друга.

4.1. Формат воркшопа

Воркшоп позволяет обсуждать риски и контроли вживую и получать поддержку специалиста по рискам. Он требует больше времени, но обычно даёт более качественную информацию.

Дополнительные преимущества:

повышение осведомлённости о рисках и контролях;

обсуждение «мягких» контролей: коммуникаций, обучения, ответственности;

передача навыков риск-менеджмента бизнесу.

4.1.1. Подготовка

До сессии необходимо:

получить поддержку руководства;

определить приоритетные подразделения по данным потерь, событие без последствий и аудита;

объяснить локальному руководству смысл и пользу RCSA;

заранее разослать методику и повестку;

выбрать участников и резервных представителей;

изучить процессы, прошлые оценки и историю событий;

назначить независимого квалифицированного фасилитатора;

согласовать границы и цели сессии;

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

4.1.2. Участники

Обычно нужны:

представитель местного руководства и владелец риска;

владельцы ключевых контролей;

профильные эксперты: ИТ, безопасность, HR, финансы, клиентские процессы и т. д.;

независимый наблюдатель, например представитель риск-функции.

Оптимальный размер группы — 6–8 человек, верхняя практическая граница — около 12. Чем больше группа, тем сложнее дать слово всем.

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

4.1.3. Структура и длительность

Длинные сессии снижают качество решений. Даже с перерывами после 2–3 часов растёт усталость. Практично делить работу на модули:

описание рисков и оценка присущего риска;

идентификация и оценка контролей, оценка остаточного риска;

мероприятия и следующие шаги.

Тестирование контролей, назначение сроков и уточнение владельцев можно завершить после воркшопа.

Главный принцип: риски и контроли принадлежат бизнесу. Воркшоп только помогает местному руководству выполнить эту ответственность.

4.1.4. Фасилитация

Хороший фасилитатор должен:

активно слушать;

создавать безопасную среду для несогласия;

поддерживать дисциплину и темп;

знать методику RCSA;

точно резюмировать обсуждение;

следить за соблюдением процесса;

оспаривать предвзятость и конфликты интересов;

обеспечивать баланс мнений;

вовлекать всех участников;

фиксировать решения, мероприятия и несогласия.

Внутренний фасилитатор из риск-функции или аудита допустим, если ясно, что ответственность за оценки остаётся у местного руководства.

4.1.5. Валидация

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

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

4.2. Анкетирование

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

4.2.1. Объём анкеты

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

Подтверждающие анкеты желательно строить на едином классификаторе рисков и стандартизированном перечне контролей.

4.2.2. Минимальное содержание

Минимум вопросов должен покрывать:

присущий риск;

эффективность отдельных контролей и, если используется, среды контроля;

остаточный риск;

рекомендуемые действия.

Лишние демографические вопросы не нужны. Обычно достаточно подразделения/функции и уровня должности.

4.2.3. Конструкция вопросов

Вопросы могут быть:

стандартными, подготовленными централизованно;

локальными, которые добавляет менеджмент конкретного подразделения.

Стандартизация облегчает сравнение и агрегацию, локальная свобода повышает вовлечённость. Практичный компромисс — обязательное ядро плюс дополнительные вопросы.

Для закрытых вопросов IOR советует чёткие шкалы без удобной «нейтральной середины», например 4-балльную Likert-шкалу или «Да/Нет». Вариант «Не применимо» допустим, если респондент объясняет почему. Открытые комментарии полезны для обоснования оценки.

4.3. Другие методы сбора и анализа информации

SWIFT — Structured What-If Technique

SWIFT — структурированное командное обсуждение вопросов «что, если?» и «как могло бы произойти?». Метод широко применяется для безопасности и экологических рисков, в том числе в химической промышленности и производстве, но применим и к другим операционным рискам.

Экспертная группа рассматривает отклонения от нормальной работы систем, процессов и контролей. Руководитель SWIFT направляет обсуждение, регистратор фиксирует результаты. Метод гибкий и способен охватить больше сценариев и пробелов в контролях, но требует значительных ресурсов. Поэтому он особенно уместен в опасных отраслях.

Метод Delphi

Delphi помогает получить консенсус группы экспертов без давления авторитетов. Участники отвечают анонимно; фасилитатор обобщает ответы и возвращает их группе на следующий раунд. Процесс повторяется до сближения позиций.

Плюсы — снижение группового давления и доминирования одного человека. Минус — высокая трудоёмкость, особенно если консенсус достигается трудно.

Анализ коренных причин

Root Cause Analysis исходит из того, что событие обычно имеет цепочку причин. Цель — понять не только непосредственный триггер, но и более глубокий процессный дефект, чтобы предотвратить повторение.

Пример «5 почему» из руководства:

Почему произошёл пожар? Загорелся горючий материал.

Почему он загорелся? Его воспламенила искра.

Откуда искра? Из-за электрической неисправности проводки.

Почему возникла неисправность? Проводка была изношена.

Почему она оставалась изношенной? Не проводилась требуемая проверка безопасности.

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

5. Интеграция RCSA в систему управления операционным риском

RCSA не должен существовать отдельно. Он получает данные из других элементов ORMF и сам снабжает их информацией.

5.1. Связь с внутренними и внешними данными потерь

История внутренних и внешних событий помогает:

оценивать остаточный риск и эффективность контролей;

проверять правдоподобие RCSA.

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

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

5.2. Сценарный анализ

Существенные риски и пробелы в контролях из RCSA — естественный источник сценариев. Обратно, сценарный анализ может обнаружить риски и слабости, которых ещё нет в RCSA.

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

5.3. Отчётность по RCSA

Форматы могут сочетаться:

текстовый риск-регистр;

тепловые карты и светофорные отчёты;

дашборды с KRI/KCI/KPI;

журнал выгод — перечень улучшений среды контроля и полученного эффекта.

Чем выше аудитория, тем меньше деталей. Совет директоров и высшее руководство должны видеть наиболее значимые экспозиции и слабости контролей. Линейным руководителям нужна более детальная информация для управления мероприятиями.

IOR отдельно рекомендует журнал выгод: он показывает бизнесу, что RCSA создаёт реальную ценность — например снижает потери, убирает ненужные контроли или повышает эффективность.

5.4. Планирование действий

RCSA должен приводить к решениям, но не каждое несовершенство требует нового контроля. Любое мероприятие нужно оценивать по затратам и выгодам. Нет смысла тратить 1 млн фунтов на устранение пробела, максимальная ожидаемая потеря от которого оценивается в 100 тыс. фунтов. Более того, дополнительный контроль может ухудшить процесс и породить новый риск.

Четыре классические стратегии обработки риска:

Принять — остаточный риск в пределах аппетита или дополнительный контроль экономически не оправдан.

Снизить — улучшить контроль, уменьшив вероятность и/или последствия.

Передать — например страхованием или передачей части деятельности внешнему поставщику. При аутсорсинге ответственность организации нередко сохраняется.

Избежать — изменить или прекратить деятельность, процесс или систему, чтобы уменьшить присущий риск.

У каждого действия должны быть содержание, ответственный и срок. Контроль прогресса продолжается до закрытия.

5.5. Внутренний аудит

Выходы RCSA помогают внутреннему аудиту:

формировать риск-ориентированный план проверок;

проверять оценки эффективности контролей;

получать дополнительное понимание локальных рисков.

Сам процесс RCSA также периодически должен проверяться внутренним аудитом на эффективность и соразмерность.

6. Выводы

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

Приложение A. Примеры форм RCSA

В исходном руководстве приведены четыре типа шаблонов:

простой табличный RCSA;

отдельный план мероприятий;

фрагмент анкеты по контролям доступа в ИТ-администрировании;

сквозной шаблон оценки процесса.

Практический принцип для российского предприятия: начать с понятной таблицы и только после стабилизации полей переносить методику в GRC/ИТ-систему.

Минимальный русский шаблон

Поле | Что фиксировать
Процесс/цель | Что должно быть достигнуто
Событие риска | Что может произойти
Причины | Почему это может произойти
Последствия | Что потеряет организация
Присущий риск | Вероятность и влияние без учёта контролей
Контроли | Предупреждающие, выявляющие, смягчающие меры
Эффективность контроля | Оценка + доказательства
Остаточный риск | Экспозиция после действующих контролей
Действие | Что нужно изменить
Владелец и срок | Кто отвечает и когда завершить

Приложение B. Тепловая карта для руководства

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

Источник: Institute of Operational Risk / Institute of Risk Management, Risk and Control Self Assessment — Operational Risk Sound Practice Guidance.

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