Сайт и 152-ФЗ: формы, согласия и проверка на соответствие

Коротко

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

Проверку можно начать самостоятельно за один-два дня: составить реестр форм, пройти каждую глазами посетителя, посмотреть, куда уходят письма и заявки, и сверить тексты документов. Юридическую оценку текстов делает юрист, а техническую часть — формы, хранение, скрипты, доступы — разработчик. Ниже разобран порядок работы и типичные находки на WordPress и 1С-Битрикс.

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

Основная мысль

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

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

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

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

Что такое персональные данные на сайте

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

Данные, которые посетитель вводит сам

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

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

Данные, которые собираются автоматически

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

Где эти данные оказываются дальше

Заявка с сайта редко остаётся на сайте. Она уходит письмом на почту, попадает в CRM, в 1С, в мессенджер менеджера, в таблицу. Каждое такое место — часть обработки персональных данных, и его нужно учитывать при проверке. Подробно о маршрутах заявок написано в статье о том, как настроить приём заявок с сайта.

Аудит сайта по 152: пошаговый план

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

Шаг 1. Реестр форм

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

Для каждой формы зафиксируйте:

  1. Страницу или шаблон, где она выводится.
  2. Какие поля в ней есть и какие из них обязательные.
  3. Куда уходят данные: письмо, CRM, база сайта, сторонний сервис.
  4. Есть ли чекбокс или другая форма согласия и ссылка на документы.
  5. Кто в компании получает и читает эти заявки.

Шаг 2. Проверка поведения форм

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

Шаг 3. Инвентаризация скриптов

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

Шаг 4. Хранение и доступы

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

Шаг 5. Сверка документов

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

Шаг 6. План исправлений

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

Формы и согласие: как должно выглядеть

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

Что проверить в каждой форме

  • Чекбокс согласия не отмечен заранее: посетитель ставит галочку сам.
  • Без согласия форма не отправляется, и посетитель видит понятное сообщение об этом.
  • Рядом с чекбоксом есть ссылка на текст согласия и на политику, ссылки открываются.
  • Текст согласия описывает именно эту форму: её цели и поля.
  • Форма не спрашивает лишнего: если для звонка нужен телефон, фамилия и почта не нужны.

Несколько форм с разными целями

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

Формы на WordPress

На WordPress формы чаще всего сделаны через Contact Form 7, WPForms или конструктор темы. В Contact Form 7 чекбокс согласия добавляется тегом acceptance: пока он не отмечен, кнопка отправки неактивна. В других плагинах есть аналогичное поле согласия или обязательный чекбокс. Проверьте также формы, которые выводит тема или конструктор страниц, — их часто забывают, потому что они не видны в списке форм плагина. Про настройку отправки подробно написано в статье о том, как сделать форму обратной связи на WordPress.

Отдельный пункт — комментарии. Стандартная форма комментариев WordPress собирает имя, почту и IP-адрес. Если комментарии на сайте не нужны, их проще отключить в настройках обсуждения, чем приводить форму в порядок.

Формы на 1С-Битрикс

В 1С-Битрикс формы строятся на модуле веб-форм, на инфоблоках или на собственных компонентах шаблона. В стандартных компонентах есть параметр согласия с выбором текста соглашения, а сами соглашения создаются в настройках главного модуля. Если форма сделана на кастомном компоненте, согласие нужно добавлять в код. Форма оформления заказа магазина — отдельный компонент, и её проверяют отдельно.

Документы на сайте

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

Политика обработки персональных данных

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

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

Текст согласия

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

Уведомление о cookie

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

Уведомление Роскомнадзора

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

Сторонние сервисы и трансграничная передача

Счётчики, чаты, капча и шрифты загружаются с чужих серверов. Каждый такой сервис получает как минимум IP-адрес посетителя, а некоторые — содержимое форм и переписки.

Какие сервисы искать

Тип сервисаЧто может передаватьсяЧто сделать
Системы аналитикиСведения о визитах, cookieОписать в политике, проверить настройки
Онлайн-чатыПереписка, имя, телефонПроверить, где хранятся данные сервиса
КапчаIP-адрес, поведение на страницеВыбрать сервис, размещённый в России
Шрифты и библиотеки с внешних CDNIP-адресПодключить локально с сервера сайта
Рекламные пикселиСведения о визитах и конверсияхОписать в политике, убрать ненужные

Зарубежные сервисы

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

Яндекс Метрика и цели

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

Хранение данных и безопасность

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

Где хранятся заявки

  • База сайта. Многие плагины форм на WordPress сохраняют заявки в базу, в 1С-Битрикс результаты веб-форм тоже хранятся в базе. Проверьте, сколько лет накоплено и нужны ли эти записи.
  • Почта. Заявки в личных ящиках сотрудников на бесплатных почтовых сервисах — частая находка. Лучше завести корпоративный ящик и настроить доступ по ролям.
  • Файлы. Резюме и документы из форм иногда лежат в папке загрузок с открытым доступом по прямой ссылке. Такие файлы нужно закрыть от прямого доступа.
  • Резервные копии. Бэкапы содержат ту же базу, и хранить их нужно так же аккуратно.

Сроки хранения

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

Доступы и техническая защита

  1. Удалить учётные записи бывших сотрудников и подрядчиков из админки, хостинга и сервисов.
  2. Включить HTTPS на всём сайте, без смешанного содержимого.
  3. Обновить ядро, тему и модули, закрыть известные уязвимости.
  4. Настроить сложные пароли и, где возможно, двухфакторную авторизацию.
  5. Проверить, что хостинг находится в России и имеет понятные условия по защите данных — критерии выбора разобраны в статье о хостинге для WordPress и 1С-Битрикс.

Особые случаи

Интернет-магазин

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

Личный кабинет

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

Формы во внешних сервисах

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

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

Сайт, переехавший с конструктора

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

На чём опасно экономить

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

  • Одна ссылка на политику в подвале вместо согласия у каждой формы.
  • Чекбокс согласия, отмеченный заранее.
  • Шаблон политики, скачанный из интернета и не отредактированный под сайт.
  • Забытые формы: старые лендинги, всплывающие окна, квизы в отдельных сервисах.
  • Заявки, которые копятся в базе сайта годами без очистки.
  • Файлы из форм, доступные по прямой ссылке.
  • Администраторы, которые давно не работают с компанией.
  • Внешние шрифты, капча и виджеты, про которые никто не помнит.

Чек-лист проверки

  1. Составлен реестр всех форм с полями и получателями данных.
  2. В каждой форме есть неотмеченный чекбокс согласия и ссылки на документы.
  3. Форма не отправляется без согласия.
  4. Формы собирают только необходимые поля.
  5. Политика опубликована, доступна и описывает реальные цели и сервисы.
  6. Текст согласия оформлен отдельно и соответствует формам.
  7. Составлен список внешних скриптов, ненужные удалены.
  8. Шрифты и библиотеки по возможности подключены локально.
  9. Определено, где хранятся заявки, настроен срок хранения.
  10. Файлы из форм закрыты от прямого доступа.
  11. Лишние учётные записи удалены, пароли обновлены.
  12. Сайт работает по HTTPS, ядро и расширения обновлены.
  13. Документы и уведомление сверены с юристом.

Частые вопросы

Что входит в аудит сайта по 152-ФЗ?

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

Можно ли проверить сайт самостоятельно?

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

Достаточно ли ссылки на политику в подвале?

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

Нужно ли согласие для формы подписки?

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

Можно ли поставить галочку согласия заранее?

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

Какие сервисы на сайте передают данные за рубеж?

Чаще всего это зарубежные шрифты с внешних CDN, капча, некоторые чаты, аналитика и рекламные пиксели. Точный список показывает инвентаризация скриптов.

Где должны храниться данные с сайта?

При сборе данные граждан России записываются в базы на территории России. Проверьте, где расположены хостинг, CRM и почтовый сервис.

Нужен ли баннер про cookie?

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

Как часто повторять проверку?

После каждого заметного изменения: новой формы, нового сервиса, редизайна, переезда. Без изменений — примерно раз в год.

Сколько занимает аудит сайта по 152?

Для небольшого сайта техническая часть вместе с исправлениями занимает от 3 рабочих дней. Для интернет-магазина с личным кабинетом и интеграциями — дольше, в зависимости от числа форм и сервисов.

Итог

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

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

Если нужна техническая проверка сайта перед сверкой с юристом, я как частный разработчик проведу аудит сайта на WordPress или 1С-Битрикс: составлю реестр форм и сервисов, проверю согласия, хранение и доступы и исправлю найденное. Работаю напрямую, без посредников.

Что будем искать? Например,Продвижение