Введение

SwiftRide T+13M, четверг 02:47 UTC. PagerDuty срабатывает с SEV-1 на нарушение сверки CDE-SWR-003 — дельта Snowflake fct_driver_earnings vs Aurora swiftpay.payouts = 0.34%, порог 0.05%. Priya (on-call data steward) подтверждает в 02:51. По процессу M7.4 — решение по triage ≤ 30 мин. К 03:15 Priya подключает Carlos (Finance Lead) + SwiftPay Tech Lead Marko + дежурного офицера General Counsel Lina. Обсуждение на бридже:

• Первичная оценка влияния: 1247 выплат водителям затронуто; ~€47k совокупного недоплат.
• Географическая концентрация: 87% DACH (Германия + Австрия + Швейцария) + 13% Benelux.
• Паттерн напоминает инцидент с округлением DACH 2024 (CDE-SWR-003 = “poster child” с того инцидента).
• Видимо клиенту — водители увидят недоплату в UI кошелька.

Carlos: «Нам нужно запустить clocks уведомлений. Какие?». Lina: «Дай проверить матрицу». 03:18 UTC — Lina возвращается со списком: PSD2 Art. 96 (4ч начальное — clock стартовал в 02:47, истекает в 06:47), DORA Art. 19 (4ч начальное если классифицировано как major — нужно немедленное решение по классификации), DPC Ireland GDPR Art. 33 (72ч если затронут driver PII — да, так как payout-записи содержат PII), внутреннее в Audit Committee (следующее регулярное заседание + внеочередное если материально). Плюс налоговые органы BZSt (DE) + AT FA + CH ESTV по затронутому pay-периоду если материально — не немедленный clock, но окно конца квартала приближается.

Это не один clock — это 4 параллельных clocks, начиная с T+0 (обнаружение). Если предклассифицированных процессов не существует, бригада тратит первые 30 минут на обсуждение вместо действия. M8.4 — о том, как этого избежать через severity matrix + предмаппированные потоки уведомлений + runbooks.

Severity matrix — 4 уровня

M7.4 рассматривал 3 уровня (SEV-1 / SEV-2 / SEV-3). Для реагирования на инциденты CDE целесообразно расширить до 4 уровней:

Назначение severity в SwiftRide автоматизировано:

• Источник = tier CDE (реестр) × тип правила × downstream blast radius.
• Материальный CDE + видимый клиенту → автоматически SEV-1.
• Материальный CDE + только внутренний → SEV-2, пока не появится видимость клиенту.
• Tier-2 CDE + изолированный → SEV-3.
• Tier-3 / косметика → SEV-4.

Различие материальный vs нематериальный. Материальный = соответствует порогу SAB 99 И/ИЛИ триггерит clock уведомления регулятора. Материальный инцидент — автоматически SEV-1.

Тайминг уведомлений регуляторов — координация нескольких регуляторов

Сценарий SwiftRide T+13M выше (нарушение сверки SwiftPay) — взгляд из RegulatoryNotificationTimeline для типа инцидента “SwiftPay payout regression”:

4 параллельных clocks стартуют T+0 (detection 02:47 UTC):

1. PSD2 Art. 96 — 4 часа начальное уведомление в DNB. Clock истекает 06:47 UTC. Требуется: коммуникация клиентам затронутых PSU, план митигации, начальное уведомление регулятора.
2. DORA Art. 19 — 4 часа с классификации как major (максимум 24ч с detection). Решение классификации должно быть принято в течение часов. SwiftRide CDE-SWR-003 + трансграничный + видимый клиенту = вероятно major. Clock эффективно 4ч от 02:47 = 06:47, или 24ч максимум = 26:47 на следующий день.
3. GDPR Art. 33 — 72 часа с момента осведомлённости. Clock истекает в воскресенье 02:47 UTC. Требуется: уведомление DPO, шаблон DPC Ireland, оценка влияния, вероятные последствия.
4. Внутренний к Audit Committee — следующее регулярное заседание или внеочередное, если кандидат на material weakness. Контекст pre-IPO = вероятно внеочередное.

Сложность координации нескольких регуляторов. Разные регуляторы ожидают разной формулировки сообщения, разных оценок влияния, разных обязательств ремедиации. Несогласованность = supervisory finding. Паттерн SwiftRide:

• Единый источник истины — incident-документ поддерживается в Confluence + S3-архив; обновляется по мере уточнения фактов.
• Шаблон по регулятору маппится из source-документа; офис General Counsel поддерживает предодобренные шаблоны для типовых сценариев.
• Скоординированный timeline подач — наиболее строгий дедлайн диктует каденс подачи; последующие подачи ссылаются на предыдущие для согласованности.
• Кросс-функциональный bridge-колл — все clocks регуляторов обсуждаются совместно; никто не ускользает от упоминания.

Точка эскалации: когда внутренний инцидент эскалирует во внешнее уведомление?

Критерии решения:

• Материальное отклонение точности / полноты данных, которое заботит аудитора → трек SEC / SOX (после IPO).
• Влияние, видимое клиенту (финансовое / сервис / privacy) → PSD2 / DORA / GDPR / законы privacy штатов.
• Нарушение трансграничного data flow → уведомления нескольких DPA.
• Затронута критическая ICT-функция > 2ч → порог major-инцидента DORA.
• Подозрительная активность не флагирована → AML SAR + уведомление надзора.

Преднастроенный runbook “дерева решений” помогает; ad-hoc оценка в 03:00 под давлением = ошибки.

Runbooks для топ-5 типов инцидентов

SwiftRide T+13M поддерживает 5 предмаппированных runbooks (Markdown в репо runbooks/; печатные PDF-версии закешированы локально на ноутбуках on-call для офлайн-доступа):

Runbook 1: Утечка данных / несанкционированная эксфильтрация

Сценарий: PII / регулируемые данные раскрыты через misconfigured public ACL S3-бакета, публичный коммит в GitHub-репо, API-эндпоинт без аутентификации, или инсайдерская эксфильтрация.

Severity: SEV-1 автоматически.

Дерево решений:

• T+0: PagerDuty звонок on-call + CISO + DPO + General Counsel.
• T+30мин: Containment — отозвать доступ, ротировать креды, отключить эндпоинт.
• T+2ч: классификации GDPR Art. 33 / Art. 34 + NIS2 Art. 23 + SEC 8-K Item 1.05 (после IPO).
• T+72ч: подача GDPR.
• T+1мес: финальный отчёт DORA + финальная оценка GDPR DPA.

Артефакты: пакет доказательств, forensic-логи, манифест раскрытия (какие записи / сколько), подачи уведомлений, лог коммуникации клиентам.

Runbook 2: Нарушение точности / целостности (провал сверки)

Сценарий: Инцидент по паттерну SwiftPay — материальное отклонение точности данных; затронут payout / финансовый расчёт.

Severity: SEV-1 если видим клиенту или материальный; SEV-2 если только внутренний.

Дерево решений:

• T+0: PagerDuty звонок on-call + Business Owner + Finance Lead.
• T+1ч: Containment — заморозить затронутый пайплайн / payout DAG.
• T+2ч: классификации PSD2 + DORA + GDPR (если затронут PII).
• T+4ч: попытка разрешения — reprocess + верификация.
• T+5 рабочих дней: RCA + превентивное действие в очереди.

Артефакты: доказательство дельты сверки, вывод reprocess DAG, RCA-документ, доказательство restitution.

Runbook 3: Переполнение AML-алертов / провал мониторинга

Сценарий: Сбой engine мониторинга транзакций; очередь алертов растёт за пределы SLA ревью; подозрительные активности потенциально пропущены.

Severity: SEV-1 если обнаружен материальный разрыв после восстановления; SEV-2 если бэклог алертов очищен в SLA.

Дерево решений:

• T+0: PagerDuty звонок on-call + AML Officer + Risk Function.
• T+1ч: Containment — активирован резервный мониторинг (ручной обзор очереди + эскалация).
• T+24ч: уведомление национальной FIU если SAR-подлежащие активности не проревьюены во время сбоя.
• T+72ч: уведомление национального надзора (DNB / BaFin) о материальном провале AML-контроля.

Артефакты: логи сбоя, снапшот очереди алертов до/после, лог ручного обзора, подачи SAR если применимо.

Runbook 4: Промах sanctions screening

Сценарий: Sanctions screening OFAC / EU / OFSI падает (ошибка конфигурации, задержка обновления списка, mismatch транслитерации); флагированный клиент / транзакция не заблокированы.

Severity: SEV-1 автоматически независимо от единичного-vs-многих инцидентов.

Дерево решений:

• T+0: PagerDuty звонок on-call + Sanctions Officer + General Counsel.
• T+1ч: Containment — активирован ручной backstop screening; заморозка транзакций (в зависимости от координации финансового регулятора).
• T+10 рабочих дней: подача apparent-violation в OFAC если применимо.
• T+24-72ч: EU / OFSI по применимому режиму.

Артефакты: детали транзакции, логи screening engine, сравнение версий списков, документ рассмотрения добровольного self-disclosure.

Runbook 5: Сбой вендора / влияние CTPP

Сценарий: Major-сбой Snowflake / Confluent / Databricks / AWS > 2ч, затрагивающий CDE-несущие сервисы.

Severity: SEV-1 если материальная функция недоступна; SEV-2 если только деградирована.

Дерево решений:

• T+0: PagerDuty звонок on-call + Platform Engineering Lead + Vendor Manager.
• T+1ч: активация BCP (по M6 BIA + DRP); failover на secondary если доступен.
• T+4ч: DORA Art. 19 (если классификация ICT major-инцидента).
• T+72ч: промежуточное уведомление DORA.
• T+1мес: финальный DORA + обновление DORA Register of Information (Arts. 28-44).
• T+5 рабочих дней: post-mortem с вендором + документ supplier review.

Артефакты: скриншоты vendor status-страниц, лог активации BCP, данные о влиянии на клиентов, post-mortem вендора (когда опубликован), обновление RoI если существенное изменение.

Шаблон post-mortem

По дисциплине RCA M7.4 — шаблон post-mortem обеспечивает структурированные поля:

# Post-mortem: [Incident ID] [Short title]

**Date:** YYYY-MM-DD
**Severity:** SEV-1 / SEV-2
**Incident commander:** [name]
**Business owner:** [name]
**Affected CDE:** [CDE-IDs]
**Duration:** detection T0 → closure T+X

## Executive summary (3 sentences max)

## Impact

- Financial: $X / €X
- Customers: N affected
- Regulatory clocks fired: [GDPR, DORA, PSD2, ...]
- Reputational: [public / internal-only]

## Timeline (UTC)

- T+0 02:47 — DQ rule fires; PagerDuty page
- T+0:30 — Triage; SEV-1 confirmed
- T+1:00 — Containment complete
- ...

## Root cause (5-why)

Why 1: ...
Why 2: ...
Why 3: ...
Why 4: ...
Why 5: ...

## Contributing factors

- Technical: ...
- Process: ...
- Organisational: ...

## What went well

- ...

## What went poorly

- ...

## Action items (preventive)

| Action | Owner | Severity | Due | Status |
|---|---|---|---|---|
| Increase parity check sample to 100% | Priya | high | T+30d | open |
| ... | | | | |

## Lessons learned

...

## Internal Audit observer notes

...

Шаблон + автоматизация: post-incident-автоматизация Atlassian Jira наполняет структуру; инженер заполняет секции; обязательные поля заблокированы от закрытия, если пустые; наблюдатель Internal Audit ревьюит качество; публикуется во внутреннюю wiki + пакет доказательств S3.

Состояние SwiftRide T+13M

• 5 runbooks живые + тестируются ежеквартально через tabletop-упражнения.
• 3 SEV-1 инцидента Q3 2026 — все в SLA; координация нескольких регуляторов протестирована (1 GDPR + 1 PSD2 / DORA комбинированный + 1 AML).
• Шаблон post-mortem принудительно исполнен; качество проревьюено Internal Audit для 100% выборки SEV-1 в Q3.
• Паттерн: время исполнения runbook реагирования на инциденты снижается — среднее Q1 2026 от T+0 до первого уведомления регулятора = 5.5ч; Q3 = 4.2ч (ближе к целям PSD2 / DORA 4ч).
• Цель pre-IPO T+15M — среднее ≤ 3.5ч до первого уведомления регулятора; 100% SEV-1 в применимых clocks.

Антипаттерны

Ad-hoc интерпретация clock под давлением

Паттерн: на bridge-колле в 03:00 команда дебатирует “это 4ч DORA или 24ч max”; теряются ценные минуты.

Почему плохо: решения, принятые под давлением, не оптимальны; согласованность деградирует; supervisory finding вероятен из-за непоследовательности.

Исправление: предмаппированные деревья решений в runbook; ежеквартальные tabletop-упражнения прогоняют сценарии; шаблоны General Counsel предодобрены.

Фокус на одном регуляторе

Паттерн: команда фокусируется на clock PSD2 (наиболее знакомом); уведомления GDPR / DORA / SEC пропущены или задержаны; перекрёстные проверки надзорных органов находят несогласованность.

Почему плохо: координация нескольких регуляторов — явное требование; пропуск одного = независимый finding от пропущенного регулятора.

Исправление: bridge-колл обязателен — обсуждаются все clocks регуляторов; General Counsel поддерживает clock-матрицу; скоординированный timeline подач.

Ad-hoc коммуникация клиентам

Паттерн: водители видят недоплату в UI кошелька; Support Twitter отвечает до официальной коммуникации; непоследовательные сообщения.

Почему плохо: явное требование коммуникации клиентам PSD2 Art. 96(1); нескоординировано = дополнительный supervisory finding.

Исправление: предодобренные шаблоны коммуникации клиентам (мультиязычные); Support Lead активирован на bridge-колле с T+30мин; координация через одобренный релиз General Counsel.

Post-mortem пропущен или низкого качества

Паттерн: инцидент закрыт в SLA; post-mortem написан, но секция contributing factors пуста; “transient infrastructure” — общий RCA.

Почему плохо: по M7.4 — паттерн квази-management-override; control deficiency по PCAOB AS 1305 на процесс RCA.

Исправление: шаблон обеспечивает секции; наблюдатель Internal Audit ревьюит качество 100% SEV-1; авто-отказ от закрытия, если секции пусты.

Резюме

• 4-уровневая severity matrix: SEV-1 (материальный CDE, видимый клиенту) / SEV-2 (деградация качества) / SEV-3 (tier-3 информационный) / SEV-4 (косметика / не-CDE).
• Уведомление нескольких регуляторов — параллельные clocks: GDPR Art. 33 (72ч) + DORA Art. 19 (4ч initial / 72ч intermediate / 1 месяц final) + SEC 8-K Item 1.05 (4 рабочих дня после IPO) + PSD2 Art. 96 (4ч initial) + NIS2 Art. 23 (24ч / 72ч / 1 месяц) + AMLR national SAR + национальный надзор.
• Документ единого источника истины об инциденте + маппинг шаблонов по регулятору + скоординированный timeline подач = согласованность между регуляторами.
• 5 runbooks для топ-типов инцидентов: утечка данных, нарушение точности, переполнение AML-алертов, промах sanctions screening, сбой вендора / CTPP.
• Шаблон post-mortem обеспечивает 5-why + contributing factors + action items + заметки наблюдателя Internal Audit.
• SwiftRide T+13M: 3 SEV-1 инцидента Q3; все в SLA; цель T+15M ≤ 3.5ч до первого уведомления регулятора.
• Антипаттерны: ad-hoc интерпретация clock, фокус на одном регуляторе, ad-hoc коммуникация клиентам, низкокачественный post-mortem — все детективные контроли — ежеквартальные.

В M8.5 разберём управление поставщиками — DPA / чтение SOC1/SOC2 / DORA Register of Information / CTPP / exit-стратегия.