Сайт сделали, форму подключили. Кто теперь отвечает за 152-ФЗ: заказчик, разработчик или юрист?

Большинство проблем с персональными данными на сайте появляется не потому, что кто-то сознательно решил нарушить закон. Чаще каждый участник проекта уверен, что этим занимается другой.

Владелец бизнеса думает, что разработчик сдал готовый сайт. Разработчик считает, что юридические документы должен предоставить заказчик. Юрист готовит политику со слов владельца и не видит, что происходит внутри формы. Маркетолог подключает аналитику и новую CRM уже после запуска.

В итоге у сайта есть политика, форма и галочка. Но никто не может уверенно ответить на простые вопросы:

1. Какие данные сейчас собираются? 2. Куда они отправляются? 3. Какие сторонние сервисы получают доступ к странице? 4. Совпадает ли всё это с опубликованными документами?

Так кто всё-таки отвечает за 152-ФЗ?

Закон связывает роль оператора не с тем, кто написал код, а с тем, кто определяет цели обработки, состав данных и совершаемые с ними действия. Такое определение содержится в [статье 3 Федерального закона № 152-ФЗ].

Если компания размещает на своём сайте форму заявки и решает собирать через неё имена и телефоны клиентов, именно она, как правило, выступает оператором. Роскомнадзор также [относит владельца сайта, собирающего данные посетителей, к операторам персональных данных].

Передача технической работы студии, CRM или другому подрядчику не означает автоматическую передачу всей ответственности. Согласно части 5 статьи 6 закона, если обработка поручена другому лицу, ответственность перед субъектом персональных данных несёт оператор. Исполнитель отвечает перед оператором в рамках поручения и договора.

Но юридический ответ не решает практическую проблему. Владелец сайта может отвечать по закону и при этом не знать, что именно настроил подрядчик.

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

- зачем в форме запрашиваются имя, телефон, почта или другие сведения; - кому внутри компании доступна заявка; - какие подрядчики и сервисы участвуют в обработке; - сколько времени информация хранится; - что происходит после отзыва согласия; - соответствуют ли фактические процессы сведениям, переданным юристу и Роскомнадзору.

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

Но технически исправная форма ещё не означает, что её работа правильно описана и организована. Она может передавать заявку не только на корпоративную почту, но и в CRM, сервис сквозной аналитики, чат или систему автоматизации.

Разработчик не обязан самостоятельно становиться юристом заказчика. Он не должен придумывать цели обработки, определять правовое основание или обещать клиенту полное соответствие закону.

Но именно разработчик обычно видит техническую сторону процесса:

- какие поля есть в форме; - куда настроен запрос; - какие скрипты загружаются на странице; - установлена ли ссылка на нужный документ; - не отмечен ли чекбокс заранее; - добавлялись ли аналитика, виджеты, капча или внешняя CRM; - менялась ли конфигурация после запуска.

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

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

Юрист превращает бизнес-процесс и технические факты в документы и правовые решения. Он может определить подходящее основание обработки, проверить содержание согласия, политику, договоры с подрядчиками и сведения об операторе.

Но юрист не может описать то, о чём ему не сообщили.

Если в анкете указана только корпоративная почта, а форма фактически проходит через CRM и внешний сервис автоматизации, документ будет описывать неполную картину. Это не обязательно ошибка юриста. Возможно, исходные сведения уже были неверными.

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

Представим типичный, собирательный сценарий.

Владелец просит сделать форму обратного звонка. Студия подключает готовый модуль конструктора. Маркетолог добавляет аналитику. Через полгода CRM меняют, но старый интеграционный сервис оставляют. Затем юрист получает задачу «подготовить политику для сайта» и заполняет документ по анкете владельца.

Никто не пытается что-то скрыть. Просто у каждого своя версия системы:

- владелец видит бизнес-процесс; - разработчик видит код и настройки; - маркетолог видит рекламные инструменты; - юрист видит документы; - посетитель видит одну кнопку «Отправить».

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

Перед запуском сайта или новой формы я бы предложил фиксировать шесть вещей:

1. Страницу и назначение каждой формы.

2. Перечень запрашиваемых полей.

3. Адрес или сервис, куда направляется заявка.

4. Подключённые внешние инструменты.

5. Документ и основание, на которые ссылается форма.

6. Человека, который должен сообщать об изменениях.

После этого зоны работы становятся понятнее.

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

Это не гарантирует отсутствие любых нарушений. Но такой процесс хотя бы не строится на предположении, что соседний участник проекта уже всё проверил.

Я начал разрабатывать «Периметр», потому что заметил именно этот разрыв между документами и технической конфигурацией.

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

«Периметр» не назначает виновного и не заменяет юриста. Его задача скромнее: дать владельцу, разработчику и юристу одну картину сайта, которую можно обсуждать и исправлять.

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

Как эта ответственность распределяется у вас на практике?

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

Владельцы: вы считаете проверку 152-ФЗ частью разработки сайта или отдельной задачей бизнеса?

Юристы: хватает ли вам информации от клиента и разработчика, чтобы документы соответствовали реальному сайту?

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

#152фз #персональныеданные #вебразработка #вебстудия #малыйбизнес #юристы