Введение

CDE — это не one-time decision. Это артефакт жизненного цикла, который проходит через структурированные стадии: предложен, проверен, утверждён, поддерживается несколько лет, перепроверяется ежегодно, и в конечном итоге retired (когда бизнес-модель меняется или система выводится из эксплуатации). На каждой стадии — разные роли, разные входы / выходы, разные gate criteria.

Этот урок строит workflow lifecycle, который SwiftRide может развернуть на неделе 4 программы — и работать на нём 18 месяцев до IPO. Плюс sequence diagram, иллюстрирующий, как один CDE проходит полный lifecycle.

5 стадий lifecycle

Эти 5 стадий стабильны; production-версия может добавлять промежуточные sub-stages (например, «pilot controls» между approval и maintenance). Это нормально — основные 5 стадий — общий backbone.

Стадия 1: Nomination

Триггер: кто угодно идентифицирует датасет, который заслуживает рассмотрения как CDE. Источники:

• Audit finding (Big 4, internal audit) — самый частый.
• Регуляторный дедлайн (новая регуляция требует идентификации данных).
• Инцидент (DQ issue, затрагивающий financial / regulatory output).
• Новая бизнес-модель (новый бизнес-юнит, запуск нового продукта).
• Ежегодный portfolio sweep — все датасеты с определёнными характеристиками номинируются массово.

Форма nomination (минимально требуемые поля):

• nominator (кто предложил)
• dataset_identifier (техническая ссылка — table, fields)
• nomination_trigger (audit / incident / regulatory / и т.д.)
• proposed_business_rationale (1-2 предложения почему)
• proposed_owner (best guess; уточняется в review)

Gate criteria для перехода в Review:

• Датасет технически идентифицируем (table + columns)
• Бизнес-обоснование не тривиально («всё важное»)
• Предлагаемый владелец — реальный человек или роль, не «TBD»

Если gate не пройден — nomination возвращается с feedback, не auto-rejected. Цель — поощрять номинации, даже imperfect.

Пример SwiftRide: Internal auditor номинирует swiftcapital.dl.loan_portfolio_ecl_stage после запроса Big 4. Форма заполнена, trigger=audit, proposed owner=Head of SwiftCapital Risk. Gate пройден → переход в Review.

Стадия 2: Review

Владелец: Data Steward + предлагаемый Data Owner совместно проводят review.

Процедура:

1. Верифицировать периметр — подтвердить границы датасета (table + columns, не surrounding).
2. Применить фреймворк scoring (M1.3-1.4) — score 4 dimensions с rationale на ячейку.
3. Проверить классификации (M1.5) — PII? Master Data? Reference Data? Confidential tier?
4. Проверить существующие controls — что уже на месте; что в gap.
5. Оценить effort — стоимость реализации controls, ongoing maintenance.
6. Подготовить review packet — scoring + классификации + gap analysis + оценка effort.

Gate criteria для перехода в Approval:

• Все 4 dimensions оценены с rationale
• Verdict ясен (CDE / borderline / not-CDE) по threshold scoring
• Кандидат во владельцы подтвердил готовность (устное согласие)
• Оценка effort ориентировочная (например, в кварталах: «1 sprint для baseline controls»)

Если verdict = «not-CDE» — packet всё равно архивируется (для audit trail), но не proceed. Если «borderline» — эскалация по M1.4 (past incident? imminent deadline? input owner + compliance?).

Бюджет времени: 2-4 часа на кандидата в первом цикле; 1-2 часа, когда команда experienced. Если scoring занимает 1 день на кандидата — фреймворк слишком расплывчат.

Стадия 3: Approval

Владелец: Data Council (председатель CDO).

Ритм: Обычно bi-weekly batch review. Размер пакета 5-10 кандидатов на встречу.

Процедура:

1. Pre-read — review packets распространяются за 48ч до встречи.
2. Обсуждение — по кандидату: оспаривание rationale scoring, обсуждение effort controls, подтверждение владения.
3. Решение — голосование / консенсус по кандидату: approve / reject / defer для дополнительной info.
4. Запись в реестре создаётся для approved CDE с метаданными:
   • Дата approval, участники совета, обоснование решения
   • Подписанные DQ tolerances
   • Периметр baseline controls
   • Ритм attestation (default quarterly)
   • Следующая дата рецертификации (default +12 месяцев)

Gate criteria для перехода в Maintenance:

• Запись в реестре создана
• Data Owner формально принимает (подписанное acceptance — email или e-signature)
• Initial работа по реализации controls запланирована
• DQ tolerances baselined (initial; refinable)

Пример SwiftRide T+1M: Data Council просматривает первый batch из 10 кандидатов (после initial nomination + review). Approves 6 как CDE подтверждено; 3 borderline → эскалирует; 1 not-CDE → архивирует. Протокол совета ссылается на записи в реестре.

Стадия 4: Maintenance

Владелец: Data Owner (primary accountability), Data Steward (operational execution).

Активности (ongoing):

• DQ-мониторинг — daily / hourly / per-batch проверки против tolerances.
• Реагирование на инциденты — когда DQ-проверка падает, incident workflow (M5 / M8).
• Quarterly attestation — Data Owner подписывает эффективность controls за период (M7).
• Управление изменениями — предложенные изменения датасета (schema, source) требуют CDE-aware review.
• Поддержка lineage — lineage до authoritative source остаётся актуальной.
• Sync метаданных — записи каталога поддерживаются актуальными.

Gate criteria для здорового maintenance:

• 4 quarterly attestations завершены в течение fiscal year
• DQ tolerances met >95% measurement windows
• Нет нерешённых инцидентов > 90 дней
• Покрытие lineage > заявленного tolerance (например, 95% column-level)

Failed maintenance триггерит эскалацию:

• Пропущенный attestation → эскалация CDO → уведомление audit committee, если пропущены 2.
• Повторный breach DQ tolerance → редизайн controls (M5).
• Gap в lineage → engineering remediation sprint.

Стадия 5: Retirement

Триггеры:

1. Decommission системы — source-система выведена (например, legacy DB shut down).
2. Изменение бизнес-модели — бизнес-юнит divested, продукт прекращён.
3. Регуляторный delisting — регуляция, которая driving CDE-статус, отменена или изменён периметр.
4. Re-scoping — re-scoring показывает, что датасет больше не соответствует CDE threshold (редко; обычно отражает баг в initial scoring).
5. Замена — датасет заменён новым CDE, который теперь покрывает те же controls.

Процедура:

1. Retirement proposal — Data Owner предлагает с rationale + триггером.
2. Impact analysis — какие controls / evidence зависели от этого CDE.
3. План замены / миграции — если датасет заменён, обеспечить миграцию controls.
4. Data Council approval — формальный sign-off.
5. Retirement record — запись в реестре со статусом «retired», retention метаданные для audit trail.
6. Архивированный evidence — прошлые attestation packets сохранены по SOX retention (7 лет).

Критический анти-паттерн: silent retirement. CDE тихо удалён из реестра без формальной retirement record. Audit позже спрашивает «что случилось с CDE-007» — нет ответа. Всегда формальный retirement.

Визуализация lifecycle — sequence diagram

Ритм рецертификации

Default: Ежегодно минимум. Некоторые CDE — чаще:

Процедура рецертификации:

1. Извлечь запись CDE из реестра — текущее scoring, классификации, владелец, controls.
2. Re-score через текущий фреймворк (potentially обновлённые веса, критерии).
3. Проверить классификации — всё ещё PII? Всё ещё Confidential tier? Изменился ли GDPR scope?
4. Проверить эффективность controls — past year attestations, частота инцидентов, частота breach DQ tolerance.
5. Обновить или retire — запись в реестре обновлена, или инициирован retirement.

Типичный finding рецертификации: датасет эволюционировал — добавились новые columns, новые downstream consumers, новый regulatory exposure. Scoring остаётся тем же или растёт; периметр controls расширяется.

Retirement — когда и почему

Триггер 1: Decommission системы. SwiftRide мигрирует legacy CockroachDB cluster в Aurora PostgreSQL. Старая запись CDE для swiftpay.legacy.transactions retired; новая запись CDE для swiftpay.aurora.transactions создана. Past evidence сохранён.

Триггер 2: Изменение бизнес-модели. SwiftRide divests segment SwiftAds (гипотетически). Все записи CDE по SwiftAds retired. Evidence сохранён для potential audit / litigation.

Триггер 3: Регуляторный delisting. Гипотетически: некая юрисдикция отменяет требование data residency. Запись CDE для eu_data_residency_register может быть retired, если нет другой driving регуляции.

Триггер 4: Re-scoping. Редко. Initial scoring переоценил criticality (например, предположил regulatory exposure, но новое legal opinion clarifies нет exposure). Re-scoring → not-CDE → retirement. Документируйте тщательно — выглядит плохо, если воспринимается как governance reduction без basis.

Триггер 5: Замена. Новый CDE заменяет старый. Старый retired, новый active. Обеспечить, что миграция controls протестирована.

Правило retention: Retirement НЕ удаляет past evidence. SOX retention 7 лет; GDPR ROPA retention варьируется. Всегда retain evidence для покрытия audit period.

Версионирование определений CDE

Определения CDE эволюционируют. Без версионирования, «какое было обоснование scoring в Q3 2026?» становится неотвечаемым.

Минимальные поля версионирования:

• version_number (семантический: 1.0 → 1.1 minor обновление tolerance → 2.0 обновление фреймворка scoring)
• version_effective_date
• change_summary (1-2 предложения)
• changed_by (user)
• superseded_versions (ссылка на предыдущие)

Триггеры для version bump:

• Изменение DQ tolerance
• Изменение периметра (columns добавлены / удалены)
• Изменение владельца
• Изменение baseline controls
• Изменение классификации

Rule of thumb: любое изменение, которое затронет future attestation, должно поднять версию.

Пример SwiftRide: один CDE через 18 месяцев

Проследим CDE driver_earnings_ledger через программу:

В T+24M (после курса): если SwiftRide divests Marketplace BU (гипотетически), CDE driver earnings ledger retired через формальный процесс Стадии 5.

Анти-паттерны рецертификации

1. Rubber-stamp рецертификация. Owner копирует прошлогодние tolerances + подписывает. Пропускает actual re-scoring. Подрывает цель — framework drift не пойман.

2. Пропуск рецертификации, потому что «нет изменений». Даже если датасет не меняется, регуляторная среда меняется (новая регуляция, supervisor guidance). Всегда re-check классификации.

3. Рецертификация без back-testing. В прошлом году не было инцидентов — assumed tolerances хорошие. Возможно, tolerances слишком мягкие — back-test, используя симулированные DQ-сценарии.

4. Нет retirement records. CDE тихо исчезает из реестра. Audit позже — «куда делся CDE-014?» — нет ответа. Всегда формальный retirement.

5. Версионирование пропущено, потому что «минорное изменение». Каждое изменение tolerance требует version bump. Иначе — «какой tolerance был активен в Q3 2026?» неотвечаемо.

Итоги

• 5 стадий lifecycle: Nomination → Review → Approval → Maintenance → Retirement. Каждая — определённый владелец, входы / выходы, gate criteria.
• Nomination — кто угодно может номинировать; gate keeper — Steward, проверяет полноту.
• Review — применён фреймворк scoring; 4 dimensions + классификации + gap controls + оценка effort. 2-4 часа на кандидата в первом цикле.
• Approval — Data Council batch review раз в 2 недели. Запись в реестре создаётся при approval; gate формального acceptance владельцем.
• Maintenance — ongoing: DQ-мониторинг, реагирование на инциденты, quarterly attestation, управление изменениями, поддержка lineage.
• Retirement — decommission системы / изменение бизнеса / регуляторный delisting / re-scoping / замена. Всегда формальная запись; evidence хранится по SOX 7 лет.
• Ритм рецертификации: ежегодно по default; раз в полгода для high-risk; ежеквартально для новых (первые 12 месяцев); раз в 2 года разрешено для зрелых стабильных CDE.
• Версионирование — минимальные поля: номер версии, effective date, change summary, changed by, superseded versions. Bump на любое изменение, затрагивающее future attestation.
• Пример SwiftRide driver earnings ledger — полная траектория 18 месяцев T0 → IPO.
• Анти-паттерны: rubber-stamp рецертификация, пропуск рецертификации, нет back-testing, silent retirement, пропуск версионирования.
• Дальше: урок 7 — hands-on лаба: score 10 кандидатов SwiftRide, используя шаблон + фреймворк из последних 4 уроков.