Governance данных третьих сторон
Введение
Сценарий: BioGenesis Lab (БиоГенезис Лаб)
BioGenesis получает данные из 8 внешних источников: лабораторные результаты от 5 вендоров (еженедельные CSV-файлы), данные клинических исследований от 3 CRO-партнёров (Contract Research Organizations), погодные данные для экологических исследований через API. Ни один из 8 источников не имеет governance-соглашения. Результат: 12% записей от Lab Vendor #3 содержат null patient_id, 8% записей от CRO #2 имеют invalid date formats. Эти данные загружаются в PostgreSQL без валидации и попадают в клинические анализы.
В терминах lifecycle management (урок 06): данные от третьих сторон входят в организацию на стадии Create. Если governance не применяется при ingestion, некачественные внешние данные загрязняют всю downstream-цепочку.
Предыдущий урок показал, как governance управляет внутренним жизненным циклом данных. Но современные организации зависят от внешних данных: вендорские поставки, партнёрские обмены, API-интеграции, данные с маркетплейсов. Третьи стороны — это расширение вашего data estate за пределы контролируемой инфраструктуры. Governance данных третьих сторон определяет, как управлять качеством, безопасностью и compliance данных, которые вы не создаёте.
Vendor Data Governance
Vendor Risk Assessment Framework
Прежде чем принять данные от вендора, организация должна оценить риски. Vendor risk assessment включает 5 категорий:
| Категория риска | Что оценивается | Пример вопроса |
|---|---|---|
| Data Quality | Способность вендора обеспечить качество | Какой SLA на accuracy, completeness, timeliness? |
| Security | Защита данных при передаче и хранении | Поддерживает ли вендор encryption in transit? |
| Compliance | Соответствие регуляциям | Сертифицирован ли вендор по ISO 27001? |
| Business Continuity | Устойчивость вендора | Что произойдёт, если вендор прекратит работу? |
| Data Sovereignty | Юрисдикция хранения данных вендора | В какой стране хранятся данные? |
- 01Data Quality SLA определёнAccuracy >= 99%, Completeness >= 98%, Timeliness <= 24h delivery. Penalty clauses за нарушение.~Частично
- 02Audit rights включены в контрактПраво на аудит качества данных вендора 1 раз в год. Доступ к исходным системам для верификации.~Частично
- 03Exit strategy определенаФормат экспорта данных при смене вендора. Transition period >= 90 дней. Полное удаление данных организации из систем вендора.~Частично
- 04Incident notification: < 48 часовВендор уведомляет о data quality incidents, breaches, system outages в течение 48 часов.✓Соответствует
- 05Data lineage предоставляетсяВендор документирует: источник данных, transformations, validation rules, delivery format.~Частично
- 06Backup и disaster recoveryВендор обеспечивает RPO < 24h, RTO < 48h для критичных data feeds.~Частично
Для сравнения: FinSecure Bank (ФинСекьюр Банк)
FinSecure получает данные кредитного скоринга от внешнего бюро. SLA: accuracy >= 99.5%, delivery <= 6 часов после запроса, completeness 100% для обязательных полей. Penalty: если accuracy < 99.5% три месяца подряд — расторжение контракта. Audit right: FinSecure проверяет scoring модель вендора ежегодно. Exit strategy: данные в стандартном MISMO формате, transition period 180 дней.
Data Sharing Agreements
Data Sharing Agreement (DSA, соглашение об обмене данными) — юридический документ, определяющий правила обмена данными между организациями. DSA значительно шире, чем NDA (Non-Disclosure Agreement).
Ключевые элементы DSA
| Элемент | Описание | Почему критичен |
|---|---|---|
| Purpose limitation | Конкретная цель использования | Предотвращает re-purposing данных |
| Data minimization | Передача только необходимых полей | Снижает exposure при breach |
| Retention period | Срок хранения у получателя | Данные не хранятся бесконечно |
| Security standards | Минимальные требования безопасности | Защита за пределами вашей инфраструктуры |
| Breach notification | Сроки и процедура уведомления | Время реагирования при инциденте |
| Audit rights | Право проверки получателя | Верификация соблюдения DSA |
| Termination & deletion | Процедура при расторжении | Данные не остаются у партнёра навсегда |
External API Governance
Современные организации интегрируют десятки внешних API. Governance API-зависимостей критичен для stability и compliance.
API Governance Framework
| Аспект | Governance-требование | Действие при нарушении |
|---|---|---|
| Schema validation | Проверка формата каждого response | Quarantine + alert |
| Rate limit monitoring | Отслеживание приближения к лимитам | Throttle + optimize |
| Version deprecation | Мониторинг deprecation notices | Migration plan за 60+ дней |
| Fallback strategy | Альтернативный источник данных | Switch to fallback + alert |
| Data quality at ingestion | Quality checks на каждый batch/response | Reject + retry / quarantine |
Сценарий: DataTech
DataTech интегрирует API маркетплейса для обогащения каталога товаров. API возвращает descriptions, categories, images. Без governance: API внезапно меняет формат response (v2 -> v3), 2,000 товаров получают broken categories. Время обнаружения: 3 дня (business user заметил). С governance: validation gate обнаруживает schema change в момент ingestion, quarantines 100% записей, alert Data Engineer — fix за 2 часа.
Data Marketplace Governance
Рынок данных (Data Marketplace) — растущая реальность. Организации покупают данные (weather, demographics, industry benchmarks) и всё чаще создают internal data marketplaces для контролируемого обмена данными между подразделениями.
Internal Data Marketplace
| Аспект | Governance-правило |
|---|---|
| Data Product Certification | Датасет проходит quality review перед публикацией |
| Usage Tracking | Кто скачал, для какой цели, когда |
| Access Control | RBAC на уровне data product |
| Freshness SLA | Гарантия актуальности для каждого data product |
| Feedback Loop | Потребители оценивают качество data product |
External Data Marketplace
При покупке данных на внешнем marketplace governance включает:
- Due diligence: Откуда данные? Как собраны? Есть ли consent субъектов?
- License compliance: Разрешено ли использование для вашей цели?
- Quality assessment: Провести quality check до покупки (sample data)
- Monetization governance: Если вы продаёте данные — classification, consent, de-identification обязательны
Third-Party Risk Assessment
Due Diligence Framework
Risk assessment третьих сторон — это не one-time event, а continuous process:
| Фаза | Действия | Частота |
|---|---|---|
| Pre-engagement | Vendor questionnaire, security assessment, reference checks | До подписания контракта |
| Onboarding | DSA подписание, quality baseline, access provisioning | При запуске |
| Ongoing monitoring | Quality metrics review, compliance verification, incident tracking | Ежеквартально |
| Annual review | Full risk re-assessment, SLA performance review, audit | Ежегодно |
| Offboarding | Data deletion verification, access revocation, destruction certificate | При завершении |
Incident Response для третьих сторон
Когда вендор допускает data quality failure или breach, governance определяет response:
- Detect: Мониторинг quality metrics на ingestion обнаруживает аномалию
- Assess: Масштаб воздействия — какие downstream-системы затронуты?
- Contain: Quarantine вендорного data feed
- Notify: Уведомить affected teams + регуляторов (если PII)
- Remediate: Потребовать root cause analysis от вендора
- Review: Обновить SLA и quality gates
Итоги
- Vendor risk assessment — 5 категорий (quality, security, compliance, business continuity, data sovereignty) оцениваются до подписания контракта
- Data Sharing Agreement (DSA) — значительно шире NDA: purpose limitation, retention, security, breach notification, audit rights, termination
- API governance — validation gates на ingestion, schema checks, fallback strategies, version monitoring
- Data marketplace — certification, usage tracking, quality SLA для internal и due diligence для external
- Continuous risk assessment — pre-engagement, onboarding, ongoing monitoring, annual review, offboarding
- Incident response — даже при breach у вендора, ответственность перед клиентами остаётся у вашей организации
Вы научились управлять внутренним жизненным циклом данных и внешними источниками. Теперь ключевой вопрос: как коммуницировать результаты governance руководству, которое мыслит бизнес-результатами, а не governance-процессами? В следующем уроке мы изучим язык governance-отчётности для C-level executives.