Какие персональные данные собирает ваш сайт: аудит форм и счётчиков
Как найти все точки сбора данных на сайте, включая скрытые, и понять, что из этого требует согласия, политики и уведомления Роскомнадзора.
Содержание
Аудит персональных данных на сайте из 40 страниц занимает около 20 минут: выписать все формы, все счётчики и все сторонние виджеты, а потом посмотреть, куда каждый отправляет данные. Формой заявки список не ограничивается почти никогда.
Проверить сайт на персональные данные владельцы обычно решают в двух случаях: пришло письмо из Роскомнадзора или юрист контрагента спросил, где политика. Дальше выясняется неприятное: данные собирает далеко не одна форма заявки. Их собирает счётчик, виджет обратного звонка, чат в углу экрана, карта проезда и даже шрифты, которые подгружаются с чужого сервера. Ниже порядок, по которому я разбираю типовой сайт малого бизнеса: как за пару часов найти все точки сбора, включая скрытые, что из найденного требует согласия и политики, а что надо просто выкинуть.

Оговорюсь сразу: я не юрист, я инженер, который шесть лет обслуживает чужие сайты и регулярно разгребает последствия. Юридические формулировки для документов пусть пишет юрист. Моя часть техническая: найти, где именно данные собираются, куда уезжают и как это выключить или привести в порядок. Обычно после такого аудита у клиента остаётся список из 12-18 строк, из которых треть он видит впервые.
Что считается персональными данными на практике
В статье 3 закона 152-ФЗ определение размытое до неприличия: любая информация, относящаяся прямо или косвенно к определённому или определяемому физическому лицу. Слово «косвенно» тут главное, и именно оно ломает интуицию владельцев сайтов.
На практике для сайта услуг в список попадает:
- имя, фамилия, отчество в любом сочетании,
- телефон,
- электронная почта, если по ней можно понять человека (ivanov.a@company.ru вполне можно),
- адрес доставки или адрес объекта, куда выезжает мастер,
- дата рождения, ИНН, паспортные данные (в формах малого бизнеса встречаются чаще, чем хотелось бы),
- фотография человека,
- содержимое поля «опишите задачу», если человек написал там про себя,
- cookie и идентификатор посетителя, когда их можно связать с конкретной заявкой,
- IP-адрес в тех же условиях.
Про cookie и IP спорят с 2015 года. Позиция Роскомнадзора по совокупности сводится к простому: если по набору данных человека можно вычислить, это персональные данные. И на реальном сайте связка выстраивается сама собой. Метрика ставит _ym_uid, человек отправляет заявку с именем и телефоном, номер клиента попадает в CRM, а в CRM уже видно, с какой страницы он пришёл и что смотрел. Отдельно cookie обезличена, в связке с заявкой уже нет.
Отдельная категория, про которую забывают чаще всего. Если у вас медцентр, стоматология, юридическая или психологическая практика, то поле «с каким вопросом обращаетесь» собирает специальные категории данных: здоровье, судимость и прочее. Требования к ним жёстче, обычным чекбоксом это не закрывается.
Что персональными данными не является
- Обезличенная агрегированная статистика: 1 200 визитов за месяц, 30 процентов с мобильных.
- Данные юридического лица: ИНН ООО, адрес офиса, общий телефон приёмной, ящик info@.
- Ваши собственные реквизиты в футере. Хотя тут есть нюанс: если вы ИП, ваш адрес регистрации это ваши персональные данные, и публиковать домашний адрес в подвале сайта я никому не советую.
Инвентаризация: собираем список точек сбора
Аудит начинается не с DevTools, а со списка страниц. Берите sitemap.xml, выгружайте все URL и идите по ним глазами. На сайте из 40 страниц это 20 минут.
Явные точки сбора, которые надо выписать:
- форма заявки в первом экране,
- форма в модальном окне по кнопке «Оставить заявку» (она обычно живёт в подвале и есть на всех страницах сразу),
- форма на странице контактов,
- калькулятор с кнопкой «прислать расчёт на почту»,
- подписка на рассылку,
- комментарии в блоге,
- форма отзыва,
- регистрация и личный кабинет,
- корзина и оформление заказа,
- запись на приём или бронирование времени,
- отклик на вакансию (резюме это горсть персональных данных за один раз),
- лид-магнит вида «скачайте прайс, оставьте почту».
Важный момент, который путает почти всех: каждая форма это отдельная цель обработки. Заявка на услугу и подписка на рассылку не одно и то же, даже если поле одно и то же, почта. Из этого потом вырастает половина проблем с согласиями.
Что записывать по каждой форме: адрес страницы, полный список полей (включая скрытые), куда уходит отправка, кто получает письмо, сохраняется ли заявка в базе сайта.
Последний пункт владельцы обычно не знают. Contact Form 7 сам по себе ничего не хранит, но в паре с плагином Flamingo складывает все заявки в базу типом записи flamingo_inbound, и они там лежат годами. WPForms и Gravity Forms хранят всё по умолчанию. У меня был клиент, который искренне считал, что заявки живут только в почте, а в базе нашлось 4 600 записей с телефонами за пять лет.
Скрытые сборщики: то, что вы не заказывали
Дальше начинается интересное. Внешние скрипты собирают данные молча, и владелец сайта про половину из них не в курсе, потому что их поставил прошлый подрядчик или маркетолог.
Счётчики и аналитика. Яндекс Метрика ставит свои cookie и, если включён Вебвизор, пишет действия пользователя на странице. По умолчанию Вебвизор 2.0 не сохраняет содержимое полей ввода, но настройки сбиваются, а на кастомных формах поведение стоит проверять руками. Для гарантии есть классы ym-hide-content и ym-disable-keys, которые вешаются на блок с формой. Google Analytics в довесок к сбору даёт трансграничную передачу, о которой ниже.
Пиксели рекламных систем. Пиксель ВКонтакте, Top.Mail.Ru, старые остатки счётчика Facebook, которые до сих пор висят в шаблонах и стучатся в никуда. Каждый из них создаёт свой идентификатор посетителя.
Виджеты обратного звонка и коллтрекинг. Calltouch, Callibri, Comagic. Человек оставляет номер телефона, номер уходит на сервер сервиса, а не к вам. Это передача данных третьему лицу, и её надо оформлять поручением на обработку.
Онлайн-чаты. Jivo, виджет Битрикс24, чат из мессенджера. Собирают имя, телефон, почту и всю переписку, включая то, что клиент написал сгоряча.
Карты. Яндекс Карты в российском контуре вопросов не вызывают. Google Maps через iframe тянет данные посетителя на серверы за пределами РФ.
Шрифты. Классика жанра. Подключение вида fonts.googleapis.com отправляет IP каждого посетителя в Google при каждой загрузке страницы. Лечится переносом шрифтов на свой хостинг, попутно страница начинает грузиться быстрее.
Капча. Google reCAPTCHA собирает поведенческие данные и передаёт их за рубеж. Для формы малого бизнеса она избыточна, honeypot ловит ботов почти так же и никому ничего не передаёт.
Встроенные видео и кнопки соцсетей. YouTube ставит cookie ещё до нажатия play, если не использовать режим youtube-nocookie.com.
Сервис рассылок. Unisender, Sendsay, DashaMail. Ваша база подписчиков физически лежит у них, это тоже поручение обработки и тоже строка в аудите.
Отдельным пунктом держите в голове трансграничную передачу: всё, что уходит на серверы за пределами России, требует отдельного уведомления в Роскомнадзор до начала передачи, и подаётся оно до первого байта, а не постфактум.
Как проверить руками
Теория закончилась, дальше руки. Порядок такой.
Шаг 1. Сетевые запросы. Откройте сайт в режиме инкогнито, F12, вкладка Network, поставьте галку Disable cache, перезагрузите страницу. Отсортируйте по колонке Domain. Всё, что не ваш домен, выписывайте. Пройдите так по главной, странице услуги, странице контактов и по странице с формой заказа: наборы скриптов на них часто разные.
Шаг 2. Cookie. Вкладка Application, раздел Cookies. Смотрите на домен каждой куки. Свои начинаются с домена сайта, чужие сразу видно. Отдельно проверьте, ставится ли что-то до того, как посетитель нажал кнопку в cookie-баннере. Как правильно построить сам баннер и что в нём писать, разбирал в статье про cookie-баннер для российского сайта.
Шаг 3. Тестовая заявка. Заполните форму мусорными данными и отправьте, не закрывая Network. Смотрите на POST-запрос: куда он ушёл, какие поля улетели, нет ли параллельных запросов на сторонние домены в тот же момент. Тут вылезают неожиданности вроде дублирования заявки в чужую CRM, про которую владелец уже забыл.
Шаг 4. Поиск по файлам и базе. Дальше в консоль. Команды ниже для WordPress, но принцип одинаковый для любой CMS.
# все внешние домены, к которым обращается главная страница
curl -s https://example.ru/ | grep -oE 'https?://[a-zA-Z0-9.-]+' | sort -u
# формы в шаблонах темы
grep -rn "<form" wp-content/themes/ --include="*.php"
# сторонние скрипты в теме и плагинах
grep -rnE "(googletagmanager|google-analytics|mc.yandex|jivosite|calltouch|fonts.googleapis|recaptcha)"
wp-content/themes/ wp-content/plugins/ --include="*.php" --include="*.js"
Половина скриптов на живых сайтах вставлена не в шаблон, а через админку: виджет, поле «код в head» в настройках темы, плагин вставки скриптов. Поэтому обязательно смотрим базу.
# где спрятаны сторонние счётчики
wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%mc.yandex%' OR option_value LIKE '%googletagmanager%' OR option_value LIKE '%jivosite%';"
# сохранённые заявки Contact Form 7 через Flamingo
wp post list --post_type=flamingo_inbound --format=count
# комментарии хранят почту и IP автора
wp db query "SELECT comment_author_email, comment_author_IP, comment_date FROM wp_comments ORDER BY comment_date LIMIT 5;"
Для Битрикса смотрите таблицы b_form_result и b_form_result_answer (результаты веб-форм), b_event (отправленные письма с телом сообщения) и b_sale_order для магазина. Для Тильды всё проще и хуже одновременно: заявки лежат в личном кабинете Тильды на их серверах, и это тоже надо отражать в документах.
И последнее место, про которое забывают: логи веб-сервера. access.log пишет IP каждого посетителя. У большинства хостингов они хранятся 30-60 дней и ротируются, но если админ когда-то отключил ротацию, у вас на диске лежит история IP за три года.
Таблица аудита
Все находки сводятся в одну таблицу. Это не бюрократия ради бюрократии: без неё вы не составите нормальную политику и не ответите на запрос Роскомнадзора. Мой рабочий формат для сайта услуг:
| Точка сбора | Поля | Цель | Основание | Срок хранения | Куда уходит |
|---|---|---|---|---|---|
| Форма в модалке | имя, телефон, комментарий | обработка заявки | согласие, чекбокс | 1 год | почта владельца, Telegram |
| Форма на /contacts/ | имя, телефон, почта | обработка заявки | согласие, чекбокс | 1 год | почта владельца |
| Подписка на рассылку | почта | рекламная рассылка | отдельное согласие | до отписки | Unisender |
| Комментарии в блоге | имя, почта, IP | публикация комментария | согласие | бессрочно, нужен срок | база сайта |
| Отзыв на сайте | имя, город, фото | публикация на сайте | согласие на распространение | до отзыва согласия | база сайта |
| Яндекс Метрика | cookie, IP, поведение | веб-аналитика | согласие в баннере | по правилам сервиса | Яндекс, РФ |
| Виджет звонка | телефон | обратный звонок | согласие, поручение | по договору | сервис коллтрекинга |
| Google Fonts | IP | ничего полезного | нет | нет | Google, за рубеж |
| access.log | IP, user-agent | техническая | законный интерес | 60 дней | хостинг |
Колонка «основание» самая полезная. Если в ней пусто или стоит вопрос, у вас проблема ровно в этой строке. Строка про Google Fonts в примере не выдумана, она встречается у меня в каждом втором аудите: данные утекают, пользы ноль, чинится за 20 минут.
Колонка со сроком хранения отвечает на вопрос, который часто задают на проверке. По части 7 статьи 5 закона данные хранятся не дольше, чем требуют цели обработки. Заявка пятилетней давности цели уже не служит.
Что делать с находками
По каждой строке таблицы решение одно из трёх.
Убрать. Самое приятное и самое дешёвое. Google Fonts переносим на свой сервер. reCAPTCHA меняем на honeypot. Мёртвый пиксель Facebook, который никто не открывал с 2022 года, вырезаем. Поле «дата рождения» в форме заявки на ремонт кондиционера убираем, потому что мастеру она не нужна: часть 5 статьи 5 требует, чтобы объём данных соответствовал целям, а лишнее поле это лишняя ответственность и минус к конверсии заодно.
Узаконить. То, что реально нужно бизнесу, остаётся, но получает основание. Чекбокс с рабочей ссылкой на политику, упоминание в самой политике, при передаче третьему лицу договор поручения. Общая логика требований к сайту разложена в разборе про 152-ФЗ для сайта малого бизнеса.
Ограничить. Данные собираются, но урезаем срок и доступ. Заявки старше года чистим по расписанию, IP в комментариях перестаём писать, доступ к базе есть у двух человек, а не у пяти.
Дальше три технических дела, которые обычно всплывают следом:
- Уведомление в Роскомнадзор о начале обработки. Сейчас его подаёт практически любой оператор, включая ИП с одной формой обратной связи на сайте-визитке. Ориентир по штрафу за неподанное уведомление: десятки тысяч рублей для должностного лица и ИП, до сотен тысяч для юрлица. Порядок подачи и что писать в полях разбирал в материале про уведомление РКН об обработке ПД.
- Локализация. Запись, систематизация и хранение данных граждан России должны выполняться на серверах в РФ. Практический вывод для сайта: хостинг российский, CRM российская, облачная таблица с лидами на зарубежном сервисе это риск.
- План на случай утечки. Уведомить регулятора о факте инцидента надо в течение 24 часов, а результаты внутреннего расследования отправить в течение 72 часов. Придумывать процесс в момент инцидента поздно.
Когда одного чекбокса мало
Самая частая ошибка после аудита: владелец лепит один универсальный чекбокс на все случаи и считает вопрос закрытым. Не закрытым. Отдельные согласия нужны минимум в трёх ситуациях.
Реклама и рассылка. Закон о рекламе требует предварительного согласия абонента на получение рекламы. Согласие на обработку заявки этого не покрывает. Практическое решение: второй чекбокс, необязательный, отдельным текстом. Обязательным его делать нельзя, иначе это уже не свободное волеизъявление.
Публикация отзыва с именем и фото. Это распространение персональных данных, статья 10.1. Согласие на распространение оформляется отдельно от других согласий, общим чекбоксом в форме заявки его не подменить. Если собираете отзывы с фотографиями клиентов, нужен отдельный документ.
Специальные категории. Здоровье, вероисповедание, судимость. Тут требования к форме согласия жёстче, и общая галочка не подходит.
Что должно быть написано рядом с чекбоксом в любом случае: кому даётся согласие (полное наименование и адрес оператора в политике), для какой цели, какие данные, на какой срок и как согласие отозвать. Формулировки и готовая структура текста разобраны в статье про согласие на обработку ПД.
Техническая деталь, на которой ловятся многие: чекбокс не должен быть отмечен заранее. Предзаполненная галочка это не согласие, а имитация. То же самое с фразой «нажимая кнопку, вы соглашаетесь» без явного действия: как единственный механизм для обычной формы заявки я бы на неё не полагался.
Чек-лист аудита на один вечер
Пробегитесь по пунктам, отмечая факты, а не ощущения:
- Выгружен список всех страниц из sitemap, формы найдены и посчитаны.
- По каждой форме известен полный список полей, включая скрытые.
- Проверено, сохраняются ли заявки в базе сайта и сколько их там.
- Собран список всех внешних доменов из вкладки Network на четырёх разных страницах.
- Проверено, какие cookie ставятся до взаимодействия с баннером.
- Отправлена тестовая заявка с наблюдением за сетевыми запросами.
- Выполнен поиск по шаблонам и базе на предмет чужих скриптов.
- Проверены логи сервера: пишутся ли IP и как долго хранятся.
- Заполнена таблица аудита, в колонке «основание» нет пустых ячеек.
- Определён срок хранения для каждого массива и настроена чистка старого.
- Проверено, что ссылки в чекбоксах ведут на живые страницы, а не на 404.
- Проверено, подано ли уведомление в Роскомнадзор и совпадают ли в нём цели с реальностью.
Если в списке набралось больше трёх незакрытых пунктов, это нормальное состояние сайта, который никто не аудировал. Ненормально оставлять их незакрытыми, зная о них.
С чего начать завтра
Начните с пункта 4: вкладка Network и список внешних доменов. Это 15 минут, а находки обычно самые обидные, потому что половина скриптов не приносит бизнесу ничего и висит по инерции. Дальше по таблице сверху вниз.
Аудит форм и счётчиков у меня входит в абонентское обслуживание и делается раз в год плюс после любых изменений на сайте, состав пакетов и цены смотрите в тарифах. Разовой задачей аудит тоже берётся: на типовой сайт услуг уходит 3-5 часов, на выходе таблица со всеми точками сбора, список того, что нужно вырезать, и техническое задание для юриста по документам. Что именно не входит в такую работу: разработка сайта с нуля и составление самих юридических текстов, документы должен подписывать юрист.
Если пришло требование от Роскомнадзора и время уже идёт, пишите через форму на главной и укажите срок ответа в первом же сообщении. Такие задачи я ставлю в очередь вперёд плановых.
Частые вопросы
Как проверить, какие данные собирает сайт
Пройти по трём слоям. Формы, включая обратный звонок и подписку. Счётчики и рекламные пиксели. Сторонние виджеты: чат, карта, отзывы, оплата. Каждый из них может уводить данные наружу незаметно.
Считаются ли cookie и IP персональными данными
Практика спорит об этом с 2015 года. Безопаснее считать, что да, когда их можно связать с конкретным человеком. Обезличенная статистика вида 1 200 визитов за месяц под это не подпадает.
Что делать с находками аудита
Лишнее убрать, нужное описать в политике и в согласии, зарубежное либо заменить на российское, либо уведомить о трансграничной передаче. Каждой точке сбора нужны цель, основание и срок хранения.
Хватит ли одного чекбокса согласия
Не хватит, если данные уходят третьим лицам или за границу. Тогда нужно отдельное согласие с перечнем получателей, а не общая галочка про обработку персональных данных.