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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Формулировка «данные хранятся до отзыва согласия» часто неверна. Во-первых, не вся обработка основана на согласии. Во-вторых, после отзыва могут сохраняться сведения, необходимые для исполнения установленной законом обязанности или защиты прав. В-третьих, бесконечное хранение до отзыва не соответствует принципу ограничения обработки сроком, необходимым для цели.

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

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

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

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

Подтверждение внедрения включает:

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

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

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

Основные группы несоответствий:

1. **Неверный оператор.** В документе указано другое лицо, бренд без юридической идентификации или разработчик сайта вместо лица, определяющего цели обработки.

2. **Формальные цели.** Цели описаны чрезмерно широко либо не соответствуют формам и договорной модели.

3. **Лишние или пропущенные данные.** Политика перечисляет сведения, которые не собираются, и не учитывает автоматически создаваемые идентификаторы или данные интеграций.

4. **Смешение политики и согласия.** Публичный документ предлагается «принять» вместо отдельного согласия либо текст согласия спрятан в пользовательском соглашении.

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

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

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

8. **Отсутствие процесса обновления.** Документ не пересматривается при изменении сайта, CRM, аналитики или рекламных инструментов.

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

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

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