Введение

SwiftRide T+14M. Партнёр аудита Big 4 Daria запрашивает: «Проведите меня через ваше обращение с риском вендора для топ-5 CDE-поддерживающих вендоров. Покажите контракты, SOC 2-отчёты, записи DORA Register of Information, exit-стратегии и доказательства мониторинга за Q3 2026». Офис CDO формирует таблицу:

Daria проверяет SOC 2-отчёты… «Я вижу, Snowflake SOC 2 Type 2 покрывает период январь-декабрь 2025; аудит-фирма = Deloitte; opinion unqualified opinion; секция IV (CUEC — Complementary User Entity Controls) — там 14 контролей, ожидаемых от клиентов. Покажите, как SwiftRide реализует эти 14 CUEC. В частности — “Customer is responsible for monitoring authentication failures” — у вас есть дашборд Snowflake SecOps?». Офис CDO: «…мы открываем дашборд аккаунта Snowflake, но не систематически ревьюим». Daria: «Это SOC 2-finding на стороне SwiftRide; vendor SOC 2 не защищает вас, если CUEC не реализованы».

Этот диалог захватывает суть управления поставщиками: SOC-отчёты вендора — не plug-and-play assurance; они требуют активной реализации CUEC. M8.5 — полный жизненный цикл vendor risk для CDE-поддерживающих провайдеров.

Жизненный цикл vendor risk — 5 этапов

1. Identification → 2. Due Diligence → 3. Contracting → 4. Monitoring → 5. Exit

Этап 1: Identification.

• Запрос на нового вендора от бизнес-команды (PR-шаблон в scaffolder Backstage).
• Классификация вендора — касается ли CDE? Tier? Контекст регулятора?
• Требуется: бизнес-кейс, рассмотрение альтернатив, оценка концентрации.
• Результат: запись кандидата вендора в ServiceNow vendor master.

Этап 2: Due Diligence.

• Опросник по безопасности (CAIQ или кастомный).
• Опросник по privacy (соответствие GDPR / state privacy).
• Проверка финансовой стабильности.
• Ревью SOC 1 / SOC 2 / SOC 3-отчёта (если применимо).
• Звонки с reference-клиентами.
• Pen-тест или ревью раскрытия вендора.
• Результат: due diligence-отчёт → подписание CDO + Risk Function + CISO + General Counsel + Procurement.

Этап 3: Contracting.

• DPA (Data Processing Agreement) по GDPR Art. 28.
• MSA / Service Agreement с контрактными минимумами DORA Arts. 28-30.
• Раскрытие субподрядчиков (DORA Art. 30).
• SLA, согласованные с внутренними RTO / RPO (ссылки M6 BIA).
• Условия прекращения + контрактно обеспеченная exit-стратегия.
• Результат: подписанный контракт в Workiva CLM + модуле контрактов ServiceNow.

Этап 4: Monitoring.

• Ежегодное обновление SOC 2 Type 2.
• Триггер обновления DPA (изменение субпроцессора, новая цель обработки, изменение регулирования).
• Поддержка записи в DORA RoI.
• Трекинг SLA производительности вендора.
• Мониторинг цепочки субподрядчиков.
• Ежеквартальная оценка concentration risk.
• Результат: ежеквартальная vendor scorecard; обновлён реестр рисков.

Этап 5: Exit.

• Exit-стратегия задокументирована + протестирована.
• Процесс возврата / уничтожения данных по DPA.
• Размотка цепочки субподрядчиков.
• План миграции + период dual-running.
• Результат: запись об offboarding вендора + финальный сертификат уничтожения данных.

DPA (Data Processing Agreement) — обязательные поля GDPR Art. 28

GDPR Art. 28(3) требует, чтобы DPA минимум содержал:

1. Subject matter — какая обработка касается.
2. Duration — начало + конец обработки.
3. Nature и purpose — какие операции выполняются.
4. Type personal data — категории.
5. Categories of data subjects — кто затронут.
6. Obligations + rights of controller — что делает controller + к чему обязуется processor.
7. Processor only on documented instructions — Art. 28(3)(a).
8. Confidentiality — Art. 28(3)(b).
9. Security measures Art. 32 — TOMs.
10. Sub-processor restrictions — Art. 28(3)(d) — предварительная конкретная/общая авторизация.
11. Assistance с data subject rights — Art. 28(3)(e).
12. Assistance с Art. 32-36 obligations — security + breach + DPIA.
13. Deletion / return at end — Art. 28(3)(g).
14. Audit + inspection rights — Art. 28(3)(h).

Шаблон DPA SwiftRide поддерживается General Counsel; ~32 страницы; вариативные секции:

• Секция TOMs (Art. 32) — vendor-специфична (Snowflake security defaults vs Confluent SASL/SCRAM specifics).
• Расписание sub-processor (annex с именованными субпроцессорами + локациями + ролями).
• TIA (Transfer Impact Assessment) — для non-EU вендора; на основе CNIL Practical Guide Jan 2025.
• SLA уведомления о breach — vendor-специфичный (стандарт SwiftRide: 24ч окно vendor → SwiftRide notification).

Антипаттерн: стандартный DPA вендора принят без ревью. Стандартные DPA от крупных вендоров обычно перекошены в пользу вендора; General Counsel SwiftRide настаивает на двусторонних переговорах для tier-1 CDE-затрагивающих вендоров.

SOC-отчёты — глубокое чтение

SOC-отчёты = определённые AICPA attestation-отчёты на контроли service organization. Три типа:

Type 1 vs Type 2:

• Type 1: design effectiveness на точку во времени. Полезно при онбординге вендора; недостаточно для ongoing assurance.
• Type 2: design + operating effectiveness за период (обычно 12 месяцев). Требуется для ongoing-мониторинга вендора.

Trust Services Criteria SOC 2:

• Security (Common Criteria) — обязательны для всех SOC 2-отчётов.
• Availability — uptime + производительность.
• Processing Integrity — точность + полнота + своевременность.
• Confidentiality — защита конфиденциальной информации.
• Privacy — сбор / использование / retention / раскрытие персональной информации по принципам.

Глубокое чтение SOC 2 — 4 секции:

1. Section I — Management Assertion — заявление вендора о scope.
2. Section II — Independent Auditor’s Report — opinion (unqualified / qualified / adverse / disclaimer); период даты.
3. Section III — Service Organization Description — система + процессы + контроли.
4. Section IV — CUEC (Complementary User Entity Controls) — контроли, ожидаемые от клиента для общего control framework функции.

Реализация CUEC — не подлежит обсуждению. Section IV обычно перечисляет 10-30 контролей, которые клиент должен реализовать. Vendor SOC 2 unqualified opinion предполагает, что CUEC реализованы. Ответственность SwiftRide:

• Маппить CUEC-контроли на контроли SwiftRide (CTL-CDE-*).
• Реализовывать + тестировать ежегодно.
• Доказательства хранятся в пайплайне S3 параллельно основным CDE-контролям.
• Квартальная аттестация включает статус реализации CUEC по вендору.

Примеры CUEC SwiftRide (Snowflake SOC 2 Type 2 — 14 CUEC):

Антипаттерн: SOC 2-отчёт получен и забыт. Вендор присылает SOC 2 PDF ежегодно; SwiftRide подшивает в репозиторий документов; никто не извлекает список CUEC; первый audit walkthrough находит разрыв.

Исправление: процесс ревью SOC 2 — Risk Function ежегодно извлекает CUEC; маппит на контроли SwiftRide; разрывы приоритизированы; квартальная аттестация включает % покрытия.

DORA Register of Information — Arts. 28-44

DORA Art. 28 требует регистр ежегодно. Первая подача 30 апреля 2025 — выводы:

• ESMA / EBA / EIOPA опубликовали общие технические спецификации; финансовые сущности отчитались о значительных усилиях при первой подаче.
• ~30% первых подач имели проблемы с качеством данных по фидбэку ESA (разрывы идентификации ICT third-party, вариативность категоризации функций).
• Подача 2026 (30 апреля 2026) — улучшенные шаблоны + автоматическая валидация.
• Подача 2027 — ожидается полная операционная зрелость.

Поля RoI — полный инвентарь по шаблону ESA:

• Идентификация сущности (LEI, дерево организации).
• Идентификация ICT third-party провайдера (LEI, страна, родитель).
• Характеристики контракта (начало, конец, периметр, критичность).
• Категории функций (по таксономии RTS).
• Получаемые ICT-сервисы (по таксономии RTS).
• Поддержка критической или важной функции (да/нет по функции).
• Цепочка субподрядчиков (дерево LEI).
• Substitutability провайдера (доступность exit-стратегии).
• Трансграничные потоки данных.
• Маркеры concentration risk.

Процесс RoI SwiftRide (T+13M):

1. CMDB → автоматический скрипт извлечения (см. M8.3) генерирует сырой экспорт RoI ежеквартально.
2. Офис CDO + Risk Function + General Counsel ревьюит перед подачей.
3. Записи vendor master перекрёстно сверяются по точности LEI / родителя / цепочки субпроцессоров.
4. Анализ substitutability — зрелость exit-стратегии скорится; задокументированные разрывы отчитываются.
5. Финальная подача в портал ESA ежегодно (следующая: 30 апреля 2027).
6. Подача архивируется в S3 Object Lock на 7 лет.

CTPP (Critical Third-Party Provider) — 19 назначены 18 ноября 2025

DORA Art. 31 — назначение CTPP триггерится:

• Скор критичности (на основе сервисов + концентрации + substitutability).
• Усмотрение ESA.

18 ноября 2025 — первые 19 CTPPs назначены EBA / EIOPA / ESMA совместно:

• Hyperscale cloud-провайдеры: AWS, GCP, Microsoft Azure.
• Провайдеры дата-центров / colocation.
• Технологические провайдеры специфичные для финансовых сервисов.

Импликации для назначенного CTPP:

• Назначить юр. лицо EU (если non-EU origin).
• Платить ежегодные надзорные сборы (пропорционально масштабу).
• Принять inspection rights ESA.
• Соответствовать CTPP-специфичным обязательствам (участие в TLPT, отчётность об инцидентах ESA).

Импликации для SwiftRide (финансовая сущность, использующая CTPP):

• AWS назначен CTPP → дополнительный due diligence субподрядчика по Art. 30.
• Накладные документации — AWS-специфичные маппинги контролей + exit-стратегии под большим scrutiny.
• Периметр TLPT (threat-led penetration testing) может расшириться на AWS-зависимые сервисы.
• Контрактные минимумы повышены по DORA Arts. 30-34.

Ответ SwiftRide T+14M:

• Контрактное ревью AWS Q1 2027 — привести DPA + MSA в полное соответствие DORA Art. 30.
• Exit-стратегия для AWS — мульти-регион тестирование + анализ feasibility альтернативного cloud-провайдера.
• Concentration risk признан — AWS = основной cloud, GCP минимально (только Vertex AI), нет Azure; concentration HIGH; митигация = мульти-регион внутри AWS + протестированный DR.

Exit-стратегия — DORA Art. 28(3)(g) + GDPR Art. 28

Exit-стратегия = задокументированный + протестированный план миграции от вендора, если необходимо. Требуется:

• DORA Art. 28(3)(g) для ICT third-party договорённостей.
• GDPR Art. 28(3)(g) для возврата / уничтожения данных в конце контракта.

5 элементов зрелой exit-стратегии:

1. Оценка lock-in субпроцессора / вендора.

   • Форматы данных портируемые vs проприетарные?
   • API стандартизованы vs кастомные?
   • Передаваемость навыков?

2. План миграции — конкретные шаги.

   • Целевой альтернативный провайдер идентифицирован.
   • Подход к экспорту данных + формат.
   • Охват рефакторинга приложения.
   • Timeline + оценка ресурсов.
   • Оценка стоимости.

3. Период dual-running.

   • Запуск обоих вендоров параллельно во время миграции.
   • Проверки сверки подтверждают паритет.
   • Критерии cutover задокументированы.

4. Возврат / уничтожение данных.

   • По DPA — вендор возвращает или уничтожает данные в конце контракта.
   • Получен сертификат уничтожения.
   • Верификация на стороне SwiftRide (проверки бэкапов).

5. Периодическое тестирование.

   • Ежегодное tabletop-упражнение, симулирующее триггер exit.
   • Ежеквартальное ревью свежести плана.
   • Lessons learned инкорпорированы.

Зрелость exit-стратегии SwiftRide T+13M:

Готовность pre-IPO листинга — аудитор Big 4 ожидает зрелые exit-стратегии минимум для топ-3 вендоров. Deliverable Q4 2026.

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

”Большой вендор должен быть безопасным”

Паттерн: Snowflake / AWS / Databricks предполагаются безопасными по репутации; due diligence light-touch; SOC 2 подшит без маппинга CUEC.

Почему плохо: vendor SOC 2 защищает контроли вендора; не ваше приложение; CUEC на стороне SwiftRide важны.

Исправление: маппинг SOC 2 CUEC обязателен по вендору; ежегодное ревью; квартальная аттестация включает % покрытия.

Статический DPA

Паттерн: DPA подписан при онбординге; никогда не обновлялся; изменения субпроцессоров не отражены; новые цели обработки добавлены без поправки DPA.

Почему плохо: нарушение GDPR Art. 28; supervisory finding; ответственность processor смещена.

Исправление: триггеры обновления DPA — изменение субпроцессора вендора, новая цель обработки, изменение регулирования; CLM-процесс автоматизирует продление; квартальная scorecard свежести DPA.

Театр exit-стратегии

Паттерн: документ exit-стратегии существует; никогда не тестировался; написан без практического знания; “мы мигрируем за 6 месяцев” — на самом деле невозможно.

Почему плохо: DORA Art. 28(3)(g) требует тестируемого exit; театр = supervisory finding + реальная outage-экспозиция.

Исправление: ежегодное tabletop-упражнение; lessons learned инкорпорированы; квартальная проверка свежести плана; ротация ключевого персонала включает walkthrough exit-стратегии.

”TBD” застрял в RoI

Паттерн: подача DORA RoI 2025 имела TBD-записи; подача 2026 наследует те же TBD; “исправим в следующем году” — никогда не исправлено.

Почему плохо: фидбэк ESA явный по качеству данных 2025; 2026 — ожидается прогресс; наследование TBD = риск supervisory эскалации.

Исправление: поддержка RoI — ongoing-процесс, не ежегодная гонка; ежеквартальное ревью; совместная ответственность CDO + Risk Function.

Резюме

• Жизненный цикл vendor risk — 5 этапов: identification → due diligence → contracting → monitoring → exit.
• GDPR Art. 28 DPA — 14 обязательных полей; двусторонние переговоры для CDE-затрагивающих вендоров; TIA для non-EU вендоров по гайденсу CNIL Jan 2025.
• SOC-отчёты: SOC 1 (ICFR-релевантный), SOC 2 (TSC — security обязательны + 4 опциональных), SOC 3 (публичное саммари); Type 1 (design POI) vs Type 2 (design + operating effectiveness 12мес).
• CUEC (Section IV SOC 2) — 10-30 контролей, которые клиент должен реализовать; маппинг обязателен; % покрытия в квартальной аттестации.
• DORA Register of Information (Arts. 28-44) — первая подача 30 апреля 2025; автоматическая CMDB-driven генерация; совместное подписание CDO + Risk Function + General Counsel.
• Назначение CTPP 18 ноября 2025 — 19 CTPPs (AWS / GCP / Azure + другие); контрактные минимумы повышены по Art. 30; периметр TLPT расширяется.
• Exit-стратегия — 5 элементов: оценка lock-in + план миграции + dual-running + возврат/уничтожение данных + периодическое тестирование; зрелая для топ-3 вендоров перед IPO-листингом.
• SwiftRide T+14M: 4 разрыва остались — exit-стратегии Confluent/Databricks + формализация Snowflake CUEC + контрактное отражение AWS CTPP + скоринг substitutability RoI; deliverables Q4 2026.

В M8.6 разберём AI / ML-оверлей — обучение моделей на CDE + EU AI Act Art. 10 + Annex IV + маппинг model risk management.