Learning Platform
Глоссарий Troubleshooting
Урок 03.02 · 25 мин
Продвинутый
ISO 31000ISO 27005Risk ProcessRisk IdentificationRisk Treatment

Введение

SwiftRide N.V. — нидерландский холдинг с операциями в 40 странах. Когда CDO встречается с CISO немецкой дочерней компании для обсуждения интеграции управления рисками, CISO говорит: «Мы работаем по ISO 31000 и ISO 27005 — это наш референс. COSO у нас не используется». Этот разговор типичен: организации с EU-корнями часто оперируют в ISO-ландшафте, с US-корнями — в COSO-ландшафте. SwiftRide как pre-IPO трансатлантическая компания должна понимать оба.

Этот урок — ISO 31000:2018 (Risk Management — Guidelines) и ISO 27005:2022 (Information Security Risk Management) как рабочие фреймворки. После урока вы сможете объяснить, когда ISO 31000 предпочтительнее COSO ERM, как ISO 27005 встраивается под зонтик ISO 31000, и как один реестр рисков обслуживает оба фреймворка в setup SwiftRide.

ISO 31000:2018 — структура

ISO 31000:2018 опубликован в феврале 2018, заменил версию 2009 года ISO 31000 :2018. Не сертифицируемый (guidelines, а не requirements), но широко принят как референсный фреймворк. Три уровня:

8 принципов (уровень purpose)

Это не выполнимые инструкции — это качества, которыми эффективный risk management должен обладать:

  1. Integrated — risk management — часть governance, а не побочная активность.
  2. Structured and comprehensive — систематический подход, согласованные результаты.
  3. Customised — адаптирован к контексту организации.
  4. Inclusive — вовлекает стейкхолдеров.
  5. Dynamic — адаптируется к изменениям.
  6. Best available information — явное признание качества данных и неопределённости.
  7. Human and cultural factors — учитывает поведение, культуру.
  8. Continual improvement — учится на опыте.

Эти принципы — тест, который применяется к существующей программе: интегрирована? адаптирована? непрерывно улучшается? Гипотетическая чисто количественная модель рисков без stakeholder input провалит Principle 4.

6 элементов framework (операционный уровень)

Framework — управленческая структура для встраивания risk management в организацию. Циклический, а не линейный:

ISO 31000:2018 framework — 6 элементов

Циклическая структура: Leadership and commitment в центре; остальные 5 элементов вращаются вокруг

1. Leadership & commitment
Владение топ-менеджментаLeadership and commitment. Топ-менеджмент и governing body демонстрируют подотчётность. Без этого фреймворк — бумажное упражнение.
2. Integration
Встроить в орг-структуруIntegration. Risk management встроен в организационную структуру и процессы (стратегическое планирование, project management, управление изменениями).
3. Design
Политика + роли + ресурсыDesign. Понимание организации и контекста, формулирование risk management policy, назначение ролей, выделение ресурсов, установление коммуникации.
4. Implementation
Исполнить фреймворкImplementation. Исполнение фреймворка — план применяется, механизмы операционны. Критично: разрыв между дизайном и операцией.
5. Evaluation
Измерить результатыEvaluation. Периодическое измерение против ожидаемых результатов. KPI (частота инцидентов, время response, опрос risk-культуры).
6. Improvement
Непрерывная адаптацияImprovement. Непрерывная адаптация — с учётом результатов оценки, изменений среды, извлечённых уроков.

5 шагов процесса (уровень активности)

Это идентифицируемые, операционно значимые шаги — для каждого риска индивидуально:

Процесс risk management по ISO 31000:2018

5 шагов для каждого идентифицированного риска; communication, consultation, monitoring обвязывают всё

1. Scope, context, criteriaScope, context, criteria. Определяет границы анализа, внутренний/внешний контекст, risk criteria (что считать материальным).
2. IdentificationRisk identification. Что может случиться? Какие источники, события, причины, последствия? Не скорит пока — фиксирует.
3. AnalysisRisk analysis. Likelihood + consequence + уровень риска. Может быть количественным, качественным или полуколичественным.
4. EvaluationRisk evaluation. Сравнение результатов анализа с criteria — решение: treat / accept / further analyse / re-frame.
5. TreatmentRisk treatment. Mitigate (modify) / Share (transfer) / Avoid (eliminate) / Accept / Retain. Итеративно: после treatment риск переоценивается.
loop-back
Monitor + CommunicateMonitoring + review во всех шагах; communication + consultation во всех шагах. Это не отдельный шаг — это обёртка.

Критично: monitoring + communication — не активности после treatment. Они обвязывают весь процесс. Risk identification без консультации со стейкхолдерами проваливает Principle 4; анализ без коммуникации к decision-makers проваливает Principle 6.

ISO 27005:2022 — управление рисками информационной безопасности

ISO/IEC 27005:2022 (Information security, cybersecurity and privacy protection — Guidance on managing information security risks) — четвёртая редакция, опубликована в октябре 2022. Это операционное дополнение к ISO 31000 для infosec/cyber-рисков ISO 27005 :2022.

Не заменяет ISO 31000 — это сужение, применённое к конкретному классу рисков. Структура зеркалит ISO 31000:

Элемент ISO 31000Специализация ISO 27005
Scope, context, criteriaAsset identification, threat catalogues (ссылки на ISO 27001 Annex A)
IdentificationТриангуляция asset → threat → vulnerability
AnalysisScoring в стиле CVSS, факторы likelihood (skill, opportunity, motivation)
EvaluationInformation security risk criteria (нарушения CIA triad)
TreatmentПодбор контролей (ISO 27001 Annex A + sectoral overlays)
MonitoringМониторинг событий безопасности, реагирование на инциденты

Изменения ISO 27005:2022 vs 2018: согласование с терминологией ISO 31000:2018 + контролями ISO 27001:2022 (пересмотренный Annex A с 93 контролями против 114 ранее). Усиленный акцент на context-driven risk identification и scenario-based анализ.

Для SwiftRide: CISO немецкой дочки рассматривает ISO 27005 как основной инструмент. CDO Office интегрирует через единую терминологию — реестр рисков у CDO имеет колонку iso_27005_scenario_id для перекрёстной ссылки на каталог CISO. Один enterprise risk view, два framework-specific view.

ISO 31000 vs COSO ERM — когда какой

АспектISO 31000:2018COSO ERM 2017
ПроисхождениеМеждународный (ISO) — географически нейтральныйСША (COSO) — изначально для US accounting controls
СертифицируемыйНет (guidelines)Нет (framework)
Уровень детализацииБолее высокая абстракция; более гибкийБолее предписывающий; встроенные best practices
Основная аудиторияПрофессия risk management во всех отрасляхСовет директоров публичных компаний + руководители + аудиторы
Интеграция со стратегиейЧерез Principles + frameworkЯвный компонент Principle 6-9 — strategy + objective-setting
Региональное предпочтениеEU, UK, Asia-PacificСША, Канада
Экосистема инструментовISO 31010 (risk assessment techniques) — крепкая библиотекаЗрелые US-центричные инструменты (Workiva, Archer) часто согласованы с COSO
Релевантность SOXНе упомянут напрямуюDe facto IC 2013 + дополнение ERM 2017

Выбирайте ISO 31000, когда:

  • Многонациональное присутствие с EU/UK/APAC-смещением
  • Среди стейкхолдеров есть поставщики, сертифицированные по ISO 27001 / 22301 / 9001
  • Риск-функция подотчётна CRO (не напрямую CFO)
  • Программа не управляется SOX напрямую

Выбирайте COSO ERM, когда:

  • Листинг в США (SOX), публичная компания
  • Audit Committee ожидает отчётность, согласованную с COSO
  • Инструменты (Workiva, Archer, MetricStream) оптимизированы под COSO
  • Сильный существующий IC framework (COSO IC 2013) — связность через одну семью

Гибрид (setup SwiftRide):

SwiftRide использует COSO ERM как основной (путь к листингу в США) и терминологию ISO 31000 внутри для многонациональной связности. Схема реестра рисков покрывает оба: принципы COSO ERM в именах атрибутов, шаги процесса ISO 31000 в стадиях workflow. ISO 27005 — встроен под ISO 31000 для infosec-рисков. CDO Office ведёт mapping matrix:

Поле реестра рисковПринцип COSO ERMШаг ISO 31000
risk_statementP10 Identifies RiskStep 2 Identification
inherent_score, residual_scoreP11 Assesses SeverityStep 3 Analysis
risk_responseP13 Implements Risk ResponsesStep 5 Treatment
next_review_dateP15-16 Review & RevisionMonitor + review обёртка

Практика: матрица идентификации рисков для одного CDE

ISO 31000 Step 2 (Identification) — наиболее ошибкоопасный шаг на практике. Риски, пропущенные на этом этапе, никогда не попадают в реестр. Структурный подход — risk identification matrix на CDE:

ИзмерениеИсточники для сканирования
Внутренние событияСбои систем (DB outage, schema drift); сбои процессов (ошибки ручных рабочих потоков); человеческие ошибки (ввод данных, деплой кода)
Внешние событияКибератаки; сбои вендоров (Snowflake outage, Confluent downtime); регуляторные изменения; рыночные события
События, специфичные для данныхДеградация качества исходных данных; разрывы lineage; сбои reconciliation; тихие сбои пайплайнов
События людей/культурыInsider threat; потеря ключевого персонала (single-person-dependency); пробелы в навыках
Стратегические событияСдвиг бизнес-модели; интеграционный риск M&A; риски data sovereignty при выходе на новый рынок

Применяем эту матрицу к одному CDE — driver_earnings_ledger SwiftRide:

Категория источникаКонкретный рискLikelihoodImpact
Внутреннее событиеОшибка округления при расчёте комиссии (инцидент 2024)24
Внешнее событиеНалоговый аудит вскрывает per-country mis-calculation24
Событие данныхЛаг репликации исходного PostgreSQL вызывает устаревшие данные в payouts33
Событие людейПотеря инженера payroll без документированной передачи23
Стратегическое событиеDACH labour reclassification (employee vs contractor)15

Из этой матрицы — 5 рисков для реестра. Без структурного подхода легко идентифицировать только внутренние события (типичный bias). ISO 31000 Principle 6 (best available information) явно требует сканирования по нескольким источникам.

Варианты treatment рисков — точная таксономия

ISO 31000:2018 Section 6.5 определяет 7 вариантов risk treatment. На практике часто упрощают до 4-5; полный список:

  1. Avoid — не вовлекаться в активность, создающую риск
  2. Take or increase — принять больший риск ради возможности (positive risk taking)
  3. Remove source — устранить базовую причину
  4. Modify likelihood — контроли, снижающие вероятность
  5. Modify consequence — контроли, снижающие impact
  6. Share with another party — страхование, контракт, партнёрство
  7. Retain by informed decision — принять остаточный после должного рассмотрения

В реестре SwiftRide — свёрнуто до стандартных 5: Avoid / Mitigate (объединяет 3, 4, 5) / Share / Transfer (подмножество Share) / Accept.

Критично: «accept» — информированное решение, а не дефолт. Документация требует явного обоснования и подписи подотчётного владельца. Тихое принятие (риск остался в реестре без решения о treatment) — частая audit finding.

Пример SwiftRide — процесс ISO 31000 на одном CDE

Применяем 5-шаговый процесс к CDE pricing_engine_outputs:

Шаг 1 — Scope, context, criteria. Scope: CDE pricing_engine_outputs (surge multipliers, цена для райдера, оплата водителю). Контекст: EU AI Act high-risk classification вероятна с августа 2026; применимы обязательства DSA по transparency; возможен антимонопольный надзор. Критерии: любой алгоритмический disparate impact >2% триггерит эскалацию; любое уведомление о regulatory enforcement = материальное.

Шаг 2 — Identification. Идентифицировано 7 рисков по категориям: model bias, model drift, качество входных features, сбой компонента third-party-модели, regulatory enforcement, антимонопольный вызов, потеря талантов.

Шаг 3 — Analysis. Количественные likelihood/impact для model bias (исторические данные распределения PSI); качественные для regulatory enforcement (нет прецедентов); полуколичественные для drift (рамки расчёта задокументированы, но enforcement — субъект суждения).

Шаг 4 — Evaluation. 5 рисков оценены как «требуют treatment» (выше tolerance), 2 — «monitor and accept» (ниже tolerance, низкая likelihood).

Шаг 5 — Treatment. Model bias: митигация через quarterly fairness audit + monthly PSI monitoring (modify likelihood + modify consequence). Model drift: митигация через автоматический retraining gate + champion-challenger comparison. Regulatory enforcement: share через retainer внешнего юридического советника + подготовка документации в стиле Annex IV (modify consequence). Антимонопольный: avoid через явный отказ координироваться с конкурентами. Потеря талантов: share через кросс-обучение + задокументированные runbooks (modify consequence).

Monitor + Communicate обвязывают всё: ежемесячный совместный обзор CDO + CRO; quarterly summary для Board Risk Committee; консультации со стейкхолдерами на закрытии квартала (engineering, ML, compliance, legal, BU leads).

Проверка знанийKnowledge check
CISO немецкой дочки SwiftRide предлагает использовать ISO 27005:2022 для всех активностей по управлению рисками информационной безопасности, отдельно от реестра рисков CDO Office (который использует терминологию COSO ERM). CDO возражает: «Единый enterprise risk view критичен для audit-readiness; никакого двойного учёта». Какой подход примиряет обе позиции согласно M2.2?
ОтветAnswer
Единый enterprise-реестр рисков с двойной framework-ссылкой. Подход: (1) Поддерживать ОДИН центральный реестр рисков под governance CDO Office — схема покрывает оба фреймворка через колонки (например, `coso_erm_principle`, `iso_31000_step`, `iso_27005_scenario_id`). (2) Работа по ISO 27005 остаётся основным инструментом для функции CISO — все infosec-специфичные активности (asset catalog, threat scenarios, анализ CIA triad) выполняются по фреймворку ISO 27005. (3) При создании записи в реестре — CISO записывает поля, специфичные для ISO 27005; CDO Office автоматически заполняет перекрёстные ссылки COSO ERM через mapping matrix. (4) Audit-ready экспорты настраиваемы: COSO-style view для Audit Committee и аудитора из США; ISO-style view для EU regulator submissions и сертификационного органа ISO 27001. (5) Единый источник истины — без параллельного учёта. (6) Совместный quarterly review CDO + CRO + CISO — обзор одного реестра через две framework-lens. (7) Tooling — GRC-платформа (Workiva / Archer / ServiceNow IRM), поддерживающая custom field schema, обслуживает оба. Критический anti-pattern: параллельные реестры в двух функциях — гарантированные несоответствия; «какая версия истины?» — автоматическая audit finding. Translation matrix между фреймворками должна быть задокументирована, версионирована и пересмотрена (ежегодно + при изменении версии фреймворка, например при обновлениях ISO 27005).

Anti-patterns

1. Трактовка ISO 31000 + COSO ERM как взаимоисключающих. Выбрать один, отвергнуть другой. Результат: международные организации сталкиваются с framework-mismatch со стейкхолдерами. Лекарство: гибридный mapping (как setup SwiftRide).

2. ISO 27005 без зонтика ISO 31000. CISO работает в ISO 27005 изолированно; CDO Office — в COSO; CRO — в framework-agnostic таблицах. Результат: enterprise risk view фрагментирован; нет единого Board MIS. Лекарство: ISO 27005 встроен под ISO 31000 (или COSO ERM); mapping matrix задокументирован.

3. Тихое принятие. Риски остаются в реестре под Accept без явной подписи, обоснования, даты пересмотра. Audit finding: «не информированное решение». Лекарство: response Accept требует подписи, обоснования, даты истечения.

4. Идентификация рисков только через lens внутренних событий. Шаг identification покрывает только сбои систем и человеческие ошибки; пропущены внешние, стратегические события и события людей. Результат: пробелы вскрываются инцидентами. Лекарство: identification matrix, покрывающая 5 категорий источников.

5. Monitoring без communication. События рисков мониторятся, но не коммуницируются decision-makers вовремя. Результат: известные риски материализуются без митигации; аудит находит «известные и проигнорированные». Лекарство: задокументированы пороги monitoring → communication; обязательные пути эскалации.

6. Принятие фреймворка без customisation. Организация принимает ISO 31000 буквально, без адаптации согласно Principle 3 (Customised). Результат: бумажный compliance, никакого операционного улучшения. Лекарство: адаптируйте категории рисков, пороги response, governance под контекст организации.

Итоги

  • ISO 31000:2018 (февраль 2018) — действующий; 8 принципов, 6 framework-элементов, 5 шагов процесса. Не сертифицируемый, guidelines.
  • ISO 27005:2022 (октябрь 2022) — действующий; операционное дополнение к ISO 31000 для рисков информационной безопасности. Согласован с ISO 27001:2022 Annex A (93 контроля).
  • Выбирайте ISO 31000, когда: EU/UK/APAC-смещение, ISO-сертифицированная экосистема, риск-функция под управлением CRO, не SOX-программа.
  • Выбирайте COSO ERM, когда: US-listed, под управлением SOX, инструменты, согласованные с COSO, framework IC 2013 уже операционен.
  • Гибрид (SwiftRide): COSO ERM основной (US listing), терминология ISO 31000 для многонациональной связности, ISO 27005 встроен для infosec.
  • Матрица идентификации рисков — 5 категорий источников (внутренние, внешние, специфичные для данных, люди/культура, стратегические). Без структурного подхода пробелы неизбежны.
  • Таксономия treatment — Avoid / Mitigate / Share / Transfer / Accept (свёрнутая из 7 опций ISO). Accept требует информированного решения, подписи, истечения.
  • Единый enterprise-реестр рисков с двойной framework-ссылкой — основное лекарство от anti-pattern.
  • Далее (урок 3) — Three Lines Model (IIA, июль 2020) — кто что делает в CDE-программе.
Audit Logging и Compliance

Проверьте понимание

Результат: 0 из 0
Прикладной
Вопрос 1 из 4. SwiftRide German subsidiary CISO работает под ISO 27005:2022 + ISO 31000:2018; SwiftRide HQ CDO/CRO работают под COSO ERM 2017. Big 4 audit team на pre-IPO walkthrough спрашивает: «Покажите single enterprise risk view». Какой approach correct per M2.2 hybrid setup, и почему?

Закончили урок?

Отметьте его как пройденный, чтобы отслеживать свой прогресс

Войдите чтобы оценить урок

Прогресс модуля
0 из 7