Что такое поручение на обработку персональных данных
Поручение на обработку персональных данных - это ситуация, когда оператор передает работу с данными клиентов или сотрудников другой компании: хостингу, CRM-сервису, колл-центру, бухгалтерии на аутсорсе или сервису рассылок. Юридически это оформляется договором или отдельным пунктом внутри уже существующего договора, и с этого момента подрядчик перестает быть посторонним лицом - он обрабатывает данные по заданию заказчика и в его интересах, а не по собственному усмотрению.
Тема касается практически любого бизнеса с сайтом, интернет-магазином или CRM. Редкая компания сегодня хранит и обрабатывает все данные клиентов своими силами, на собственном сервере, без единого стороннего сервиса. Хостинг сайта, платежный шлюз, облачная CRM, сервис email-рассылок, курьерская служба, бухгалтерия на аутсорсе - у каждого из них есть доступ к персональным данным, и почти в каждом случае нужен оформленный договор поручения.
Игнорирование этого требования не снимает ответственность с заказчика. Если утечка произошла на стороне подрядчика, отвечать перед Роскомнадзором и перед клиентами все равно будет оператор - тот, кто собрал данные и получил согласие субъекта. За нарушение условий обработки персональных данных предусмотрена административная ответственность по статье 13.11 КоАП РФ, а после поправок, действующих с 30 мая 2025 года, суммы штрафов для юридических лиц выросли ощутимо. Отсутствие оформленного поручения только ухудшает позицию оператора в такой ситуации: подрядчику предъявить претензию нечем, потому что в договоре с ним нет обязательств по защите данных.
Типичная ситуация выглядит так: сайт несколько лет собирает заявки через форму, данные уходят в CRM, договор с провайдером CRM подписан на оказание услуг связи или программного обеспечения и ни слова не говорит про персональные данные. Потом компания меняет CRM на другую, а доступ к старой базе у прежнего провайдера формально остается - выгрузить или удалить данные никто не просил, потому что в договоре не было такого пункта. С точки зрения закона это уже нарушение сразу по двум основаниям: нет оформленного поручения и не решен вопрос с данными после окончания работы с подрядчиком.
Дальше по порядку: что именно говорит закон, кому реально нужен такой договор, какие условия в нем обязательны и что делать, если подрядчик все равно нарушил условия работы с данными.
Часть 3 статьи 6 ФЗ-152: что говорит закон
Право поручать обработку персональных данных другому лицу закреплено в части 3 статьи 6 федерального закона от 27 июля 2006 года N 152-ФЗ о персональных данных. Норма разрешает оператору передать обработку третьему лицу на основании заключенного с этим лицом договора, включая государственный или муниципальный контракт, либо на основании принятия государственным или муниципальным органом соответствующего акта.
Отдельно спрашивать у субъекта персональных данных согласие именно на поручение обычно не нужно - действует то согласие, которое субъект уже дал оператору на обработку своих данных. Но это не освобождает от обязанности заключить с подрядчиком договор с определенным набором условий. Закон прямо перечисляет, что должно быть прописано в договоре поручения на обработку персональных данных:
- перечень действий (операций) с персональными данными, которые будет совершать подрядчик
- цели обработки, ради которых подрядчику передаются данные
- обязанность подрядчика соблюдать конфиденциальность персональных данных
- обязанность подрядчика обеспечить меры защиты, соответствующие требованиям к безопасности персональных данных, установленным для оператора
Если хотя бы одно из этих условий в договоре отсутствует, поручение формально оформлено с нарушением. При проверке это заметно сразу: инспектору достаточно попросить сам договор и сверить его с этим списком, отдельные пояснения тут не помогут.
Отдельный нюанс: подрядчик, который получил поручение, не становится самостоятельным оператором для этих данных и не обязан отдельно подавать уведомление в Роскомнадзор именно по этому основанию. Но если он параллельно ведет и собственную обработку - например, использует те же данные клиентов для своей аналитики или маркетинга, - для этой части он уже выступает как отдельный оператор со всеми вытекающими обязанностями, и договор поручения его от них не освобождает.
Здесь стоит различать два похожих, но разных случая. Поручение - это когда подрядчик обрабатывает данные строго в интересах заказчика и по его указаниям, а сам никаких решений о целях обработки не принимает. Другой случай - когда две компании совместно определяют, зачем и как обрабатывать данные, и обе выступают операторами одновременно: например, партнерская программа, где оба участника используют общую базу клиентов каждый в своих целях. Во втором случае одного договора поручения недостаточно - нужно распределять обязанности перед субъектами данных и перед Роскомнадзором иначе, и обычному подрядчику вроде хостинга или бухгалтерии такая схема не подходит.
Кому нужен договор поручения на обработку персональных данных: типовые подрядчики
Список тех, кому реально передаются персональные данные, обычно шире, чем кажется руководителю на первый взгляд. Ниже - подрядчики, с которыми чаще всего работает бизнес с сайтом или офлайн-точкой продаж, и статус каждого с точки зрения закона.
| Подрядчик | Какие данные обрабатывает | Нужен ли договор поручения |
|---|---|---|
| Хостинг-провайдер, дата-центр | Все данные, которые хранятся на сервере: заявки, база клиентов, резервные копии | Да |
| Облачная CRM или SaaS-сервис | ФИО, телефон, email, история обращений и заказов | Да |
| Колл-центр на аутсорсе | ФИО, телефон, содержание разговоров, если ведется запись | Да |
| Бухгалтерия на аутсорсе | Данные сотрудников для расчета зарплаты и налогов, реквизиты клиентов-физлиц | Да |
| Сервис email- и sms-рассылок | Email, телефон, иногда имя и история покупок | Да |
| Курьерская служба, служба доставки | ФИО, адрес, телефон получателя | Да |
| Рекламное агентство, настраивающее таргетинг | Списки контактов для похожих аудиторий, обезличенные идентификаторы | Да, если передается список контактов |
| Разработчик или подрядчик по сайту с доступом к базе | Полный доступ к базе клиентов на время работ | Да |
| Клининговая компания, обслуживающая офис | Как правило, доступа к данным клиентов нет | Нет |
Если подрядчик технически не видит и не может увидеть персональные данные - например, обслуживает только офисную сеть без доступа к базе клиентов, - договор поручения не требуется. Граница простая: как только сторонняя компания получает доступ к данным клиентов или сотрудников, независимо от того, читает она их вручную или просто хранит на своих серверах, возникает необходимость в договоре.
Частая ошибка - считать, что раз программа стоит на собственном сервере компании, поручение не нужно в принципе. Это не так, если у разработчика или интегратора есть удаленный доступ для обслуживания: техподдержка 1С, подрядчик, который дорабатывает сайт, или компания, обслуживающая CRM по договору сопровождения. Сам факт доступа к базе данных клиентов - уже основание заключить договор поручения, даже если физически сервер стоит в офисе заказчика, а не у подрядчика.
Отдельно про зарубежные сервисы
С иностранными сервисами ситуация сложнее вдвойне: помимо договора поручения нужно учитывать правила трансграничной передачи данных, а часть популярных зарубежных инструментов вообще не подписывает договоры на условиях, которые требует российский закон. Разбор, что делать с сервисами вроде Notion, Slack и Mailchimp, есть в статье про зарубежные сервисы в российской компании: там же объясняется, почему сам факт регистрации в облачном сервисе с данными клиентов - уже риск, даже если формальный договор с этим сервисом никто не подписывал и подписать не может.
Что обязательно включить в договор поручения обработки персональных данных: образец структуры
Готового бланка, который подойдет любому бизнесу без правок, не существует - условия сильно зависят от того, что именно делает подрядчик с данными. Но структура, которая закрывает требования части 3 статьи 6, выглядит примерно одинаково для большинства случаев:
- Предмет договора: конкретный перечень операций - сбор, хранение, передача, удаление и так далее, без обтекаемых формулировок про любую обработку, которая может потребоваться в будущем
- Цель обработки, которая совпадает с целью, указанной в согласии субъекта и в уведомлении в Роскомнадзор
- Категории и перечень персональных данных, к которым подрядчик получает доступ
- Обязанность подрядчика соблюдать конфиденциальность и не передавать данные третьим лицам без отдельного согласования с заказчиком
- Обязанность подрядчика применять организационные и технические меры защиты данных, соответствующие требованиям к безопасности персональных данных
- Срок обработки и порядок действий после окончания договора: возврат или уничтожение данных, подтверждающий акт
- Порядок и срок уведомления заказчика об инцидентах - в течение какого времени подрядчик обязан сообщить о подозрении на утечку
- Ответственность подрядчика за нарушение условий договора, включая компенсацию убытков заказчика
Пункт про срок уведомления об инцидентах стоит прописывать в часах, а не в днях. У оператора есть свои сроки уведомления Роскомнадзора об утечке - 24 часа на первичное сообщение и 72 часа на уточненные детали, и эти сроки не сдвигаются из-за того, что информация от подрядчика пришла с опозданием. Как устроен весь процесс на стороне оператора по шагам, разобрано в статье про план реагирования на утечку персональных данных.
Отдельно стоит прописать порядок действий при субобработке - когда подрядчик сам передает данные дальше, другому исполнителю. Например, CRM-сервис может хранить данные не на своих серверах, а в стороннем дата-центре. Формально это уже цепочка из двух поручений, и заказчику стоит знать о ней и согласовывать смену такого субподрядчика, а не узнавать о ней постфактум из технической документации сервиса.
Ответственность заказчика за действия обработчика
Здесь чаще всего возникает главное заблуждение. Бизнес считает: раз данные утекли из CRM или с хостинга, отвечать должен именно этот сервис. Закон устроен иначе: оператор отвечает перед субъектом персональных данных за действия лица, которому поручил обработку. Подрядчик, в свою очередь, отвечает перед оператором - в рамках того договора, который между ними заключен, и не более того.
Практическое следствие: если в договоре с хостингом или CRM нет пункта об обязанности обеспечить защиту данных, оператору будет нечем компенсировать свои потери от штрафа или судебного иска, даже если формально виноват подрядчик. А перед Роскомнадзором и перед клиентами отвечать в любом случае будет тот, кто собрал данные и получил согласие субъекта, то есть заказчик.
Похожая логика действует, когда данные не просто обрабатываются подрядчиком по заданию, а передаются третьим лицам - партнерам, рекламным сетям, службам проверки контрагентов. Передача персональных данных третьим лицам - отдельное основание обработки, которое не стоит путать с поручением: поручение подразумевает, что подрядчик действует строго по заданию оператора и в его интересах, а передача третьим лицам может означать, что данные используются в интересах этого третьего лица и требует отдельного согласия или другого законного основания. Путаница между этими двумя понятиями - частая причина нарушений при интеграции сайта с внешними сервисами, разбор типичных случаев есть в статье про интеграцию CRM с сайтом.
Пример из практики проверок: интернет-магазин подключил CRM для обработки заказов и передавал туда ФИО, телефон и адрес доставки покупателей без какого-либо оформленного поручения - только техническая интеграция через API. Формально это уже два самостоятельных нарушения: нет договора с обязательными условиями по части 3 статьи 6, и покупатели не были проинформированы, что их данные обрабатывает еще и сторонний сервис. Оба нарушения фиксируются отдельно, даже если сама CRM не допустила утечки и обработала данные аккуратно.
Как оформить поручение на обработку персональных данных: пошагово
Шаг 1. Составить список всех подрядчиков, у которых есть доступ к персональным данным клиентов или сотрудников - от хостинга до сервиса рассылок. На практике список почти всегда оказывается длиннее, чем ожидает руководитель, особенно если за годы работы накопились сервисы, подключенные разными сотрудниками без согласования с юристом или директором.
Шаг 2. Для каждого подрядчика проверить, есть ли действующий договор и упомянуты ли в нем персональные данные вообще. Часто выясняется, что договор с хостингом или разработчиком подписан на оказание технических услуг и ни словом не касается обработки данных - формально поручения не существует, хотя подрядчик годами работает с базой клиентов и имеет к ней полный доступ.
Шаг 3. Добавить недостающие условия - либо отдельным соглашением к уже действующему договору, либо новым пунктом при следующем продлении. Пример: сервис email-рассылок обрабатывает базу email-адресов клиентов, и этот случай стоит закрыть договором поручения одновременно с проверкой самой рассылки на соответствие требованиям закона о рекламе - оба вопроса разобраны в статье про email-рассылки и двойной чек-лист легальности.
Шаг 4. Зафиксировать перечень заключенных договоров поручения во внутреннем документе - реестре или таблице с колонками: подрядчик, какие данные передаются, дата договора, срок действия. Это не обязательное требование закона, но при проверке такой реестр экономит часы: не нужно поднимать все договоры компании подряд, чтобы найти нужные среди десятков папок.
Шаг 5. Периодически, раз в год или при смене подрядчика, сверять список заново. Сервисы меняются чаще, чем кажется: сегодня рассылка идет через один сервис, через полгода - через другой, а договор поручения с прежним подрядчиком так и остается неразорванным вместе с доступом к данным, которые давно нужно было отозвать.
Резервные копии и облачные хранилища у подрядчика
Отдельная ловушка - резервные копии. Договор поручения обычно составляют, думая об основной рабочей базе данных, и забывают, что та же информация регулярно копируется в бэкапы - у хостинга, у CRM-провайдера, иногда у стороннего сервиса резервного копирования. Формально это тоже обработка персональных данных, и на нее распространяются те же требования: место хранения, срок хранения, доступ, защита.
Если бэкапы хранятся за рубежом или у сервиса, с которым не заключен договор поручения, это нарушение независимо от того, что происходит с основной базой. Подробно про правила хранения резервных копий - в статье где можно, а где нельзя хранить бэкапы с персональными данными. Прежде чем подписывать договор поручения с хостингом, стоит уточнить отдельно, как и где хранятся резервные копии - это редко прописано в стандартном тарифе, но обязательно должно быть в самом договоре.
Что делать, если подрядчик нарушил условия договора
Если выясняется, что подрядчик обрабатывает данные не так, как договорились - передает их дальше без согласования, хранит дольше нужного срока или не сообщает об инцидентах вовремя, - у заказчика есть право требовать устранения нарушения и компенсации убытков в рамках самого договора. Но это работает только тогда, когда нужные обязательства в договоре действительно прописаны: без них требовать, по сути, нечего, кроме общих норм о ненадлежащем исполнении услуг, которые доказать сложнее и дольше.
На практике стоит закладывать в договор не только обязанности подрядчика, но и право заказчика на проверку: запрос информации о принятых мерах защиты, право аудита при подозрении на нарушение, обязанность подрядчика содействовать при проверке Роскомнадзора, если она касается переданных ему данных. Эти условия редко встречаются в типовых договорах на хостинг или CRM, их приходится добавлять отдельно - через переговоры с подрядчиком или дополнительное соглашение к уже действующему договору.
Если подрядчик отказывается вносить такие условия в договор, это само по себе повод задуматься о смене сервиса, особенно если через него проходят данные с высокой чувствительностью: медицинские сведения, паспортные данные, финансовая информация. Отказ обсуждать условия защиты данных обычно означает, что сервис либо не готов их обеспечить, либо не привык, чтобы это вообще спрашивали.
Отдельно стоит зафиксировать, что происходит с данными при расторжении договора с подрядчиком, а не только при его нарушении. Смена CRM, переход на другой хостинг, отказ от услуг колл-центра - в каждом из этих случаев нужен понятный порядок: подрядчик либо возвращает данные заказчику, либо уничтожает их и подтверждает это актом. Без такого условия данные клиентов могут годами оставаться на серверах компании, с которой давно нет никаких отношений, и заказчик об этом даже не узнает, пока не случится проверка или утечка.
Как проверить свои договоры и что делать дальше
Если в компании никогда не проверяли договоры с подрядчиками именно на предмет поручения обработки персональных данных, начать стоит с простого шага - собрать все действующие договоры с сервисами, которые так или иначе видят данные клиентов или сотрудников, и свериться со списком обязательных условий из части 3 статьи 6. Даже беглая сверка обычно показывает два-три места, где условий не хватает, а иногда и подрядчиков, о которых забыли вовсе. Отдельно стоит проверить не только новые договоры, но и старые, заключенные несколько лет назад: требования к содержанию поручения не менялись радикально, но многие типовые договоры на хостинг и техподдержку составлялись еще до того, как в компании вообще задумались о персональных данных как об отдельном вопросе, и о них попросту забывают при любой проверке.
Дальше можно двигаться самостоятельно: дописать недостающие пункты, оформить дополнительные соглашения, завести реестр подрядчиков и держать его в актуальном состоянии. Если времени или юридической подготовки не хватает, на сайте 152fzpro.ru есть услуга аудита сайта и документов на соответствие закону о персональных данных, включая проверку договоров с подрядчиками и подготовку недостающих соглашений поручения. Итог такой проверки - понятный список: что уже в порядке, а что нужно донести или переподписать, без требований сверх того, что реально нужно этому конкретному бизнесу.
