Что сайт на самом деле делает с данными посетителей: технический чек-лист по 152-ФЗ

На сайте может быть политика обработки персональных данных, уведомление о cookie и аккуратный чекбокс под формой. Но эти элементы не отвечают на главный практический вопрос: что происходит после того, как посетитель вводит телефон и нажимает «Отправить»?

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

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

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

> Коротко: документы описывают, как обработка должна быть организована. Техническая проверка показывает, что доступная часть сайта делает фактически. Эти два слоя нужно сопоставить, а значимые выводы проверить вручную.

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

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

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

Начните с инвентаризации. На сайте может быть не одна форма, а несколько вариантов одного сценария:

- обратный звонок в шапке;

- заявка на странице услуги;

- подписка на рассылку;

- вопрос специалисту;

- оформление заказа;

- форма внутри всплывающего окна;

- отдельная мобильная версия.

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

«Периметр» начинает с главной страницы, sitemap и внутренних ссылок. Он фиксирует найденные формы и их поля.

Под формой нужно смотреть не только на наличие галочки. Важны состояние и контекст элемента:

- не выбран ли чекбокс заранее;

- может ли пользователь отправить форму без действия с его стороны;

- понятно ли, на что именно он соглашается;

- открывается ли связанный документ;

- относится ли ссылка к владельцу проверяемого сайта;

- не смешаны ли разные согласия в одной общей фразе.

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

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

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

Проверка должна ответить на несколько вопросов:

1. Возвращает ли ссылка рабочую страницу, а не ошибку 404.

2. Можно ли прочитать документ без регистрации.

3. Совпадает ли указанный оператор с владельцем сайта.

4. Описаны ли формы, цели и категории данных, которые наблюдаются на сайте.

5. Упомянуты ли используемые подрядчики и внешние сервисы, когда это необходимо.

6. Не противоречат ли друг другу политика, согласие и фактическая форма.

«Периметр» извлекает доступный текст HTML и PDF, ищет реквизиты и тематические разделы. Но наличие ключевых слов не доказывает юридическую достаточность документа.

Этот пункт часто даёт владельцу сайта больше новой информации, чем проверка подвала и чекбокса.

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

Однако здесь особенно важно не перепутать наблюдение с выводом. Адрес запроса показывает технический маршрут, но не доказывает место хранения базы данных. IP-адрес может принадлежать CDN, а запрос к российскому домену может дальше обрабатываться другими системами.

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

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

Современная страница редко загружает данные только со своего домена. На ней могут работать:

- системы аналитики;

- рекламные пиксели;

- онлайн-чаты;

- карты;

- виджеты обратного звонка;

- внешние шрифты;

- CAPTCHA;

- системы A/B-тестирования.

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

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

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

Обычная загрузка HTML не всегда показывает то, что видит посетитель. Форма может создаваться JavaScript только после клика, выбора города или открытия модального окна.

Поэтому у проверки должно быть как минимум два режима. Первый анализирует публично доступный HTML, ссылки, DNS, TLS и заголовки. Второй использует браузер и проверяет безопасные элементы интерфейса.

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

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

Это один из главных принципов «Периметра»: неопределённость нужно показывать, а не прятать за зелёной оценкой.

Автоматизация хорошо собирает повторяющиеся технические признаки. Но она не знает полный контекст бизнеса.

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

Поэтому значимые находки «Периметра» сначала попадают в рабочую ревизию. Оператор подтверждает или исключает каждую из них. Исключение требует короткой причины, а сохранённые решения остаются в истории.

Только после ревизии формируется клиентский отчёт. В нём должны быть разделены:

- наблюдаемый факт;

- место обнаружения;

- доказательство;

- уровень уверенности;

- вопрос, требующий юридической оценки;

- техническая рекомендация;

- область, которую проверить не удалось.

Такая структура полезнее автоматического вердикта «соответствует» или «не соответствует».

Без специального инструмента владелец сайта может выполнить базовую проверку:

1. Открыть все формы в обычном и мобильном режиме.

2. Выписать поля и назначение каждой формы.

3. Проверить исходное состояние чекбоксов.

4. Открыть каждую ссылку на политику и согласие.

5. Сравнить название оператора в документах с фактическим владельцем.

6. Спросить разработчика, куда отправляется каждая заявка и какие внешние сервисы подключены.

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

После любых исправлений проверку нужно повторить. Удалённый виджет может оставить старый скрипт, новая форма может не получить ссылку на документ, а обновление шаблона способно вернуть прежнюю настройку.

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

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

Мне также важна обратная связь: каких данных вам не хватило бы в таком отчёте и что должно быть в нём, чтобы вы доверяли результату?

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