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

