NDA не спасет: поручение на обработку персональных данных с разработчиком-подрядчиком

Статья 6 (ч. 3) 152-ФЗ разрешает оператору передать обработку персональных данных другой компании, но при двух условиях: согласие субъекта и договор с обязательными пунктами. На практике эти два условия редко проверяют, когда речь идет о разработке сайта, CRM или мобильного приложения.

Типичная картина: подрядчик делает портал на 1С-Битрикс, получает доступ к рабочему серверу, ему присылают дамп базы для настройки интеграции с 1С, тестировщик выгружает реальные карточки клиентов. В договоре при этом одна строчка — «оказание услуг по разработке». Юридически доступа к данным у подрядчика нет, а ответственность за все, что происходит на сервере заказчика, лежит на заказчике.

Поручение на обработку — не отдельная бумажка для проверки. Это приложение к договору подряда с конкретным периметром данных, целями и обязанностью удалить или вернуть персональные данные по окончании работ. Без него оператор перед Роскомнадзором отвечает сам, а разработчик не отвечает ничем.

Правовая рамка: что говорит 152-ФЗ

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

Часть 3 статьи 6 требует, чтобы поручение было оформлено договором, и перечисляет условия, которые должны в него войти:

• перечень действий с персональными данными;

• цели обработки;

• обязанность соблюдать конфиденциальность;

• требования по защите данных из статьи 19;

• обязанность по запросу оператора сообщать сведения об обработке;

• обязанность уничтожить или вернуть данные после окончания договора.

Часть 2 статьи 28 требует, чтобы поручение было письменным, а его форма закреплена в локальном акте оператора.

Смысл для читателя простой: нет обязательного условия — поручение недействительно. Подрядчик работает с данными без правового основания, а штраф по статье 13.11 КоАП получает оператор.

Когда нужен документ, а когда хватит NDA

Здесь чаще всего путаются, поэтому разделим три документа.

NDA, соглашение о конфиденциальности. Запрещает разглашать сведения. Не легализует обработку персональных данных. NDA не заменяет поручение: он защищает коммерческую тайну, а не дает правовое основание работать с базой клиентов.

Договор подряда или оказания услуг. Регулирует работы, сроки, приемку, оплату. Без приложения о персональных данных он не закрывает требования части 3 статьи 6.

Поручение на обработку. Приложение к договору, которое делает обработку законной и описывает, какие данные, зачем и в каком объеме подрядчик видит.

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

Кто такой разработчик-подрядчик и чем он рискует вместе с вами

В схеме три роли. Оператор — заказчик, который определяет цели обработки. Подрядчик — обработчик по поручению. Субподрядчик — если разработчик привлекает фрилансеров или смежную команду. Цепочка поручений должна читаться: подрядчик вправе передать данные дальше, только если это разрешено и описано.

Разработка отличается от других услуг тем, что доступ к данным возникает по ходу работ, часто вне графика:

• доступ к продуктивному серверу и базе для отладки и переноса;

• тестовые дампы с реальными данными — классический источник утечек;

• удаленная работа и личные ноутбуки разработчиков;

• CI/CD-пайплайны, где данные оседают в логах сборки и артефактах.

Для оператора последствия: штраф по статье 13.11 КоАП, отдельная ответственность за утечку по частям 10–11 той же статьи (оборотные штрафы), репутационные потери и невозможность взыскать ущерб с подрядчика, если в договоре его обязанности не прописаны. Без поручения требовать нечего: подрядчик не нарушал ни условия договора, ни закон — он просто работал с данными, которые ему не передавали.

Структура поручения: обязательные и рекомендуемые блоки

Обязательное, прямо из части 3 статьи 6:

• перечень персональных данных — категории субъектов и состав полей;

• цели обработки, и не общие, а конкретные: разработка, тестирование, сопровождение, перенос на новую платформу;

• перечень операций — только те, что нужны для этих целей;

• обязанность соблюдать конфиденциальность;

• меры защиты по статье 19: правовые, организационные, технические;

• обязанность по запросу оператора сообщать, что и как он обрабатывает;

• срок действия и порядок уничтожения или возврата данных.

Рекомендуемое, то, что добавляет практика и снижает риск:

• запрет передавать данные третьим лицам без письменного согласия оператора и порядок согласования субподрядчиков;

• локализация баз и запрет трансграничной передачи;

• запрет использовать реальные данные в тестовых средах, обязанность обезличивать дампы;

• срок уведомления об инциденте, например 24 часа;

• право оператора проверить меры защиты;

• ответственность подрядчика: неустойка, возмещение убытков, регресс, если штраф заплатил оператор;

• порядок действий при расторжении: удаление данных и акт об уничтожении.

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

Чек-лист оформления

1. Составьте список данных, которые реально увидит подрядчик: категории субъектов, поля, объем, срок.

2. Решите, нужен ли доступ к продуктиву. Если нет — зафиксируйте обезличивание и запрет доступа.

3. Включите раздел о персональных данных в договор или оформите отдельное приложение-поручение с реквизитами договора.

4. Впишите субподрядчиков и порядок их согласования, включая фрилансеров.

5. Подпишите поручение до начала работ и до выдачи доступов, а не после.

6. Закрепите форму поручения в локальном акте оператора (часть 2 статьи 28).

7. По завершении получите акт уничтожения данных и закройте доступы, включая ключи, токены и доступы к репозиториям.

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

Типичные ошибки

Поручение подписано задним числом, после старта работ и выдачи доступов. Формально даты сходятся, фактически обработка без основания велась месяц.

Цель сформулирована как «оказание услуг». Так не проходит: часть 3 статьи 6 требует конкретных целей обработки. «Услуги» — это предмет договора, а не цель работы с данными.

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

Субподрядчики не упомянуты, а реальные данные уходят через фрилансеров, которых подрядчик привёл на этап верстки или тестирования.

Есть NDA, нет поручения. Оператор считает вопрос закрытым. Проверка Роскомнадзора видит только договор об оказании услуг и отсутствие правового основания.

Ответственность и споры

Перед субъектом данных и перед Роскомнадзором отвечает оператор: так устроены часть 3 статьи 6 и статья 13.11 КоАП. Ссылка на подрядчика не помогает — регулятор работает с тем, кто определил цели обработки.

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

Для госзаказа и компаний с закупками по 44-ФЗ и 223-ФЗ добавляется еще один слой: поручение входит в составление документации и проверяется на этапе приемки. Фиксированная цена контракта не освобождает от обязанности закрыть требования по персональным данным.

Заключение

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

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

Команда MACHAON ведет проекты на 1С-Битрикс, PHP и Laravel с оформлением поручения на обработку персональных данных, разграничением доступов и актом уничтожения данных по завершении работ. Если по вашим текущим договорам с разработчиками такого приложения нет — начните с аудита доступа: кто, к каким базам и на каком основании заходит.