DPA Agreement: когда IT-компании нужен договор об обработке персональных данных

Компания продает SaaS-сервис клиенту из ЕС. Клиент загружает в систему сведения о сотрудниках или покупателях, поставщик хранит их, создает резервные копии и предоставляет доступ службе поддержки. При согласовании договора клиент просит подписать Data Processing Agreement, или DPA.

Такой документ часто воспринимают как формальное приложение из стандартного пакета GDPR. Однако DPA определяет юридическую модель работы с данными: кто устанавливает цели обработки, кто выполняет инструкции, какие подрядчики получают доступ к информации и как стороны действуют при утечке.

Если положения соглашения расходятся с архитектурой продукта, DPA не поможет пройти аудит клиента. Более того, компания может принять обязательства, которые ее техническая команда не способна выполнить.

Выражение DPA Agreement часто встречается в поисковых запросах, хотя слово Agreement уже входит в аббревиатуру DPA. Корректное полное название документа: Data Processing Agreement, соглашение об обработке персональных данных.

Когда заключение DPA обязательно

DPA требуется, если одна компания обрабатывает персональные данные от имени другой. Это правило установлено статьей 28 GDPR и применяется к отношениям между контролером и обработчиком.

Контролер решает, зачем использовать персональные данные и какие основные правила обработки будут действовать. Обработчик выполняет операции по его поручению и следует документированным инструкциям.

Например, клиент использует CRM для работы с собственной базой покупателей. Он определяет состав сведений, цели их использования и сроки хранения. Поставщик CRM предоставляет техническую среду, хранит информацию и поддерживает работу системы. В этой операции клиент является контролером, а поставщик CRM выступает обработчиком.

IT-компании обычно нужен DPA в следующих случаях:

• SaaS-сервис хранит или анализирует сведения, которые загрузил клиент
• разработчик получает доступ к производственной базе, логам или резервным копиям заказчика
• служба поддержки видит обращения пользователей и данные их учетных записей
• облачный провайдер размещает базы данных или файловые хранилища
• сервис рассылок обрабатывает email-адреса и историю коммуникации
• система мониторинга получает IP-адреса, идентификаторы устройств и журналы событий

Для применения статьи 28 не требуется, чтобы подрядчик регулярно просматривал данные. Доступ может использоваться только при технической поддержке или расследовании инцидента. Если такой доступ входит в функции подрядчика и касается персональных данных, отношения сторон следует проверить на соответствие модели контролер-обработчик.

DPA можно оформить отдельным соглашением или приложением к MSA, SaaS Agreement либо договору разработки. Название и место документа не имеют решающего значения. Условия должны быть обязательными для сторон и соответствовать статье 28 GDPR.

Когда DPA не подходит

Получение персональных данных само по себе не делает компанию обработчиком. Роль зависит от того, кто принимает решения о целях и существенных способах использования информации.

Банк, платежная организация или профессиональный консультант могут обрабатывать полученные сведения для выполнения собственных обязанностей. В такой части они действуют как самостоятельные контролеры, поэтому соглашение по статье 28 к этим операциям не подходит.

Если две компании совместно определяют цели и способы обработки, между ними могут возникнуть отношения совместных контролеров. Их обязанности распределяются по статье 26 GDPR.

Один поставщик иногда совмещает несколько ролей. SaaS-платформа обрабатывает клиентскую базу по поручению заказчика, а часть технических сведений самостоятельно использует для защиты сервиса, предотвращения мошенничества или исполнения закона. Каждую операцию нужно оценивать отдельно. Формулировка в договоре не изменит фактический статус компании, если продукт работает иначе.

Что должно быть указано в DPA

Статья 28 GDPR устанавливает обязательное содержание соглашения. Короткая оговорка о конфиденциальности или соблюдении законодательства ее не заменяет.

В DPA необходимо определить:

1. предмет и продолжительность обработки
2. характер и цели операций с данными
3. виды персональных данных и категории субъектов
4. права и обязанности контролера
5. порядок выполнения документированных инструкций
6. требования к конфиденциальности и безопасности
7. правила привлечения субобработчиков
8. порядок удаления или возврата данных
9. помощь при запросах пользователей, DPIA и инцидентах
10. предоставление информации и проведение аудитов

Описание должно позволять установить, какие сведения получает обработчик и что он вправе с ними делать. Формулировки вроде всех данных, необходимых для оказания услуг, создают слишком широкие границы.

Для SaaS-продукта можно отдельно указать регистрационные сведения, контактные данные, содержание обращений, историю действий и технические идентификаторы. Конкретный перечень зависит от функций продукта и данных, которые клиент фактически загружает в систему.

После завершения услуг информация возвращается контролеру или удаляется по его выбору, если закон не требует дальнейшего хранения. Срок удаления нужно согласовать с политикой резервного копирования. Обещание сразу удалить все копии часто невозможно выполнить, поскольку резервные данные сохраняются до окончания установленного цикла перезаписи.

Почему раздел о безопасности нужно согласовать с технической командой

Общее обещание применять соответствующие технические и организационные меры не дает клиенту понятного представления о защите данных. В DPA или отдельном приложении следует описать управление доступом, шифрование, резервное копирование, журналирование действий и порядок реагирования на инциденты.

Содержание раздела зависит от риска обработки. Поставщик медицинской платформы работает с более чувствительной информацией, чем сервис для отправки корпоративных приглашений. Одинаковый шаблон мер безопасности для таких продуктов будет либо недостаточным, либо заведомо неисполнимым.

Техническая команда должна проверить условия до подписания. В договоре могут появиться обязательства по круглосуточному мониторингу, конкретным стандартам шифрования или срокам восстановления, которым продукт пока не соответствует. После подписания расхождение обнаружится при аудите клиента или во время инцидента.

Право контролера на аудит также следует описать заранее. В соглашении можно установить срок уведомления, правила конфиденциальности, допустимые способы проверки и распределение расходов. Полный запрет на аудит противоречит статье 28, а неограниченный доступ клиента к инфраструктуре может создать угрозу для других заказчиков.

Как оформить привлечение субобработчиков

SaaS-поставщик редко выполняет все операции самостоятельно. В обработке могут участвовать хостинг, облачная платформа, система рассылок, сервис мониторинга и внешняя поддержка. Если такой подрядчик получает персональные данные в рамках услуг для контролера, он становится субобработчиком.

Для его привлечения требуется предварительное специальное или общее письменное разрешение контролера. При общем разрешении поставщик сообщает клиенту о добавлении или замене субобработчика и предоставляет время для возражений.

В DPA следует определить, где размещен актуальный список субобработчиков, каким способом направляются уведомления и сколько времени дается клиенту для ответа. Ссылка на страницу сайта не решает вопрос, если поставщик может изменить перечень без уведомления.

Субобработчик принимает сопоставимые обязанности по защите данных. Основной обработчик продолжает отвечать перед контролером за их выполнение. Перед подключением нового сервиса нужно проверить его договорные условия, меры безопасности, местонахождение систем и правила дальнейшей передачи информации.

Что предусмотреть на случай утечки

При нарушении безопасности обработчик сообщает контролеру об инциденте без неоправданной задержки. GDPR не устанавливает для обработчика универсальный срок в 72 часа. Этот срок относится к уведомлению надзорного органа контролером, если инцидент создает соответствующий риск.

В DPA стоит согласовать срок первоначального сообщения и перечень информации, которую обработчик передает на этом этапе. Контролеру понадобятся описание нарушения, категории затронутых данных, примерное количество субъектов и записей, возможные последствия и принятые меры.

Полный отчет редко можно подготовить в первые часы. Рабочая процедура предусматривает первоначальное уведомление после подтверждения инцидента и последующие обновления по мере расследования. Контактных лиц, резервный канал связи и порядок сохранения доказательств лучше определить заранее.

Заменяет ли DPA стандартные договорные условия SCC

DPA регулирует отношения контролера и обработчика по статье 28 GDPR. Standard Contractual Clauses применяются как один из механизмов передачи персональных данных за пределы Европейской экономической зоны.

Если европейский клиент передает данные обработчику в третьей стране, одного DPA может оказаться недостаточно. Сторонам нужно проверить наличие решения об адекватности или выбрать другой механизм по главе V GDPR. При использовании SCC также оцениваются законодательство страны получателя и фактические риски доступа к информации.

Модули 2 и 3 SCC, утвержденных Еврокомиссией, включают требования статьи 28. В подходящей модели они могут одновременно оформить отношения с обработчиком и международную передачу. Для этого необходимо правильно выбрать модуль и заполнить приложения с описанием обработки, мерами безопасности и перечнем субобработчиков.

Какие ошибки чаще всего возникают в DPA

Самая заметная проблема появляется, когда соглашение не соответствует продукту. В документе указано, что все данные находятся в ЕС, но резервные копии хранятся в другой стране. Поставщик обещает предварительно согласовывать каждого субобработчика, хотя техническая команда подключает сервисы без участия юриста. Срок удаления не учитывает резервные копии, а порядок уведомления об инциденте расходится с внутренней процедурой.

Ошибки также возникают при определении ролей. Компания называет себя обработчиком для всех операций, хотя использует часть данных в собственных целях. Возможна обратная ситуация: поставщик считает себя самостоятельным контролером, хотя фактически выполняет инструкции клиента.

DPA иногда путают с Privacy Policy и Cookie Policy. Политика конфиденциальности объясняет пользователям, как компания работает с их данными. Cookie Policy относится к применению файлов cookie и похожих технологий. DPA регулирует отношения между организациями.

Нарушение обязанностей по статье 28 может повлечь административный штраф до 10 миллионов евро или до 2 процентов общего мирового годового оборота за предыдущий финансовый год, в зависимости от того, какая сумма выше. Стороны также могут столкнуться с требованиями о возмещении ущерба и договорной ответственностью перед клиентом.

Что проверить перед подписанием

Проверку DPA следует начинать со схемы движения данных. Компания определяет, какие сведения поступают в продукт, где они хранятся, кто имеет к ним доступ и какие внешние сервисы участвуют в обработке.

Перед подписанием стоит проверить:

• совпадают ли роли сторон с фактической работой продукта
• перечислены ли все категории данных и субъектов
• соответствуют ли меры безопасности возможностям компании
• учтены ли поддержка, логи и резервные копии
• указан ли полный список субобработчиков
• оформлены ли международные передачи
• согласованы ли сроки уведомления об инцидентах
• можно ли выполнить требования об удалении и аудите

Если клиент предлагает собственный шаблон, каждое обязательство нужно обсудить с технической командой. Наличие подписанного документа не компенсирует слабый контроль доступа, неизвестную цепочку субобработчиков или отсутствие процедуры реагирования на утечки.