Онлайн-сервис редко обрабатывает персональные данные полностью самостоятельно.
Заявки уходят в CRM. Сайт стоит на хостинге. Платежи проходят через агрегатора. Письма отправляет сервис рассылки. Метрику собирает аналитика. Чат хранится у внешнего провайдера. Разработчик имеет доступ к базе. Техподдержка читает обращения пользователей. Бухгалтерия видит платежи и закрывающие документы.
Для бизнеса это обычная инфраструктура. Для персональных данных — передача третьим лицам или поручение обработки.
Проблема в том, что многие сервисы подключают подрядчиков технически, но не оформляют это юридически. Доступ к базе выдали, API подключили, экспорт в таблицу сделали, рекламщику дали CRM, разработчику отправили дамп, а в политике обработки персональных данных про это ничего нет. В договоре с подрядчиком тоже ничего нет. Кто отвечает за утечку, удаление, срок хранения, доступ сотрудников подрядчика и запрос пользователя — непонятно.
Передача данных подрядчику не запрещена. Но ее нужно оформлять так, чтобы было ясно: какие данные передаются, зачем, на каком основании, что подрядчик может с ними делать, как он защищает данные, кому внутри себя дает доступ, где хранит информацию, как удаляет данные после окончания работы и кто отвечает при нарушении.
ZLATA LEGAL помогает онлайн-сервисам, SaaS-проектам, сайтам, приложениям, маркетплейсам, платформам, Telegram-ботам и цифровым продуктам во Владивостоке, Приморском крае, на Дальнем Востоке и дистанционно по России оформить передачу персональных данных подрядчикам: CRM, хостингу, платежным сервисам, рассылкам, аналитике, разработчикам, техподдержке, рекламным подрядчикам и внешним исполнителям.
Короткий ответ
Передавать персональные данные подрядчикам можно, если есть правовое основание, понятная цель, договорная база и меры защиты.
Сначала нужно понять, кто именно получает данные: хостинг, CRM, платежный агрегатор, сервис рассылки, аналитика, коллтрекинг, чат-виджет, разработчик, техподдержка, бухгалтер, рекламный подрядчик, облачное хранилище, мессенджер, подрядчик по обработке заявок или внешний оператор.
Затем нужно определить роль подрядчика. Он просто обрабатывает данные по поручению оператора или сам становится отдельным оператором? Это разные модели.
Если подрядчик действует по поручению, в договоре или приложении нужно указать перечень данных, цели обработки, действия с данными, обязанности по конфиденциальности, требования к безопасности, порядок подтверждения мер защиты, уведомление об инцидентах, удаление или возврат данных после окончания договора и ответственность.
В политике обработки персональных данных нужно отразить передачу данных подрядчикам или категориям подрядчиков. В согласиях нужно учитывать передачу третьим лицам, если обработка строится на согласии и такая передача входит в цель обработки.
Главная мысль: подрядчик не должен получать персональные данные просто потому, что «так удобно». Данные передаются только в том объеме, который нужен для конкретной задачи.
Кто такие подрядчики в онлайн-сервисе
Подрядчик — это не только человек или компания, которым прямо отправили Excel с базой пользователей.
В онлайн-сервисе подрядчиком может быть любой внешний сервис или исполнитель, который получает доступ к персональным данным или технически участвует в их обработке.
Хостинг хранит сайт и базу. CRM принимает заявки. Платежный агрегатор обрабатывает оплату. Email-сервис отправляет письма. SMS-провайдер отправляет коды и рекламу. Аналитика собирает события. Коллтрекинг связывает звонки с рекламой. Чат-виджет хранит переписку. Облачное хранилище держит файлы. Разработчик видит базу при настройке. Техподдержка читает обращения. Рекламный подрядчик загружает аудитории в кабинеты. Бухгалтер получает данные для чеков, актов и возвратов.
Если у подрядчика есть доступ к данным, это нужно учитывать юридически. Даже если он «ничего не скачивает» и просто имеет админский доступ.
Передача и поручение обработки — не одно и то же
В быту говорят «передали персональные данные подрядчику». Юридически нужно точнее понять модель.
Первая модель — поручение обработки. Оператор остается главным лицом, которое определяет цели и средства обработки, а подрядчик действует по его поручению. Например, сервис рассылки отправляет письма по базе оператора, хостинг хранит данные, CRM обрабатывает заявки, техподдержка отвечает пользователям по правилам оператора.
Вторая модель — самостоятельная обработка другим оператором. Подрядчик получает данные и сам определяет часть целей обработки. Например, партнер оказывает собственную услугу пользователю, сам заключает договор, сам отвечает за качество и сам обрабатывает данные как отдельный оператор.
Третья модель — смешанная. Один и тот же сервис может в одной части быть обработчиком по поручению, а в другой — самостоятельным оператором. Например, платежный агрегатор помогает принять оплату по поручению продавца, но одновременно выполняет собственные обязанности по платежному законодательству и безопасности операций.
От модели зависит договор, согласия, политика и ответственность.
Почему нельзя просто дать доступ
Дать подрядчику доступ к базе без договора — слабое место.
Если данные утекут, пользователь придет не к подрядчику, а к владельцу сервиса. Именно сервис собирал данные, обещал безопасность и определял, кому дать доступ. Фраза «это подрядчик виноват» обычно не снимает проблему полностью.
Кроме того, без договора непонятно, что подрядчик может делать с данными. Может ли он копировать базу? Хранить резервную копию? Передавать своим субподрядчикам? Использовать данные для обучения сотрудников? Загружать в иностранные сервисы? Оставлять доступ после окончания проекта? Хранить данные бессрочно?
Если этого не описать заранее, спор будет решаться уже после инцидента.
Что должно быть в договоре с подрядчиком
В договоре или приложении к договору нужно описать поручение обработки персональных данных.
В нем указываются цели обработки, перечень персональных данных, категории субъектов, действия с данными, срок обработки, требования к конфиденциальности, меры безопасности, порядок доступа сотрудников подрядчика, запрет использования данных для собственных целей, порядок привлечения субподрядчиков, уведомление об инцидентах, порядок ответа на запросы оператора, возврат или уничтожение данных после окончания договора и ответственность.
Для сложных сервисов это может быть отдельное соглашение об обработке данных. Для простых задач — раздел в договоре или приложение.
Главное, чтобы это не было одной фразой «стороны обязуются соблюдать закон о персональных данных». Такая фраза не решает практические вопросы.
Перечень данных
В поручении нужно указать, какие данные получает подрядчик.
Например, ФИО, телефон, email, ID пользователя, IP-адрес, cookies, история заказов, платежный статус, обращения в поддержку, документы, файлы, должность, компания, адрес доставки, данные аккаунта, переписка, логи действий.
Не нужно писать слишком широко: «любые персональные данные». Это удобно, но плохо показывает реальную цель.
Если подрядчику нужен только email для рассылки, не нужно передавать телефон, историю платежей и документы. Если разработчику нужна тестовая база, лучше использовать обезличенные данные или ограниченную выборку. Если рекламщику нужно настроить кампанию, не всегда ему нужен прямой доступ ко всей CRM.
Чем точнее перечень данных, тем проще контролировать подрядчика.
Цель передачи
У каждой передачи должна быть цель.
Хостинг хранит сайт и базу. CRM ведет заявки. Платежный агрегатор проводит оплату. Сервис рассылки отправляет письма. Техподдержка отвечает пользователям. Разработчик настраивает продукт. Аналитика считает посещения и события. Бухгалтер оформляет документы. Рекламный подрядчик ведет кампании.
Если цель не сформулирована, легко появляется лишняя обработка. Например, подрядчик получил данные для технической настройки, а потом использует их для своей аналитики или кейса. Или рекламщик выгрузил базу для ретаргетинга, хотя пользователи не соглашались на рекламное использование.
Цель должна быть понятна в договоре, политике и, если нужно, в согласии пользователя.
Действия с данными
В договоре нужно описать, что подрядчик может делать с данными.
Например, получать, хранить, систематизировать, уточнять, использовать, передавать внутри системы, блокировать, удалять, уничтожать, обезличивать, отправлять сообщения, формировать отчеты, обеспечивать доступ, резервировать, восстанавливать или обрабатывать обращения.
Это не формальная деталь. Если подрядчик может только хранить данные, он не должен использовать их для маркетинга. Если он может отправлять письма, он не должен менять содержание рассылки без указания оператора. Если он может видеть обращения поддержки, он не должен выгружать их в сторонний AI-сервис без разрешения.
Конфиденциальность
Подрядчик должен соблюдать конфиденциальность персональных данных.
Это нужно прописать прямо: данные не используются для собственных целей, не раскрываются третьим лицам, не публикуются, не копируются сверх необходимого, не передаются сотрудникам без служебной необходимости и не сохраняются после прекращения договора без основания.
Также важно установить режим доступа внутри подрядчика. Не вся команда подрядчика должна видеть всю базу. Доступ должен быть по ролям: разработчик видит техническую часть, поддержка видит обращения, бухгалтер видит платежи, администратор управляет системой.
Для небольших проектов это кажется избыточным, но именно «доступ у всех» часто становится причиной утечек.
Безопасность данных
В договоре нужно указать требования к безопасности.
Это может быть ограничение доступа, учетные записи, пароли, двухфакторная аутентификация, журналирование, резервное копирование, шифрование, защита админки, ограничение выгрузок, запрет хранения данных на личных устройствах, порядок работы с файлами, антивирусная защита, контроль сотрудников, удаление доступов после окончания проекта.
Не обязательно превращать договор с небольшим подрядчиком в корпоративный стандарт на сто страниц. Но базовые требования должны быть.
Особенно если подрядчик получает доступ к CRM, базе пользователей, платежным данным, документам, личному кабинету, медицинским, финансовым, юридическим, детским или иным чувствительным данным.
Запрет использования для своих целей
Подрядчик не должен использовать данные пользователя для своих целей.
Например, сервис рассылки не должен продавать базу. Рекламный подрядчик не должен использовать контакты клиента для своих кампаний. Разработчик не должен сохранять дамп базы для портфолио. Поддержка не должна писать пользователям от себя. Хостинг не должен анализировать пользовательские данные вне своих технических задач.
В договоре нужно прямо указать: данные используются только для исполнения поручения оператора и только в согласованных целях.
Если подрядчик хочет использовать обезличенную статистику, это нужно отдельно согласовать и описать. Иначе «обезличенная аналитика» легко превращается в серую зону.
Субподрядчики
Многие подрядчики сами используют субподрядчиков.
Сервис рассылки может использовать облачную инфраструктуру. Разработчик может привлекать фрилансеров. Техподдержка может работать через внешнюю платформу. Рекламное агентство может передавать задачи другому исполнителю. Хостинг может использовать дата-центры и партнеров.
В договоре нужно указать, может ли подрядчик привлекать субподрядчиков, должен ли уведомлять оператора, кто отвечает за их действия, какие требования к ним применяются и можно ли передавать данные дальше.
Без этого оператор может думать, что данные у одного подрядчика, а фактически они ушли в цепочку из нескольких сервисов и людей.
Уведомление об инцидентах
Если у подрядчика произошла утечка, неправомерный доступ, потеря данных, ошибочная отправка, взлом аккаунта или другой инцидент, оператор должен узнать об этом быстро.
В договоре нужно указать срок уведомления, канал связи, состав информации и действия подрядчика. Например, подрядчик сообщает, какие данные затронуты, когда произошел инцидент, какие меры приняты, кто получил доступ, продолжается ли риск и какие действия нужны от оператора.
Это важно, потому что именно оператору может потребоваться реагировать перед пользователями, Роскомнадзором, контрагентами и внутри своей системы.
Если договор молчит, подрядчик может сообщить об инциденте слишком поздно или не сообщить вообще.
Возврат и удаление данных
После окончания работы подрядчик не должен бесконечно хранить данные.
В договоре нужно описать, что происходит с данными после прекращения договора: возврат, удаление, уничтожение резервных копий, подтверждение удаления, срок архивного хранения, исключения для бухгалтерии, спора или закона.
Например, разработчик после завершения работ удаляет дампы базы и доступы. Сервис рассылки удаляет список контактов после прекращения использования аккаунта. Поддержка закрывает доступ к тикетам. Рекламный подрядчик удаляет выгрузки аудиторий и таблицы.
Если это не прописать, база может остаться в старых аккаунтах, облаках, таблицах и ноутбуках на годы.
Контроль подрядчика
Оператор должен не просто подписать договор, но и иметь возможность контролировать подрядчика.
В договоре можно указать право запрашивать документы и информацию о мерах защиты, право проверять выполнение поручения, обязанность подрядчика отвечать на запросы, предоставлять подтверждения удаления данных, сообщать о субподрядчиках и изменениях в обработке.
На практике контроль может быть простым: запросить ссылку на политику безопасности, условия обработки данных, список сервисов, место хранения, порядок удаления, контакты ответственного лица, подтверждение включения 2FA и ограничение доступов.
Для крупного или чувствительного проекта контроль должен быть глубже.
CRM
CRM — один из главных получателей персональных данных.
В нее попадают заявки, имена, телефоны, email, источники рекламы, комментарии менеджеров, статусы сделок, записи звонков, переписка, документы, суммы, задачи и история коммуникации.
Если CRM облачная, нужно проверить, где хранятся данные, кто является поставщиком, какие условия обработки, есть ли трансграничная передача, кто имеет доступ, как удаляются данные и как ограничить права сотрудников.
В политике обработки персональных данных нужно отразить использование CRM или хотя бы категорию подрядчиков, которые обеспечивают учет заявок и коммуникацию с пользователями.
Внутри компании нужно ограничить доступ: не каждый менеджер должен видеть всю базу, особенно если есть чувствительные обращения.
Хостинг и облако
Хостинг и облачная инфраструктура технически хранят сайт, базу, файлы, логи и резервные копии.
Именно поэтому договор с хостингом и условия обработки данных важны. Нужно понимать, где физически находятся серверы, кто имеет доступ, есть ли резервное копирование, как обеспечивается безопасность, что происходит при расторжении и передаются ли данные за рубеж.
Для сервисов, которые собирают данные граждан РФ через интернет, отдельно проверяется вопрос российских баз данных и архитектуры хранения.
Если сервис использует иностранное облако, CDN, хранилище или зарубежный SaaS-инструмент, нужно оценивать трансграничную передачу и уведомления.
Платежный агрегатор
Платежный агрегатор получает данные для проведения оплаты.
Это может быть email, телефон, сумма, ID заказа, статус платежа, данные карты в защищенной форме, платежный токен, сведения о возврате, чековая информация и история операций.
Полные данные карты обычно обрабатывает агрегатор или банк, но сервис все равно передает часть персональных данных и должен отражать это в документах.
В оферте и политике нужно указать, что для оплаты данные могут передаваться платежному сервису. Также нужно проверить, кто формирует чек, где хранится платежная история, как оформляются возвраты и кто отвечает при спорном списании.
Если есть подписка и автоплатежи, нужно дополнительно контролировать согласие на рекуррентные платежи и отказ пользователя от дальнейших списаний.
Сервис рассылки
Email-рассылка, SMS-сервис, push-платформа или мессенджер-бот получают контакты пользователей и историю коммуникаций.
Для рекламной рассылки нужно отдельное согласие пользователя. Передача данных сервису рассылки должна быть отражена в политике и договорной базе.
Важно проверить, где хранится база, кто имеет доступ, как работает отписка, можно ли удалить контакт, используются ли иностранные серверы, передаются ли данные субподрядчикам и как сервис подтверждает получение согласия.
Если база переносится из одного сервиса рассылки в другой, нужно переносить не только email, но и доказательства согласия: дату, источник, текст согласия, канал и статус отписки.
Аналитика, cookies и пиксели
Аналитика и рекламные пиксели часто подключаются быстро, но юридически создают отдельный слой передачи данных.
Яндекс Метрика, рекламные кабинеты, ретаргетинг, сквозная аналитика, продуктовая аналитика, A/B-тесты и коллтрекинг могут получать IP-адреса, cookie-ID, события, источники перехода, формы, цели, поведение на сайте и связь с заявками.
Это нужно отражать в политике обработки персональных данных и cookie-уведомлении.
Если аналитика связана с рекламой, CRM или конкретными пользователями, риск выше. Нельзя писать, что сайт использует cookies только «для удобства», если фактически данные идут в рекламные системы для ретаргетинга.
Разработчики и IT-подрядчики
Разработчики часто получают самый широкий доступ: сервер, база данных, админка, логи, резервные копии, тестовые среды, Git, CRM, платежные интеграции и личный кабинет.
С ними особенно важно оформлять доступы.
В договоре нужно указать, какие данные они могут видеть, для какой задачи, можно ли копировать базу, можно ли использовать реальные данные в тестовой среде, как передаются доступы, когда они отзываются, где хранятся дампы, кто из команды имеет доступ и что происходит после окончания проекта.
Лучше не использовать реальные персональные данные для тестов, если можно использовать обезличенные или тестовые данные.
Самая частая проблема — разработчик закончил работу, но доступ к серверу, CRM или базе остался.
Техподдержка и аутсорсинг
Техподдержка может видеть обращения пользователей, email, телефоны, историю заказов, платежи, документы, скриншоты, файлы, проблемы аккаунта и переписку.
Если поддержка внешняя, нужно оформить поручение обработки. Важно указать, какие обращения она обрабатывает, какие данные видит, может ли выгружать данные, как фиксирует обращения, где хранит тикеты и как действует при запросах пользователей.
Нужно также разделить уровни поддержки. Первая линия может видеть только базовые данные. Вторая — технические логи. Финансовые вопросы — только платежный статус. Документы — только при необходимости.
Чем меньше лишних данных видит поддержка, тем ниже риск.
Бухгалтерия и кадровые подрядчики
Если бухгалтер или кадровый подрядчик получает персональные данные, это тоже нужно оформлять.
Бухгалтерия может видеть ФИО, ИНН, платежи, договоры, акты, счета, чеки, реквизиты, данные сотрудников, исполнителей и клиентов. Кадровый подрядчик может обрабатывать данные работников, кандидатов и подрядчиков.
Для данных работников требования обычно строже, чем для обычных пользователей сайта. Передача данных работников третьим лицам требует особенно аккуратного оформления.
Если бухгалтерия внешняя, договор должен содержать условия конфиденциальности, цели обработки, состав данных, меры защиты и порядок возврата или удаления документов.
Рекламные подрядчики
Рекламные подрядчики часто просят доступ к Метрике, рекламным кабинетам, CRM, сквозной аналитике, таблицам с лидами и клиентской базе.
Нужно ограничивать доступ по задаче.
Рекламщику не всегда нужна вся CRM с телефонами и комментариями менеджеров. Иногда достаточно агрегированной статистики, целей, рекламных кабинетов и обезличенных отчетов.
Если подрядчик загружает аудитории для ретаргетинга или look-alike, нужно проверить согласия пользователей на рекламное использование данных. Также нужно контролировать, чтобы подрядчик не использовал базу клиента для других проектов.
В договоре стоит прямо запретить использование данных для собственных рекламных целей подрядчика.
Маркетплейсы и платформы услуг
У маркетплейса есть отдельная сложность: данные передаются не только техническим подрядчикам, но и исполнителям.
Пользователь оформляет заказ, а платформа передает исполнителю имя, телефон, адрес, описание задачи, переписку, время визита, документы или другие сведения.
Здесь нужно определить, кто исполнитель: самостоятельный оператор или лицо, обрабатывающее данные по поручению платформы. В зависимости от модели оформляются договор с исполнителем, пользовательская оферта, политика обработки данных и согласия.
Пользователь должен понимать, какие его данные будут переданы исполнителю и зачем. Исполнитель должен понимать, что он не вправе использовать данные пользователя для своих рекламных рассылок или сторонних целей.
SaaS и данные клиентов клиента
В SaaS-проектах оператор может обрабатывать не только данные своих пользователей, но и данные, которые клиент загружает в сервис.
Например, CRM клиента, база заявок, сотрудники, контрагенты, водители, покупатели, клиенты, документы, договоры, логистика, платежи, переписка.
В такой модели нужно отдельно определить роли сторон. Клиент может быть оператором по отношению к своим данным, а SaaS-провайдер — лицом, обрабатывающим данные по поручению клиента. Одновременно сам SaaS-провайдер будет оператором по отношению к данным своих пользователей, аккаунтов, платежей и поддержки.
Это нужно прописывать в SaaS-договоре. Иначе непонятно, кто отвечает на запросы субъектов, кто уведомляет об инциденте, кто удаляет данные и кто определяет цели обработки.
Трансграничная передача
Если подрядчик находится за рубежом или данные уходят в иностранный сервис, возникает вопрос трансграничной передачи.
Это может быть иностранная CRM, рассылка, облако, аналитика, сервис поддержки, AI-инструмент, мессенджер, платежный сервис, CDN или субподрядчик.
До такой передачи нужно проверить страну, получателя, цели, категории данных, меры защиты, договорную базу и уведомление Роскомнадзора. Нельзя просто подключить иностранный сервис и написать в политике, что трансграничной передачи нет.
Для раннего онлайн-сервиса часто проще заранее выбрать инфраструктуру так, чтобы не перестраивать все после запуска.
Российские базы данных
При сборе персональных данных граждан РФ через интернет нужно учитывать требование о российских базах данных для записи, систематизации, накопления, хранения, уточнения и извлечения данных.
На практике это значит, что нужно понимать, где находится первичная база сайта, CRM, личного кабинета, базы пользователей, хранилище файлов и резервные копии.
Если данные сразу уходят в иностранный сервис, могут возникнуть вопросы. Если используется российская база, а иностранный сервис получает данные уже на следующем этапе для отдельной цели, модель нужно описывать и проверять отдельно.
Этот блок лучше решать до выбора хостинга, CRM и рассылки, а не после того, как база уже накоплена.
Что писать в политике обработки персональных данных
В политике нужно отразить передачу данных третьим лицам или поручение обработки подрядчикам.
Не обязательно перечислять каждого подрядчика по названию, хотя для некоторых проектов это полезно. Можно указать категории: хостинг-провайдеры, CRM, платежные агрегаторы, сервисы рассылки, аналитические сервисы, сервисы технической поддержки, подрядчики по разработке, бухгалтерские и юридические консультанты, рекламные и маркетинговые подрядчики.
Но формулировка не должна быть слишком широкой: «мы можем передавать данные любым третьим лицам по своему усмотрению». Такая фраза выглядит плохо и мало что объясняет пользователю.
Лучше писать, что данные передаются только в объеме, необходимом для конкретных целей: работы сайта, регистрации, оплаты, отправки уведомлений, поддержки, аналитики, исполнения договора, бухгалтерии и защиты прав оператора.
Что писать в согласии пользователя
Если обработка строится на согласии, в согласии нужно учитывать передачу данных подрядчикам.
Например, пользователь соглашается, что его данные могут обрабатываться оператором и лицами, действующими по поручению оператора, для обработки заявки, регистрации, оплаты, предоставления доступа, направления уведомлений, технической поддержки или иных конкретных целей.
Если данные передаются конкретному лицу, которое осуществляет обработку по поручению оператора, в письменном согласии могут потребоваться сведения о таком лице.
Но не нужно превращать согласие в бесконечный список всех возможных подрядчиков «на всякий случай». Согласие должно быть конкретным и соответствовать реальной обработке.
Что писать в оферте или пользовательском соглашении
В оферте и пользовательском соглашении нужно связать передачу данных с работой сервиса.
Например, сервис может использовать подрядчиков для хостинга, оплаты, отправки уведомлений, технической поддержки, аналитики, хранения файлов, обработки заявок и обеспечения безопасности.
Также можно указать, что пользователь обязан не загружать в сервис данные третьих лиц без правового основания, а в B2B-модели клиент отвечает за законность передачи данных своих сотрудников, клиентов и контрагентов в сервис.
Для SaaS и платформ это особенно важно. Пользователь может загрузить в сервис данные своих клиентов, а потом вопрос будет не только к сервису, но и к самому пользователю как оператору этих данных.
Доступы и пароли
Безопасная передача данных — это не только договор, но и доступы.
Нужно понимать, у кого есть доступ к CRM, сайту, базе, серверу, рекламным кабинетам, аналитике, облаку, рассылке, платежному кабинету и тикетам поддержки.
Доступы должны выдаваться персонально, а не одним общим логином. По возможности — с двухфакторной аутентификацией. После окончания работ доступы нужно отзывать. Права должны соответствовать роли подрядчика.
Если подрядчик работает временно, доступ тоже должен быть временным.
Юридический договор мало поможет, если база открыта через общий пароль, который гуляет в чатах.
Передача через таблицы и мессенджеры
Самая бытовая и опасная история — передача персональных данных через Excel, Google Sheets, Telegram, WhatsApp, почту и файлообменники.
Менеджер выгрузил базу, отправил подрядчику, тот переслал помощнику, потом файл остался в личном облаке или чате. Формально никто не хотел нарушать закон, но контроль над данными потерян.
Если данные нужно передать файлом, лучше ограничить состав данных, поставить пароль, ограничить доступ по ссылке, указать срок хранения, запретить пересылку, запросить подтверждение удаления и использовать рабочие, а не личные аккаунты.
Для регулярной работы лучше настроить ролевой доступ к системе, а не пересылать базы вручную.
Обезличивание и минимизация
Не всегда подрядчику нужны реальные персональные данные.
Разработчику для теста можно дать тестовую или обезличенную базу. Рекламщику можно дать агрегированную статистику. Аналитику можно дать отчеты без телефонов и email. Подрядчику по дизайну не нужны пользовательские заявки. Бухгалтеру не нужен доступ к переписке поддержки.
Принцип простой: передавать минимум данных, достаточный для задачи.
Это снижает риск утечки и упрощает контроль. Если подрядчик не получил лишних данных, он не сможет случайно или намеренно их раскрыть.
Проверка подрядчика до передачи данных
Перед подключением подрядчика стоит провести простую проверку.
Кто является юридическим лицом или ИП. Где находится подрядчик. Какие условия обработки данных он предлагает. Есть ли политика конфиденциальности. Где хранятся данные. Есть ли субподрядчики. Можно ли удалить данные. Есть ли двухфакторная аутентификация. Есть ли история утечек. Кто будет иметь доступ. Как прекращается обработка после окончания договора.
Для крупного подрядчика часть ответов будет в пользовательских условиях и DPA. Для маленького фрилансера нужно прописывать условия в договоре и контролировать доступы вручную.
Не каждый подрядчик, который умеет настраивать рекламу или CRM, аккуратно работает с персональными данными.
Документы для безопасной передачи
Для безопасной передачи данных подрядчикам обычно нужны несколько документов и настроек.
Политика обработки персональных данных, согласия пользователей, договор или приложение о поручении обработки, соглашение о конфиденциальности, условия с субподрядчиками, внутренний перечень подрядчиков, матрица доступов, порядок удаления данных, порядок реагирования на инциденты и правила передачи файлов.
Для небольшого сайта этот комплект может быть проще. Для SaaS, маркетплейса, приложения, платформы услуг, сервиса с подпиской или B2B-продукта — подробнее.
Важно не количество документов, а совпадение с реальностью: кто действительно получает данные, зачем, где хранит и что делает после окончания работы.
Частые ошибки
Первая ошибка — дать подрядчику доступ к CRM без договора. Вторая — передавать базу в Excel через мессенджер. Третья — не отражать подрядчиков в политике обработки данных. Четвертая — писать в политике, что данные никому не передаются, хотя сайт использует хостинг, CRM, рассылку и платежный агрегатор. Пятая — не проверять иностранные сервисы и трансграничную передачу. Шестая — не удалять доступы после окончания работ. Седьмая — давать подрядчику больше данных, чем нужно. Восьмая — не запрещать подрядчику использовать данные для своих целей. Девятая — не урегулировать субподрядчиков. Десятая — не иметь плана на случай утечки.
Обычно проблема не в том, что данные вообще передали. Проблема в том, что их передали без цели, без договора, без ограничения доступа и без понимания, кто отвечает.
Как правильно оформить передачу подрядчику
Сначала нужно составить список подрядчиков и сервисов, которые получают доступ к персональным данным: хостинг, CRM, платежи, рассылки, аналитика, поддержка, разработчики, бухгалтерия, рекламные подрядчики, облачные сервисы и мессенджеры.
Затем по каждому подрядчику нужно определить роль: обработчик по поручению, самостоятельный оператор или смешанная модель. После этого нужно описать данные, цели, действия, срок обработки, место хранения, субподрядчиков, безопасность, удаление и ответственность.
Дальше готовятся документы: политика обработки персональных данных, согласия пользователей, поручение обработки или договорные условия с подрядчиком, конфиденциальность, порядок инцидентов, правила доступа и удаления данных.
После этого нужно технически настроить доступы: персональные аккаунты, минимальные права, 2FA, журналы, запрет общих паролей, отзыв доступов после окончания работ и контроль выгрузок.
Так передача данных становится управляемой, а не просто бытовой пересылкой базы.
Локальный аспект: Владивосток, Приморье и Дальний Восток
Во Владивостоке и Приморском крае многие онлайн-проекты запускаются быстро: сайт, форма заявки, Яндекс Метрика, CRM, Telegram, платежная ссылка, подрядчик по рекламе, разработчик, бухгалтер и поддержка.
Это нормально для старта, но именно на этом этапе данные часто расходятся по разным сервисам без учета: заявки в CRM, телефоны в таблицах, переписка в мессенджерах, платежи у агрегатора, база у рекламщика, доступы у разработчика.
Для сервисов в логистике, ВЭД, поставках из Китая, складских услугах, морской отрасли, маркетплейсах, онлайн-обучении и B2B-автоматизации это особенно важно. Там в систему могут попадать не только имена и телефоны, но и документы, заявки, маршруты, коммерческая информация, сотрудники клиентов и данные контрагентов.
Если бизнес хочет выглядеть надежно перед B2B-клиентом, банком, платежным агрегатором или партнером, передача данных подрядчикам должна быть оформлена заранее.
Как ZLATA LEGAL помогает с передачей данных подрядчикам
ZLATA LEGAL помогает сайтам, онлайн-сервисам, SaaS-проектам, приложениям, маркетплейсам, платформам, Telegram-ботам и цифровым продуктам оформить передачу персональных данных подрядчикам.
Мы анализируем, какие подрядчики и сервисы получают данные: хостинг, CRM, платежные агрегаторы, сервисы рассылки, аналитика, рекламные пиксели, коллтрекинг, чат-виджеты, техподдержка, разработчики, бухгалтерия, облачные хранилища, API-интеграции и внешние исполнители.
Готовим политику обработки персональных данных, согласия, договорные условия о поручении обработки, соглашения о конфиденциальности, блоки для оферты и пользовательского соглашения, условия для SaaS и B2B-клиентов, рекомендации по трансграничной передаче, доступам, удалению данных и реагированию на инциденты.
Проверяем не только документы, но и реальную механику: кто видит базу, где лежат данные, какие сервисы подключены, кто может выгружать информацию, как отзываются доступы, что происходит после окончания договора и как пользователь узнает о передаче данных подрядчикам.
Работаем с проектами во Владивостоке, Приморском крае, на Дальнем Востоке и дистанционно по России.
Передача персональных данных подрядчикам — это не запретная зона. Это нормальная часть работы онлайн-сервиса. Но она должна быть оформлена так, чтобы данные не уходили в хаос, а владелец сервиса понимал, кто, зачем и на каких условиях их обрабатывает.
Частые вопросы
Можно ли передавать персональные данные подрядчикам?
Да, если есть правовое основание, понятная цель, договорная база и меры защиты. Передача должна быть ограничена тем объемом данных, который нужен для конкретной задачи.
Что такое поручение обработки персональных данных?
Это ситуация, когда оператор поручает другому лицу обрабатывать данные по своим правилам и для своих целей. Например, CRM хранит заявки, сервис рассылки отправляет письма, хостинг размещает базу, а техподдержка отвечает пользователям.
Подрядчик сам должен получать согласие пользователя?
Если подрядчик действует по поручению оператора, он обычно не получает отдельное согласие сам. Но оператор должен иметь основание для такой обработки и корректно оформить поручение.
Кто отвечает перед пользователем, если подрядчик допустил утечку?
Как правило, перед субъектом персональных данных отвечает оператор, который поручил обработку. Подрядчик отвечает перед оператором по договору и закону.
Нужно ли указывать подрядчиков в политике обработки персональных данных?
Да, передачу данных подрядчикам или категориям подрядчиков нужно отражать в политике. Пользователь должен понимать, что данные могут обрабатываться не только самим оператором, но и привлеченными лицами.
Нужно ли перечислять всех подрядчиков по названию?
Не всегда. Иногда достаточно категорий: хостинг, CRM, платежные сервисы, рассылки, аналитика, поддержка. Но для чувствительных или сложных проектов конкретный список может быть полезен.
Что должно быть в договоре с подрядчиком?
Цель обработки, перечень данных, действия с данными, конфиденциальность, безопасность, запрет использования для своих целей, субподрядчики, инциденты, возврат или удаление данных, контроль и ответственность.
Можно ли дать разработчику доступ к базе?
Можно, если это необходимо для работы, но доступ должен быть ограничен задачей. Лучше использовать тестовые или обезличенные данные. После окончания работ доступ нужно отозвать.
Можно ли отправить базу подрядчику в Excel?
Технически можно, но это рискованно. Лучше ограничить данные, защитить файл, использовать рабочие каналы, установить срок хранения, запретить пересылку и получить подтверждение удаления. Для регулярной работы лучше дать ролевой доступ к системе.
Что делать с иностранной CRM или сервисом рассылки?
Нужно проверить трансграничную передачу, место хранения данных, договорные условия, меры защиты, уведомление Роскомнадзора и соответствие российским требованиям по базам данных.
Нужно ли отдельное согласие пользователя на передачу подрядчику?
Зависит от основания обработки и модели передачи. Если обработка строится на согласии, передачу подрядчикам нужно учитывать в согласии. Если данные обрабатываются для исполнения договора или на другом основании, согласие может быть не единственным инструментом, но политика и договорная база все равно нужны.
Можно ли подрядчику использовать данные для своей аналитики?
Только если это отдельно предусмотрено и не нарушает цели обработки, политику, согласия и договор. По умолчанию подрядчик должен использовать данные только для выполнения поручения оператора.
Что делать после окончания договора с подрядчиком?
Нужно отозвать доступы, вернуть или удалить данные, получить подтверждение удаления, проверить резервные копии и закрыть технические аккаунты.
Какие документы нужны для безопасной передачи данных?
Политика обработки персональных данных, согласия пользователей, договор или приложение о поручении обработки, соглашение о конфиденциальности, условия по безопасности, субподрядчикам, инцидентам, удалению данных и внутренний порядок доступа.
Когда обращаться к юристу?
Лучше до подключения CRM, хостинга, рассылки, платежного агрегатора, аналитики, техподдержки, разработчиков, рекламного подрядчика или иностранного сервиса. На этой стадии передачу данных можно оформить без переделки всей инфраструктуры.
Связанные материалы