Как запрашивать персональные данные на сайте: требования 2025

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

Что считается ПДн на сайте

ПДн – это не только поле «Имя». Это любые сведения, позволяющие идентифицировать пользователя: ФИО, телефон, e-mail, IP, заявки, сообщения в чатах. В практическом смысле ПДн собираются повсюду: в заявках и поп-апах, в квизах и виджетах, в обратном звонке и веб-формах, в комментариях и CRM-интеграциях. Если на сайте собираете номера телефонов или e-mail – это персональных. И важно заранее понимать, какие поля действительно нужны бизнесу.

Зона ответственности и ожидания аудитории

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

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

• Следить за рисками при передаче данных подрядчикам и в сторонние сервисы.

• Для образовательных и гос-сайтов требования строже – там применяются дополнительные нормы и проверки.

• Запланировать назначение ответственных ролей и процессы еще до «боевого» запуска форм – иначе высока вероятность штрафов.

Обработка персональных данных на сайте: к чему готовиться

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

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

Что изменилось в 2025: было – стало

Сдвиг заметен не только в букве закона, но и в том, как выглядят формы, тексты и рассылки. Разберем, какие изменения произошли и произойдут после 30 мая и 1 сентября.

С 30 мая 2025

1. Было: чекбоксы в формах могли быть отмечены заранее, формулировка под кнопкой звучала размыто – «нажимая, согласны со всем».

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

2. Было: один общий пункт про согласие, который покрывает заявку, маркетинг и звонки.

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

3. Было: баннер про Cookies без выбора – просто уведомление внизу экрана.

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

4. Было: рассылки запускались без отдельной фиксации волеизъявления, иногда без ссылки на отписку.

   Стало: обязательная кнопка «отписаться» в каждом письме, а для подписки рекомендуется double opt-in.

5. Было: доказательства согласия могли не сохраняться системно.

   Стало: фиксация даты и времени, IP, источника и события клика – это закрывает вопросы проверяющих и снижает риски для компании.

С 1 сентября 2025

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

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

2. Было: широкие формулировки про передачу данных «неопределенному кругу лиц».

   Станет: конкретика по передаче и кругу лиц, прозрачность для пользователей и понятные тексты для оператора.

3. Было: политика на сайте могла существовать просто для вида.

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

Что менять в текстах и интерфейсах уже сейчас

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

• Рядом с чекбоксом – короткая и конкретная формулировка, где указаны цели обработки и ссылка на политику.

• В e-mail – обязательная ссылка на отписку, в базе – запись о согласии; в логах – дата, источник и IP.

• Cookie-баннер – с выбором и понятным языком, без давления и скрытых сценариев.

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

Инвентаризация и карта точек сбора данных

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

Что включить в перечень точек сбора

• формы заявки, обратной связи, квизы, поп-апы и виджеты чатов;

• обратный звонок, комментарии, личный кабинет, любые поля ввода;

• интеграции с CRM, платежными сервисами, рассылками и аналитикой;

• файлы и вложения – например, резюме с ФИО и контактами.

  Такая карта показывает, где именно проходят данные, какая цель у каждого поля и как дальше управлять обработку.

Как провести аудит по шагам

1. Собрать список всех интерфейсов, где запрашиваются персональные данные – например, чаты и формы с телефоном и e-mail.

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

3. Проверить тексты рядом с полями: есть ли уведомление, понятно ли пользователю, зачем требуются конкретные сведения.

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

5. Задокументировать маршруты: где фиксируется согласие, где хранятся доказательства и как оператор подтвердит их по запросу роскомнадзора.

Минимизация – быстрый способ снизить риски

• убирать лишние поля: если цель – обратная связь, персональным запросом может быть только ФИО и телефон, а не все подряд;

• разделять обязательные и необязательные поля, поясняя, зачем именно они нужны;

• хранить только то, что потребуется для обработки задачи – остальное не собирать.

Итог – меньше персональных данных и проще контроль за данными.

Что важно зафиксировать в документах и системах

• реестр точек сбора и карта потоков ПДн;

• шаблоны текстов рядом с полями, где оператор дает понятные разъяснения по обработке;

• журнал, где хранится дата, источник и событие клика при согласии, чтобы оператор быстро предоставил сведения;

• порядок взаимодействия с внешними сервисами и доступы к данным, чтобы роскомнадзор не нашел проблем.

Зачем это бизнесу

• быстрее отвечать на запросы пользователей и закрывать вопросы по ПДн;

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

• снизить вероятность штраф – прозрачная карта потоков помогает пройти проверку Роскомнадзора.

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

Персональные данные – политика на сайте

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

Что должно быть в документе

• реквизиты (название юрлица и ИНН), контакт для обращений и ответственного;

• цели, состав и источники персональных, сроки хранения данных и передачу третьим лицам;

• правовые основания по 152-ФЗ и ссылки на статьи, регулирующие обработки;

• порядок, по которому обрабатываются запросы субъектов, и уведомление о сроках ответа.

Где размещать и как показывать

• страница Политики должна быть доступна с любой формы на сайте – ссылка рядом с чекбоксом и в футере;

• рядом с полями – короткое уведомление: какие сведения собираются и зачем нужна обработку;

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

Как оформить согласие и дать инструменты управления

• разные цели – разные согласия: заявка отдельно, маркетинг отдельно;

• рядом с чекбоксом – ясная фраза, указан оператор, цель обработки и ссылка на политику;

• у человека должна быть понятная опция отзыва – e-mail/форма обратной связи и понятные сроки исполнения;

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

Как обрабатывать запросы субъектов

• в запросе уместно просить идентифицирующие сведения – например, ФИО и e-mail;

• фиксируется маршрут работы: кто принимает запрос, кто проверяет правовые основания и кто отвечает;

• если нужны данные от внешних сервисов, это отражено в политике и маршрутах обмена данными;

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

Формы, согласия и маркетинговые коммуникации

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

Как собрать форму без лишних рисков

• Каждой цели – свой чекбокс. Заявка отдельно, маркетинг отдельно, звонки отдельно. Так пользователь понимает, на что именно дает согласие, а оператор фиксирует законное основание на обработку.

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

• Рядом с чекбоксом – короткая фраза с указанием оператора, цели, отсылкой на документ по ст 9 152-ФЗ и ссылкой на документ, который регулирует правила 152-ФЗ в 2025.

• Валидация и понятные подсказки. Например, если требуется e-mail для ответа, прямо так и написать, не заставляя гадать, какие сведения действительно нужны.

Тексты согласий, которые работают на конверсию и закон

• Формулировки без воды: цель обработки, наименование оператора, срок, ссылка на документ и понятное уведомление о правах. Например: «Согласие на обработку для обработки заявки и обратной связи. Оператор – ООО „Х“, ИНН…, срок – …».

• Разные формулировки под разные сценарии. Для заявки – одно согласие, для рекламных материалов и звонков – другое. Это снижает вопросы роскомнадзора и упрощает жизнь команде.

• Отдельно проговорить передачу и круг получателей. Например, «для передаче сведений в сервис рассылок и CRM в целях отправки материалов и согласования звонка». Так оператор закрывает чувствительный момент заранее.

Интеграции и хранение доказательств

• Логи фиксируются там, где их легко поднять: CRM, сервис рассылок, хранилище событий. Главное – чтобы оператор быстро нашел сведения и показал их по требованию роскомнадзора.

• Для внешних сервисов указывается правовое основание и описывается передача: что именно уходит, кому и зачем. Например, «передачу фио и e-mail в ESP для отправки серии писем».

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

Юридическая точность в интерфейсе – что написать рядом с полями

• Короткая поясняющая строка над или под полем: какие сведения нужны и зачем.

• Под формой – блок с напоминанием о праве отзыва и понятным каналом для обращения.

• Отдельная строка: «Согласие оформляется отдельно, в соответствии с нормами закона. Подробности описаны в документе на сайте».

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

Организационно-технические меры защиты

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

Организационный контур

• Роли и регламенты. Прописывается, кто и на каком основании получает доступ к данным, как оформляется доступ и как он закрывается при уходе сотрудника.

• Обучение команды. Короткие сценарии по работе с формами, передаче сведений внешним сервисам, типовые ответы на запросы субъектов.

• Модели рисков и порядок действий. Что делать при инциденте: кого уведомлять, какой канал связи использовать, какие логи поднимать, какое уведомление отправлять пользователю и в какие сроки.

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

Технический контур

• Передача и хранение. Шифрование канала (TLS), включенный HSTS, защита от MITM. Для баз – шифрование «на диске», политика ключей, тест восстановления бэкапов.

• Периметр и сеть. WAF/фаервол, сегментация: база отдельно, административные панели – через VPN и с многофакторной аутентификацией.

• Доступы. Принцип минимально необходимых прав, раздельные роли для чтения/изменения, регулярный пересмотр прав.

• Обновления. Патчи по расписанию, учет активов и версий, контроль за уязвимостями библиотек.

• Мониторинг и логи. События входов, изменения прав, операции над данными – в единый журнал. Это база для расследования и ответов контролерам.

• Разработка. Проверка форм на XSS/SQLi, запрет скрытых полей, серверная валидация, защита от ботов и повторной отправки.

• Интеграции. Ограничение ключей и токенов по IP и по правам, аудит вызовов API, фиксированная схема, где видно, кому и зачем идет передачу.

Что это дает бизнесу

• Контролируемые доступы и понятная ответственность снижают шанс ошибок персонала.

• Технические барьеры не мешают маркетингу и продажам, а страхуют от лишних потерь.

• При проверке у оператора есть быстрые ответы: где хранятся сведения, кто их видел, какая была обработку, на каком основании и как подтверждается согласие на обработку персональных данных на сайте.

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

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

Внедрение, контроль и ошибки, которых стоит избегать

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

Дорожная карта внедрения

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

2. Формы и тексты – разделить согласия по целям, убрать предотмеченные чекбоксы, добавить корректные формулировки и уведомление рядом с полями. В письмах – ссылка для отказа, в базе – журнал согласия (дата, источник, IP).

3. Cookie и политика – включить полноценный Cookie-баннер с выбором, актуализировать политику, чтобы она отражала реальные процессы и была доступна из каждой формы.

4. Оргмеры – назначить ответственного, прописать регламенты, определить, кто поднимает логи и отвечает на запросы субъектов.

5. Техмеры – шифрование канала, WAF, сегментация, MFA, бэкапы, контроль версий, аудит-логи операций с данными.

6. Интеграции – описать передачу в CRM, ESP и платежные сервисы: какие сведения уходят, на каком основании и на какой срок.

7. Проверка и обучение – прогнать чек-листы, обучить сотрудников фронта и поддержки, обновить речевые модули под новые правила.

8. Мониторинг и аудит – регулярная проверка форм, ссылок, журналов; готовность выгрузить подтверждение согласия по запросу роскомнадзора.

KPI для контроля результата

• доля валидных согласий и полнота журналирования;

• скорость ответа субъектам ПДн;

• конверсия форм до и после изменений;

• доля отказов в Cookie-баннере;

• статус внутренних аудитов и устранение замечаний.

Чек-лист «перед релизом»

• на каждой форме есть понятное уведомление, рядом – корректные соглашения и рабочая ссылка на политику;

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

• Cookie-баннер дает выбор и не блокирует сценарии, необходимые для сервиса;

• журнал согласий отражает события: дата, время, IP, источник;

• в регламентах описаны обработке запросов субъектов и взаимодействие с внешними сервисами;

• по интеграциям прописаны передачи: какие сведения уходят, кому и зачем;

• у компании назначен ответственного и понятен маршрут эскалации на случай инцидента.

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

Если требуется ускорить путь из точки А в точку В (к соответствию закону), разумно начать с аудита форм, Cookie-баннера и политики, затем закрепить изменения орграспорядком и техмерами – это экономит время и деньги именно там, где бизнес обычно теряет их больше всего.