Принцип Privacy by Design

1) Що таке Privacy by Design і навіщо він потрібен

Privacy by Design (PbD) - підхід, при якому приватність користувачів закладається в продукт з самого початку: в архітектуру даних, процеси і дизайн інтерфейсів. Мета - дотримання права на приватне життя без шкоди для швидкості продукту, комплаєнсу та конверсії.

Ключові вигоди: стійкість до регуляторних ризиків, довіра користувачів/платіжних партнерів, передбачувані витрати на зміни, менше «переробок» після аудитів.

2) Сім принципів PbD (адаптація для продукту)

1. Проактивність, а не реактивність: виявляйте ризики при дизайні (DPIA/загрозмоделювання).
2. Типова приватність: мінімальні збори, «відключено, поки не потрібно», явний opt-in.
3. Приватність вбудована в дизайн: шифрування, токенізація, сегрегація даних - частина архітектури, а не «плагін».
4. Повна функціональність: баланс «приватність ↔ бізнес-цінність» (не нульова сума).
5. Безпека від початку до кінця: захист на всіх етапах життєвого циклу ПД.
6. Прозорість: зрозумілі політики, логи доступів, зрозумілість автоматизованих рішень.
7. Повага до користувача: ясна мова, зрозумілі налаштування, легкий відгук згоди.

3) Життєвий цикл даних і точки контролю

Збір → Зберігання → Використання → Передача → Архівація → Видалення/анонімізація

• Мета і основа обробки (contract/legal interest/consent і т.п.).
• Мінімальні поля (data minimization).
• Зону зберігання (PII/псевдонім/анонім).
• Терміни (Retention Matrix).
• Контролі доступу і спостережуваність (RBAC/ABAC, логи, алерти).
• Процедуру видалення/DSR (доступ/виправлення/видалення/переносимість).

4) Архітектурні патерни PbD

4. 1 Сегрегація зон даних

Zone A (PII/чутливі): суворе RBAC/ABAC, шифрування at-rest, доступ по JIT.
Zone B (псевдоніми): стабільні токени замість ідентифікаторів.
Zone C (анонімні агрегати): BI/дослідження, дифприватність при публікаціях.

4. 2 Мінімізація та псевдонімізація

Збирати тільки потрібні поля; видаляти/маскувати після використання.
Зберігати шаблони біометрії замість raw-зображень; токенізувати платіжні дані.

4. 3 «Privacy-aware» інтеграції

Server-side analytics і постбеки замість «жирних» браузерних SDK.
Prior-blocking тегів/SDK до згоди (CMP + Tag Manager).
Data contracts між сервісами: явні схеми, версії, поліцифікація полів.

4. 4 Контроль доступу і спостережуваність

SSO, MFA, JIT-доступ, секрет-менеджмент.
Логи читань/вивантажень в WORM-сховище, аномалія-детект скачувань.

5) PbD в SDLC (наскрізна інтеграція)

Discovery: privacy-triage (чи є ПД/діти/біометрія/профілювання/передачі за кордон).
Design: DPIA/DTIA, data mapping, вибір зон і мінімальних полів, схеми consent.
Build: лінтери схем, тести маскування, гейти на експорт ПД, фіксація версій політик.
Launch: чек-лист PbD, sign-off DPO/безпеки, включені журнали згоди/логів.
Run: метрики, рев'ю доступів, аудити вендорів, ретейнер інцидентів, регулярні re-consent.

6) UX-патерни «privacy by default»

Рівна помітність «Прийняти все/Відхилити все/Налаштувати».
Покрокові пояснення, навіщо окремі категорії даних.
Центр переваг: швидкий відгук згоди, статус GPC (якщо застосовується).
«Листкова» політика: коротко + подробиці; зрозумілі reason codes при автоматизованих рішеннях.
Доступність: проста мова, локалі, без «темних патернів».

7) Вендори і контракти

DPA з обмеженням цілей, каскадною підтримкою DSR і повідомленнями про інциденти.
Географія обробки і механізми транскордонних передач.
Періодичний аудит SDK/пікселів, режими restricted processing.

8) Метрики PbD (міряємо, не віримо на слово)

RoPA Completeness: повнота реєстру обробок.
Data Minimization Index: середнє число ПД на фічу/подія.
Encryption Coverage: % таблиць/бакетів/бекапів у шифруванні.
Access/Export Violations: несанкціоновані читання/вивантаження.
DSR SLA: частка запитів закрита вчасно.
Consent/GPC Honor Rate: коректність обліку згоди/сигналів.
Retention Adherence: % записів, видалених за графіком.
Incident MTTD/MTTR: час виявлення/усунення.

9) Ролі та відповідальність (RACI)

Product Owner: цілі, мінімальні поля, RoPA-введення.
DPO/Privacy: методологія, DPIA/DTIA, sign-off, навчання.
Security/CISO: техконтролі, IR-план, аудит доступів/вивантажень.
Data/Engineering: схеми, data contracts, фіче-стор з псевдонімами.
Legal/Compliance: підстави, договори, транскордонні передачі.
Support/Operations: DSR-потоки, журнали згоди, комунікації.

10) Чек-листи (готові до використання)

Перед стартом фічі

• Описана мета і основа обробки.
• Визначені мінімальні поля і зона зберігання (A/B/C).
• Виконаний DPIA/DTIA (якщо тригери).
• Налаштований CMP/consent і prior-blocking.
• Внесено в RoPA; ретеншн і видалення прописані.

Перед релізом

• Шифрування at-rest/in-transit; ключі в KMS/HSM.
• RBAC/ABAC і JIT-доступи, аудит включений.
• Серверна аналітика, маскування ідентифікаторів.
• Тести DSR/експорту, шаблони комунікацій готові.

Щоквартально

• Рев'ю доступів, відгук зайвих.
• Аудит вендорів/SDK, список і цілі актуальні.
• Перевірка Retention Adherence і фактичних видалень.
• Навчальні тривоги IR-плану (table-top).

11) Часті помилки і як їх уникнути

Приватність «як надбудова» після релізу → вбудовуйте в дизайн (SDLC-гейти).
Збір «про всяк випадок» → фіксуйте мінімальний набір полів.
Змішування маркетингу та безпеки → розділяйте підстави (consent vs LIA/legal).
Dev/stage з прод-ПД → використовуйте синтетику/маскування.
Немає журналів згоди/логів → нічим доводити відповідність.
Відсутність explainability → складні апеляції з профілювання.

12) Плейбук інцидентів (privacy-focused)

1. Класифікувати інцидент: масштаб, категорії ПД, ризик суб'єктам.
2. Ізоляція/форензика, усунення, закриття дірок.
3. Рішення про повідомлення (нагляд/суб'єкти), шаблони листів.
4. Пост-морем: причини, що змінили в архітектурі/процесах.
5. Оновити DPIA/політики, навчити команди.

13) Шаблони артефактів для вашої wiki

Privacy-by-Design Checklist. md (для SDLC-гейтів).
Data Map (діаграма зон і потоків).
Retention Matrix (категорія → термін → метод видалення).
DSR SOP (процедури, SLA, шаблони відповідей).
Vendor DPA Checklist (обмеження, субпроцесори, гео).
Explainability Playbook (reason codes, апеляції, bias-аудити).
Incident Response (Privacy) Runbook.

14) Дорожня карта впровадження (6 кроків)

1. Інвентаризація даних і потоків; базовий RoPA, зони A/B/C.
2. Шаблони та гейти: PbD-чек-лист, DPIA/DTIA-тріаж в SDLC.
3. Архітектура: шифрування, псевдонімізація, server-side analytics, prior-blocking.
4. Процеси: CMP, DSR, ретеншн/видалення, журнали згоди та доступу.
5. Вендори: DPA, реєстр субпроцесорів, аудит SDK/пікселів.
6. Моніторинг: метрики PbD, квартальні аудити, тренування IR, звіт Board.

Підсумок

Privacy by Design - це не «політика на сайті», а інженерно-організаційна дисципліна: мінімізація даних, сегрегація зон, шифрування і журнали + зрозумілі інтерфейси згоди і регулярні аудити. Вбудувавши PbD в SDLC і операції, ви знизите юридичні ризики, спростіть інтеграції з партнерами і зміцніть довіру користувачів - без втрати швидкості продукту і якості UX.