Введение

SwiftRide Q1 2026, репетиционный walkthrough с Big 4. Senior audit manager задаёт CDO простой вопрос: «Покажите, какие контроли покрывают риск ошибки расчёта driver earnings». CDO открывает реестр рисков — есть risk-id, есть risk_statement, есть поле current_controls («Daily reconciliation; quarterly audit»). Senior manager не удовлетворён: «Это control activities. Где control objective, который они поддерживают? И как собирается evidence?». Это — классический Risk-Control-Matrix audit pattern.

Этот урок — мост от риск-стороны (идентифицированный риск) к control-стороне (конкретная control activity) через промежуточный концепт «control objective». После него вы сможете построить полную risk-control matrix для одного риска CDE, понять принципы defense-in-depth + control efficiency и подготовить структуру для M5 (дизайн контролей).

Уровни: от риска к evidence

Каждый риск проходит через 4 уровня перед audit-defensible-состоянием:

Уровень 1: Риск (что может пойти не так)
   ↓ требует
Уровень 2: Control objective (что мы должны предотвратить / обнаружить)
   ↓ имплементируется через
Уровень 3: Control activity (как мы операционализируем)
   ↓ производит
Уровень 4: Evidence (что доказывает, что сработало)

Уровень 1 — Риск. Формулировка потенциального неблагоприятного события. Формат: «If [event] then [consequence]». Пример: «If driver earnings commission calculation produces systematically wrong values, then $2M+ underpayment + labour regulation penalties + SOX restatement risk».

Уровень 2 — Control objective. Что организация должна достичь, чтобы митигировать риск. Сформулирован как желаемый исход, а не как activity. Пример: «Driver earnings commission calculation produces accurate values per documented formula; any systematic error detected within 24 hours».

Уровень 3 — Control activity. Конкретный операционный механизм, имплементирующий objective. Сформулирован глаголом активности. Пример: «Daily reconciliation between commission_calculation_engine outputs и source-of-truth driver_payouts ledger, with delta >0.05% triggering investigation within 4 hours».

Уровень 4 — Требование к evidence. Какой артефакт доказывает, что control activity исполнен и произвёл ожидаемый исход. Пример: «Reconciliation log entries с date, source/target sums, delta percentage, signer; ServiceNow ticket для any delta investigation; quarterly attestation by Data Owner».

Критично: objective и activity часто путают. Objective = «что» (предотвращение неверных комиссий); activity = «как» (ежедневная reconciliation). Разные уровни абстракции; оба обязательны в матрице.

Шаблон risk-control matrix

Production-матрица на риск CDE имеет минимум 15 колонок:

Preventive vs Detective vs Corrective

Три типа контроля — различаются по времени относительно события риска:

• Preventive — спроектированы, чтобы остановить наступление события риска. Примеры: применение SoD (нельзя задеплоить собственный код в prod); access controls (нельзя читать PII без явного гранта); 4-eyes approval (нельзя релизнуть без peer review).
• Detective — спроектированы, чтобы обнаружить событие риска после возникновения. Примеры: правила reconciliation (обнаружение несовпавших балансов); DQ-проверки (обнаружение аномальных значений); audit logs (обнаружение несанкционированного доступа).
• Corrective — спроектированы, чтобы ремедиировать после обнаружения. Примеры: runbooks реагирования на инциденты; процедуры data restatement; восстановление из backup.

Принцип defense-in-depth: зрелая CDE-программа имеет несколько контролей на риск, по всем трём типам. Единственный контроль = единая точка отказа. Пример риска ошибки расчёта комиссии: preventive (4-eyes на изменения логики) + detective (ежедневная reconciliation) + corrective (процедура restatement).

Мэппинг одного риска → нескольких controls (defense in depth)

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

Пример: Риск «ошибка расчёта комиссии driver earnings» мэппится на 5 контролей:

Defense-in-depth работает, потому что режимы отказа различаются:

• C-001 ломается, если ревьюер штампует (сговор или усталость) — но C-002, C-003 всё ещё ловят.
• C-002 ломается, если баг в синтаксисе теста — но C-003 всё ещё ловит.
• C-003 ломается, если сам source-of-truth неверен — но C-004 статистический анализ ловит drift.
• C-004 может пропустить тонкий bias, затрагивающий подмножество водителей — но C-005 процедура restatement обрабатывает eventual обнаружение.

Правило: каждый материальный риск CDE должен иметь ≥2 контроля (предпочтительно смешанных типов). Риски с единственным контролем — высокое audit attention.

Мэппинг одного control → нескольких рисков (efficiency)

Обратный мэппинг — один control objective обслуживает несколько рисков. Эффективный дизайн контролей.

Пример: Control objective «Все изменения prod data pipelines требуют 4-eyes peer review + проход автоматических тестов + sign-off» митигирует:

• Риск 1: Дефект кода вносит data quality bug (множественные CDE)
• Риск 2: Злонамеренный insider деплоит несанкционированный код (ось integrity)
• Риск 3: Ошибка оператора при emergency change (availability + accuracy)
• Риск 4: Обход SDLC для «всего лишь config-изменения» (compliance с SOX ITGC change management)

Одна control activity (peer review + tests + sign-off) покрывает 4 риска одновременно. Контроли SOX ITGC часто следуют этому паттерну: один well-designed ITGC покрывает несколько рисков на нескольких CDE.

Компромисс: эффективные контроли (one-to-many) могут стать единой точкой отказа. Если процесс 4-eyes review деградирует (rubber-stamping), 4 риска скомпрометированы одновременно. Митигация: тестирование эффективных контролей более строго (более частое тестирование design + operating effectiveness); мониторинг метрик эффективности контроля.

Полная матрица SwiftRide — ошибка расчёта driver earnings

Табличная форма (audit-ready)

Мост к M5 (дизайн контролей)

Этот урок — сторона рисков матрицы. M5 (Controls Design) — сторона контролей:

Рабочий поток: в M2 вы строите risk-control matrix как дизайн-артефакт — какие контроли адекватно митигировали бы какие риски. В M5 вы строите реальные имплементации контролей — как эти контроли работают, куда приземляется evidence, как происходит тестирование. Та же матрица, разные стадии зрелости.

Полнота матрицы SwiftRide pre-IPO

К target T+12M SwiftRide должна иметь risk-control matrix, заполненную для:

• Все 24 CDE на T+3M (начальный scope) — частичная матрица (топ-риски идентифицированы, control objectives в черновиках, control activities — placeholder)
• Все 150 CDE на T+18M — полная матрица (все материальные риски, полные control activities, операционные evidence pipelines)

Метрики покрытия:

• Matrix completion rate — % пар CDE × материальных рисков с заполненной матрицей
• Control coverage — % рисков с ≥1 определённой control activity
• Defense-in-depth coverage — % материальных рисков с ≥2 контролями
• Evidence pipeline operational — % контролей с автоматическим сбором evidence (vs ручным)
• Testing coverage — % контролей с тестированием design + operating effectiveness в предыдущие 12 месяцев

Baseline T0 (типичный pre-IPO scale-up): matrix completion <10%, defense-in-depth <20%. Target T+18M: matrix completion >95%, defense-in-depth >80%, evidence pipeline operational >70%, testing coverage 100% для SOX-relevant CDE.

Anti-patterns

1. Путаница objective = activity. Матрица перечисляет «daily reconciliation» как objective. Результат: формулируется control activity, а не желаемый исход — путаница при аудите + сложность re-design контроля (можно ли изменить activity? а что с objective?). Лекарство: objective всегда = формулировка желаемого исхода; activity всегда = операционное описание глаголом.

2. Риски с единственным контролем. Материальный риск только с одним контролем. Результат: единая точка отказа; audit attention. Лекарство: defense-in-depth — ≥2 контроля на материальный риск, идеально смешанных типов (preventive + detective + corrective).

3. Контроли без evidence pipeline. Activity определена, но сбор evidence ручной / непоследовательный / не существует. Результат: «у нас есть control, но мы не можем продемонстрировать работу» — автоматическая audit finding. Лекарство: требование к evidence на контроль; автоматический сбор evidence к target T+12M.

4. Неправильный тип контроля для риска. Detective control там, где нужен preventive (ловит инцидент после ущерба); preventive там, где нужен detective (gate блокирует легитимные операции). Результат: неэффективная control posture; риск не митигирован. Лекарство: соответствие типа контроля характеристикам риска — preventive для рисков необратимого ущерба, detective для восстановимого мониторинга, corrective всегда присутствует.

5. Перегрузка эффективного контроля. Один control замэпплен на 15 рисков. Результат: если control деградирует, 15 рисков скомпрометированы; нагрузка тестирования сконцентрирована. Лекарство: баланс efficiency + redundancy; мониторить эффективные контроли более строго.

6. Матрица без перерасчёта residual risk. Контроли добавлены без обновления residual likelihood + impact. Результат: матрица показывает только inherent; нельзя продемонстрировать снижение риска. Лекарство: residual scoring на цикл; перекалибровка триггерится изменениями контролей.

Итоги

• 4 уровня: Риск → Control objective → Control activity → Evidence. Каждый отдельный, все обязательны.
• Шаблон risk-control matrix — минимум 15 колонок; audit-ready структура.
• Preventive / Detective / Corrective — три типа контроля; defense-in-depth использует все три.
• Один риск → много контролей (defense-in-depth) — каждый материальный риск CDE должен иметь ≥2 контролей, смешанных типов.
• Один control → много рисков (efficiency) — well-designed ITGC покрывает несколько рисков; компромисс с риском единой точки отказа.
• Пример SwiftRide — ошибка расчёта driver earnings → control objective → 5 control activities (2 preventive + 2 detective + 1 corrective) + evidence pipeline.
• Мост к M5 — M2 = сторона рисков (objectives + placeholder activities); M5 = сторона контролей (операционная модель + evidence pipeline + тестирование).
• Цели полноты SwiftRide pre-IPO: T+18M matrix completion >95%, defense-in-depth >80%, evidence pipeline operational >70%, testing coverage 100% для SOX-relevant CDE.
• Шесть anti-patterns: путаница objective/activity, материальный риск с единственным контролем, контроли без evidence pipeline, неправильный тип контроля, перегрузка эффективного контроля, нет перерасчёта residual.
• Далее (урок 7) — Lab: построить реестр рисков для портфеля CDE SwiftRide.