Это значит: вы не просто собираете контакты, а обязаны заранее описать правила обработки, получить корректные согласия, обеспечить меры защиты и — в большинстве случаев — уведомить Роскомнадзор.
Ниже — не «теория права», а прикладной список действий, который можно пройти как аудит: что должно быть на сайте, в документах и в техчасти, чтобы снизить риск претензий и штрафов. Формулировки даю в рабочем виде — их можно адаптировать под ваш проект.
1) Быстрая самопроверка: вы обрабатываете персональные данные?
- Есть формы, где пользователь оставляет имя/телефон/e‑mail/адрес/город/комментарий.
- Стоят системы аналитики (метрика, пиксели, коллтрекинг), которые используют cookie/идентификаторы.
- Есть личный кабинет, история заказов, бонусная программа, записи в сервис, онлайн‑оплата.
- Есть чат/мессенджер‑виджет, где сохраняются сообщения и контакты.
- Есть рассылки/маркетинговые коммуникации (почта, SMS, мессенджеры).
Если отмечено хотя бы одно — дальше работаем по чек‑листу. Цель простая: доказуемо, прозрачно и минимально‑достаточно обрабатывать данные, а не «собирать всё подряд и надеяться, что пронесёт».
2) Документы: что нужно подготовить в первую очередь
У Роскомнадзора и судов обычно один практический вопрос: «На основании чего вы собираете и используете данные, и где это зафиксировано?» Поэтому начинаем с пакета документов — без него технастройки мало помогают.
2.1 Политика обработки персональных данных (политика конфиденциальности)
- Минимум, который должен быть в политике:
- кто оператор (юрлицо/ИП, реквизиты, контакты для обращений субъектов ПДн);
- какие данные собираете (по категориям: контакты, аккаунт, заказы, платежные данные — если есть);
- цели обработки (обратная связь, исполнение договора/заказа, поддержка, рассылки, аналитика и т. п.);
- правовые основания (согласие, договор, законные интересы — аккуратно и обоснованно);
- сроки хранения (по целям, а не «храним бессрочно»);
- кому передаёте (хостинг, CRM, коллтрекинг, рассылки, платежный провайдер) и на каком основании;
- меры защиты (в общих чертах: организационные и технические);
- права субъекта ПДн и порядок обращения/отзыва согласия;
- трансграничная передача (если есть) и как соблюдаете требования локализации.
Важно: политика — не «страница для галочки», а ваш единый источник правды. Любое согласие на сайте должно ссылаться на неё.
2.2 Согласия: отделите «сервис» от «маркетинга»
На практике чаще всего ошибаются так: одна универсальная фраза «Нажимая кнопку, вы соглашаетесь…» покрывает всё подряд. Это слабое место: согласие должно быть конкретным и информированным. Разделите сценарии и дайте отдельные согласия там, где это действительно нужно.
- Согласие на обработку ПДн для обработки заявки/регистрации/обратной связи — рядом с каждой формой.
- Отдельное согласие на рекламно‑информационные рассылки (почта/SMS/мессенджеры) — не прячьте его внутрь общего чекбокса.
- Отдельное согласие на обработку cookie/идентификаторов для аналитики/маркетинга — через cookieбаннерр и настройки.
Технический минимум для формы: чекбокс (не предустановленный), текст согласия, кликабельная ссылка на политику, а также фиксация факта согласия в логах/CRM (дата‑время, источник/страница, версия текста согласия).
2.3 Реестр процессов и назначение ответственных
Даже маленькому бизнесу полезно иметь «карту данных» на 1–2 страницы: какие формы есть, какие данные в них, куда уходят, где хранятся, кто имеет доступ. Это сильно ускоряет ответы на запросы субъектов ПДн и подготовку к проверке.
3) Уведомление в Роскомнадзор: когда нужно и как не ошибиться
В большинстве типовых случаев оператор обязан уведомить Роскомнадзор о намерении осуществлять обработку ПДн (исключения узкие). Если у вас сайт с формами и автоматизированной обработкой — по умолчанию закладывайте, что уведомление требуется.
- Практические правила:
- Подавайте уведомление до «массового» сбора данных: до запуска рекламы, личного кабинета, рассылок.
- Укажите реальные цели и категории данных. Самая частая проблема — «слишком широко» или «не совпадает с фактом».
- Опишите меры защиты и перечень ИСПДн честно, без копипаста «для всех».
- Если меняются цели/сервисы/категории данных — обновляйте уведомление и внутренний реестр.
4) Что должно быть реализовано на сайте (UX + юридическая логика)
4.1 Все формы: чекбокс, ссылка, понятная формулировка
- Проверьте каждую форму отдельно:
- чекбокс согласия не отмечен заранее;
- ссылка ведёт на актуальную политику (не 404, не «в разработке»);
- текст согласия соответствует цели формы (заявка ≠ рассылка);
- есть защита от случайной отправки данных третьими лицами (captcha/antibot — по ситуации);
- в CRM/почте сохраняется факт согласия (лог).
4.2 Cookie‑баннер и управление трекерами
Cookie сами по себе не всегда персональные данные, но в реальной веб‑аналитике они часто становятся идентификаторами, по которым пользователя можно выделять/профилировать. Поэтому безопасная практика — баннер + выбор категорий.
- Покажите баннер при первом визите: кратко — что используется и зачем (аналитика/маркетинг/тех).
- Дайте кнопки «Принять», «Отказаться/Только необходимые», «Настроить».
- Не запускайте маркетинговые/аналитические скрипты до согласия (или настройте режим без cookies, если это допустимо).
- Храните выбор пользователя (cookie/LocalStorage) и дайте возможность изменить его позже (ссылка в футере).
- Опишите в политике cookies: какие, срок жизни, провайдеры, как отключить в браузере.
4.3 Страницы «Контакты», «О компании», реквизиты и каналы обращения
Для проверок и доверия пользователей важна идентификация оператора: в футере и/или в контактах должны быть реквизиты, e‑mail для обращений по ПДн, а также понятный маршрут «как отозвать согласие / как запросить удаление».
5) Техническая часть: безопасность и доказуемость
5.1 Базовые меры, которые должны быть включены всегда
- HTTPS везде (редирект с http, HSTS — по возможности).
- Минимизация данных: в формах спрашивайте только то, без чего услуга не оказывается.
- Разграничение доступа: отдельные учётки, роли, 2FA для админок, журналирование.
- Регулярные обновления CMS/модулей/плагинов, контроль уязвимостей.
- Резервные копии и проверка восстановления (RPO/RTO хотя бы на уровне регламента).
- Шифрование/маскирование чувствительных полей в логах (пароли, токены, платежные данные).
5.2 Локализация данных граждан РФ (если вы работаете на РФ)
Если вы собираете данные граждан РФ через сайт, закон о локализации требует, чтобы запись/накопление/хранение первичной базы происходили в РФ. Самая частая ошибка — сайт на зарубежном хостинге + CRM/формы, которые пишут данные «сразу туда».
- Хостинг/сервер с базой сайта — в РФ (либо архитектура, где первичная запись идёт в РФ).
- Формы: сначала запись в БД/CRM в РФ, и только затем (при необходимости) передача за рубеж по правилам.
- Проверьте внешние сервисы: коллтрекинг, чат, рассылки, облачная CRM — где физически хранятся данные.
- Зафиксируйте это в договорах/офертах с подрядчиками и в реестре процессов.
5.3 Подрядчики и сервисы: вы отвечаете за их выбор
Если данные уходят в сторонние сервисы, «это не мы, это подрядчик» не работает. Оператор обязан выбирать обработчиков и закреплять требования договорами.
- Заключите договор поручения обработки ПДн (или включите раздел в договор) с теми, кто обрабатывает данные по вашему поручению.
- Проверьте, что сервисы дают инструменты удаления/экспорта данных и ведут логи согласий.
- Сведите список интеграций в один документ: что передаём, зачем, где хранится, кто имеет доступ.
6) Запросы пользователей и инциденты: подготовьтесь заранее
Субъект ПДн имеет право запросить информацию об обработке, исправление, ограничение или удаление данных, а также отозвать согласие. Если вы не можете выполнить это быстро — вы уязвимы.
- Выделите e‑mail/форму для обращений по ПДн и пропишите сроки реакции внутри команды.
- Сделайте процедуру «найти человека в системах» (сайт/CRM/почта/телефония/аналитика) и удалить/обезличить там, где возможно.
- Разведите хранение: операционные данные (заказы) vs маркетинг (рассылки). Отзыв маркетингового согласия должен быть мгновенным.
- Подготовьте план реакции на утечку/инцидент: кто фиксирует, кто отключает доступ, кто уведомляет руководство/подрядчиков.
7) Итоговый чек‑лист «пройти за один день»
- Инвентаризация: все формы, скрипты, интеграции, точки хранения.
- Опубликована актуальная политика обработки ПДн + политика cookies (или раздел в основной).
- Под каждой формой — корректный чекбокс согласия + ссылка на политику + логирование согласия.
- Отдельное согласие на рассылки (если есть маркетинг).
- Cookie‑баннер: выбор категорий, блокировка трекеров до согласия, ссылка «изменить настройки».
- Уведомление Роскомнадзора подано/актуализировано (если нет оснований для исключения).
- Проверена локализация: первичное хранение в РФ, понятная схема передачи в сервисы.
- Договоры с подрядчиками/сервисами: поручение обработки, безопасность, сроки хранения, удаление.
- Техминимум: HTTPS, роли/2FA, обновления, бэкапы, контроль логов и утечек.
- Процедуры: обработка запросов субъектов, отзыв согласия, план на инциденты.
Если пройти этот список и привести сайт к соответствию, вы обычно закрываете 80–90% типовых рисков. Оставшиеся 10–20% — нюансы отрасли (медицина, финансы, дети), трансграничная передача, сложные CRM‑цепочки. В таких случаях лучше делать точечный юридико‑технический аудит под ваш стек и процессы.
Материал носит информационный характер и не заменяет индивидуальную юридическую консультацию. Но как практический контрольный список для владельца сайта — работает.
