Введение

В уроке 1 мы зафиксировали, что CDE — это ось criticality, а content-type категории (Master Data, Reference Data) — другие оси. Этот урок разворачивает каждую категорию в полную глубину: точное определение, регуляторный драйвер, lifecycle, кто владелец, какие controls. Затем — матрица пересечений: датасет может попасть в несколько категорий одновременно, и каждое пересечение порождает дополнительные требования к controls.

К концу урока вы можете для любого датасета SwiftRide указать: CDE? PII? Master Data? Reference Data? Confidential? И какой набор controls из этой multi-classification следует.

Категория 1: Critical Data Element (CDE)

Определение (recap из урока 1): гранулярный элемент данных, материально влияющий на financial, regulatory, operational или reputational outcomes.

Регуляторный драйвер: BCBS 239 (Jan 2013), ECB RDARR Guide (May 2024), MAS Information Paper (May 2024), SAB 99 (через materiality framework). Для SwiftRide после IPO — SOX 404 ICFR.

Стадии lifecycle: nomination → criticality scoring → одобрение Data Council → запись в реестре → реализация controls → генерация evidence → quarterly attestation → ежегодная рецертификация → retirement. Подробнее в уроке 6.

Владелец: Data Owner с CDE-мандатом (обычно уровень VP или Director в бизнес-юните). Sign-off на DQ tolerances, controls, attestation.

Controls: preventive (input validation, schema enforcement), detective (DQ-проверки по dimensions), corrective (incident response, reconciliation). Все 3 типа required для CDE. Подробнее в M5.

Evidence: quarterly attestation packet — логи исполнения controls, результаты DQ-проверок, сводка по инцидентам, sign-off владельца. Retention 7 лет для SOX-relevant.

Категория 2: PII / Personal Data

Определение: По GDPR Art. 4(1) — «any information relating to an identified or identifiable natural person». Identifiable = прямо или косвенно (имя, ID, location data, online identifier, факторы, специфичные для физической / генетической / экономической / культурной / социальной идентичности).

Подкатегории по GDPR:

• Personal data (ordinary) — Art. 4(1); покрывается Art. 5 principles, Art. 6 lawful basis.
• Special category data — Art. 9; расовое / этническое происхождение, политические взгляды, религиозные убеждения, членство в профсоюзе, genetic data, biometric data (для идентификации), health data, sex life, sexual orientation. Более строгие требования к consent + legitimate basis.
• Criminal conviction data — Art. 10; отдельный basis.

Регуляторный драйвер: GDPR (EU, May 2018), UK GDPR, LGPD (Бразилия), CCPA / CPRA (Калифорния), DPDP India (2023, поэтапные Rules 2025-2027), законы штатов (TX, VA, CO, MD, MN, WA). Плюс отраслевые (HIPAA в US healthcare, COPPA для детей).

Стадии lifecycle: сбор (уведомление + consent / lawful basis) → обработка → хранение (encryption at rest) → передача (cross-border safeguards, SCC, adequacy) → retention (ограниченное по Art. 5) → удаление (DSR Art. 17 право на стирание).

Владелец: Data Protection Officer (DPO) или Privacy Lead для регуляторной accountability; Data Owner (по CDE-программе) для операционной accountability. Часто путают — уточняйте в policy.

Controls: consent management, access control (need-to-know), encryption, псевдонимизация (где требуется — см. EDPB Guidelines 01/2025 Jan 2025), DPIA для high-risk processing по Art. 35, breach notification 72ч по Art. 33.

Evidence: ROPA (Records of Processing Activities, Art. 30) — канонический inventory; отчёты DPIA; consent logs; breach register; документация передач. ROPA — первый источник для CDE-реестра по PII items.

Категория 3: Master Data

Определение (DAMA-DMBOK 2, Ch. 10): persistent, business-critical data, описывающие сущности — Customer, Product, Driver, Employee, Location, Asset. Не транзакционные; описывают вещи, а не события.

Регуляторный драйвер: прямой регуляции нет; косвенно затрагивается через entity-level reporting (KYC, sanctions screening, FATCA / CRS).

Стадии lifecycle: создание (установление golden record) → обогащение (дополнительные атрибуты) → поддержка (дедупликация, survivorship rules) → архивирование (когда entity неактивна).

Владелец: команда Master Data Management (MDM) или domain Data Owner (Customer MDM owned by Sales + Service; Product MDM by Product Management).

Controls: правила match-merge, создание golden record, attribute survivorship rules, change governance, cross-system propagation.

Evidence: метрики MDM stewardship, логи аудита match-merge, отчёты по обнаружению дубликатов.

Примеры SwiftRide: таблица customers (rider master), таблица drivers (driver master), таблица merchants (delivery merchant master), locations (геогорафии).

Master Data vs CDE — часто путают. Customer master может быть CDE (если material для SOX revenue recognition, AML KYC, GDPR Art. 30); Customer master также может НЕ быть CDE (например, если customer-id используется только для marketing analytics, не для financial / regulatory). Решение по фреймворку scoring (M1.4), а не по категории.

Категория 4: Reference Data

Определение (DAMA-DMBOK 2, Ch. 10): controlled vocabularies — code lists, lookup tables, enums. Малый объём (десятки-сотни значений), меняются нечасто, structure-driven.

Примеры: ISO 3166-1 country codes, ISO 4217 currency codes, внутренние status enums (active, suspended, inactive), classification taxonomies, regulatory mapping tables.

Регуляторный драйвер: прямой регуляции нет; косвенно затрагивается через downstream regulatory dependencies. Tax jurisdiction codes фидят SOX-relevant revenue recognition → reference data становится de facto SOX-relevant.

Стадии lifecycle: определение (governance committee) → публикация (versioned release) → распространение (sync к consuming systems) → депрекация (старые значения помечены obsolete с sunset date) → архив.

Владелец: Reference Data Steward (часто в shared services / data-команде); для industry-стандартных codes — defer к external authority (ISO, SWIFT, регулятор).

Controls: Управление изменениями — самые строгие. Каждое изменение требует approval (часто на уровне Data Council), version control, downstream sync verification, regression test на consuming systems.

Evidence: история версий, логи approval workflow, downstream impact analysis.

Reference Data vs Master Data — часто путают:

Примеры SwiftRide:

• country_codes_iso — Reference Data (ISO 3166-1).
• currency_codes_iso — Reference Data (ISO 4217).
• payout_status_enum (pending, processing, paid, failed, disputed) — Reference Data (внутренний).
• vehicle_categories (economy, standard, premium, xl) — Reference Data (внутренний).

Категория 5: Confidential / Restricted (Security Classification)

Определение: ось по чувствительности и access restrictions. Стандартная 4-tier схема (по NIST SP 800-53, ISO 27001:2022, организационные адаптации):

• Public — нет вреда при exposure (опубликованный квартальный GMV, маркетинговые материалы).
• Internal — ограниченный вред (org charts, внутренние product roadmaps).
• Restricted — значительный вред (финансовые черновики, обсуждения M&A, employee compensation).
• Confidential / Highly Restricted — critical harm (PII, payment card data, intellectual property, source code в некоторых компаниях).

Регуляторный драйвер: GDPR (для PII Restricted+), PCI-DSS (для card data — Confidential), trade secret law (для IP), SOX (для неаудированных финансовых черновиков — Restricted).

Стадии lifecycle: классифицировать при создании → enforce per-tier controls → переклассифицировать при изменении контекста → деклассифицировать или уничтожить по истечении retention.

Владелец: команда Information Security / Data Security для policy; Data Owner для классификационных решений на актив.

Controls по tier:

Evidence: access logs, статус шифрования, записи о пересмотре классификации.

Примеры SwiftRide:

• Public: опубликованный квартальный GMV (объявленный для IPO).
• Internal: еженедельная дорожная карта продукта.
• Restricted: черновики SwiftCapital ECL provision (нефинализированные).
• Confidential: KYC biometric data (PII Art. 9 + Confidential).

Матрица пересечений — Venn-like

Один датасет может попадать в несколько категорий. Каждое пересечение порождает объединение controls.

Объединение controls — пример KYC profile:

• CDE-controls: Data Owner identified (Compliance + DPO co-sign), DQ tolerances строгие (accuracy=99.9%, completeness=100%), preventive + detective controls, retention evidence 7 лет.
• PII Art. 9 controls: явный consent ИЛИ basis Art. 6(1)(c) legal obligation, DPIA обязательный, breach notification 72ч.
• Confidential controls: E2E encryption, MFA access, полный audit logging, vault-only sharing.

Результат: набор controls для KYC profile — объединение всех трёх. Это почему multi-axis classification matters — single-axis мышление приводит к пробелам.

SwiftRide quick-reference table

Заметьте — payout status enum оказался CDE + Reference Data. Статус фидит payment workflows; misclassification (например, paid возвращён для failed record) приводит к incorrect commission accruals. Это Reference Data, но небольшой и критичный, контролируется максимально строго.

Анти-паттерны в multi-classification

1. Single-axis thinking. «Это CDE» — без проверки PII / Master Data / Confidential осей. Итоговый набор controls неполный.

2. Несовпадение владельцев. PII owner — DPO. CDE owner — VP Finance. Master Data owner — MDM-команда. Если три разных владельца для одного датасета, требуется разрешение конфликта. Обычно CDE Data Owner — primary; DPO + MDM дают специализированный co-sign.

3. Confidential как default. Over-classification (всё Confidential) приводит к: (a) стоимости (encryption / access controls дорогие), (b) потере продуктивности (overhead на запрос approval), (c) classification fatigue (люди перестают уважать tiers). Используйте наименьший подходящий tier.

4. Reference Data игнорируется как CDE. Маленькие датасеты часто быстро признаются «не критичными». Но провалы CDE в Reference Data (например, неверный tax jurisdiction code) часто имеют outsized impact. Проверяйте reference data явно.

5. Master Data assumed CDE. Некоторые команды по умолчанию считают «все master data — CDE». Неверно — Customer Master Data может быть not-CDE (если только marketing-use). Score по фреймворку.

Итоги

• 5 категорий — CDE (criticality), PII (privacy regulation), Master Data (описание сущностей), Reference Data (controlled vocabularies), Confidential / Restricted (security classification).
• Каждая категория — отдельное определение, регуляторный драйвер, lifecycle, владелец, набор controls. Не взаимозаменяемы.
• Категории ортогональны — multi-classification нормально. KYC profile = CDE + PII Art. 9 + Confidential; driver earnings = CDE + PII + Restricted; country codes ISO = CDE + Reference Data + Public.
• Controls — объединение из применимых категорий. Single-axis мышление → пробелы в controls.
• Конфликты владельцев при multi-classification: CDE owner — primary, DPO + MDM — специализированный co-sign.
• Reference Data может быть CDE (country codes для tax). Не пропускайте.
• Master Data не автоматически CDE. Score по фреймворку.
• Quick-reference таблица SwiftRide — 12 примеров по категориям для немедленного reference.
• Дальше: урок 6 — CDE lifecycle: nomination, review, approval, maintenance, retirement, и какая роль владеет какой стадией.