Политика обработки персональных данных для сайта: как составить по 152-ФЗ

Короткий ответ

Политика обработки персональных данных для сайта нужна не “для галочки” и не потому, что это “принято у всех”. По статье 18.1 152-ФЗ оператор обязан опубликовать или иным образом обеспечить неограниченный доступ к документу, определяющему его политику в отношении обработки персональных данных, а если данные собираются через интернет — разместить такой документ на страницах сайта, где этот сбор происходит, и обеспечить к нему доступ средствами сети. Роскомнадзор отдельно указывает среди обязанностей оператора публикацию такой политики, а РКН-рекомендации советуют включать в нее цели, правовые основания, объем и категории данных, категории субъектов, порядок и условия обработки, а также порядок актуализации, удаления, уничтожения и ответов на запросы субъектов. Иными словами, политика должна объяснять не “закон вообще”, а то, как именно ваш сайт собирает и использует данные.

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

Если вы в целом собираете комплект документов для сайта, полезно держать рядом общий хаб: какие документы нужны сайту в 2026 году. Но сама политика ПДн — это отдельный документ с собственной логикой, который нельзя подменять ни офертой, ни пользовательским соглашением, ни “коротким текстом у кнопки”.

Почему политика должна описывать конкретный сайт, а не абстрактный бизнес

Ключевая норма здесь — пункт 2 части 1 статьи 18.1 152-ФЗ. Закон требует, чтобы документы по обработке персональных данных определяли для каждой цели обработки категории и перечень данных, категории субъектов, способы, сроки обработки и хранения, а также порядок уничтожения данных при достижении цели или наступлении иных законных оснований. Это очень важная деталь: не “один общий текст про все”, а раскладка по целям. РКН в рекомендациях повторяет ту же логику, а статья 22 и форма уведомления РКН используют тот же каркас: для каждой цели указываются категории данных, категории субъектов, правовое основание, перечень действий и способы обработки. Именно поэтому хорошая политика для сайта строится не от главы закона, а от карты сайта и карты данных.

Практически это означает простое правило. Если на сайте есть форма заявки — политика должна отражать обработку обращений из формы. Если есть регистрация и личный кабинет — нужна отдельная цель, связанная с созданием и обслуживанием аккаунта. Если есть checkout — политика должна описывать обработку данных покупателя, заказа, оплаты, доставки и сервисных уведомлений. Если стоит Яндекс Метрика, пиксели рекламы или иные средства аналитики, то в документе должен появиться слой данных посетителя сайта и сведений, собираемых метрическими программами. Если лиды или обращения попадают в CRM, helpdesk или email-сервис, это тоже должно быть видно в тексте политики, а не прятаться между строк.

Хорошая проверка на качество политики звучит так: можно ли по ней восстановить, какие именно данные появляются в каждом пользовательском сценарии сайта и кто с ними работает дальше. Если нет, перед вами, скорее всего, не рабочий reference-guide, а обезличенный шаблон. И это проблема не только с точки зрения удобства. Такая абстракция часто конфликтует с принципами статьи 5 152-ФЗ: цели должны быть конкретными и законными, данные — соразмерными цели, а их объем — не избыточным.

Сценарий сайта → какие данные появляются → что должно быть в политике

Ниже — удобная матрица, из которой обычно и стоит собирать политику сайта. Она построена на логике статьи 18.1, статьи 22 и полей формы уведомления РКН: цель, субъект, данные, действия, способ обработки, третьи лица и срок/условие прекращения обработки.

Структура политики по разделам

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

Самая частая слабость таких разделов — не сами названия, а формулировка цели. По статье 5 цель должна быть конкретной, законной и заранее определенной; по статье 18.1 именно от цели зависят перечни данных, субъектов, способы и сроки. Поэтому хорошая формула цели для сайта выглядит так: действие + результат + канал/сценарий. Например: “обработка обращений, направленных через форму обратной связи”, “регистрация и обслуживание личного кабинета”, “оформление, оплата и доставка заказа”, “направление сервисных уведомлений о статусе заказа”, “направление рекламной рассылки при наличии отдельного согласия”, “анализ посещаемости сайта с использованием метрических программ”.

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

Раздел про третьих лиц и обработчиков — место, где политика особенно часто отрывается от реальности. Если вы поручаете обработку подрядчику, закон требует, чтобы в поручении были определены перечень данных, перечень действий, цели обработки, требования к конфиденциальности и безопасности; при этом ответственность перед субъектом за действия такого лица в общем случае несет оператор. А субъект, со своей стороны, вправе получать информацию о лицах, которым данные могут быть раскрыты, и о лице, обрабатывающем данные по поручению оператора. Значит, политика не должна изображать, будто CRM, helpdesk, email-платформа, платежный или логистический сервис “не существуют”. Их роль нужно раскрывать в той мере, в которой они реально участвуют в обработке.

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

Где разместить ссылку на политику на сайте

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

Рекомендуемая схема выглядит так:

Для интернет-магазина полезно дополнительно сверить политику с документами checkout и другими текстами магазина. Если вам нужен отдельный пакет под commerce-сценарии, смотрите какие документы нужны интернет-магазину. А если задача шире — проверить сайт на соответствие перед запуском или рекламной кампанией, полезен чеклист проверки сайта по 152-ФЗ.

Чем политика отличается от согласия

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

Отдельно стоит развести политику и уведомление в РКН. По статье 22 оператор до начала обработки по общему правилу уведомляет уполномоченный орган, за исключением прямо перечисленных законом случаев; при изменении сведений уведомление актуализируется, а формы таких уведомлений утверждены Роскомнадзором. Наличие политики не отменяет требование об уведомлении, а уведомление не заменяет публикацию политики. Если вам нужна именно тема согласий, лучше вынести ее в отдельный материал — согласие на обработку персональных данных на сайте.

Как кратко отразить cookie, Метрику, пиксели, CRM и платежи

Лучшая практика для политики сайта — не уходить здесь в техническую inventory-таблицу, а описать маршрут данных на достаточном уровне детализации. Для аналитики хороший ориентир дает сама форма уведомления РКН: среди категорий данных там отдельно названы “сведения, собираемые посредством метрических программ”, а среди субъектов — “посетители сайта”. Значит, если на сайте используются Метрика, пиксели или иные аналитические/рекламные инструменты, в политике имеет смысл отдельно описать цель такой обработки, типы данных/идентификаторов, роль сервисов, возможную передачу данных таким провайдерам и ссылку на отдельную cookie-политику, если вы поддерживаете ее как самостоятельный документ. Подробно тему cookie лучше раскрывать в отдельной статье: политика cookie для сайта и Метрика, Google Analytics, cookie и 152-ФЗ.

Для CRM, helpdesk и email-сервисов логика другая: это уже не только “сбор сведений”, но и вопрос о третьих лицах и поручении обработки. Если лиды из формы уходят в CRM, обращения в helpdesk, а письма отправляются через специализированный сервис, политика должна связывать эти сервисы с конкретными целями обработки и не оставлять впечатление, будто данные просто “лежат у вас на сервере”. Если часть обработки поручена подрядчику, закон требует, чтобы поручение фиксировало перечни данных, операции, цели, конфиденциальность и защиту, а ответственность перед субъектом за такого обработчика в общем случае все равно остается у операторa.

С платежами важно не фантазировать. Если оплата проходит на стороне платежного провайдера, а сайт сам не получает полные реквизиты банковской карты, не стоит писать в политике, что оператор “обрабатывает данные банковской карты”, если фактически он получает только статус оплаты, номер заказа и иные сопутствующие сведения, необходимые для исполнения договора. Правильный подход — описать реальную архитектуру: какие данные собирает сайт для заказа, какие данные уходят платежному провайдеру, что возвращается оператору, кто участвует в доставке и бухгалтерском/фискальном контуре. Это следует из принципа соразмерности данных цели и из требования раскрывать лиц, которым данные могут быть переданы или раскрыты. Если используются иностранные сервисы, дополнительно проверьте вопрос трансграничной передачи — это отдельный слой регулирования, который статья 12 и статья 14 связывают с обязанностью оператора и правом субъекта на информацию.

Плохие и хорошие формулировки

Ниже — не “универсальные образцы”, а примеры того, как превратить общие и рискованные формулы в текст, который лучше соответствует требованиям конкретности цели, соразмерности данных и прозрачности обработки. Основой здесь служат статьи 5, 14, 18.1 и 15 152-ФЗ, а также логика формы уведомления РКН.

Частые ошибки сайтов

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

1. Политика написана как шаблон “про всё на свете”, но не отражает конкретные сценарии сайта: формы, регистрацию, checkout, личный кабинет, аналитику и подрядчиков.
2. Все процессы сведены к одной размытой цели вроде “улучшение сервиса”, хотя закон требует конкретных, заранее определенных целей.
3. В документе не разведены категории субъектов и категории/перечни данных по целям, хотя статья 18.1 и форма уведомления РКН построены именно по такой логике.
4. Подрядчики фактически участвуют в обработке, но в политике их нет: CRM, рассылки, helpdesk, доставка, платежный сервис, веб-аналитика.
5. Оператор пишет, что “обрабатывает банковские карты”, хотя платежная архитектура сайта этого не предполагает; или наоборот — полностью замалчивает платежный слой, хотя тот влияет на маршрут данных. Это риск избыточности или недостоверности описания.
6. Сроки указаны как “бессрочно”, “до отзыва согласия” или вообще не указаны, хотя закон привязывает прекращение обработки и уничтожение к целям, отзыву согласия и требованиям субъекта.
7. Политика есть только в футере, но формы, регистрация и checkout не дают пользователю заметной связи с документом на страницах сбора данных.
8. Политику путают с согласием: вместо публичного документа публикуют текст “я согласен…”, а саму политику не раскрывают. Закон эти инструменты разводит.
9. На сайте стоит Метрика, пиксели и иная аналитика, но в политике нет ни посетителей сайта как категории субъектов, ни данных метрических программ как категории данных.
10. В тексте используются размытые конструкции “и др.”, “и т.п.”, “иная информация”, из-за чего невозможно понять фактический объем обработки. РКН отдельно указывает такие расплывчатые формулы как типичную ошибку при заполнении уведомлений; для политики это такой же плохой ориентир.
11. Политика не синхронизирована с уведомлением РКН: на сайте одни цели и сервисы, а в реестре и формализованных сведениях — другие. При изменении сведений статья 22 требует обновлять уведомление.
12. В политике нет понятного канала для обращений субъекта и не объяснено, как реализуются права на доступ, исправление, прекращение обработки или обжалование.

Чеклист перед публикацией политики

Перед тем как выкладывать политику на сайт, удобно пройтись по этому списку. Он собран из требований статей 5, 14, 18.1, 19, 21, 22, формы уведомления РКН и обязанностей оператора, которые РКН публикует для практики.

• [ ] В политике перечислены реальные сценарии сайта, а не абстрактные процессы компании.
• [ ] Для каждой цели указаны категории субъектов и конкретные категории/перечни данных.
• [ ] Правовые основания расписаны по целям, а не одной строкой “на основании закона и согласия”.
• [ ] Разнесены сервисные уведомления, маркетинг, рассылки и рекламные контакты.
• [ ] Указаны CRM, helpdesk, email-сервисы, платежные, логистические и аналитические провайдеры, если они реально участвуют в маршруте данных.
• [ ] В части аналитики отражены посетители сайта и сведения, собираемые метрическими программами.
• [ ] По срокам нет формул “бессрочно” без объяснения связи с целью или законным основанием.
• [ ] Есть порядок актуализации, блокирования, удаления и уничтожения данных.
• [ ] Есть контакты для обращений субъекта и объяснение, как он может реализовать свои права.
• [ ] Есть общий блок о мерах безопасности без излишнего раскрытия внутренней инфраструктуры.
• [ ] Ссылка на политику доступна не только в футере, но и там, где пользователь реально отправляет данные.
• [ ] Политика не противоречит текстам в формах, регистрации, checkout, cookie-notice и личном кабинете.
• [ ] При необходимости сведения синхронизированы с уведомлением РКН и его текущей редакцией.

Что делать дальше

После публикации политики не останавливайтесь на самом документе. Проверьте, что ей соответствуют все реальные точки сбора данных: формы, регистрация, личный кабинет, checkout, платежный маршрут, email-рассылки, Метрика и другие трекеры. Если тема уходит в согласия — вынесите ее в отдельный слой и не смешивайте с политикой. Если упираетесь в cookie и аналитику — раскройте это в отдельной статье и политике cookie. Если у вас интернет-магазин — отдельно проверьте checkout и набор обязательных полей. Практический смысл здесь один: документ должен отражать реальный маршрут данных на сайте, а не быть абстрактным шаблоном, который “просто висит в футере”. Для общего аудита комплекта документов пригодится какие документы нужны сайту в 2026 году, для согласий — согласие на обработку персональных данных на сайте, для cookie — политика cookie для сайта, для аналитики — Метрика, Google Analytics, cookie и 152-ФЗ, для проверки сайта глазами контроля — чеклист проверки сайта по РКН, а для магазина — какие документы нужны интернет-магазину. Правослой полезен именно там, где нужно собрать документы под конкретную архитектуру сайта, связать их между собой и убрать противоречия между формами, cookie-слоем, оплатой и текстами на страницах — без обещаний “юридической гарантии” от одного шаблона.

Источники и дата проверки