Дякую Тарасу за професійну та результативну допомогу у розблокуванні банківського рахунку в ЄС. Ситуація була непростою та вимагала чіткого розуміння європейських банківських процедур, однак юрист грамотно вибудував стратегію, підготував необхідні звернення та довів справу до успішного результату. Рекомендую)
Юрист
Експерт у сфері міжнародного корпоративного, ІТ та крипто-права. Має багаторічний досвід у відкритті та супроводі бізнесу в США, країнах ЄС, ЛатАм та на Близькому Сході. Спеціалізується на корпоративному структуруванні, комплаєнсі, KYC/AML, IP, GDPR та регуляції крипто і fintech проєктів.
Data Processing Agreement (DPA) для GDPR
DPA (Data Processing Agreement) — не “юридичний аксесуар” до договору з підрядником. Це документ, який робить обробку персональних даних керованою: хто кому що доручив, які дані обробляються, як вони захищаються, кому передаються, як повертаються/видаляються і хто відповідає, якщо щось пішло не так.
GDPR вимагає, щоб між controller і processor був договір (або інший юридичний акт) із чітко визначеними умовами обробки та контролем ланцюга субпідрядників. Це не “добра практика”, це базова гігієна комплаєнсу.
DPA простими словами: хто з ким і про що?
У GDPR дві ключові ролі:
- Controller (володілець/той, хто визначає цілі та засоби) — вирішує “навіщо” і “як” обробляються дані.
- Processor (обробник) — обробляє дані від імені controller і лише за документованими інструкціями .
DPA потрібен тоді, коли Ви як controller залучаєте підрядника, який має доступ до персональних даних: CRM, кол-центр, email-маркетинг, бухгалтерія, HR-сервіси, хостинг, аналітика, служба підтримки, dev-команда тощо.

Коли DPA потрібен майже завжди (і коли — ні)?
DPA майже точно потрібен, якщо:
- підрядник має доступ до Вашої клієнтської/користувацької бази;
- підрядник хостить сервіси/бекенд/логи;
- підрядник робить підтримку й бачить профілі/історію звернень;
- підрядник робить розсилки/таргетинг/аналітику поведінки;
- підрядник обробляє дані співробітників (HR, payroll, рекрутинг).
DPA може не бути потрібен, якщо:
- підрядник є окремим controller, бо сам визначає цілі/засоби обробки;
- у Вас модель controller-to-controller (там інша логіка зобов’язань і відповідальності).
Найчастіша проблема — неправильна кваліфікація ролей. Один абзац “processor/controller” у договорі не лікує фактичну реальність.
Обов’язкові умови DPA: що має бути всередині (чекліст)?
Мінімальний “must-have” набір (по суті вимог ст. 28 GDPR):
- Предмет і межі обробки: що обробляється, для яких сервісів, у яких системах.
- Строк, характер і цілі обробки.
- Категорії даних і категорії суб’єктів.
- Документовані інструкції controller (як видаються, хто затверджує).
- Технічні й організаційні заходи безпеки (TOMs) (логіка ст. 32 GDPR).
- Субпроцесори: порядок залучення, реєстр, повідомлення про зміни, механізм заперечень, “flow-down” зобов’язань.
- Допомога controller: запити суб’єктів (DSR), DPIA, взаємодія з регулятором, інциденти/витоки.
- Повернення/видалення даних після завершення послуг (включно з політикою щодо бекапів).
- Аудит/інспекції та надання інформації для демонстрації комплаєнсу.
- Конфіденційність персоналу processor (NDA, доступ за ролями, навчання).
Таблиця-шпаргалка: структура DPA “без істерики”
| Блок DPA | Що фіксуємо? | Навіщо це Вам? |
| Опис processing | предмет/цілі/тривалість/системи | прибирає “розмитість” і спір про межі |
| Дані та суб’єкти | типи даних, категорії осіб | правильні TOMs, DPIA, трансфери |
| Інструкції | як видаються, хто затверджує, SLA | доказ “documented instructions” |
| Безпека (TOMs) | шифрування, доступ, логування, резерви, SDLC | зменшує ризик інцидентів і претензій |
| Субпроцесори | список + оновлення + право заперечити | контроль ланцюга постачання |
| DSR/брічи/DPIA | строки, канали, відповідальні | щоб Ви не “горіли” у дедлайнах регулятора |
| Аудит | формат (SOC2/ISO/онлайн), частота, NDA | баланс контролю й реалістичності |
| Termination | delete/return, бекапи, підтвердження | “чистий вихід” без хвостів |
Субпроцесори: де компанії найчастіше програють?
Майже кожен processor має ланцюг субпроцесорів (хмари, логування, саппорт, аналітика). Практичний мінімум, який має бути в DPA:
- Реєстр субпроцесорів (Subprocessor List);
- Процедура повідомлення про зміни (Change Notice);
- Механізм заперечення (Objection workflow) і що робимо далі;
- Flow-down: ті самі вимоги безпеки/конфіденційності “вниз по ланцюгу”.
Коротко: не контролюєте субпроцесорів — не контролюєте ризик.
А якщо є міжнародні передачі? (SCC і “одна архітектура”)
Якщо дані виходять за межі ЄЕЗ/UK (або в ланцюгу є non-EEA), одного DPA може бути недостатньо — потрібен механізм трансферу (часто SCC) та узгоджений набір додатків/заходів.
Здоровий підхід: не плодити документи “для галочки”, а зібрати одну логічну конструкцію: основний договір + DPA/Annex + трансферні умови (за потреби).
Типові помилки (і чому вони дорожчі за юриста)
- “Універсальний DPA на 2 сторінки” без опису реальної обробки.
- TOMs як маркетинг (“ми дуже безпечні”), без конкретики.
- Немає механіки субпроцесорів і повідомлень про зміни.
- Аудит: або “заборонено”, або “приходьте щотижня” (обидва варіанти погані).
- Termination без delete/return і без логіки по бекапах.
- Немає SLA по DSR/інцидентах — і потім винні Ви, бо строки Ваші.
Як ми зазвичай робимо DPA “під ключ” (процес)?
- Кваліфікуємо ролі: controller/processor/joint controllers.
- Описуємо processing (Annex): системи, потоки, категорії даних, доступи.
- Фіксуємо TOMs під сервіс і ризик-профіль, а не “копіпаст”.
- Субпроцесори: реєстр + governance + flow-down.
- Трансфери: SCC/додаткові заходи — якщо потрібно.
- Переговори з вендором: приводимо DPA до реалістичного, але захисного стандарту.
5 питань “так/ні” для самоперевірки
- У договорі з підрядником описані предмет/цілі/строк обробки та типи даних?
- Є TOMs/Annex, який відповідає Вашому сервісу, а не шаблону?
- Є реєстр субпроцесорів і процедура повідомлення/заперечень?
- Прописані строки й порядок щодо DSR/інцидентів/DPIA?
- Є “exit plan”: delete/return + бекапи + підтвердження?
Якщо хоча б на два питання відповідь “ні” — Ваш DPA, ймовірно, декоративний.
Що ми можемо зробити для клієнта (коротко, по суті)?
- Підготовка DPA (ст. 28) з додатками під конкретний сервіс.
- Редлайн DPA вендора + матриця ризиків (що критично, що торгується).
- Governance субпроцесорів і трансферна частина (якщо є non-EEA).
- Пакет для due diligence: опис TOMs, відповіді партнерам/клієнтам, аудит-логіка.
DPA — як парасоля: коли вона у Вас є, дощ здається дрібницею; коли її нема — раптом з’являється регулятор і з’ясовується, що промокли Ви, а винен чомусь підрядник.
Розрахуйте вартість послуг
1 питання
Вам потрібна консультація по GDPR?
2 питання
Вас цікавить розробка для компанії Data Processing Agreement?
3 питання
Вам потрібен повний фінтех-комплаєнс для вашого бізнесу?
Вам також може знадобитися:
передзвонимо
протягом дня
