Експорт даних за GDPR (ст. 15/20)

Коротко: Право отримати в структурованому вигляді всі персональні дані, які компанія зберігає про вас, — право доступу (ст. 15 GDPR) і право на переносимість даних (ст. 20 GDPR).

Докладніше: На практиці зазвичай реалізується як кнопка «експортувати дані» у власному акаунті, яка збирає на сервері всі записи, пов’язані з увійшовшим користувачем, і пропонує їх для завантаження, наприклад у вигляді файлу JSON. Важливе усвідомлене рішення про те, ЩО входить в експорт: суто технічні/пов’язані з безпекою поля (хеш пароля, push-підписка) і персональні дані ТРЕТІХ осіб (наприклад, хто ще брав участь у спільному зверненні до підтримки) сюди не належать.

Наш контекст: В Emzett app/utils/gdprExport.ts (exportUserData) збирає для увійшовшого користувача дані акаунта, замовлення, історію балів, звернення до підтримки, повідомлення чату тощо — навмисно БЕЗ passwordHash і pushSubscription. Проходить через загальну перевірку ліміту запитів, бо повний експорт даних — порівняно дорога операція.

Подробиці

Ст. 15 GDPR (право доступу) і ст. 20 GDPR (право на переносимість даних) на практиці часто реалізуються разом як «експорт даних», але юридично різняться за обсягом: ст. 15 зобов’язує надати інформацію про всі оброблювані персональні дані, зокрема цілі обробки, одержувачів і строк зберігання — незалежно від того, як дані зібрано. Ст. 20 вужча: вона застосовується лише до даних, які суб’єкт даних сам надав компанії (наприклад, дані профілю, завантажений контент) і обробка яких ґрунтується на згоді чи договорі — але не до даних, які компанія сама отримала чи обчислила (наприклад, внутрішньо розрахований показник цінності клієнта).

Поширена правова вимога — строк відповіді: на запит доступу потрібно відповісти «без невиправданої затримки й у будь-якому разі протягом одного місяця» (ст. 12(3) GDPR), з можливістю продовжити його ще на два місяці для складних запитів. Автоматичний самообслуговуваний експорт в області акаунта від самого початку вкладається в цей строк, бо користувачі можуть отримати дані одразу самі, замість того щоб подавати ручний запит і чекати обробки, — що водночас значно знижує навантаження на підтримку в компанії.

Технічно особливо складна робота з пов’язаними даними, що зачіпають інших людей. Історія чату чи спільне звернення до підтримки зазвичай містить повідомлення кількох учасників — наївний експорт «усіх записів з моїм ID користувача» мимоволі розкрив би й персональні дані третіх осіб, що саме по собі може бути порушенням GDPR. Поширені підходи — експортувати в гілці лише власні повідомлення, анонімізувати внесок інших (наприклад, «Інший користувач» замість справжнього імені) або включати цілі гілки лише якщо запитувач — єдиний чи основний відповідальний учасник.

// Спрощений шаблон експорту даних за GDPR
async function exportUserData(userId: string) {
  const [account, orders, tickets] = await Promise.all([
    db.query.users.findFirst({ where: eq(users.id, userId) }),
    db.query.orders.findMany({ where: eq(orders.userId, userId) }),
    db.query.tickets.findMany({ where: eq(tickets.userId, userId) }),
  ]);
  // Навмисно виключаємо поля, пов’язані з безпекою
  const { passwordHash, pushSubscription, ...safeAccount } = account;
  return { account: safeAccount, orders, tickets };
}

Див. також: Правило малого підприємства (§ 19 UStG), Право відмови за цифрового контенту (§ 356(5) BGB), Видалення акаунта з періодом заперечення (м’яке видалення + анонімізація), GDPR, Журнал аудиту