Введение

SwiftRide T+10M первый комплексный DR drill для Tier-1 SwiftPay. Engineering team подготовила: pre-staged Snowflake replication group, валидированные скрипты Aurora failover, on-call team briefed. Drill начинается 09:00 UTC; объявлен incident; failover инициирован; данные восстановлены; smoke tests passed; «успешно» на 09:47 (47 min RTO под target 1h). Continuity Lead пишет report «drill passed». Через три месяца происходит реальный инцидент — Snowflake account experiences storage degradation. Engineering применяет ту же процедуру — но в реальности replication group не pre-staged (этот сценарий отличается от drill), скрипт Aurora failover фейлится (DNS изменился со времени drill, не тестировался), restore занимает 4.5h. Раскрыт material weakness.

«Успех» drill — это не бинарный pass/fail. Дизайн drill определяет, какая часть recovery фактически валидирована, какая симулирована, какая предполагается работающей. Аудитор оценивает: «опишите scope drill; что было фактически exercised; что было scripted; какие отклонения от designed procedure произошли». Этот урок — playbook дизайна DR drill, сбора evidence, и audit defensibility.

Периодичность DR drill на каждый tier

Индустриальная базовая периодичность:

Заметка: Continuity Team обычно планирует table-top BCP-упражнения отдельно (semi-annual минимум для Tier-1). DR drills фокусируются на слое DRP technical.

DORA DORA Art. 25 mandates «sound, comprehensive and effective digital operational-resilience testing programme» — annual basic testing для всех in-scope entities. Significant entities дополнительно subject к TLPT (см. ниже).

Типы тестов

Walkthrough (table-top)

Самый low-investment тест. Stakeholders собираются; сценарий инцидента представлен нарративно; команда проходит по процедуре шаг за шагом разговорно. Никакие реальные системы не затронуты.

• Длительность — 2–4 часа.
• Участники — IC, on-call engineer, Continuity Lead, business owner.
• Output — минуты обсуждения, action items.

Применение: валидировать корректность runbook; идентифицировать gaps в документации; обучать новых членов команды.

Ограничения: не валидирует фактическую recovery capability. Инженер может уверенно сказать «failover script работает» — drill этого не доказывает.

Simulation (partial restore)

Mid-investment. Подмножество восстановления фактически выполняется в изолированном окружении — failover к replica account, но без сдвига production-трафика; restore data к sandbox account; валидировать процедуру end-to-end без воздействия на реальных пользователей.

• Длительность — 4–8 часов.
• Участники — Engineering team + Continuity Lead + observer от Audit (рекомендуется).
• Output — recovery timeline logs, success/failure на шаг, отклонения.

Применение: валидировать, что фактические recovery procedures выполняются корректно; измерить фактический RTO/RPO; раскрыть script-level issues.

Ограничения: production-трафик не затронут; некоторые процедуры (DNS-flip, customer comms) только симулированы. Может дать ложную уверенность — реальный инцидент может всплыть production-specific issues (например, реальное поведение bank-partner API во время failure).

Full restore (production failover)

Самый high-investment. Production-трафик фактически сдвинут к alternative region/account; primary преднамеренно taken offline (или предполагается offline); бизнес работает на recovery infrastructure для defined window; затем failback.

• Длительность — 8–48 часов (включая failback).
• Участники — all hands; business stakeholders observe; customer comms выполняются live.
• Output — full operational metrics, измерения customer-impact, отклонения.

Применение: ultimate валидация; обязательно для regulated entities на periodic basis (DORA significant entities); валидирует всю цепочку восстановления, включая customer-facing tier.

Ограничения: самый высокий риск (customer impact возможен); resource-intensive; требует extensive prep + change-management approval.

SwiftRide T+12M планирует первый full restore Tier-1 SwiftPay на 2027-Q1 (post-IPO листинг); ранее только walkthroughs + simulations.

DORA TLPT — threat-led penetration testing

Специальная категория — DORA DORA Arts. 26-27. Требуется минимум каждые 3 года для significant entities. Методология TIBER-EU framework типична. Симулирует реальные кибер-атаки против critical systems с full red-team engagement; оценивает resilience не только technical recovery, но также detection, response, коммуникаций.

• Scope — financial entities, признанные «significant» ESAs (критерии designation — размер, interconnectedness, complexity, cross-border).
• Cost — значительный ($500K–$2M на engagement).
• Outcomes — конфиденциальный report shared с ESAs; remediation plan tracked.

SwiftPay в настоящее время не в TLPT-scope (sub-significant scale); bank-partner subject; ожидания flow-down к SwiftRide.

Evidence — что показывать аудитору

«Успех» drill недостаточен — аудитор хочет реконструируемое evidence. Per DORA DORA Art. 24 entities поддерживают «complete documentation of testing activities, including findings, gaps, recommendations, and remediation efforts». PCAOB AS 1105 «sufficient appropriate evidence» применяется аналогично.

Evidence checklist на каждый drill

drill_id: "DRILL-SWP-2026Q1-001"
scope: "SwiftPay Tier-1 failover simulation"
type: "simulation"
date: "2026-03-15"
participants:
  - "IC: Priya (Data Platform Lead)"
  - "Engineer: Yuki (Platform Engineering)"
  - "Continuity: Sarah (Continuity Lead)"
  - "Observer: Carlos (Finance Lead)"
  - "Auditor observer: Big 4 senior associate"

scenario:
  description: "Aurora swiftpay-cluster primary region (EU-W) experiences storage failure; failover to replica region (US-E); restore CDE-SWR-003 data integrity verified."
  starting_state: "Pre-staged: replication group active, replica lag <30s, all systems healthy"

steps_executed:
  - step: "T+0min: Incident declared (PagerDuty Sev-1)"
    actual_time: "09:00:00 UTC"
    designed_time: "T+0"
    status: "OK"
    evidence_artifact: "pagerduty-incident-2026031509000.json"

  - step: "T+5min: VP Engineering joined incident bridge"
    actual_time: "09:04:32"
    designed_time: "T+5"
    status: "OK"
    evidence_artifact: "slack-channel-incidents-tier1-archive.json"

  - step: "T+15min: Aurora Global Database failover initiated"
    actual_time: "09:14:50"
    designed_time: "T+15"
    status: "OK"
    evidence_artifact: "aws-rds-failover-log-2026031509145000.json"

  - step: "T+30min: Snowflake account aliasing flipped к US-E"
    actual_time: "09:32:18"
    designed_time: "T+30"
    status: "DEVIATION"
    deviation_notes: "Took 2 min longer than designed; manual approval step in Saviynt PIM not pre-approved; required Risk Lead callback (3 min delay)."
    evidence_artifact: "snowflake-account-history-replication.json"

  - step: "T+45min: Application restart Argo Rollouts blue-green"
    actual_time: "09:46:01"
    designed_time: "T+45"
    status: "OK"
    evidence_artifact: "argo-rollouts-revision-history.json"

  - step: "T+50min: Health-check + smoke test"
    actual_time: "09:50:33"
    designed_time: "T+50"
    status: "OK"
    evidence_artifact: "smoke-test-results-2026031509503300.json"

  - step: "T+55min: Customer comms 'restoring'"
    actual_time: "SIMULATED (no production customers affected)"
    designed_time: "T+55"
    status: "SIMULATED"
    evidence_artifact: "comms-templates-c1.pdf + slack-screenshot.png"

  - step: "T+60min: Full service restored (in sandbox env)"
    actual_time: "09:47:12"
    designed_time: "T+60"
    status: "EARLY (achieved RTO target with 13 min margin)"
    evidence_artifact: "service-health-dashboard-snapshot.png"

data_integrity_verification:
  - verification: "CDE-SWR-003 gross_earnings_usd — last 24h trailing checksum"
    pre_drill_value: "checksum_a1b2c3d4..."
    post_drill_value: "checksum_a1b2c3d4..."
    delta: "0 (zero data loss; RPO target 5min met)"
  - verification: "CDE-SWR-006 commission_pct — count and distribution"
    pre_drill: "{count: 12534, mean: 0.247, stddev: 0.043}"
    post_drill: "{count: 12534, mean: 0.247, stddev: 0.043}"
    delta: "Identical"

deviations_summary:
  - "T+30min step — Saviynt PIM manual approval не pre-approved; 2 min delay. Action: pre-approve PIM elevation for designated DR-runner role; remediation closed 2026-03-22."

outcomes_summary:
  designed_rto: "60 min"
  actual_rto: "47 min"
  designed_rpo: "5 min"
  actual_rpo: "0 (zero data loss)"
  verdict: "PASS with one deviation (closed)"
  next_drill: "2026-Q2 (semi-annual simulation; full restore scheduled 2027-Q1 post-IPO)"

audit_trail:
  - "Pre-drill briefing slides — confluence/swp-drill-2026q1-brief"
  - "Live drill recording — Zoom session"
  - "All evidence artifacts stored — s3://swr-cde-evidence/drills/DRILL-SWP-2026Q1-001/"
  - "Post-drill review meeting minutes — confluence/swp-drill-2026q1-pmr"
  - "Auditor observer notes — confidential, Big 4 audit working paper"

Этот артефакт — drill report. Audit-defensible. Хранится 7y по SOX retention. Audit walkthrough просит «покажите мне последний Tier-1 drill report» → артефакт выше представлен; вопросы отвечены из evidence references.

Типичные failure modes

Failure mode 1 — Неполный scope restore

Паттерн: drill восстанавливает primary CDE-SWR-003; не восстанавливает зависимую CDE-SWR-006 (commission_pct). Smoke test passes (primary CDE recovers); реальный инцидент раскрывает сломанные зависимости.

Почему плохо: scope основан на памяти, не на задокументированном графе зависимостей. 4-level mapping M6.2 должно driver scope.

Fix: scope drill выведен из mapping table — все зависимости + downstream CDE включены. Validation step сравнивает scope с mapping.

Failure mode 2 — Stale runbook

Паттерн: runbook говорит «failover к Aurora replica EU-C». Replica была перенесена к US-E 6 месяцев назад; runbook не обновлён. Drill следует stale runbook; команды фейлятся.

Почему плохо: runbooks drift; нет governance, форсирующего refresh.

Fix: ownership runbook (Engineering Lead на asset); quarterly review cadence; CI-style validation — script тестирует «работает ли эта команда фактически против текущей инфраструктуры».

Failure mode 3 — Нет test-данных

Паттерн: drill выполняется против production data — но production data небезопасно мутировать. Test scope сводится к «verify restore command syntax»; фактическая data integrity не верифицируется.

Почему плохо: недостаточное evidence. Аудитор: «как вы знаете, что restore фактически сработал?» Ответ: «команда exited 0». Не достаточно.

Fix: test environment с representative data; pre-drill checksum baseline; post-drill checksum верификация. Saved evidence.

Failure mode 4 — Drill оптимизирован away

Паттерн: pre-drill prep устраняет неопределённость — replication pre-validated, scripts pre-warmed, on-call team briefed. Drill выполняется безупречно. Реальный инцидент — ни одно из pre-conditions не держится; drill outcomes не предсказательны.

Почему плохо: drill измеряет «можем ли мы выполнить pre-warmed процедуру», не «можем ли мы восстановиться под реалистичными условиями». PCAOB inspection 2024 spotlight: «drills with relaxed initial conditions = control not operating as designed».

Fix: occasional «cold drill» — нет pre-prep; on-call team обрабатывает как если бы реальный инцидент. Более реалистично; всплывают issues. SwiftRide T+12M планирует первый cold drill 2026-Q4.

Failure mode 5 — Отклонения не задокументированы

Паттерн: drill сталкивается со small deviations; инженер adjusts; drill «passes»; отклонения не зафиксированы.

Почему плохо: отклонения — самый ценный артефакт (показывает real-world friction points); без записи learnings потеряны.

Fix: явный deviation log на шаг; remediation actions tracked. «Успех» drill определён как «procedure executed correctly with deviations documented», не «no deviations».

Failure mode 6 — Коммуникации не валидированы

Паттерн: drill валидирует technical restore; customer-facing comms «симулированы». Никакие фактические сообщения не drafted.

Почему плохо: реальный инцидент — comms team scrambling; шаблоны имеют ошибки; status page сломан.

Fix: минимум раз в год, черновики comms фактически отправлены (на test-каналы — internal email distribution, status-page staging). Валидирует шаблоны + workflows.

Failure mode 7 — Аудитор не приглашён

Паттерн: drill проводится внутренне; нет audit observer.

Почему плохо: упущенная возможность для валидации качества evidence. Аудитор видит drill report только after-the-fact; не может зондировать вопросы в real-time.

Fix: пригласить Internal Audit или external auditor observer на major drills (semi-annual + annual). Документировать presence в drill report.

Quarterly drill matrix SwiftRide

T+12M operational drill calendar:

drill_calendar_2026:
  2026-Q1:
    - drill_id: "DRILL-SWP-2026Q1-001"
      tier: "Tier-1"
      scope: "SwiftPay simulation; CDE-SWR-003 + CDE-SWR-006"
      type: "Simulation"
      duration: "4h"
      status: "COMPLETED (47 min actual RTO; 1 deviation closed)"

  2026-Q2:
    - drill_id: "DRILL-SWP-2026Q2-001"
      tier: "Tier-1"
      scope: "SwiftPay simulation; CDE-SWR-003 + CDE-SWR-006 + CDE-SWR-008 (expanded)"
      type: "Simulation"
      duration: "6h"
      status: "PLANNED (2026-06-15)"
    - drill_id: "DRILL-SWC-2026Q2-001"
      tier: "Tier-2"
      scope: "SwiftCapital walkthrough; CDE-SWR-007"
      type: "Walkthrough"
      duration: "3h"
      status: "PLANNED (2026-06-22)"

  2026-Q3:
    - drill_id: "DRILL-SWP-2026Q3-001"
      tier: "Tier-1"
      scope: "SwiftPay simulation; cross-region failover"
      type: "Simulation"
      duration: "6h"
      status: "PLANNED"
    - drill_id: "DRILL-MKT-2026Q3-001"
      tier: "Tier-3"
      scope: "Marketplace analytics; CDE-SWR-018"
      type: "Walkthrough"
      duration: "2h"
      status: "PLANNED"

  2026-Q4:
    - drill_id: "DRILL-SWP-2026Q4-001"
      tier: "Tier-1"
      scope: "SwiftPay COLD drill; no pre-warming"
      type: "Simulation"
      duration: "8h"
      status: "PLANNED (high realism — minimal prep)"
    - drill_id: "DRILL-AML-2026Q4-001"
      tier: "Tier-2"
      scope: "AML transaction monitoring; CDE-SWR-014"
      type: "Walkthrough"
      duration: "3h"
      status: "PLANNED"

  2027-Q1_planned:
    - drill_id: "DRILL-SWP-FULL-2027Q1-001"
      tier: "Tier-1"
      scope: "SwiftPay FULL restore; production traffic shift"
      type: "Full restore"
      duration: "24h (включая failback)"
      status: "PLANNED (post-IPO listing complete)"

annual_summary:
  total_drills_planned: 9
  total_drills_completed: 1
  cumulative_evidence_artifacts: "stored s3://swr-cde-evidence/drills/"
  retention: "7 years SOX"
  next_audit_walkthrough: "Big 4 Q4 audit"

Расписание drill — одобрено Risk Committee + CRO; tracked в дашборде Risk Committee; SLA закрытия отклонений 30 дней (Tier-1).

DRP testing — opt-in tooling refs

Конкретный tooling, полезный для сбора drill evidence:

• AWS Resilience Hub — оркестрация drill; auto-собирает измерения RTO/RPO; интегрируется с AWS Backup.
• Snowflake replication group + failover group APIs — программный failover; evidence через ACCOUNT_USAGE views.
• Chaos Engineering tools (Gremlin, AWS Fault Injection Service) — controlled failure injection для cold-drill сценариев.
• PagerDuty/Opsgenie incident archives — автоматический evidence для timing.
• Confluence / Notion — drill brief + post-mortem; интегрировано с GRC tools (Workiva, Riskonnect) для tracking.

Выбор tooling менее важен, чем строгость; базовая spreadsheet + S3 evidence storage достаточно для audit defensibility.

Резюме

• Периодичность drill на каждый tier: Tier-1 quarterly simulation + annual full restore; Tier-2 semi-annual walkthrough + annual simulation; Tier-3 annual walkthrough минимум.
• Три типа тестов: walkthrough (table-top discussion, $); simulation (partial restore в sandbox, $$); full restore (production failover, $$$).
• DORA TLPT каждые 3 года для significant entities; типична методология TIBER-EU; cost $500K–$2M.
• Evidence checklist: drill_id, scope, type, participants, выполненные шаги (фактическое vs designed время, статус, evidence artifact), верификация data integrity (pre/post checksum), deviations log, summary outcomes, audit trail, retention.
• 7 типичных failure modes: неполный scope restore, stale runbook, нет test-данных, drill оптимизирован away (relaxed pre-conditions), отклонения не задокументированы, коммуникации не валидированы, аудитор не приглашён.
• Annual drill calendar встроен в governance Risk Committee; SLA закрытия отклонений tracked; кумулятивный evidence хранится 7y SOX.
• DORA Arts. 24–27 testing + ISO 22301 Clause 8.5 exercise programme — первичные regulatory anchors.

В M6.7 (лаба) — синтез M6.1–M6.6: построить полный BIA → CDE → infrastructure → recovery plan для SwiftPay wallet, как практический артефакт, применимый к T+9M SwiftRide.