Введение

Шесть предыдущих уроков построили фреймворк: COSO ERM 2017, ISO 31000:2018, Three Lines Model, maturity models (DCAM v3), 6-осевая risk taxonomy и структура risk-control matrix. Эта практика — первое интегрированное практическое применение: вы в роли SwiftRide CDO Office на T+2M, строите первую версию реестра рисков для топ-5 CDE-кандидатов (из output практики M1.7).

Практика — doc-centric (обязательный). Output — заполненный реестр рисков в формате markdown-таблицы. Опционально opt-in: импорт реестра в LogicGate / Archer / ServiceNow IRM (sketched в конце; hands-on в M7).

Inputs

Топ-5 CDE из практики M1.7

В M1.7 вы скорили 10 кандидатов и идентифицировали топ-5 для одобрения Data Council на T+3M. Используем для этой практики:

Референсы фреймворков

• 5-шаговый процесс ISO 31000:2018: scope/context/criteria → identification → analysis → evaluation → treatment (+ monitoring + communication обёртка)
• COSO ERM 2017 — согласование через mapping колонок (таблица M2.2)
• 6-осевая taxonomy: accuracy, availability, confidentiality, integrity, privacy, ethics (M2.5)
• Структура risk-control matrix: риск → control objective → control activity → evidence (M2.6)
• Risk identification matrix: 5 категорий источников (внутренние, внешние, специфичные для данных, люди/культура, стратегические) (M2.2)

Шаблон практики

Создайте файл labs/m2-risk-register/results.md (если есть локальный workspace):

# SwiftRide CDE risk register — T+2M draft

## Risk register table

| risk_id | cde_id | risk_statement | risk_axis | inherent_L | inherent_I | inherent_score | current_controls | residual_L | residual_I | residual_score | risk_response | risk_owner | next_review_date |
|---------|--------|----------------|-----------|-----------|-----------|----------------|------------------|-----------|-----------|----------------|---------------|------------|------------------|
| R-001 | driver_earnings_ledger | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? |
| ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... |

## Risk-control matrix entries (top-3 risks)

[Per risk: control_objective + 2-4 control_activities + evidence_requirements]

## Methodology notes

[Brief description: framework alignment, source categories scanned, evaluator team]

Цель: 12-18 рисков всего (3-4 на CDE). Не меньше — слишком узко. Не больше — over-scoping для первой итерации.

Шаги выполнения

Шаг 1 (ISO 31000 Step 1): Scope, context, criteria

Задокументируйте явно:

• Scope: топ-5 CDE из short-list M1.7 (driver_earnings, trip_records, pricing_engine, kyc_profile, swiftcapital_loan).
• Внутренний контекст: SwiftRide T0 (pre-IPO 18-месячный таймлайн), 3 200 FTE, 40 стран, GMV $8.4B, EBITDA отрицательный.
• Внешний контекст: Big 4 audit engagement Q1 2026; регуляторная среда (SOX runway, GDPR зрелый, DORA в действии, EU AI Act фазируется с августа 2026, AMLR в действии с июля 2027).
• Risk criteria: материальность $20-25M на уровне group /$10M порог CDE-программы (согласно M1.2); inherent score ≥10 → приоритет; residual score ≥6 → обязательный текущий мониторинг; AML / sanctions / незаконное — автоматический приоритет независимо от score.
• Методология: COSO ERM — основной фреймворк (путь US-листинга), структура процесса ISO 31000, классификация по 6-осевой taxonomy, шаблон risk-control matrix.
• Команда: CDO + senior дата-инженер + Risk Manager + представитель Compliance (multi-axis-композиция M1.6).

Шаг 2 (ISO 31000 Step 2): Identification

На CDE — применить 5-категорийную identification matrix (M2.2):

Для driver_earnings_ledger:

Для pricing_engine_outputs:

Покройте все 5 категорий источников для каждого CDE. Типичный пробел (согласно anti-pattern M2.2): сканирование только внутренних событий. Без 5-категорийной структуры пробелы неизбежны.

Ожидаемо: 3-4 риска на CDE × 5 CDE = 15-20 рисков идентифицировано.

Шаг 3 (ISO 31000 Step 3): Analysis

Скорьте каждый риск по inherent likelihood + impact (1-5 каждый):

Шкала Likelihood:

• 1 = Очень редко (<1 раз в 5 лет исторически)
• 2 = Редко (1 раз в 2-5 лет)
• 3 = Возможно (1 раз в 1-2 года)
• 4 = Вероятно (1+ в год)
• 5 = Почти неизбежно (несколько раз в год)

Шкала Impact (финансовая компонента):

• 1 = <$0.5M
• 2 = $0.5M-$2M
• 3 = $2M-$10M
• 4 = $10M-$50M
• 5 = >$50M

Плюс качественные override-факторы согласно SAB 99 + risk taxonomy:

• Multi-regulator exposure → +1 likelihood (больше точек enforcement)
• Публичное репутационное измерение → bump категории impact
• AML / sanctions / незаконное → автоматический Impact = 5
• Кандидатура на material weakness (контекст SOX) → автоматический приоритет

Для каждого риска: также классифицировать по 6-осевой taxonomy (M2.5) — основная ось + второстепенные оси, если применимы.

Пример:

Шаг 4 (ISO 31000 Step 4): Evaluation

Для каждого риска: сравните inherent score с risk criteria; решите действие.

• Inherent score ≥10 И выше tolerance → обязательный treatment (Mitigate / Share / Avoid)
• Inherent score 5-9 → опциональный treatment ИЛИ информированный Accept с задокументированным обоснованием
• Inherent score <5 → информированный Accept уместен
• Качественный override (AML / sanctions / незаконное / material weakness) → автоматически обязательный treatment

Для топ-5 CDE SwiftRide — ожидается 12-15 рисков, требующих обязательного treatment, 2-3 кандидата на информированный Accept.

Шаг 5 (ISO 31000 Step 5): Treatment

Для каждого риска, требующего treatment, — выберите response:

• Avoid — не выполнимо для рисков CDE (операционная активность создаёт риск; устранение активности = выход из бизнеса)
• Mitigate — типичный; разверните контроли, снижающие likelihood + impact
• Share — страхование, third-party-контракты (vendor SLA penalties), партнёрские модели
• Transfer — конкретное подмножество share (например, явные клаузулы indemnification)
• Accept — информированное решение, подписано подотчётным владельцем, дата истечения установлена

После решения о treatment — набросайте residual scoring (likelihood + impact после контролей). Задокументируйте планируемые контроли. Для топ-3 рисков — полная запись risk-control matrix согласно M2.6 (objective + 2-4 control activities + требования к evidence).

Шаг 6 (ISO 31000 wrap): Monitoring + communication

Задокументируйте:

• Каденс мониторинга на риск: real-time / ежедневно / еженедельно / ежемесячно / ежеквартально
• Триггеры эскалации: изменение residual score, пробой порога, regulatory change, инцидент
• Пути коммуникации: кто узнаёт что когда (CRO dashboard ежедневно; Board Risk Committee ежеквартально; Audit Committee раз в полгода; Internal Audit ежегодный обзор)
• Дата следующего обзора на риск (обычно раз в полгода; high-risk + компоненты AI Act — ежеквартально)

Ожидаемый output

Реестр рисков с:

• 12-18 рисков всего (3-4 на топ-5 CDE)
• Все риски классифицированы по 6-осевой taxonomy
• Inherent + residual scoring завершён
• Топ-3 риска с полными записями risk-control matrix
• Топ-3 риска с структурированными формулировками «If [event] then [consequence]»
• Идентифицированы владельцы (single или multi-axis согласно M1.5)
• Установлены даты следующих обзоров на каденс
• Покрыты 5 категорий источников по всему реестру (тест: отфильтровать по категории источника — все 5 представлены)

Self-check критерии

После завершения реестра, проверьте:

Распространённые ошибки (избегайте)

1. Идентификация только внутренних событий. Просканированы только внутренние события; пропущены внешние + стратегические + люди. Результат: 3-4 риска на CDE в очевидных категориях; 5-6 пробелов. Лекарство: явно применить 5-категорийную матрицу; не останавливаться после 3 рисков на CDE.

2. Single-axis-классификация multi-axis-риска. Алгоритмический bias классифицирован только под accuracy. Результат: контроли ethics + privacy не спроектированы; regulatory exposure невидим. Лекарство: Multi-axis разрешена; задокументировать основную + второстепенные; обеспечить, что контроли покрывают все оси (пример M2.6).

3. Inherent = residual scoring. Ленивый scoring — копирование inherent в residual без артикуляции снижения от контролей. Результат: реестр не демонстрирует снижение риска; нельзя показать эффективность ERM. Лекарство: артикулируйте, какой контроль вызывает какое снижение; явный расчёт residual.

4. Тихий Accept. Риски помечены Accept без обоснования, подписи, истечения. Лекарство: каждая запись Accept — полная документация (обоснование, подпись, истечение, триггеры переоценки, компенсирующие контроли). Anti-pattern #3 из M2.2.

5. Расплывчатые risk statements. «Driver earnings risk» (без структуры). Результат: невозможно оценить likelihood / impact / response. Лекарство: «If [конкретное событие] then [конкретное последствие + оценка магнитуды]».

6. Владелец = «Data Team». Общие записи ownership. Результат: никакого подотчётного индивида; аудит находит accountability gap. Лекарство: Именованная роль (VP Finance + Engineering Lead совместно) или конкретный head функции; multi-axis для сложных рисков.

7. Пропуск каденса. next_review_date пустое. Результат: реестр статичен; риски материализуются без обзора. Лекарство: обязательное поле; дефолт — раз в полгода; ежеквартально для high-risk + AI-related; ежегодно для low-risk.

8. Нет прослеживаемости к реестру CDE. Риски не связаны с CDE ID. Результат: невозможно ответить «какие риски затрагивают этот CDE?»; учёт изолирован. Лекарство: cde_id — обязательное поле; multi-CDE риски перечислены в реестре со всеми связанными ID.

Opt-in tooling sketch — импорт в GRC-платформу

После завершения markdown-based реестра, опциональный следующий шаг — импорт в GRC-платформу. Hands-on в M7; здесь — sketch.

Решение SwiftRide (иллюстративно): Начальный реестр T+3M — markdown / Google Sheets (output этого lab); миграция в Workiva в Q4 2026 для SOX-аттестации; дополнить ServiceNow IRM, если уже развёрнут. Пропустить Archer / LogicGate, учитывая существующее согласование инструментов.

Связь с M3 + M5

Этот lab — input для:

• M3 (Regulatory Landscape) — каждый риск имеет regulatory mapping (SOX, GDPR, EU AI Act, AMLR и т.д.). M3 углубляет регуляторные специфики на регуляцию; output lab — это начальный mapping, который M3 оттачивает.
• M5 (Controls Design) — записи risk-control matrix (топ-3 риска) — стартовая структура. M5 расширяется до полного controls catalog, покрывающего все материальные риски; проектирует evidence pipelines; протоколы тестирования operating effectiveness.

Output lab прослеживается через курс: short-list M1.7 → реестр рисков M2.7 → regulatory deep dive M3 → полный реестр CDE M4 → controls catalog M5 → evidence pipelines M7.

Итоги (self-assessment summary lab)

Если выполнено корректно, ваш реестр рисков для топ-5 CDE SwiftRide имеет:

• 12-18 рисков (3-4 на CDE)
• Все 5 категорий источников представлены по реестру
• Классификация по 6-осевой taxonomy на риск (основная + второстепенные, где применимо)
• Структурированные формулировки «If [event] then [consequence]»
• Inherent + residual scoring, демонстрирующий эффект контролей
• Risk treatments (в основном Mitigate; немного информированный Accept; редко Share)
• Топ-3 риска с полной risk-control matrix (objective + 2-4 activities + evidence)
• Multi-axis ownership, где применимо
• Regulatory mapping на риск
• Каденс установлен на риск

Далее — M3 (Regulatory Landscape) — 10 уроков глубокого погружения в SOX, BCBS 239, Basel, IFRS, GDPR, DORA, EU AI Act, PCI-DSS, AML с юрисдикционными спецификами + временным мэппингом.

Модуль M2 завершён. Экзамен по модулю — синтез по всем 7 урокам (frameworks, lines model, maturity, taxonomy, matrix, lab).