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

Юрист

E-mail

vinnik@prikhodko.com.ua

Номера телефонов

Эксперт в сфере международного корпоративного, IT и крипто-права. Имеет многолетний опыт в открытии и сопровождении бизнеса в США, странах ЕС, ЛатАм и на Ближнем Востоке. Специализируется на корпоративном структурировании, комплаенсе, KYC/AML, IP, GDPR, а также регулировании crypto и 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, бекапы, подтверждение	“чистый выход” без хвостов

Субпроцессоры: где компании чаще всего проиграют?

Практически каждый процессор имеет цепь субпроцессоров (облака, логирование, саппорт, аналитика). Практический минимум, который должен быть в DPA:

Реестр субпроцессоров (Subprocessor List);
Процедура сообщения об изменениях (Change Notice);
Механизм отрицания (Objection workflow) и делаем дальше;
Flow-down: те же требования безопасности/конфиденциальности «вниз по цепи».

Коротко: не контролируете субпроцессоры — не контролируете риск.

А если есть международные передачи? (SCC и «одна архитектура»)

Если данные выходят за пределы ЕЭС/UK (или в цепи не 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 вопрос

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

Да