Политика обработки данных на сайте: что должно быть внутри

MAATRIX

Дисклеймер сразу, чтобы не было иллюзий: это обзор типовой структуры документа, а не юридическая консультация и не шаблон для копирования. Ниже — про то, какие разделы принято включать в политику обработки персональных данных и зачем каждый из них нужен с практической точки зрения. Финальный текст политики для конкретного сайта должен проверить юрист или специалист по защите данных — здесь такой проверки нет и быть не может. Почти любой сайт с формой — заявка, регистрация, подписка на рассылку, корзина в интернет-магазине — обязан объяснить посетителю, что происходит с его данными после отправки формы. Обычно это делается одним документом со ссылкой в футере: «Политика обработки персональных данных» или «Privacy Policy». Проблема в том, что большинство таких страниц пишутся не под конкретный сайт, а копируются откуда-то целиком — и в результате не совпадают с тем, что сайт реально делает. Разберём, из каких разделов такой документ обычно состоит и почему пропуск любого из них — это не формальность, а конкретный риск.

Кто является оператором данных

Первый раздел любой политики — прямой ответ на вопрос «кто именно собирает и обрабатывает данные». Это не абстрактная формальность: пользователь должен понимать, к кому именно относятся его данные и кому он, по сути, выдаёт согласие на обработку.

Обычно здесь указывают:

• полное наименование владельца сайта (юридическое лицо, ИП или, для совсем небольших проектов, физическое лицо — в зависимости от того, как оформлен бизнес на самом деле);
• регистрационные реквизиты (ОГРН/ОГРНИП, ИНН — для российской юрисдикции; аналогичные номера регистрации — для других стран);
• юридический или фактический адрес;
• контакт для связи именно по вопросам обработки данных (об этом отдельно — в разделе про обратную связь).

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

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

Какие данные фактически собирает сайт

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

Практический подход — пройтись по каждой форме на сайте и выписать её реальные поля:

Форма обратной связи:      имя, email, телефон, текст сообщения
Форма регистрации:         email, пароль (хеш), имя пользователя
Оформление заказа:         ФИО, email, телефон, адрес доставки,
                            реквизиты для выставления счёта (без хранения номера карты)
Подписка на рассылку:      email
Комментарии на сайте:      имя (или ник), email (обычно скрытый), текст комментария
Метрика/аналитика:         IP-адрес, cookie-идентификатор, данные о браузере и устройстве

Такой список — не в коде, а буквально в тексте политики — сразу закрывает половину типичных претензий: пользователь видит, что именно у него просят, а не гадает. Отдельно стоит упомянуть данные, которые собираются не напрямую от пользователя, а автоматически: IP-адрес в логах сервера, cookie от систем аналитики (Яндекс.Метрика, счётчики, пиксели), данные о user-agent. Это тоже персональные данные (или могут быть отнесены к ним в зависимости от юрисдикции), и о них тоже нужно написать честно — а не только про то, что вводится руками в формы.

Здесь же практический совет, о котором сборщики шаблонов обычно не думают: если на сайте физически нет формы, собирающей телефон, не нужно про телефон писать в политике «для полноты». Это создаёт обратную проблему — политика обещает то, чего сайт не делает, и в случае проверки или спора это тоже несоответствие.

С какой целью собираются данные

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

Конкретные формулировки целей выглядят примерно так:

• обработка и выполнение заказа (доставка товара, оказание услуги);
• связь с пользователем по его обращению (ответ на заявку через форму обратной связи);
• отправка информационной или рекламной рассылки — и отдельно: только при наличии отдельного согласия на неё, не «заодно» с согласием на обработку заявки;
• ведение статистики посещаемости и поведения на сайте (аналитика, A/B-тесты);
• выставление счетов и бухгалтерский/налоговый учёт (для юрлиц и ИП это часто отдельное законное основание, не совпадающее с «согласием»);
• обеспечение безопасности сайта (антифрод, защита от спама и автоматических атак).

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

Сколько времени хранятся данные

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

Более честный и рабочий подход — привязать срок к типу данных и реальной причине хранения:

Практический момент: сроки в таблице должны совпадать с тем, что реально настроено на сервере и в используемых сервисах — например, с реальной политикой ротации логов nginx или reverse-proxy, а не быть придуманными «для солидности». Если в политике написано «логи хранятся 30 дней», а по факту ротация логов на сервере не настроена и они копятся годами, — это ровно тот разрыв между заявленным и фактическим, о котором предупреждение в начале статьи говорит не просто для формы.

Передаются ли данные третьим лицам

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

Типичный список выглядит так:

• Платёжная система (эквайринг, платёжный агрегатор) — получает данные, необходимые для проведения платежа. Сайт обычно не хранит и не видит полный номер карты — это на стороне платёжного сервиса, и это тоже стоит явно написать, так как снимает часть ответственности и опасений с самого оператора.
• Служба доставки — получает ФИО, адрес, телефон получателя, необходимые для доставки заказа.
• Сервис email-рассылок (транзакционные письма, маркетинговые рассылки) — получает email, иногда имя, для отправки писем от имени сайта.
• Системы аналитики и рекламные сети — получают обезличенные или частично обезличенные данные о поведении на сайте (IP, cookie-идентификатор).
• Хостинг-провайдер / провайдер сервера — технически имеет доступ к данным, физически находящимся на сервере, хотя обычно не использует их в своих целях, а выступает технической инфраструктурой.

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

Права пользователя и как связаться с оператором

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

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

Чтобы эти права были не декларацией, а рабочим механизмом, в этом же разделе указывается контакт: отдельный email (например, privacy@ или data@ вашего домена, а не общий info@, в который сваливается всё подряд) и, желательно, ожидаемый срок ответа на такое обращение. Если у сайта есть аудитория за пределами страны регистрации оператора — например, сайт принимает заказы из Евросоюза или Великобритании, — стоит отдельно уточнить, какому законодательству о данных сайт следует для этой аудитории; общий обзор подхода в ЕС есть в статье законодательство о персональных данных в ЕС для сервера.

Главная ошибка — политика, скопированная с чужого сайта

Самый частый способ создать политику обработки данных — открыть похожий сайт конкурента, скопировать его текст, поменять название компании и реквизиты. Соблазн понятен: документ выглядит солидно, юридические формулировки на месте, времени тратится минимум. Проблема в другом — скопированная политика описывает практику ЧУЖОГО сайта, а не вашего.

Конкретные последствия такого расхождения:

• в политике написано «мы используем cookie для персонализации рекламы», хотя на сайте нет ни одного рекламного пикселя — это создаёт впечатление, что оператор либо не понимает, что происходит на его же сайте, либо пишет неправду;
• в политике не упомянут сервис аналитики, который реально стоит на сайте (например, скопированный текст был написан до того, как владелец сайта подключил счётчик) — а значит, документ не соответствует действительности уже в другую сторону;
• в политике описаны права и механизмы обращения по законодательству страны, для которой был написан оригинальный документ, а сайт работает в другой юрисдикции с другими правилами.

Разрыв между заявленным в политике и фактической практикой сайта — это отдельный юридический риск, не менее серьёзный, чем отсутствие политики вообще: отсутствие документа выглядит как недоработка, а недостоверный документ выглядит как введение пользователя в заблуждение. Поэтому практический алгоритм всегда один: сначала честно выписать, какие формы есть на сайте, какие сервисы аналитики и платежей реально подключены и куда реально уходят данные, — и только потом писать (или заказывать у юриста) текст, который описывает именно это, а не общий шаблон отрасли. Заодно стоит свериться, что сама техническая часть — сервер, на котором эти данные лежат, — соответствует базовым требованиям безопасности; отправная точка для проверки — чеклист безопасности нового сервера.

Частые вопросы