Юрист
Експерт у сфері міжнародного корпоративного, ІТ та крипто-права. Має багаторічний досвід у відкритті та супроводі бізнесу в США, країнах ЄС, ЛатАм та на Близькому Сході. Спеціалізується на корпоративному структуруванні, комплаєнсі, 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 питання
Вам потрібен повний фінтех-комплаєнс для вашого бізнесу?
Вам також може знадобитися:
передзвонимо
протягом дня
Відшкодування моральної, матеріальної шкоди
Захист честі, гідності та ділової репутаціїВедення бухгалтерського обліку
Відшкодування моральної, матеріальної шкоди
Ліцензування господарської діяльності
Розробка договорів для бізнесу та юридичних осіб
Гранти та залучення інвестицій
Захист честі, гідності та ділової репутації
Юридичні послуги для медичного бізнесу та лікарів
Реєстрація і супровід бізнесу в ЄС
Реєстрація і супровід бізнесу в країнах Перської затоки (GCC)
Реєстрація і супровід бізнесу в США
Реєстрація і супровід бізнесу в Туреччині
Реєстрація і супровід бізнесу в Швейцарії
Реєстрація і супровід бізнесу у Великій Британії
Адвокат по адміністративних справах
Адвокат по господарським справам
Адвокат по кримінальних справах
Судовий адвокат: супровід та захист у суді
Європейський суд з прав людини (ЄСПЛ)
Продаж та купівля готових фірм
РЕЄСТРАЦІЯ КОМПАНІЙ ТА ВІДКРИТТЯ БАНКІВСЬКИХ РАХУНКІВ
Юридичні послуги у сфері криптовалют і блокчейн

