152-ФЗ для сайта: что нужно сделать в 2026 году

Представьте обычную форму «Получить консультацию». Посетитель вводит имя, телефон и электронную почту, нажимает кнопку и получает сообщение «Спасибо, мы свяжемся с вами». На этом для пользователя процесс заканчивается.

Но для владельца сайта он только начинается.

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

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

Сначала нужно понять реальную архитектуру обработки данных. И только после этого правильно оформить документы, согласия и технические процессы.

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

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

Сначала браузер отправляет данные на сервер. Backend принимает запрос и может записать информацию в базу данных. Затем заявка может автоматически отправиться в CRM. Система аналитики фиксирует отправку формы или другие действия пользователя. А позже база данных может быть скопирована в резервное хранилище.

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

Именно поэтому недостаточно проверить только хостинг сайта.

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

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

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

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

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

Следующий элемент – политика обработки персональных данных.

И здесь важна не сама страница с названием «Политика конфиденциальности», а ее соответствие реальным процессам.

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

Особенно часто проблемы возникают после доработки сайта. Разработчик добавил новое поле, подключил новый сервис или установил новый аналитический инструмент, а юридические документы никто не обновил.

Получается интересная ситуация: технически сайт изменился, а юридическая модель осталась прежней.

Отдельно стоит помнить о принципе минимизации. Закон устанавливает, что обрабатываться должны только те персональные данные, которые отвечают целям обработки.

Для бизнеса это, кстати, может быть даже полезно.

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

Каждое лишнее поле увеличивает количество действий пользователя и потенциально снижает конверсию формы.

Главное здесь не название категории, а то, что именно делает конкретная cookie и какое основание используется для ее обработки.

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

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

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

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

Поэтому перед подключением нового сервиса стоит задать простой вопрос: «Какие данные этот сервис получает от моего сайта и где они обрабатываются?»

Даже идеально оформленные документы не помогут, если сами данные защищены плохо.

Начнем с базового уровня: сайт должен работать по HTTPS с корректным SSL/TLS-сертификатом. Это защищает передачу данных между браузером и сервером от ряда сетевых угроз и является обязательной технической базой современного сайта.

Но HTTPS – это только начало.

Нужно понимать, кто вообще имеет доступ к персональным данным.

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

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

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

Есть еще один полезный вопрос: «Что произойдет с этими данными через неделю?»

Если ответ выглядит примерно так: «Ну, наверное, они где-то в CRM, потом база делает бэкап, а еще у нас вроде бы подключена аналитика», значит, архитектуру стоит изучить подробнее.

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

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

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

А если вам интересно, как сделать так, чтобы сайт не только соответствовал требованиям, но и действительно приводил клиентов, посмотрите статью «Первый экран сайта: 7 вещей, которые заставляют посетителя остаться». Там я разбираю, что человек должен увидеть в первые секунды после перехода на сайт.