ПОЛИТИКА ОБРАБОТКИ ПЕРСОНАЛЬНЫХ ДАННЫХ ДЛЯ САЙТА: ЧТО ДОЛЖНО БЫТЬ В ДОКУМЕНТЕ

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

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

ПОЛИТИКА НЕ ЗАМЕНЯЕТ ОСТАЛЬНЫЕ ДОКУМЕНТЫ

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

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

Если сайт используется для сбора персональных данных, политика должна быть доступна на страницах, через которые такой сбор происходит. В письме от 14 июля 2023 года Роскомнадзор отдельно разъяснял именно такой подход к размещению документа.

ТИПИЧНЫЕ ТОЧКИ СБОРА

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

Общую карту требований для сайта я собрал в отдельном гайде «Персональные данные на сайте: требования 152-ФЗ». Эта страница посвящена именно политике и не пытается заменить остальные элементы compliance-процесса.

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

БАЗОВЫЕ РАЗДЕЛЫ

1. Общие положения и сведения об операторе.
2. Цели сбора и обработки персональных данных.
3. Правовые основания обработки.
4. Категории и перечень персональных данных.
5. Категории субъектов, чьи данные обрабатываются.
6. Порядок и условия обработки.
7. Сроки обработки и хранения, порядок прекращения и уничтожения.
8. Условия передачи или поручения обработки другим лицам, если применимо.
9. Порядок актуализации, исправления, удаления данных и работы с обращениями субъектов.
10. Сведения о мерах по защите данных в объёме, допустимом для публичного документа.

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

ПРИМЕР ЛОГИКИ

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

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

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

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

ЧТО ПРОВЕРИТЬ ПО КАЖДОМУ СЕРВИСУ

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

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

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

Часть 2 статьи 18.1 требует обеспечить доступ к политике. Для интернет-сбора это означает публикацию документа в сети и доступ на страницах, с использованием которых собираются данные. В письме № 08ВМ-59834 Роскомнадзор подтвердил, что размещение документа осуществляется на интернет-страницах сайта, посредством которых оператор собирает персональные данные.

ПРАКТИЧЕСКАЯ СХЕМА ДЛЯ САЙТА

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

1. Составьте список всех форм, личных кабинетов, заказов, регистраций и других точек сбора.
2. Определите цели обработки для каждого сценария.
3. Зафиксируйте категории субъектов и перечень собираемых данных.
4. Проверьте правовые основания по каждой цели.
5. Проследите маршрут данных после отправки формы.
6. Проверьте сроки обработки и условия удаления.
7. Сопоставьте документ с фактическими сервисами и третьими лицами.
8. Проверьте локализацию и возможную трансграничную передачу.
9. Убедитесь, что политика открывается со всех страниц сбора.
10. Проверьте, что формы и согласия не противоречат самой политике.

Если оператор ещё не проверял обязанность по уведомлению Роскомнадзора, это отдельная задача. Для неё мы используем самостоятельный материал «Уведомление Роскомнадзора об обработке персональных данных». Так страницы сохраняют разные поисковые интенты и не конкурируют между собой.

ТИПОВАЯ ОШИБКА: ПОЛИТИКА ИЗ ШАБЛОНА

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

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

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

ПОВОДЫ ДЛЯ ПРОВЕРКИ

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

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