Prikhodko&Partners
Послуги
ФінТех
Комплаєнс Data Processing Agreement (DPA) для GDPR

Юрист

E-mail

vinnik@prikhodko.com.ua

Номери телефонів

Експерт у сфері міжнародного корпоративного, ІТ та крипто-права. Має багаторічний досвід у відкритті та супроводі бізнесу в США, країнах ЄС, ЛатАм та на Близькому Сході. Спеціалізується на корпоративному структуруванні, комплаєнсі, 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 питання

Вам потрібен повний фінтех-комплаєнс для вашого бізнесу?

Так