Разработчик получает доступ к базе клиентов: нужно ли поручение на обработку персональных данных и что в нём указать

Короткий ответ: если разработчик видит или копирует данные ваших клиентов — переносит CRM, поддерживает личный кабинет, чинит форму с доступом к заявкам, — он обрабатывает персональные данные по вашему поручению, и это поручение нужно оформить договором. В нём по ч. 3 ст. 6 закона 152-ФЗ указывают перечень данных и действий, цели, требования к защите и ещё несколько обязательных пунктов. Пункта о конфиденциальности в договоре на разработку для этого недостаточно. А во многих задачах поручение можно вообще не оформлять — если дать разработчику обезличенную копию вместо боевой базы.

Ниже — как понять, обрабатывает ли подрядчик данные, что записать в поручение, как выдать доступ без лишнего и что сделать, когда работы закончены. Статья опирается на текст 152-ФЗ в редакции от 26 июля 2026 года на consultant.ru. Это разбор для заказчика, а не юридическая консультация: формулировки поручения стоит согласовать с юристом компании.

Когда разработчик обрабатывает ПДн по поручению?

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

Под это определение попадает больше задач, чем кажется. Типовые случаи:

• Миграция. Переезд со старой CRM, перенос клиентов магазина на новую платформу, объединение двух баз после слияния. Разработчик получает всю базу целиком.
• Поддержка работающей системы. Чтобы разобраться, почему у клиента не проходит оплата или не открывается кабинет, разработчик смотрит его запись, логи и историю действий.
• Сайт с формами. Если подрядчику дали вход в админку, где лежат заявки, или в почтовый ящик, куда они приходят, — он видит имена и телефоны.
• Интеграции. Связка CRM с 1С, телефонией или сервисом рассылок: при отладке через разработчика проходят живые карточки клиентов.
• Резервные копии. Подрядчик, который делает бэкапы базы на своё хранилище, хранит ваши данные, даже если ни разу их не открыл.

Простой тест: если завтра у подрядчика украдут ноутбук или взломают учётную запись, утекут ли данные ваших клиентов? Если да — это ваш случай, и дальше читать стоит внимательно. Ответственность перед клиентами за действия подрядчика по ч. 5 ст. 6 несёт оператор, то есть вы; подрядчик отвечает перед вами. Если обработку поручили иностранному лицу, по ч. 6 ст. 6 перед субъектом отвечают оба.

Задача	Что видит разработчик	Поручение	Как сократить доступ
Перенос клиентов из старой CRM в новую	Всю базу: ФИО, телефоны, почту, историю сделок	Нужно	Отладка на обезличенной копии, боевой перенос — один раз по согласованному окну
Личный кабинет клиента с нуля	До запуска — только тестовые записи	Обычно не нужно до запуска	Генерировать тестовых пользователей, боевую базу не давать
Поддержка работающего кабинета или CRM	Боевой сервер и базу, логи с данными пользователей	Нужно	Отдельная учётная запись, журнал входов, доступ к базе только на чтение, где можно
Починка формы заявок на сайте	Заявки в админке и в почте, если туда пустили	Нужно, если есть доступ к заявкам	Дать доступ к коду и хостингу без входа в раздел заявок
Интеграция CRM с 1С или сервисом рассылок	Поток данных клиентов между системами, тестовые выгрузки	Нужно	Тестовые среды обеих систем, ключи с минимальными правами
Вёрстка лендинга или правка дизайна	Код и тексты, данных нет	Не нужно	Не выдавать доступ к почте, CRM и админке заявок

Что обязательно указать в поручении?

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

Из этих пунктов чаще всего пропускают три, и именно они полезнее всего на практике:

• Конкретный перечень данных. Не «персональные данные клиентов», а список полей. Это дисциплинирует обе стороны: если в переносе участвуют только ФИО, телефон и почта, паспортные данные из старой анкеты переносить не нужно.
• Документы по запросу. Закон прямо даёт оператору право запросить подтверждение мер, в том числе до начала обработки. Спросите заранее: где будет лежать копия, кто из команды получит доступ, как он отключается.
• Уведомление об инциденте. Если данные утекли, у оператора по ч. 3.1 ст. 21 24 часа на первое уведомление Роскомнадзора и 72 часа на результаты внутреннего расследования. Без срока в поручении вы можете узнать об утечке от подрядчика через неделю, а отвечать перед клиентами и Роскомнадзором всё равно вам. Пишите конкретно: «незамедлительно, но не позднее N часов с момента обнаружения».

Цели формулируйте узко и под задачу: «перенос базы и проверка переноса», «техническая поддержка CRM по договору от…». Широкая цель вроде «оказание услуг» не помогает ни вам, ни проверяющему. Ниже — таблица условий с примерами того, как они выглядят в проекте разработки.

Условие закона	Как это выглядит в проекте разработки
Перечень персональных данных	«ФИО, телефон, адрес электронной почты, адрес доставки, история заказов клиентов заказчика»
Перечень действий с данными	«Хранение на сервере заказчика, извлечение, систематизация, изменение структуры, перенос между базами, удаление, уничтожение»
Цели обработки	«Перенос базы клиентов в новую CRM и проверка корректности переноса»
Конфиденциальность	Не раскрывать и не распространять данные, не использовать для собственных целей
Требования ч. 5 ст. 18 и ст. 18.1	Работать с данными только в базах на территории России, принять меры оператора по ст. 18.1 в своей части
Документы по запросу оператора	По запросу, в том числе до начала работ, подтвердить принятые меры: кто имеет доступ, как хранится копия
Безопасность и требования ст. 19	Доступ по личным учётным записям, без копий на личных устройствах, защищённые каналы передачи
Уведомление об инцидентах	Сообщить оператору об утечке или неправомерном доступе сразу, с указанием срока в часах

Отдельный договор или раздел в договоре на разработку?

Подойдут оба варианта: закон требует договор, но не отдельный документ. Удобнее всего приложение к договору на разработку или поддержку: в нём перечень данных, действия, цели и меры защиты, а срок действия связан с основным договором. Главное — чтобы все обязательные условия были записаны полностью.

Как выбрать формат:

• Разовая задача — приложение к договору на разработку. Переезд CRM, перенос клиентов магазина. Поручение действует на время работ и заканчивается уничтожением копий.
• Постоянная поддержка — приложение к договору на поддержку. Доступ нужен месяцами, состав данных может меняться — проще обновлять приложение, чем переписывать основной договор.
• Несколько подрядчиков — отдельное соглашение с каждым. Если CRM ведёт одна команда, а сайт другая, у каждой свои данные и свои действия. Общий документ на всех запутает зоны ответственности.

Что важно знать про наши документы. В типовых договорах Roboweb есть раздел 6 о конфиденциальности: стороны не разглашают полученную информацию, включая доступы и персональные данные, весь срок договора и три года после его прекращения. Это условие о неразглашении, а не поручение: в нём нет перечня данных, действий, целей и требований к защите. Если проекту нужен доступ к персональным данным, условия поручения добавляют приложением к договору, а текст стоит показать вашему юристу. Разница между NDA и поручением подробно разобрана в статье о том, что защищает NDA с разработчиком.

Ещё один момент — согласие ваших клиентов. Ч. 3 ст. 6 говорит, что поручение даётся с согласия субъекта, если федеральным законом не предусмотрено иное. Проверьте до начала работ, упоминают ли ваша политика и текст согласия, что обработку могут поручать подрядчикам, и решите с юристом, хватает ли этого для вашего основания обработки.

Как дать доступ без лишних данных?

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

Как это устроить по шагам:

1. Обезличенная копия на вашей стороне. Ваш администратор или подрядчик по отдельному короткому заданию заменяет ФИО, телефоны, почту и адреса в копии базы. Связи «клиент — заказ — оплата» сохраняются, чтобы ловить реальные ошибки переноса: дубли, пустые поля, кривые форматы телефонов.
2. Разработка и тесты — только на копии. Скрипты переноса, обмен с 1С, экраны кабинета отлаживаются без единой настоящей записи. Это заодно ускоряет работу: копию не жалко сломать и пересоздать.
3. Боевой прогон — в согласованное окно. Настоящая база участвует один раз: при финальном переносе или запуске. Время, участники и сервер известны заранее, доступ после прогона закрывается.
4. Личные учётные записи вместо общего пароля. У каждого участника своя учётная запись в CRM, на сервере и в базе. Так видно, кто и когда входил, и доступ одного человека отключается без смены паролей у всей компании.
5. Права по ролям. Тому, кто чинит интеграцию, не нужна выгрузка всей базы; тому, кто правит вёрстку, — раздел заявок. Как спроектировать такие права, разобрано в статье о ролях и правах доступа в CRM и кабинете.
6. Данные не покидают ваш контур. Работа идёт на вашем сервере или в вашем облаке в России, без выгрузок на личные компьютеры и в мессенджеры. Требования к месту хранения — в материале о локализации данных по 152-ФЗ.

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

Что сделать после окончания работ?

Забрать доступы и убедиться, что у подрядчика не осталось копий. По ч. 4 ст. 21 оператор прекращает обработку и уничтожает данные в течение 30 дней после достижения цели, а если данные обрабатывает другое лицо по поручению — обеспечивает это. Значит, проконтролировать удаление копий у разработчика — ваша задача.

Чек-лист закрытия работ:

• Отключить личные учётные записи подрядчика в CRM, админке, на сервере и в базе; сменить общие пароли, если они всё же передавались.
• Отозвать ключи API и токены, которые выпускались для работ.
• Получить письменное подтверждение, что у подрядчика уничтожены копии базы, тестовые выгрузки с настоящими данными и резервные копии на его стороне.
• Оформить подтверждение уничтожения по требованиям приказа Роскомнадзора от 28.10.2022 N 179: акт, а при автоматизированной обработке — ещё выгрузка из журнала регистрации событий.
• Проверить журнал входов за период работ: не было ли доступа в нерабочее время или с неожиданных адресов.
• Если поддержка продолжается — обновить приложение-поручение: оставить только те данные и действия, которые нужны для поддержки.

Удобно привязать эти шаги к подписанию акта сдачи-приёмки: передали результат и доступы, тут же закрыли временные учётные записи. Если после запуска подрядчик продолжает обслуживать систему, это отдельная работа и отдельное поручение под неё — например, в составе договора на поддержку от 7 900 ₽/мес.

Когда поручение не нужно?

Когда разработчик не видит персональных данных: верстает лендинг, правит дизайн, пишет код на тестовых записях, настраивает сервер без доступа к базе. Чем больше задач удаётся решить так, тем меньше у вас бумаг и рисков.

• Новая система до запуска. Личный кабинет или CRM с нуля отлаживают на сгенерированных пользователях. Живые данные появятся после запуска — тогда и решайте, кто будет поддерживать систему и нужно ли поручение.
• Работы только с кодом. Доработка функций в репозитории без доступа к боевому серверу и базе.
• Копия с вымышленными значениями. Если имена, телефоны, адреса и комментарии заменены вымышленными, а таблицы соответствия с реальными людьми у разработчика нет, данных ваших клиентов он не получает. Хватит ли вашей замены полей — вопрос к юристу: иногда человека выдают комментарии менеджеров или редкие сочетания полей.
• Сотрудник в штате. Свой программист — работник оператора, а не «другое лицо» из ч. 3 ст. 6: его доступ регулируют внутренними документами компании.

Какие ошибки встречаются чаще всего?

Почти все ошибки сводятся к одному: доступ к живым данным дали «на время», а оформить и закрыть его забыли. Ниже — то, что встречается регулярно.

• Общий пароль администратора. Подрядчику пересылают логин и пароль директора. Через год неизвестно, у кого он есть, а отключить одного человека невозможно.
• Дамп базы в чате. Выгрузку отправляют файлом в мессенджере или почтой. Копия живёт на чужих серверах и устройствах без срока — пока кто-нибудь её не удалит.
• Поручение «обо всём». Перечень данных — «все персональные данные», цели — «оказание услуг». Формально документ есть, по сути он не описывает работу.
• Нет срока уведомления об утечке. Обязанность сообщить записана, срок нет — и вы узнаёте об утечке последним, хотя уведомлять Роскомнадзор за 24 часа обязаны именно вы.
• Доступы после сдачи. Работы приняты, а учётные записи подрядчика в CRM и на сервере остаются активными.
• Боевая база для отладки. Скрипт переноса гоняют десятки раз на настоящих данных, хотя хватило бы копии.

Сколько это стоит?

Само поручение — документ, его готовит юрист заказчика. С технической стороны затраты появляются в двух местах: подготовка обезличенной копии и настройка раздельных доступов. Их оцениваем в составе работ после брифа, отдельной строкой в смете.

Ориентиры по прайсу: интеграции и автоматизация, включая обмен между CRM и 1С, — от 32 000 ₽, веб-приложение с кабинетами и ролями — от 160 000 ₽, поддержка — от 7 900 ₽/мес. Цена и срок фиксируются в договоре до старта, подробности — на странице цен. Обезличенная копия экономит время: отладка идёт быстрее, когда данные можно ломать и пересоздавать, а боевой прогон сводится к одной проверенной операции.

Итог для заказчика: прежде чем отправлять подрядчику пароль от CRM, ответьте на три вопроса — какие данные ему нужны на самом деле, можно ли обойтись копией и кто закроет доступ после работ. Если без живых данных не обойтись, оформите поручение с полным набором условий из ч. 3 ст. 6 152-ФЗ.

Короткие ответы на частые вопросы

Нужно ли поручение, если разработчик только переносит базу и ничего с ней не делает?

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

Кто составляет поручение — заказчик или студия?

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

Хватит ли условия о конфиденциальности в договоре на разработку?

Нет. Конфиденциальность — только одно из условий поручения. Закон требует ещё перечень данных и действий, цели, требования к защите, уведомление об инцидентах и предоставление документов по запросу оператора.

Нужно ли согласие клиентов на передачу их данных разработчику?

По ч. 3 ст. 6 152-ФЗ поручение даётся с согласия субъекта, если федеральным законом не предусмотрено иное. Проверьте, упоминает ли ваше согласие и политика привлечение подрядчиков, и решите вопрос с юристом до начала работ.

Что делать с копией базы после завершения работ?

Разработчик уничтожает все копии и тестовые выгрузки с персональными данными, отключает свои учётные записи и подтверждает это письменно. Подтверждение уничтожения оформляют по требованиям Роскомнадзора — актом и, при автоматизированной обработке, выгрузкой из журнала.

Услуги и кейсы по теме: типовые договоры · заказная разработка · цены и сроки