Введение

Распространённая ошибка стартующих программ CDE — data team пытается провести fresh BIA «с нуля». Появляется проект на ~3–6 месяцев: интервью business owners, документирование процессов, построение impact curves, установка допусков. К моменту окончания проекта Continuity Team в Risk function заметно протестует: «у нас уже есть BIA, ISO 22301-compliant, обновлённый полгода назад. Зачем дублировать?». Внутренний аудит отмечает дублирование — два BIA-артефакта с потенциально несогласованными допусками. Pre-IPO assessment Big 4 видит governance issue.

Правильный подход — переиспользование. Continuity Team владеет BIA (это их ISO 22301-мандат); CDO Office извлекает data-relevant entries, заполняет data-specific gaps и интегрирует результат через кросс-ссылки. Этот урок — playbook стратегии reuse: identify, extract, gap-fill, negotiate, embed.

Идентификация существующего BIA — кто владеет, где живёт

В большинстве организаций BIA-артефакт уже существует. Типичные владельцы:

• Risk function / Continuity Team — основной владелец. Поддерживает фреймворк ISO 22301, планирует BCM-упражнения, представляет Risk Committee.
• Business Continuity Manager / Resilience Officer — single-role appointment в средних компаниях; reports to CRO или Head of Risk.
• CISO function — иногда co-owns из-за пересечения с cybersecurity incident response.
• Operations / IT — implementation arm; редко владеет самим BIA-артефактом.

В SwiftRide T+7M (период в хронологии курса): BCM существует как ISO 22301-aligned framework, владеет Continuity Team (2 FTE, отчитываются CRO). BIA последний раз обновлён 4 месяца назад, покрывает ~35 критических процессов. CDO Office видит BIA впервые только через cross-team meeting.

Где смотреть

• Confluence / SharePoint — типичное хранилище. Поиск: «BIA», «business impact analysis», «BCM», «continuity», «ISO 22301».
• Инструмент risk register (Riskonnect, MetricStream, Workiva) — BIA entries часто встроены в risk records.
• Прямой запрос Continuity team — самый эффективный маршрут.
• Минуты Board / Risk Committee — annual BCM report представляется; ссылки на BIA.

Если ничего не находится — возможно, организация работает без формального BIA (редко в regulated entities, обычно в pre-IPO scale-up < 1000 FTE). В этом случае CDO присоединяется к Continuity Team в проведении первого BIA — co-authorship, а не параллельные усилия.

Реверс-инжиниринг output BIA к data layer

Существующий BIA обычно структурирован process-centric (не data-centric). Каждая entry — процесс с допусками; data layer неявен или отсутствует. Процесс реверс-инжиниринга:

Шаг 1 — Перечислить все процессы в BIA

Инвентаризация: читать BIA-артефакт end-to-end; построить плоский список [process_id, name, tier, RTO, RPO, MTPD]. Существующий BIA SwiftRide T+7M — 35 процессов; ~20 relevant к данным (исключая facilities, HR, vendor management).

Шаг 2 — Сопоставить data-relevant процессы с приложениями

Для каждого процесса определить, какие приложения/системы его реализуют. Кросс-ссылка с ICT-asset inventory (требование DORA Art. 8). Output:

process_id: PROC-SWP-001
bia_rto: 1h
bia_rpo: 5min
applications:
  - driver-earnings-service (Go microservice)
  - commission-reconciler (Python Airflow DAG)
  - swiftpay-api (Kotlin)

Шаг 3 — Сопоставить приложения с data assets

Приложение читает/пишет какие schemas/tables/streams? Используй OpenLineage, если доступно (см. M5.8), либо ручной code review, либо dbt-graph manifests:

applications:
  - driver-earnings-service:
      reads: [pg.trips, pg.drivers, pg.commission_rules]
      writes: [snowflake.dl_marts.fct_driver_earnings, kafka.driver.earnings.daily]
  - commission-reconciler:
      reads: [snowflake.dl_marts.fct_driver_earnings, aurora.swiftpay.payouts]
      writes: [snowflake.audit.recon_runs, s3.swr-cde-evidence]

Шаг 4 — Идентифицировать CDE-колонки в задействованных schemas

Отфильтровать schemas к тем, что содержат CDE-помеченные колонки (из CDE registry M4.5):

schemas_with_cde:
  - snowflake.dl_marts.fct_driver_earnings:
      cdes: [CDE-SWR-003 (gross_earnings_usd), CDE-SWR-006 (commission_pct)]
  - aurora.swiftpay.payouts:
      cdes: [CDE-SWR-008 (payout_amount_usd), CDE-SWR-009 (payout_status)]

Шаг 5 — Унаследовать tier к data layer

Применить правило tier-inheritance (правило worst-case M6.2); CDE наследует worst-case tier среди всех потребляющих процессов. Output SwiftRide T+7M — CDE-SWR-003 выводит Tier-1 от PROC-SWP-001; CDE-SWR-006 также Tier-1.

Шаг 6 — Вычислить data-tier RTO/RPO

Применить tier matrix (M6.3): Tier-1 → data RTO 2h, RPO 5 min; Tier-2 → 16h, 60 min; Tier-3 → 72h, 24h. Документировать как первичный draft; пересмотреть с Continuity Team.

Output этого пайплайна — расширение data-layer для существующего BIA. Не заменяет BIA; дополняет его. Continuity Team сохраняет process-level ownership; CDO Office владеет data extension.

Заполнение gap — BIA часто без data-specific элементов

Существующий BIA обычно пишется на уровне application/process; data layer отсутствует или generic. Типичные gaps:

Gap 1 — Data tier RTO/RPO не специфицирован

Паттерн: BIA entry говорит «RTO 4h» для приложения. Data layer отдельно не специфицирован.

Fix: добавить entries per CDE, наследующие через правило M6.2 + matrix M6.3. Явные data_rto, data_rpo на каждый material CDE в реестре; кросс-ссылка из BIA entry.

Gap 2 — Каталог CDE не упомянут

Паттерн: BIA process entry перечисляет приложение «driver_earnings_service»; ничего про data assets, которых касается.

Fix: секция data assets на process entry — список CDE IDs, которых касается, с ролью (input / output / transformation). M4 CDE registry как canonical source.

Gap 3 — Crisis production не адресован

Паттерн: допуски BIA применяются к «normal operating conditions». BCBS 239 Principle 5 явно требует data production во время stress/crisis; существующий BIA может не адресовать.

Fix: per process документировать «stress-mode RTO/RPO», если отличается от normal. Обычно похоже или tighter; обоснование задокументировано.

Gap 4 — Recovery patterns не специфицированы на data tier

Паттерн: BIA entry говорит RTO 4h; не специфицирует как — ручной restore? Automated failover? Sync replica?

Fix: поле pattern на data asset — sync replica / async replica / daily backup / etc. Кросс-ссылки к ICT-asset inventory.

Gap 5 — Зависимости не сопоставлены

Паттерн: BIA process entry изолирована; не показывает upstream/downstream process dependencies.

Fix: поддерживается граф зависимостей — какие процессы питают этот, какие зависят от этого. Каскадный анализ явен.

Gap 6 — Периодичность валидации не специфицирована

Паттерн: BIA написан; никогда не валидирован через drill. Допуски теоретические.

Fix: per process расписание drill cadence (quarterly Tier-1, semi-annual Tier-2, annual Tier-3). Документировать last drill outcome + отклонения.

Переговоры — убедить Continuity Team расширить scope

Несколько реалий в переговорах:

Continuity Team имеет ограниченный bandwidth

Большинство Continuity Teams — 1–3 FTE, поддерживающих всю организацию. Они не могут провести глубокое погружение в 200+ CDE без помощи. CDO Office должен предоставить «расширение» — методология, черновые допуски, mapping данных.

Continuity Team владеет authority артефакта

Фреймворк ISO 22301 говорит — BIA принадлежит BCM function. Финальные допуски подписывает Continuity Lead + business owner. CDO Office представляет черновики; Continuity Team одобряет.

Убеждать через бизнес-кейс

Pitch к Continuity Team Lead:

«Pre-IPO assessment Big 4 пометил, что data layer не адресован в существующем BIA. У нас два выбора: (a) вы проводите data BIA — 6 месяцев, забирает ваш bandwidth от BCM-упражнений; (b) CDO Office предоставляет черновые data-допуски через методологию M6.2/M6.3, вы делаете review + approve. Подход (b) — 2 месяца elapsed, ваша роль неизменна, моя команда делает тяжёлую работу. Sign-off authority остаётся за вами».

Continuity Lead очевидно предпочитает (b). Успех переговоров обычно достижим; препятствия:

• Неоднозначность scope процесса — «кто владеет этим процессом — Finance? Ops?». Разрешение: Risk Committee adjudicates.
• Споры по допускам — engineering говорит RTO 1h невозможен; business говорит обязателен. Разрешение: data-driven (cost-impact matrix M6.3 представлен комитету).
• Всплывают неточности существующего BIA — расширение раскрывает, что существующий BIA имеет stale-допуски. Continuity Lead обороняется. Разрешение: framing как «refresh opportunity», не «fault-finding».

Встроить в periodicity governance

После одобрения data extension встроить:

• Annual BIA refresh cycle включает review data-tier.
• Обновления CDE registry триггерят рассмотрение BIA refresh — добавлен новый CDE, проверить, затронуты ли допуски процесса.
• Результаты DR drill возвращаются в BIA — фактические RTO/RPO измерены; отклонения от BIA targets — formal review.
• Дашборд Risk Committee включает метрики data-tier — coverage %, drill outcomes, deviations.

DORA DORA Art. 6 требует «sound, comprehensive, and well-documented ICT risk management framework that is updated based on observations from continuous monitoring» — явно включает BIA refresh при изменениях.

Выполнение SwiftRide T+8M — конкретные шаги

1. Неделя 1. CDO Office запрашивает у CRO доступ к существующему BIA; предоставлен. Читает end-to-end (35 process entries).
2. Недели 2–3. Извлечь 20 data-relevant процессов; построить черновую таблицу data-mapping (4-level, M6.2).
3. Неделя 4. Совместная встреча CDO Office + Continuity Lead. Представить gap analysis: 20 процессов не имеют data-tier RTO/RPO; 6 gaps идентифицированы (список M6.4 выше). Предложить методологию расширения.
4. Недели 5–6. Методология одобрена Risk Committee (CRO + CFO + CIO + General Counsel). Continuity Team сохраняет authority артефакта; CDO Office предоставляет расширения.
5. Недели 7–10. Черновые расширения данных для 20 процессов; ~80 material CDE reverse-mapped. Унаследовать tier по M6.2; вывести RTO/RPO по M6.3.
6. Недели 11–12. Reviews по трекам. Business owners подписывают допуски; Engineering Leads подписывают feasibility; Continuity Lead подписывает интеграцию.
7. Недели 13–14. Интегрированный BIA опубликован; ICT-asset inventory обновлён с per-asset tier; кросс-ссылки в CDE registry.
8. Quarter +1. Первый совместный DR drill (Tier-1 SwiftPay); outcomes возвращаются. Annual refresh встроен.

Общая стоимость ~$80–120K (в основном FTE-время CDO Office); timeline 3–4 месяца, не 6 «с нуля»; нет дублирования; integrity governance сохранена.

Anti-patterns

Параллельный BIA — дублирующие артефакты

Паттерн: CDO Office проводит data BIA без buy-in Continuity Team.

Почему плохо: два артефакта; потенциальные несогласованности; audit committee помечает governance issue; pre-IPO assessment неблагоприятна.

Fix: см. секцию Переговоры. Continuity Team владеет артефактом; CDO Office предоставляет расширения.

Реверс-инжиниринг без валидации

Паттерн: CDO Office реверс-инжинирит tier inheritance алгоритмически; никогда не валидирует с business owners.

Почему плохо: алгоритмическое наследование может быть неправильным — scope процесса неправильно понят, границы приложения неправильно нарисованы, tier classification спорна.

Fix: каждое derivation валидировано с process owner + business owner. Tolerance подписан явно.

«Existing BIA устарел, мы напишем новый»

Паттерн: CDO Office обнаруживает, что существующий BIA последний раз обновлялся 18 месяцев назад; рассматривает как stale, проводит fresh.

Почему плохо: существующий BIA имеет институциональное знание; refresh проще, чем starting from scratch; отношения с Continuity Team повреждены.

Fix: существующий BIA — стартовая точка. Расширить + refresh вместе. Refresh date отмечена; процесс изменился с refresh — пометить для review.

Crisis production не адресован

Паттерн: существующий BIA предполагает normal operating conditions; data extensions наследуют то же.

Почему плохо: BCBS 239 Principle 5 — crisis production timeliness. SwiftRide pre-IPO listing на regulated exchange (NYSE) с financial-services бизнес-юнитом (SwiftPay) — ожидание crisis production проходит насквозь.

Fix: на каждый material CDE документировать stress-mode допуски, если отличаются. Обычно tighter (под cyber stress, slower recovery неприемлем); обоснование задокументировано.

Допуски «снижены» инженерией

Паттерн: фидбэк инженерной команды на черновые допуски — «RTO 1h невозможен, реалистично 8h». Continuity Lead одобряет смягчение.

Почему плохо: допуски должны выводиться из business impact, не из инженерных возможностей. Инженерные возможности формируют recovery pattern + cost; не определяют приемлемую толерантность. Если RTO 1h business-required, но engineering говорит 8h — engineering должен инвестировать, не смягчать tolerance.

Fix: business owner + Risk Committee adjudicate; план инженерных инвестиций, если нужно. Cost-impact matrix (M6.3) защищает инвестицию.

Резюме

• Существующий BIA принадлежит Continuity Team (Risk function), не Data team. Reuse, не проводить fresh.
• Процесс реверс-инжиниринга: перечислить процессы → сопоставить с приложениями → сопоставить со schemas → сопоставить с CDE → унаследовать tier → вывести data RTO/RPO.
• Шесть типичных gaps: data-tier RTO/RPO не специфицирован; CDE catalog не упомянут; crisis production не адресован; recovery patterns не специфицированы; зависимости не сопоставлены; периодичность валидации не специфицирована.
• Тактики переговоров: методология, забирающая тяжёлую работу, сохранённая artifact authority с Continuity Team, бизнес-кейс (ожидание Big 4 + избегание дублирования), framing как «расширение», а не «критика».
• Интеграция: annual BIA refresh включает data-tier; обновления CDE registry триггерят review BIA; результаты DR drill возвращаются; дашборд Risk Committee.
• ISO 22301 + DORA Art. 6 + BCBS 239 Principle 5 — первичные якоря. DORA явно требует обновлений, driven by continuous monitoring.

В M6.5 раскроем BCP integration — что включает business continuity plan (ручные обходные пути, alternative sites, communication trees), как восстановление данных вписывается в BCP, различие BCP vs DRP (BCP шире; DRP ⊆ BCP technical subset).