Штраф до 20 млн евро или 4% мирового годового оборота по GDPR может возникнуть не только из-за утечки. Риск появляется раньше — когда SaaS-платформа, агрегатор или парсинг-агентство передает контрагенту клиентскую базу, логи пользователей или доступ к API без корректно оформленной договорной конструкции. Договор обработки или соглашение конфиденциальности в такой ситуации решают разные задачи, и подмена одного документа другим оставляет бизнес без нужной защиты.
Для фаундера вопрос обычно возникает в момент масштабирования: внешний подрядчик подключается к облачному хранилищу, агентство очищает собранные контакты, поставщик предоставляет технологию обогащения данных или новый клиент требует выгрузку датасета. Коммерческая команда хочет закрыть сделку быстро, а юрист контрагента предлагает подписать стандартный NDA. Иногда этого достаточно. Но если стороны начинают обрабатывать персональные данные, стандартный NDA не выполняет требования GDPR.
Чем отличается договор обработки данных от NDA
Соглашение о конфиденциальности, или NDA, устанавливает режим неразглашения. Оно отвечает на вопрос, какую информацию получатель обязан хранить в тайне, кому ее можно раскрывать, как долго действует обязанность и что происходит при нарушении. В его предмет могут входить исходные файлы, коммерческие условия, методы сбора данных, списки клиентов, результаты аудита, документация API и непубличные сведения о продукте.
DPA, или соглашение об обработке персональных данных, регулирует другую конструкцию. В ней одна сторона определяет цели и средства обработки — контролер, а другая обрабатывает сведения только по документированным инструкциям контролера — обработчик. Для компаний, работающих с лицами из Европейской экономической зоны, минимальное содержание такого соглашения закреплено в статье 28 GDPR.
Разница имеет практическое значение. NDA запрещает раскрытие информации, но не обязывает подрядчика обрабатывать данные исключительно по инструкциям заказчика, обеспечивать права субъектов, привлекать субподрядчиков по установленным правилам или содействовать при инциденте. Эти обязанности нельзя предполагать по умолчанию.
Когда требуется соглашение об обработке персональных данных
DPA нужен, когда контрагент получает доступ к персональным данным и действует от имени вашей компании. Типовые ситуации — хостинг и облачная инфраструктура, CRM-провайдер, служба технической поддержки, подрядчик по рассылкам, аналитический сервис, внешний разработчик с доступом к production-базе, провайдер верификации или команда, выполняющая дедупликацию записей.
Для веб-скрапинга особенно важен анализ фактических ролей, а не названий в договоре. Если агентство собирает общедоступные данные по вашим параметрам, передает результат только вам и не определяет самостоятельную цель использования, оно может выступать обработчиком. Если агентство формирует собственную базу, повторно использует ее для других заказчиков или самостоятельно решает, какие данные и для каких коммерческих целей собирать, модель обработки меняется. В отдельных операциях стороны могут быть самостоятельными контролерами, а иногда — совместными контролерами.
Неправильная квалификация опасна двумя последствиями. Во-первых, формально подписанный DPA не устранит нарушение, если фактическая модель ему противоречит. Во-вторых, контролер не сможет доказать, что надлежащим образом выбрал и контролировал поставщика, как требует статья 28 GDPR.
NDA остается необходимым, когда сведения не являются персональными данными либо когда нужно дополнительно защитить коммерческую тайну. Например, при передаче методологии парсинга, лимитов запросов, списка доменов-источников, ценовой модели или технического описания интеграции. На практике для data-проектов часто требуется пакет документов: DPA регулирует персональные данные, NDA — конфиденциальные сведения, а лицензионный договор — права на базу данных и допустимые способы ее использования.
Что должно быть в DPA для международного проекта
Статья 28 GDPR требует не абстрактного обещания соблюдать закон, а конкретных условий. Документ должен фиксировать предмет и срок обработки, характер и цель операций, категории данных и субъектов, а также права и обязанности контролера. Формула «обработка любых данных по необходимости» плохо защищает обе стороны: она не дает инженерам понятных границ доступа и не выдерживает проверку регулятора.
Особого внимания требуют инструкции на случай, если подрядчик получает данные через скрапинг или закрытый API. В договоре стоит прямо разделить, какие источники разрешены, какие методы сбора исключены, кто проверяет правила платформы и правовое основание для обработки, а также кто несет расходы при претензии правообладателя или субъекта данных. DPA не легализует обход технических ограничений сайта, брутфорс API или сбор материалов, защищенных авторским правом и правом на базу данных.
Условия о безопасности должны быть соразмерны архитектуре. Для облачного сервиса недостаточно фразы «принимаются разумные меры». Стороны обычно согласуют разграничение прав доступа, многофакторную аутентификацию, журналирование, шифрование при передаче и хранении, порядок резервного копирования, сроки удаления и правила работы с тестовыми средами. Если разработчик выгружает продуктивную базу в локальную среду без контроля, формальный договор не компенсирует операционный риск.
Отдельный блок посвящают субобработчикам. Подрядчик не должен незаметно передавать данные другому поставщику. Контролеру нужен механизм предварительного специального или общего письменного разрешения, уведомления о замене субподрядчика и право возразить при существенном риске. Для SaaS-компаний это особенно чувствительно: цепочка может включать облачный хостинг, сервис мониторинга, поддержку и провайдера электронной почты.
Также договор должен описывать порядок помощи при запросах субъектов, оценке воздействия на защиту данных и проверках. При инциденте обработчик обязан уведомить контролера без неоправданной задержки. Сам контролер при наличии риска для прав и свобод обязан уведомить надзорный орган в срок до 72 часов после того, как узнал о нарушении, согласно статье 33 GDPR. Поэтому договорной срок уведомления подрядчика обычно делают значительно короче и привязывают к минимальному составу первичного сообщения.
Почему NDA не закрывает риски скрапинга и передачи баз
Представим e-commerce-агрегатор, который передает подрядчику выгрузку карточек товаров, контактов продавцов и историю обращений пользователей для нормализации. NDA защитит сам факт передачи и коммерческую ценность выгрузки. Но если в файлах есть имена, телефоны, идентификаторы аккаунтов или IP-адреса, нужны правила законной обработки, безопасности, удаления и контроля субподрядчиков.
Другой пример — дата-брокер продает бизнес-клиенту набор контактных данных. Здесь ключевой документ может быть не DPA, а договор лицензирования базы данных с условиями допустимого использования, ограничениями на дальнейшую передачу, гарантиями о происхождении данных и распределением ответственности. Если покупатель самостоятельно определяет цели маркетинга, он не является вашим обработчиком. Называть его процессором только для удобства опасно: регулятор и суд будут смотреть на реальное распределение ролей.
В российском контуре требуется учитывать Федеральный закон № 152-ФЗ «О персональных данных». Договор с поручением обработки должен содержать перечень действий с персональными данными, цели обработки, обязанность соблюдать конфиденциальность и обеспечивать безопасность. Для трансграничных операций, проектов с пользователями из ЕС или поставщиками из США договорная схема должна проверяться одновременно по применимым юрисдикциям, а не копироваться из локального шаблона.
Ошибки, которые дорого обходятся бизнесу
Самая частая ошибка — подписать один короткий NDA со всеми подрядчиками и считать вопрос закрытым. Вторая — использовать шаблон DPA, который не соответствует фактической архитектуре: он не называет субобработчиков, не описывает категории данных и не устанавливает порядок удаления копий из резервных систем.
Не менее рискованно обещать клиенту в договоре абсолютную анонимизацию без технической проверки результата. Псевдонимизированные записи часто остаются персональными данными, если их можно связать с человеком с помощью дополнительной информации. Перед передачей датасета необходимы документированная оценка идентификационного риска, правила доступа к ключам сопоставления и запрет на попытки обратной идентификации.
Наконец, нельзя смешивать конфиденциальность с правами на данные. Даже если база передана по NDA, это не означает, что получатель вправе копировать ее, продавать третьим лицам, использовать для собственных проектов или создавать производную базу. Эти вопросы должны быть урегулированы отдельными лицензионными условиями.
Как выбрать договорную конструкцию до запуска проекта
Начинать стоит не с шаблона, а с карты потоков данных. Нужно установить, какие сведения передаются, есть ли среди них персональные данные, откуда они получены, где хранятся, кто имеет доступ и для каких целей каждая сторона их использует. После этого определяется роль участников и формируется связка документов.
Если контрагент действует строго по вашим инструкциям, потребуется DPA, а NDA добавляется для защиты коммерчески чувствительных материалов. Если стороны обмениваются данными как независимые владельцы процессов, договор должен закреплять самостоятельную ответственность, правовые основания и пределы использования. Если передается база как коммерческий актив, потребуется лицензия с точным описанием объема прав и ограничений.
Дата-юристы Data Lawyer Agency проводят аудит потоков данных, квалифицируют роли сторон и готовят DPA, NDA и лицензионные договоры под архитектуру конкретного сервиса. Это позволяет вывести подрядчика или клиента в рабочий контур без слепого копирования шаблонов и без того, чтобы юридические риски всплыли после первой претензии, утечки или инвестиционной проверки.