Введение

Это основное упражнение capstone. Выбираете один бизнес-юнит SwiftRide и проектируете полный стек программы для него: реестр + каталог контролей + архитектура evidence pipeline + BIA mapping + операционная модель + KPI. Результат — это единый репозиторий, который вы могли бы передать CDO в реальной компании в первый день.

Это не абстрактный knowledge check. Это прикладной интеграционный тест на всё, что вы знаете после M0-M8. Если выходите из него — у вас есть конкретный артефакт для собеседования, для портфолио, для консалтингового engagement.

Выбор бизнес-юнита

Шесть бизнес-юнитов SwiftRide. Каждый — отдельный регуляторный профиль, отдельный CDE-ландшафт, отдельная констелляция стейкхолдеров. Выбирайте тот, который ближе к вашему реальному опыту или интересу. Оценка сложности — сколько часов capstone требует для полной поставки.

Если вы — начинающий в CDE governance, начинайте с Rides или Delivery — меньше CDE, проще регуляторные пересечения. Если вы — опытный GRC / risk practitioner, выбирайте SwiftPay или SwiftCapital — несколько регуляторных режимов, реальная сложность.

В этом уроке мы используем SwiftPay как worked example — вы видите, как один бизнес-юнит превращается в полную поставку. Ваше собственное упражнение — выбрать свой бизнес-юнит + повторить процесс.

Процесс из 8 шагов

Полное design-упражнение — 8 шагов, каждый с обратной ссылкой на курс.

Шаг 1 — Scope: определить границы вашего бизнес-юнита

Цель: Установить ясный scope. Что включено; что нет. Какие предусловия (мандат, бюджет, спонсорство, существующее состояние программы).

Поставки:

• Заявление о scope бизнес-юнита (1 страница): миссия, географическое присутствие, регуляторный профиль, текущие болевые точки.
• Карта стейкхолдеров: CFO sponsor + Compliance lead + Tech lead + Risk lead + представитель IA. Именованные роли, не «TBD».
• Границы программы: что в периметре (например, «все финансовые данные SwiftPay»); что вне периметра (например, «маркетинговые данные — отдельная DG-инициатива»).
• Проверка предусловий: бюджет обеспечен, headcount одобрен, право брифинга в комитете по аудиту предоставлено.

SwiftPay пример:

scope:
  bu: SwiftPay
  mission: "Wallet водителей и пассажиров; payouts через banking partner"
  jurisdictions: ["EU-NL (HQ)", "EU-DE", "EU-FR", "EU-AT", "EU-CH", "EU-PL", "EU-PT"]
  regulatory_regimes:
    - PSD2 / PSD3 (payment services)
    - PCI-DSS v4.0.1 (card data)
    - AMLR / AMLD5 (AML)
    - DORA (operational resilience)
    - GDPR (PII)
    - SOX 404 (post-IPO, ICFR-material)
  
  programme_scope_in:
    - "Wallet balances ledger (per user + per driver)"
    - "Payout calculations + executions"
    - "Card data (PAN tokens, BIN, expiry)"
    - "AML transaction monitoring outputs"
    - "KYC profiles"
    - "Sanctions screening results"
  
  programme_scope_out:
    - "Marketing automation data (governed under SwiftAds programme)"
    - "Fraud ML model internals (separate MRM project)"
  
  stakeholders:
    cfo_sponsor: "Anna Müller (CFO SwiftRide N.V.)"
    compliance_lead: "Tomas Holst (Head of Compliance, SwiftPay)"
    tech_lead: "Yuki Tanaka (VP Engineering, SwiftPay)"
    risk_lead: "Priya Sharma (2nd Line Risk, SwiftPay)"
    ia_rep: "Carlos Vega (Senior IA, data audit)"
    dpo: "Marta Lewandowska (DPO SwiftRide N.V.)"

Обратная ссылка: M0.4 «SwiftRide setup», M3 «Regulatory landscape».

Шаг 2 — Discovery: выявить CDE-кандидатов

Цель: Top-down + bottom-up discovery, результат — отсортированный список CDE-кандидатов.

Поставки:

• Top-down карта: для каждого регуляторного обязательства → список data assets, поддерживающих compliance.
• Bottom-up карта: для каждого финансового отчёта / регуляторной отчётности → трассировка lineage в обратную сторону к исходным датасетам.
• Анализ пересечений: где одни и те же данные появляются в нескольких обязательствах.
• Начальный список кандидатов — 30-50 кандидатов нормально.

Обратная ссылка: M4.1 «Discovery methodology», M4.2 «Top-down», M4.3 «Bottom-up», M4.4 «Интервью со стейкхолдерами».

Шаг 3 — Реестр: criticality scoring + одобрение

Цель: Weighted criticality scoring → отсев кандидатов до финального списка CDE. Workflow одобрения.

Поставки:

• Scoring spreadsheet (шкала 1.00-5.00) на каждого кандидата, weighted критерии — финансовый impact, регуляторная экспозиция, операционная зависимость, репутационный риск.
• Решения по отсеву: approved / rejected / parked. Обоснование на каждое решение.
• Лог одобрений Data Council + история версий.
• Финальный CDE-реестр в формате YAML (используя схему из M4.5).

SwiftPay пример записи реестра:

cde:
  cde_id: CDE-SPAY-001
  name: wallet_balance_ledger
  version: 1.0.0
  status: approved
  
  business_definition: |
    Authoritative wallet balance per user/driver, transactions ledger.
    Source-of-truth for all customer-facing balance displays + payout
    eligibility calculations. Material к financial statements (current
    assets — wallet liabilities); critical for regulatory reporting
    (AML transaction monitoring; PSD2 transaction history).
  
  technical_definition: |
    Aurora PostgreSQL 15 — schema `swiftpay`, primary tables:
    - `wallet_accounts` (account_id, user_id, currency, status, opened_at)
    - `wallet_transactions` (tx_id, account_id, amount, currency, type, 
       counterparty_account, status, settled_at, idempotency_key)
    - `wallet_balances_snapshot` (account_id, snapshot_ts, balance, 
       hold_amount, available_balance) — materialised hourly
    CockroachDB cross-region replica для DR + read-scale.
  
  business_owner:
    role: "VP Finance SwiftPay"
    person: "Anna Müller (CFO SwiftRide; interim BO before VP Finance hire)"
  
  data_steward:
    role: "SwiftPay Data Lead"
    person: "Yuki Tanaka"
  
  classification: 
    - "Confidential"
    - "PII (Art. 4 GDPR)"
    - "PCI scope adjacent (linked к card data CDE-SPAY-006)"
    - "SOX-scope (post-IPO ICFR material)"
  
  criticality_score: 4.85
  scoring_rationale: |
    Financial impact: 5.0 (direct ICFR material; misstatement risk near 
    materiality threshold $4.2M post-IPO).
    Regulatory exposure: 4.8 (PSD2 + AMLR + DORA + GDPR + SOX).
    Operational dependency: 5.0 (every SwiftPay transaction reads/writes).
    Reputational: 4.5 (any incident = front-page risk).
  
  applicable_regulations:
    - "SOX 404 (post-IPO ICFR)"
    - "PSD2 Art. 64-77 (transaction record-keeping)"
    - "AMLR Art. 50 (CDD records 5 years)"
    - "DORA Art. 5-15 (operational resilience)"
    - "GDPR Art. 6 + Art. 30 + Art. 32"
  
  lineage_refs:
    - "openmetadata://swiftpay/wallet_accounts"
    - "openmetadata://swiftpay/wallet_transactions"
    - "marquez://swiftpay/wallet_balance_pipeline"
  
  control_refs:
    - "CTL-CDE-SPAY-001-001"  # daily reconciliation ledger ↔ Snowflake
    - "CTL-CDE-SPAY-001-002"  # GE expectation suite — null/range/uniqueness
    - "CTL-CDE-SPAY-001-003"  # SoD — separation payment authorisation 
                              #        от ledger update
    - "CTL-CDE-SPAY-001-004"  # ITGC — Aurora access management
    - "CTL-CDE-SPAY-001-005"  # ITGC — Aurora change management
  
  bia_refs:
    - "BIA-SPAY-WALLET-001"  # RTO 2h / RPO 5min
  
  retention: "7 years (SOX-aligned)"
  cross_border_transfer: "EU-internal only; no transfer to US без SCCs"
  
  created_at: "2026-04-15T10:00:00Z"
  last_reviewed_at: "2026-04-15T10:00:00Z"
  next_review_due: "2026-10-15T00:00:00Z"
  
  change_history:
    - v: "1.0.0"
      date: "2026-04-15"
      change: "Initial approval Data Council"
      approver: "Data Council (Anna Müller chairing)"

Обратная ссылка: M1.4 «Criticality scoring», M4.5 «Registry data model».

Шаг 4 — Контроли: спроектировать каталог контролей

Цель: Для каждого CDE спроектировать набор контролей по таксономии M5. Результат — каталог контролей со схемой objective / activity / evidence.

Поставки:

• Инвентарь контролей: ITGC + application + DQ + SoD + reconciliation, на каждый CDE.
• Документация дизайна на каждый control: objective, activity, схема evidence, частота, владелец, IPE designation.
• Шаблоны test plan по типам контролей.

SwiftPay пример контроля:

control:
  control_id: CTL-CDE-SPAY-001-001
  control_name: "Daily reconciliation wallet_balances_snapshot ↔ Snowflake fct_wallet_balances"
  cde_refs: ["CDE-SPAY-001"]
  control_type: "reconciliation"
  
  objective: |
    Ensure consistency between operational Aurora wallet_balances_snapshot
    (source of truth для customer-facing displays) и Snowflake 
    fct_wallet_balances (source of truth для financial reporting + AML 
    monitoring). Discrepancy > $1k OR > 0.01% balance triggers SEV-1.
  
  activity: |
    Daily 02:00 UTC reconciliation job:
    1. Aurora SELECT — sum of available_balance grouped by currency, 
       snapshot_ts = previous day's 23:59:59 UTC.
    2. Snowflake SELECT — sum of balance_usd grouped by currency, 
       date = previous day.
    3. Compare per-currency totals; flag > $1k absolute или > 0.01% relative.
    4. If flag — pageduty (SEV-1) к oncall data engineering.
    5. RCA documented в Jira; resolution within 4h SLA.
  
  evidence:
    schema:
      - run_ts: timestamp
      - aurora_total_usd: numeric
      - snowflake_total_usd: numeric
      - delta_absolute: numeric
      - delta_relative: numeric
      - flag: boolean
      - pageduty_alert_id: string (if flagged)
      - jira_ticket_id: string (if flagged)
      - resolution_summary: string (if flagged)
    storage: "S3 immutable bucket; 7y retention"
    indexing: "Snowflake audit.evidence_index"
  
  frequency: daily
  owner: "SwiftPay Data Lead"
  ipe_designation: |
    External electronic information: Snowflake export from Aurora — 
    PCAOB AS 1105 ¶.10A applies. Auditor will require:
    - Source: ETL пайплайн documented + reviewed
    - Completeness: row counts checked
    - Accuracy: sample sub-test
  
  test_plan:
    auditor_walkthrough:
      - "Select 5 reconciliation runs from past 90 days (random)"
      - "Re-execute reconciliation SQL on archived data; expect same result"
      - "Verify SLA compliance for all flagged exceptions"
      - "Verify RCA documentation completeness for SEV-1 incidents"
    sample_size: "25 per quarter (one quarter as walkthrough; rest population)"
    expected_pass_rate: ">= 99%"

Обратная ссылка: M5.1 «Control taxonomy», M5.4 «Objective / Activity / Evidence», M5.6 «Reconciliation».

Шаг 5 — Evidence: спроектировать архитектуру пайплайна

Цель: Спроектировать evidence pipeline (GE + OpenLineage + Jira + Workiva). Результат — архитектурная диаграмма + спецификации интеграций.

Поставки:

• Архитектурная диаграмма: поток данных GE → S3 → Marquez → Workiva.
• Схема индекса evidence (Snowflake audit.evidence_index).
• Спецификация issue workflow (Jira webhook → SLA → RCA template).
• Спецификация attestation cycle (28-дневный квартальный цикл, Business Owner sign-off, отчёт в комитет по аудиту).

Обратная ссылка: M7.2 «Evidence collection», M7.3 «OpenLineage», M7.4 «Issue management», M7.5 «Attestation cycle».

Шаг 6 — BIA: вывод RTO/RPO + планы восстановления

Цель: Business Impact Analysis на каждый CDE — финансовый, регуляторный, репутационный impact при разных длительностях простоя. Целевые RTO/RPO. Планы BCP/DRP.

Поставки:

• BIA на каждый CDE: кривая impact (4 измерения × минимум 8 временных корзин).
• Целевые RTO/RPO, выведенные из BIA.
• Процедуры DRP для каждого CDE tier-1.
• План тестов DRP + частота (минимум ежегодно для critical).

Обратная ссылка: M6.1 «BIA fundamentals», M6.3 «RTO/RPO derivation», M6.4 «BCP integration», M6.5 «DRP testing».

Шаг 7 — Операционная модель: SDLC + изменения + инциденты + поставщики

Цель: Операционная модель оборачивает технические слои (реестр + контроли + evidence + BIA) governance’ом + процессной дисциплиной.

Поставки:

• Интеграция в SDLC: CI/CD gates (CDE-impact-check pre-commit / pre-merge).
• Управление изменениями: классификатор (emergency / standard / normal), workflow одобрения.
• Runbook’и реагирования на инциденты по категориям CDE.
• Управление поставщиками: DORA Register of Information + индексация SOC-отчётов + имплементация CUEC.
• Оргструктура: Three Lines укомплектованы; reporting lines прописаны.

Обратная ссылка: M8.1 «SDLC integration», M8.2 «Change management», M8.4 «Incident response», M8.5 «Vendor governance», M8.7 «Org structure».

Шаг 8 — KPI: фреймворк измерений

Цель: KPI, покрывающие 4 категории — Coverage, Control Effectiveness, Operational, Audit Outcomes. На каждую метрику: формула + цель + ответственный + drill-down.

Поставки:

• Словарь KPI (по M8.8).
• Базовые замеры + цели на 6 / 12 / 18 месяцев.
• Спецификация дашбордов (аудитория: совет директоров / комитет по аудиту / CDO / инженерные команды).
• Проверка на анти-паттерны: нет vanity-метрик, нет возможностей для gaming, баланс leading + lagging индикаторов.

Обратная ссылка: M8.8 «KPIs and metrics», M7.6 «Dashboard reporting».

Self-check: 25 критериев

После завершения 8 шагов проведите self-check. По каждому критерию: pass / fail / partial.

Scope + стейкхолдеры (5):

1. Миссия бизнес-юнита + юрисдикции задокументированы.
2. Регуляторные режимы перечислены с версиями / датами вступления в силу.
3. Карта стейкхолдеров именует людей (не роли).
4. Спонсорство CFO явно + задокументировано.
5. Границы в периметре / вне периметра ясны.

Реестр (5):

6. Методология criticality scoring задокументирована + применена.
7. Каждая CDE имеет обязательные поля по схеме M4.5 (cde_id, name, business_definition, technical_definition, business_owner, criticality_score, applicable_regulations, lineage_refs, control_refs, bia_refs, version, status, timestamps).
8. Лог workflow одобрения сохранён.
9. Версионирование консистентное (semver или инкрементальное — выбрать одно + придерживаться).
10. Forward-references (control_refs, bia_refs) заполнены.

Контроли (5):

11. Каждая CDE tier-1 имеет минимум 3 контроля (смесь типов).
12. Каждый control задокументирован objective / activity / evidence / frequency / owner.
13. ITGC-инвентарь завершён для систем, держащих CDE.
14. IPE designations применены на каждый control.
15. SoD-анализ для финансовых процессов.

Evidence + BIA + операционная модель (5):

16. Архитектурная диаграмма evidence pipeline ясная.
17. Схема evidence специфицирует retention + immutability.
18. BIA покрывает 4 измерения × несколько временных корзин на CDE.
19. Целевые RTO/RPO явные + выведены из BIA.
20. Интеграция в SDLC задокументирована (CI/CD gate + классификатор управления изменениями).

KPI + анти-паттерны (5):

21. KPI покрывают все 4 категории (Coverage, Effectiveness, Operational, Audit Outcomes).
22. Базовая линия + цели на 6/12/18 месяцев заданы на каждую KPI.
23. Нет vanity-метрик (метрики на основе активности не используются как первичные).
24. Cross-stream consistency check пройден (registrycontrol_refs ↔ controlscde_refs совпадают; то же для bia_refs).
25. Уровень документации — аудитор мог бы провести walkthrough на Day 1 (не «мы подготовим»).

Оценка:

• 23-25 pass: audit-defensible программа. Готово к собеседованию, готово к портфолио.
• 18-22 pass: солидная база, пробелы выявлены. Итерируйте по самым слабым секциям.
• < 18 pass: существенная переделка. Пересмотрите соответствующие модули.

Типичные ошибки из прошлых попыток студентов

Накопленный wisdom — 10 паттернов, которые регулярно повторяются.

1. «Вселенная из 200 датасетов» в реестре. Студент стремится к всеохватности, перечисляет каждый датасет с любой финансовой релевантностью. Результат: реестр без глубины, владельцы пусты на 60%, контроли неизбежно orphaned. Фикс: безжалостный отсев. 20 CDE с глубиной > 200 CDE с шириной.

2. Карта стейкхолдеров с «TBD» людьми. Роли («Compliance Lead») вместо людей («Tomas Holst»). Fail по критерию 3. Reality check: при подходе к реальному CDO первый вопрос — «кто ответственный». Если ответ — title, программа не запущена.

3. Copy-paste objectives для контролей. Каждый control с идентичной формулировкой objective и лёгкими вариациями. Результат: каталог контролей кажется всеохватным, но фактически 5 версий одного и того же control. Аудитор поднимет flag.

4. Evidence без спецификации retention. Схема спроектирована красиво, но нет retention policy. Через 6 месяцев evidence удаляется по S3 lifecycle. Audit walkthrough — «покажите evidence Q1» — нет. SOX retention: 7 лет immutable.

5. BIA с единственной временной корзиной. «RTO 2ч, RPO 5мин» — объявлено, но нет обоснования. BIA должен раскладывать impact по 1ч / 4ч / 24ч / 1 неделя — иначе RTO выбран произвольно, не business-justified.

6. Пропущен ITGC-инвентарь. Студент фокусируется на application + DQ контролях; ITGC (access management + change management + computer ops + SDLC) — мимоходом. Spotlight PCAOB 2024: deficiencies в ITGC = замечание №1. Неизбежный пробел в аудите.

7. Нет SoD-анализа. «SoD не релевантен в современной data team — у всех есть доступ» — ложное обоснование. SoD в финансовых процессах — non-negotiable. Конкретная проверка: один и тот же человек не может (а) обновить данные CDE, (б) одобрить изменения, (в) ревьюить attestation evidence.

8. Управление поставщиками как afterthought. SOC-отчёты не проиндексированы; имплементация CUEC не подтверждена evidence; DORA Register of Information отсутствует. Управление поставщиками — целый workstream (M8.5), не приложение.

9. KPI на основе активности. «12 контролей развёрнуто в Q3» — vanity-метрика. Аудитор: «из этих 12, сколько эффективны?» — студент не знает. Доминируют outcome-based метрики: % эффективности, MTTR, доля замечаний аудита.

10. SOX-readiness без SOX scoping. Студент предполагает, что всё material — SOX-релевантно. Реальность: SOX scope основан на materiality threshold (примерно 5% pre-tax income по SAB 99). Студент должен рассчитать threshold + применить, а не предполагать.

Общий результат SwiftRide — распознавание паттернов

Если студент успешно завершает capstone — вот паттерны, которые отличают сильные работы от средних:

Сильная работа:

• Карта стейкхолдеров именует конкретных людей + роли, включая DPO + представителя комитета по аудиту.
• Записи CDE цитируют конкретные регуляторные статьи, не «GDPR», а «GDPR Art. 30 + Art. 32(1)».
• Cross-stream consistency автоматизирована через CI check, а не полагается на ручную сверку.
• KPI включают leading индикаторы (покрытие контролей, покрытие lineage) + lagging (замечания аудита, заполнение аттестаций).
• Осознание анти-паттернов: явное «мы рассмотрели анти-паттерн X; митигация — Y».

Средняя работа:

• Всеохватная на поверхности; пробелы в глубине (например, 30 CDE, но только 5 с полной схемой).
• Общие лейблы стейкхолдеров.
• Перекрёстные ссылки частично заполнены.
• KPI в основном на основе активности.
• Анти-паттерны не адресованы.

Слабая работа:

• Реестр в виде списка, без глубины.
• Нет каталога контролей.
• Evidence pipeline описан прозой без архитектуры.
• BIA — нарратив, без вывода RTO/RPO.
• Операционная модель замята.

Результат: структура единого репозитория

Финальная поставка — единый репозиторий, layout:

cde-programme-{bu}/
├── README.md                        # 2-page summary
├── 01-scope/
│   ├── scope-statement.md
│   ├── stakeholder-map.yaml
│   └── pre-conditions-checklist.md
├── 02-discovery/
│   ├── top-down-mapping.md
│   ├── bottom-up-lineage-traces.md
│   ├── overlap-analysis.md
│   └── candidates-list.yaml
├── 03-registry/
│   ├── criticality-scoring.csv
│   ├── data-council-approval-log.md
│   └── registry/
│       ├── CDE-XXX-001.yaml
│       ├── CDE-XXX-002.yaml
│       └── ...
├── 04-controls/
│   ├── controls-catalog.yaml
│   ├── itgc-inventory.yaml
│   ├── sod-matrix.yaml
│   └── test-plans/
│       └── per-control-type/
├── 05-evidence/
│   ├── pipeline-architecture.md (with diagram)
│   ├── evidence-index-schema.sql
│   ├── jira-workflow-spec.md
│   └── attestation-cycle.md
├── 06-bia/
│   ├── bia-per-cde/
│   ├── rto-rpo-targets.yaml
│   ├── drp-procedures.md
│   └── drp-test-plan.yaml
├── 07-operating-model/
│   ├── sdlc-integration.md
│   ├── change-management.md
│   ├── incident-response-runbooks/
│   ├── vendor-governance.md
│   ├── dora-register-of-information.yaml
│   └── org-structure-and-raci.md
├── 08-kpis/
│   ├── kpi-dictionary.yaml
│   ├── baselines-and-targets.csv
│   └── dashboard-specs.md
└── 09-self-check/
    ├── 25-criteria-self-check.md
    └── lessons-learned.md

Репозиторий на GitHub / GitLab под MIT-лицензией — это portfolio item. Собеседование: «вот как я бы спроектировал CDE-программу для бизнес-юнита $YourCompany; взято из реального сквозного кейса».

Итоги

• Упражнение capstone — выбрать один из 6 бизнес-юнитов SwiftRide; спроектировать полный стек программы: реестр → контроли → evidence → BIA → операционная модель → KPI.
• Процесс из 8 шагов мапится напрямую к модулям курса M0-M8. Никакой новой теории; интеграционный тест.
• Self-check 25 критериев — pass 23-25 = audit-defensible.
• Типичные ошибки — широта реестра без глубины, общие лейблы стейкхолдеров, evidence без retention, пропуск ITGC, vanity KPI.
• Результат: структура единого репозитория — готова для портфолио, собеседования, реального консалтингового engagement.
• Оценка 20-60ч в зависимости от выбора бизнес-юнита. SwiftPay/SwiftCapital — наиболее сложные; Rides/Delivery — простейшие.