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