Введение
CDO SwiftRide получил от Big 4 список pre-IPO findings; параллельно CRO готовит первый отчёт Enterprise Risk Management для нового Board Risk Committee. На kick-off CRO задаёт CDO вопрос: «Какой risk framework мы используем для данных? COSO ERM? ISO 31000? Что-то своё?». Это не риторический вопрос — audit committee будет требовать формулировки recognized framework в каждом attestation-документе.
Этот урок — фиксация COSO ERM 2017 (Enterprise Risk Management, июнь 2017) как рабочего framework для data risk и точное разграничение с COSO IC 2013 (Internal Control, май 2013). После урока вы сможете на уровне совета директоров объяснить, какие data risk activities попадают в scope ERM, какие — в scope IC, и почему это различие важно при SOX-attestation.
Две редакции COSO, одна семья
COSO (Committee of Sponsoring Organizations of the Treadway Commission, комитет спонсорских организаций комиссии Тредвея) публикует две связанные, но разные редакции:
- COSO IC — Internal Control Integrated Framework (май 2013) — действующая, заменила framework 1992 года с 15 декабря 2014. 5 компонентов, 17 принципов. De facto framework для SOX 404 management assessment COSO IC 2013 Principle 11.
- COSO ERM — Enterprise Risk Management Integrating with Strategy and Performance (июнь 2017) — действующая, заменила framework 2004 года. 5 компонентов, 20 принципов.
Фреймворки не конкурируют — они дополняют друг друга. IC фокусируется на operational, compliance и financial reporting objectives. ERM расширяет до strategy + performance, встраивая мышление о рисках в стратегические решения. Для SwiftRide:
- Ежеквартальный SOX-relevant attestation для CDE → framework IC.
- Ежегодный ERM-отчёт для совета директоров с консолидированным взглядом на риски по всем БЮ → framework ERM.
- Один Data Council обслуживает оба — единая регистрация, разные срезы данных.
COSO ERM 2017 — структура
5 компонентов, 20 принципов COSO ERM 2017.
Каждый компонент — этап жизненного цикла risk-thinking. Тултипы на компонентах раскрывают список принципов.
Принципы 1-5Принципы 1-5: Exercises Board Risk Oversight; Establishes Operating Structures; Defines Desired Culture; Demonstrates Commitment to Core Values; Attracts/Develops/Retains Capable Individuals.
Принципы 6-9Принципы 6-9: Analyzes Business Context; Defines Risk Appetite; Evaluates Alternative Strategies; Formulates Business Objectives. Здесь рождаются risk appetite statements и стратегические выборы по рискам.
Принципы 10-14Принципы 10-14: Identifies Risk; Assesses Severity of Risk; Prioritizes Risks; Implements Risk Responses; Develops Portfolio View. Это операционное ядро ERM — идентификация рисков, scoring, response, портфельная агрегация.
Принципы 15-17Принципы 15-17: Assesses Substantial Change; Reviews Risk and Performance; Pursues Improvement in Enterprise Risk Management. Это loop-back — переоценка по триггерам изменений + непрерывное улучшение.
Принципы 18-20Принципы 18-20: Leverages Information and Technology; Communicates Risk Information; Reports on Risk, Culture, and Performance. Это reporting-слой — данные, коммуникация, board-ready-выходы.
Ключевой сдвиг 2017 — интеграция со strategy и performance. ERM 2004 трактовался как параллельная функция управления рисками рядом с бизнесом. ERM 2017 — это lens, через которую организация смотрит на стратегические решения. Риск не в углу; риск на strategy-митинге.
Для дата-инженера это означает: когда команда выбирает между Snowflake и BigQuery для критичной reporting-нагрузки, risk assessment не «делается потом командой compliance» — это часть architectural decision document со ссылкой на risk appetite.
COSO ERM vs COSO IC — где граница
| Аспект | COSO IC 2013 | COSO ERM 2017 |
|---|---|---|
| Основной фокус | Operations, reporting, compliance objectives | Strategy + performance + риск |
| Аудитория | Менеджмент, оценивающий эффективность внутреннего контроля | Совет директоров + executive + риск-функция |
| Использование по умолчанию в SOX | Обязательный recognized framework для 404 attestation | Опциональное дополнение |
| Data scope | Качество данных, IT general controls, доступ к системам | Риски для целей, включая решения на основе данных |
| Output | Матрица контролей, отчёт о deficiencies, заключение по ICFR | Реестр рисков, портфельный view, отчётность по риск-аппетиту |
| Периодичность | Непрерывно (ежегодная полная оценка) | Ежегодно + по триггерам изменений |
Правило для SwiftRide: SOX-relevant data controls (revenue, payouts, фиды в финансовую отчётность) → framework COSO IC, чёткий мэппинг в Principles 10-12. Enterprise-wide data risk (предвзятость AI pricing engine, vendor concentration risk, data sovereignty exposure) → COSO ERM, мэппинг в Principles 6-9 (Strategy & Objective-Setting). Когда вопрос «можем ли мы доверять модели?» — это ERM. Когда вопрос «работает ли контроль над фидом в revenue recognition?» — это IC.
Реестр рисков — что внутри для данных
Реестр рисков (risk register) — первичный артефакт COSO ERM Principles 10-12. Это структурированный список идентифицированных рисков со scoring, response, владением. Для data-программы SwiftRide минимально жизнеспособный реестр имеет 14 колонок:
| Колонка | Описание | Пример (SwiftRide) |
|---|---|---|
risk_id | Устойчивый идентификатор | swiftride-risk-2026-014 |
risk_statement | Одно предложение, структура «If [event] then [consequence]» | «If pricing engine outputs systematically biased to driver-favouring surge, then revenue mis-recognition + DSA transparency exposure» |
risk_category | Ось таксономии (см. урок 5) | accuracy + ethics |
inherent_likelihood | 1-5, до контролей | 4 |
inherent_impact | 1-5, до контролей | 5 |
inherent_score | Вычисляемое | 20 |
current_controls | Существующие меры митигации | Daily PSI monitoring; quarterly bias audit |
residual_likelihood | 1-5, после контролей | 2 |
residual_impact | 1-5, после контролей | 4 |
residual_score | Вычисляемое | 8 |
risk_response | Accept / Avoid / Mitigate / Share / Transfer | Mitigate |
risk_owner | Подотчётный руководитель | Head of ML Platform + Chief Risk Officer co-sign |
related_cde | Связанные CDE ID (перекрёстная ссылка) | swiftride-cde-2026-004 pricing-engine-outputs |
next_review_date | Триггер переоценки | 2026-11-15 (раз в полгода) |
В production-реестрах — дополнительные поля для ссылок на evidence, протоколов decision council, подписей о принятии остаточного риска.
Критический принцип: реестр рисков не существует изолированно. Каждая запись должна быть прослеживаемой к реестру CDE (если связана с данными) или к process inventory (если операционная). Без этой прослеживаемости реестр рисков превращается в параллельный артефакт учёта, который никто не читает после первого квартала.
Risk appetite vs tolerance vs capacity — три точных различения
Три термина часто путают, но в COSO ERM они имеют разные значения COSO ERM Principle 7. Путаница стоит реальных денег при challenge со стороны совета директоров.
Risk appetite (риск-аппетит) — объём и тип риска, который организация готова принять в рамках реализации стратегии. Это намеренный стратегический выбор, а не ограничение. Высокий риск-аппетит не означает «бесконтрольно»; означает «осознанно accept высокий потенциал ради достижения высокой ценности».
Пример SwiftRide: «Принимаем высокий риск-аппетит для AI-driven pricing optimisation (значительный revenue upside оправдывает высокий модельный риск при дисциплинированном MRM). Принимаем низкий риск-аппетит для нарушений AML compliance (unlawful behaviour = автоматически material, нулевая толерантность к systemic gaps).»
Risk tolerance — допустимое отклонение от целей. Если цель — «monthly revenue $200M ±5%», tolerance — 5%. За пределами tolerance триггерится эскалация. Tolerance числовой, измеримый.
Пример SwiftRide: «Daily SwiftPay reconciliation tolerance: <0.1% gap между commission_calculation_outputs и actual driver_payouts (above — incident).» «AML alert false-positive rate tolerance: <5% (above — model recalibration).»
Risk capacity — максимальный риск, который организация может поглотить без катастрофического сбоя. Это ограничение, а не выбор. Capacity — функция капитала, ликвидности, regulatory headroom, репутации.
Пример SwiftRide: «Один material weakness в SOX attestation = capacity-breaching. Сбой внутреннего контроля, вызвавший >$50M убытка без страхового покрытия = capacity-breaching. Потеря возможности IPO из-за compliance breach = capacity-breaching.»
Правило принятия решений: appetite ≤ tolerance bands ≤ capacity. Если организация работает за пределами capacity — экзистенциальный риск. Если работает выше tolerance — пробелы в контроле. Если работает ниже appetite — оставляет ценность на столе.
Количественное и качественное выражение рисков
COSO ERM 2017 явно поддерживает обе формы выражения рисков, не отдавая приоритет количественной над качественной. Это сдвиг от редакции 2004 года, которая была более количественно смещённой.
Количественное выражение работает, когда:
- Доступны исторические данные для базовой линии (loss history, частота инцидентов)
- Магнитуда измерима в финансовых / операционных единицах ($M, % MAU, часы downtime)
- Статистические отношения понятны (Loss Distribution Approach для operational risk)
- RoI моделирования оправдывает усилия (топ-20% рисков в реестре)
Пример: «SwiftPay rounding incident 2024 вызвал 1.5M. Mitigation control снижает probability до 1 per 60 months. Annualised expected loss with control: $0.5M.»
Качественное выражение работает, когда:
- Недостаточно исторических данных (новые риски — enforcement actions по EU AI Act)
- Репутационные / стратегические измерения трудно квантифицировать
- Кросс-функциональные риски, где количественная агрегация вводит в заблуждение
- Коммуникация с нетехническими членами совета директоров
Пример: «EU AI Act high-risk classification для pricing engine — high probability of enforcement scrutiny после августа 2026. Material reputational exposure если первый публично освещённый случай. Quantification преждевременна до first enforcement precedents. Mitigation: pre-emptive Annex IV technical documentation, independent fundamental rights impact assessment, conservative deployment gates.»
Смешанный подход — наиболее распространён на практике. Количественный score для inherent / residual likelihood + impact, качественный нарратив для контекста, обоснования response, триггеров эскалации. ERM-обучение Q1 2026 для CRO-функции SwiftRide делает акцент на смешанном подходе как на дефолтном.
SwiftRide pre-IPO — ERM в применении к данным
Мэппинг от компонентов COSO ERM к конкретным активностям data-программы на T0 (старт CDE-программы):
| ERM-компонент | Активность по данным SwiftRide (T0 → T+18M) |
|---|---|
| Governance & Culture (Principles 1-5) | Board Risk Committee chartered Q1 2026; reporting lines CDO + CRO; ежегодный опрос risk-aware-культуры; CDE programme charter подписан CEO |
| Strategy & Objective-Setting (Principles 6-9) | Risk appetite statement (покрывает оси data risk — accuracy, integrity, privacy, ethics, availability); data-стратегия согласована с таймлайном IPO; рассмотрены альтернативы (in-house GRC tool vs Workiva); годовые цели для data-программы |
| Performance (Principles 10-14) | Реестр рисков операционен на T+3M (стартовые 24 риска, привязанные к 24 CDE); scoring через rubric likelihood/impact, согласованный с COSO ERM; решения о response задокументированы; портфельный view (data risk dashboard) операционен на T+6M |
| Review & Revision (Principles 15-17) | Quarterly Board Risk Committee review; переоценка по триггерам (AI Act enforcement, regulatory change, M&A); ежегодный полный ERM refresh; цикл непрерывного улучшения (audit findings → обновления framework) |
| Information, Communication & Reporting (Principles 18-20) | Risk MIS + дашборды (Q1 2026 → Q1 2027); язык рисков в OKR и инженерных тикетах; ежегодный ERM-отчёт для совета директоров (Q2 2026 первая версия); метрики risk-культуры в опросах сотрудников |
Критично: не ждите T+18M, чтобы начать внедрять ERM. Начальная версия реестра рисков для топ-10 data risks возможна на T+1M (одновременно со стартом CDE-программы). Полное покрытие поэтапно расширяется до T+12M. К моменту внешнего audit walkthrough на T+15M ERM-артефакты должны быть операционными, а не черновыми.
Anti-patterns
1. Трактовка ERM как параллельной функции. Риск-команда пишет ERM-артефакты в изоляции от бизнес-решений. Результат: реестр рисков не отражает реальное принятие решений; совет директоров с удовольствием обходит риск-функцию. Лекарство: встроить риск-офицеров в strategy / product committees; язык рисков в decision-документах.
2. Смешение scope IC и ERM. Риск-команда пытается аудировать operational controls через ERM-lens — не тот framework. Результат: пробелы в покрытии IC (мы думали — ERM покрывает); дублирующие усилия. Лекарство: явная scope matrix; IC = контроли, ERM = риски-для-целей.
3. Статичный риск-аппетит. Аппетит написан один раз и не обновляется. Результат: appetite-drift — реальная практика расходится с задокументированным аппетитом, аудит находит пробел. Лекарство: минимум ежегодный пересмотр; пересмотры по триггерам (M&A, regulatory change, крупный инцидент).
4. Только количественно или только качественно. Чистая количественность пропускает новые риски; чистая качественность теряет доверие совета директоров. Результат: ERM либо теоретический, либо анекдотический. Лекарство: смешанный подход по умолчанию; обязательно оба для топ-рисков.
5. Реестр рисков без прослеживаемости. Риски в реестре не связаны с CDE / процессами / контролями. Результат: невозможно ответить «что это митигирует?» при аудите; двойная бухгалтерия. Лекарство: схема требует связанных артефактов; интеграция инструментов (Workiva / Archer / ServiceNow IRM).
6. ERM-на-таблицах после T+12M. Начальная таблица OK; production-масштаб требует инструмента. Результат: конфликты версий, нет audit trail, утрата институциональной памяти. Лекарство: миграция таблица → GRC-инструмент с согласованием governance.
Итоги
- COSO ERM 2017 (июнь 2017) — действующий; 5 компонентов, 20 принципов. Ключевой сдвиг: интеграция со strategy + performance.
- COSO IC 2013 (май 2013) — действующий; 5 компонентов, 17 принципов. De facto framework для SOX 404.
- Дополняющие, а не конкурирующие. IC = фокус на контролях; ERM = фокус на рисках-для-целей. Один Data Council обслуживает оба.
- Реестр рисков — первичный артефакт ERM для Principles 10-12. Минимум 14 колонок; прослеживаемость до CDE и процессов критична.
- Risk appetite ≤ tolerance bands ≤ capacity. Три различных концепта; путаница стоит доверия совета директоров.
- Количественный + качественный смешанный подход — дефолт в ERM 2017. Чистая количественность пропускает новые риски; чистая качественность теряет доверие при аудите.
- Прогрессия SwiftRide T+1M → T+15M. Стартовые 10 рисков → полная операционная ERM до walkthrough.
- Шесть anti-patterns: параллельная функция, смешение, статичный риск-аппетит, крайности quant/qual, нет прослеживаемости, таблицы за пределами масштаба.
- Далее (урок 2) — ISO 31000:2018 + ISO 27005 — альтернативный framework, когда какой использовать.