Аудит сайта на соответствие 152-ФЗ: формы, согласия и политика
Технический аудит помогает собрать наблюдаемые признаки обработки персональных данных: какие сведения запрашиваются, куда они отправляются, какие документы показаны пользователю и какие сторонние сервисы загружаются. Это исходные данные для последующей юридической проверки, а не заключение о законности обработки.
Что именно нужно обнаружить
Персональные данные появляются на сайте не только в форме регистрации. Имя, телефон, адрес электронной почты, данные заказа, резюме, текст обращения и прикрепленный файл могут относиться к человеку прямо или косвенно. Технические идентификаторы, передаваемые системам аналитики, рекламы или поддержки, также требуют внимания в контексте всей обработки.
Поэтому аудит сайта на соответствие 152 фз начинают не с поиска одной галочки, а с инвентаризации всех точек сбора и передачи данных. Проверять следует основной домен, поддомены, мобильную версию, всплывающие окна и формы, открывающиеся после действий пользователя.
Задача технического этапа — зафиксировать факты: поле присутствует, запрос уходит на определенный адрес, ссылка на документ доступна, переключатель установлен заранее. Определять достаточность правового основания, корректность формулировок и обязанности оператора должен профильный специалист с учетом реальных процессов организации.
Диагностический алгоритм
1. Составить карту пользовательских сценариев
Обойдите страницы как новый посетитель и выпишите все действия, при которых можно передать информацию: обратный звонок, заявка, заказ, подписка, регистрация, комментарий, чат, отклик на вакансию, загрузка файла. Отдельно проверьте формы в шапке, подвале, модальных окнах и виджетах.
Для каждой точки запишите URL, назначение формы, перечень обязательных и необязательных полей, текст рядом с кнопкой и ссылку на документ. Сделайте снимок экрана до отправки и после нее: интерфейс может меняться в зависимости от состояния формы.
2. Проследить сетевые запросы
Откройте инструменты разработчика браузера, вкладку Network, очистите журнал и отправьте тестовую форму с безопасными вымышленными значениями. Зафиксируйте домен получателя, путь запроса, метод, названия передаваемых параметров и сторонние запросы, возникающие после отправки.
Не публикуйте в отчете токены, идентификаторы сессий и введенные значения. Достаточно указать тип данных и технический маршрут. Если сведения уходят не только на домен сайта, сопоставьте получателей с CRM, аналитикой, коллтрекингом, рассылкой, чатом или антиспам-сервисом.
3. Проверить механику согласия
Определите, показывается ли пользователю понятное действие, связанное с передачей данных. Проверьте состояние чекбокса при первой загрузке, возможность отправить форму без него, наличие ссылки на актуальный текст и поведение формы при снятой отметке.
Предустановленная галочка, ссылка без подписи «согласие» или общий текст, объединяющий разные цели, — признаки для юридической оценки. Само наличие чекбокса не подтверждает соблюдение требований: согласие должно рассматриваться вместе с целью, составом данных, способом фиксации и другими основаниями обработки.
4. Сопоставить формы с политикой
Откройте политику обработки персональных данных и проверьте, доступна ли она без авторизации, читается ли на мобильном устройстве и относится ли к фактическому владельцу сайта. Сопоставьте описанные категории данных и цели с каждой найденной формой.
Отдельно отметьте оператора, контакт для обращений, порядок отзыва согласия, сведения о применяемых внешних сервисах и дату либо версию документа, если она указана. Несовпадение названия организации в политике и реквизитов сайта — существенный сигнал для ручной проверки.
5. Исследовать загрузку сторонних ресурсов
Перезагрузите страницу в чистом профиле браузера и изучите запросы до любого взаимодействия с баннером или формой. Составьте список внешних доменов, cookies, localStorage и сценариев, которые запускаются автоматически. Затем повторите проверку после выбора доступных настроек.
По одному имени файла нельзя надежно определить назначение обработки. Связывайте технический след с документацией подключенного сервиса, настройками проекта и договорной схемой. Неизвестный домен следует вынести в отдельный список, а не автоматически считать нарушением.
Чек-лист проверяемых критериев
| Объект | Что проверить | Что сохранить в отчете |
|---|---|---|
| Формы | Все поля, обязательность, вложения, скрытые параметры | URL, сценарий, снимок экрана, перечень данных |
| Согласие | Исходное состояние, связь с отправкой, доступность текста | Формулировка, ссылка, результат попытки без отметки |
| Политика | Доступность, оператор, цели, категории данных, контакты | URL, версия или дата, обнаруженные расхождения |
| Сеть | Адресаты запросов и момент передачи | Домены, типы параметров, последовательность событий |
| Хранилища браузера | Cookies и localStorage до и после выбора пользователя | Имена, домены, срок хранения, момент создания |
| Внешние сервисы | Чаты, аналитика, CRM, карты, видео, антиспам | Название интеграции и подтвержденное назначение |
Типовые ошибки
- Проверена только страница контактов. Формы могут находиться в каталоге, личном кабинете, виджетах и всплывающих окнах.
- Политика существует, но недоступна из формы. Пользователь видит документ только после отправки либо получает ошибку перехода.
- Чекбокс установлен заранее. Интерфейс не фиксирует отдельного активного действия пользователя.
- Документ и интерфейс расходятся. Форма собирает телефон или файл, которого нет среди описанных категорий.
- Не учтены сторонние получатели. Запрос принят сайтом, но одновременно данные передаются виджету или системе автоматизации.
- Отчет содержит реальные персональные данные. Диагностику следует проводить на тестовых значениях с минимальным объемом информации.
- Наличие HTTPS принимается за полное соответствие. Шифрование соединения важно, но не отвечает на вопросы о целях, основаниях и составе обработки.
Как оформить результат для юриста
Удобная единица отчета — отдельный сценарий. Для него указывают страницу, действие пользователя, состав полей, получателей сетевых запросов, состояние согласия, связанные документы и приложенные доказательства. Наблюдения отделяют от выводов: «запрос отправлен на внешний домен» — факт, а роль владельца этого домена требует проверки.
Добавьте перечень вопросов, которые невозможно закрыть через публичный интерфейс: где хранятся заявки, кто имеет к ним доступ, как фиксируется согласие, когда удаляются записи, какие договоры заключены с подрядчиками. Такой формат сокращает разрыв между осмотром сайта и анализом внутренних процессов.
Границы метода
Проверка публичного URL не показывает конфигурацию CMS, серверные журналы, базы данных, права сотрудников, резервные копии и внутренний документооборот. Она также не устанавливает правовое основание обработки и не подтверждает исполнение всех обязанностей оператора.
SiteVisor анализирует доступный извне URL и собирает технические, SEO/GEO и конверсионные сигналы. Результат может помочь обнаружить страницы, формы и публичные несогласованности, но не заменяет ручную инвентаризацию интеграций, проверку внутренних систем и юридическое заключение.
Итог
Практический аудит строится вокруг четырех связей: форма и собираемые данные, действие пользователя и согласие, фактическая передача и получатель, интерфейс и политика. Чем точнее зафиксированы эти связи, тем меньше предположений останется на юридическом этапе.
Начните с полного перечня сценариев, проверьте сетевые события и документы, затем передайте структурированный отчет специалисту по персональным данным. Для первичного осмотра публичных сигналов можно запустить бесплатную проверку SiteVisor.