Михаил Якубенко
Требования 152-ФЗ к сайту — не абстрактная юридическая формальность, а конкретные технические детали: как должен быть свёрстан чекбокс, где физически должны лежать данные и какой счётчик аналитики использовать. Разберём это как техническое задание — для владельца бизнеса и для разработчика, который будет всё это внедрять.
Что именно проверяет закон на сайте
Требования к сайту по 152-ФЗ укладываются в пять технических блоков: форма согласия на обработку данных, cookie-баннер с отдельным согласием, локализация хостинга персональных данных в РФ, замена зарубежных сервисов аналитики и форм на легальные, и логирование того, кто и когда дал согласие. Ниже — по каждому пункту отдельно, с конкретикой для разработчика, а не только для юриста.
Инспектору Роскомнадзора не нужно запрашивать доступ к внутренним системам компании, чтобы проверить эти пункты, — большая часть проверяется прямо в браузере: открыть сайт, посмотреть форму заявки, проверить, загружаются ли счётчики аналитики до согласия, найти политику конфиденциальности. Именно поэтому сайт часто становится первой точкой, где фиксируют нарушение, даже если остальные документы компании в порядке.
Чекбокс согласия: как это должно быть устроено технически
Форма на сайте — будь то заявка, подписка на рассылку или регистрация — должна содержать отдельный чекбокс согласия на обработку персональных данных. Технические требования:
- Чекбокс не может быть отмечен по умолчанию — пользователь должен поставить галочку сам, активным действием.
- Согласие на обработку персональных данных должно быть отдельным элементом, не объединённым с согласием на рассылку, cookie или публичной офертой в одном чекбоксе (правило действует с 24 июня 2025 года).
- Текст рядом с чекбоксом должен содержать прямую ссылку на политику обработки персональных данных — не общую фразу без ссылки.
- Форма не должна отправляться без отмеченного чекбокса — проверка должна быть и на фронтенде, и на бэкенде.
Минимальный пример разметки, которая закрывает эти требования:
<label class="consent-checkbox">
<input type="checkbox" name="pdn_consent" required>
Я даю согласие на <a href="/policy" target="_blank">обработку персональных данных</a>
</label>
<button type="submit" id="submit-btn">Отправить</button>Атрибут required даёт базовую HTML-валидацию, но полагаться только на неё нельзя — форма должна отклонять отправку без согласия и на стороне сервера, иначе проверка легко обходится отключением JavaScript.
Cookie — тоже персональные данные
Частая путаница — считать, что согласие на cookie и согласие на обработку персональных данных это одно и то же, или что достаточно упомянуть cookie в политике конфиденциальности одной строкой. Это не так.
По разъяснениям Роскомнадзора, cookie-файлы, включая IP-адрес и идентификаторы устройства, позволяют идентифицировать пользователя — то есть их сбор тоже является обработкой персональных данных, требующей согласия до начала обработки, а не после. Технические cookie, не привязанные к личности пользователя (например, сохранение выбранного языка интерфейса), под это требование не подпадают.
| Согласие на обработку ПДн | Согласие на cookie | |
|---|---|---|
| Что покрывает | Данные, введённые пользователем в формах (имя, телефон, email) | Данные, которые сайт собирает автоматически через браузер |
| Когда нужно | При отправке любой формы | При первом заходе на сайт, до загрузки счётчиков |
| Можно ли объединить | Нет — это разные основания обработки, разные чекбоксы/баннеры | |
На практике это означает: cookie-баннер должен появляться при первом визите и блокировать загрузку счётчиков аналитики и рекламных виджетов до того, как пользователь даст согласие — а не просто информировать постфактум, что сайт "использует cookie".
Google Analytics и локализация: почему риск резко вырос
До недавнего времени требование локализации персональных данных на практике часто сводилось к формальности: закон требовал хранить копию данных на сервере в РФ, но обработка могла продолжаться и за рубежом. С 1 июля 2025 года требование стало жёстче: сбор и первичная обработка персональных данных россиян обязаны происходить исключительно на территории РФ.
Это прямо касается Google Analytics: архитектура сервиса построена на том, что данные о поведении посетителей передаются напрямую на серверы за рубежом в момент сбора — то есть первичная обработка происходит не в России. Формально установленный на сайте Google Analytics при наличии там форм с персональными данными — нарушение требования локализации, а не абстрактный "риск использования зарубежного сервиса". Штраф по ч. 8 ст. 13.11 КоАП — от 1 000 000 до 6 000 000 ₽, одинаково для ИП и юрлица.
| Сервис | Локализация данных | Что делать |
|---|---|---|
| Google Analytics | Серверы за рубежом | Заменить на Яндекс.Метрику |
| Google Forms | Серверы за рубежом | Заменить на Яндекс.Формы или форму на своём хостинге |
| Яндекс.Метрика | Серверы в РФ | Легальная замена, но согласие на сбор данных всё равно нужно |
| VK Pixel | Серверы в РФ | Легальная альтернатива для рекламной аналитики |
Замена сама по себе не отменяет обязанность получить согласие пользователя — российский счётчик аналитики законен по локализации, но данные всё ещё собираются, и на это тоже нужно согласие через cookie-баннер, описанный выше.
Хостинг: где физически должны храниться данные
Требование касается не только счётчиков аналитики, но и того, где физически размещена база данных сайта — CRM, база клиентов, форма заявок. Если сайт и его база данных размещены на зарубежном хостинге, это нарушение локализации независимо от того, какая доменная зона у сайта: домен .ru не гарантирует, что сервер физически находится в России.
Российские хостинг-провайдеры (например, Selectel, Timeweb, REG.RU и другие с дата-центрами в РФ) закрывают формальное требование локализации, но перед переносом стоит уточнить у провайдера конкретную юрисдикцию дата-центра — не все тарифы одного и того же провайдера обязательно физически в России.
Перенос сайта на новый хостинг сам по себе не требует переделки кода — если сайт написан без привязки к специфичным сервисам конкретного провайдера, перенос сводится к копированию файлов и базы данных и смене DNS-записей. Сложнее, если сайт использует внешние интеграции, завязанные на зарубежную инфраструктуру, — тогда перенос стоит планировать вместе с заменой самих интеграций, а не только смены адреса сервера.
Логирование согласий
Получить согласие недостаточно — нужно уметь подтвердить, что оно было получено, если это потребуется при проверке. Технически это означает фиксацию для каждого случая согласия: IP-адрес пользователя, точное время отметки чекбокса и версию текста согласия, под которым он поставил галочку (если текст политики менялся, важно знать, какую именно версию видел пользователь).
Это не требует сложной инфраструктуры — обычно достаточно отдельной таблицы в базе данных сайта или лог-файла, куда при отправке формы записывается эта информация вместе с самой заявкой.
Например, при отправке формы заявки вместе с именем и телефоном клиента в базу можно писать ещё три поля: IP-адрес отправителя, точное время отправки и хеш или версию текста согласия на момент отправки. Если через полгода политика изменится, а клиент обратится с претензией, эта запись покажет, какую именно версию текста он видел и на что фактически согласился — без такой фиксации доказать факт согласия при споре или проверке будет нечем, даже если чекбокс на сайте технически стоял правильно.
На практике так поступают немногие: большинство сайтов ограничивается самим чекбоксом без логирования. Это описанный выше идеальный вариант — то, к чему стоит стремиться, а не тот минимум, без которого сайт автоматически считается нарушителем.
Если сайт на конструкторе — Tilda, WordPress
Если сайт сделан на конструкторе, часть требований реализуется иначе, чем на сайте с собственным бэкендом:
- Tilda позволяет добавить чекбокс согласия в настройках формы, но объединение с другими чекбоксами (согласие на рассылку, оферта) нужно проверять и разводить вручную — по умолчанию конструкторы этого не делают правильно.
- WordPress — при использовании стандартных форм (Contact Form 7 и аналогов) чекбокс согласия придётся добавлять отдельным полем и следить, чтобы плагины аналитики не подключали внешние счётчики до согласия пользователя.
- В обоих случаях замена Google Analytics на Яндекс.Метрику делается через соответствующий плагин или встроенный блок конструктора — технически несложно, но требует проверки, что счётчик не загружается до согласия.
Если у сайта нет собственной серверной части и вся база данных живёт внутри конструктора — вопрос локализации во многом зависит от того, где сам конструктор хранит данные, и это стоит уточнять у площадки отдельно.
Что грозит, если сайт не привести в соответствие
| Нарушение | Норма | Штраф (ИП/юрлицо) |
|---|---|---|
| Хостинг не локализован в РФ | ч. 8 ст. 13.11 КоАП | 1 000 000 – 6 000 000 ₽ |
| Нет согласия на обработку / cookie | ч. 1 ст. 13.11 КоАП | 50 000 – 100 000 ₽ / 150 000 – 300 000 ₽ |
| Нет политики конфиденциальности | ч. 3 ст. 13.11 КоАП | 10 000 – 20 000 ₽ / 30 000 – 60 000 ₽ |
Нарушения на сайте — одна из самых заметных точек для проверки, потому что инспектору не нужно запрашивать документы очно: достаточно открыть сайт и посмотреть, что видно публично. Реальные примеры дел по этим нарушениям — в разделе судебной практики по ст. 13.11 КоАП.
Самостоятельно или доверить специалистам
Технически большинство этих правок несложные — это не редизайн сайта, а точечные изменения: добавить чекбокс, подключить cookie-баннер, заменить счётчик аналитики, проверить хостинг. Сложность обычно не в объёме работы, а в том, что изменения затрагивают две разные области — юридический текст (что именно написано в согласии и политике) и код (как это технически реализовано), и без координации между ними легко получить формально правильный текст, который на практике не работает, или наоборот — рабочий чекбокс без корректного юридического основания за ним.
По нашей практике, самая частая ошибка — не отсутствие чекбокса вообще, а чекбокс, который технически есть, но отмечен по умолчанию, или объединён с другим согласием, или ссылается на несуществующую страницу политики. Внешне сайт выглядит соответствующим требованиям, но при внимательной проверке это не так.
Если хотите закрыть это без переписки между юристом и разработчиком — можно заказать приведение сайта в соответствие под ключ: работают юрист и программист вместе, готово за 3 рабочих дня, без предоплаты.
Итог
Требования 152-ФЗ к сайту — это не общие пожелания, а конкретные технические детали: отдельный неотмеченный по умолчанию чекбокс, cookie-баннер до загрузки счётчиков, хостинг в РФ, легальная аналитика вместо Google Analytics, и логирование согласий на случай проверки. Самый резко подорожавший риск — локализация: с 1 июля 2025 года нарушение обходится до 6 000 000 ₽, и Google Analytics подпадает под это требование напрямую.
Если хотите проверить, что уже не так на сайте — начните с бесплатного аудита. Если нужно закрыть все пункты сразу — закажите приведение сайта в соответствие под ключ, юрист и программист вместе, 3 рабочих дня, без предоплаты. Дальше по теме: регистрация в реестре операторов персональных данных, комплект документов по 152-ФЗ и бесплатный генератор согласия и политики конфиденциальности.
Источники:
- КонсультантПлюс, подборка "Локализация персональных данных", проверено 2026-07-31
- Роскомнадзор, разъяснения от 14.12.2012 «О вопросах отнесения информации к персональным данным» (cookie-файлы, IP-адреса и идентификаторы устройства, позволяющие идентифицировать пользователя, — персональные данные), позиция подтверждена разъяснениями 2021 и 2023 годов; текст самого разъяснения на rkn.gov.ru недоступен для прямой сверки из этой среды, факт независимо подтверждён по нескольким юридическим изданиям (drc.law, ic-tech.ru, cyberosnova.ru), проверено 2026-09-29
- КонсультантПлюс, КоАП РФ, ст. 13.11, проверено 2026-07-31
- Внутренняя таблица штрафов по 152-ФЗ/КоАП, проверено 2026-07-31
Частые вопросы
Нужно ли менять хостинг, если сайт на Tilda или WordPress?
Зависит от того, где физически хранит данные сама платформа. Для сайтов с собственным бэкендом и базой данных — да, если текущий хостинг не в РФ: с 1 июля 2025 года сбор и первичная обработка персональных данных россиян обязаны идти только на серверах на территории России, и нарушение обходится в 1 000 000–6 000 000 ₽ по ч. 8 ст. 13.11 КоАП. Для сайтов полностью внутри конструктора — Tilda, некоторых тарифов WordPress без своей базы — вопрос локализации зависит от того, где хранит данные сама площадка, это нужно уточнять у неё отдельно, а не у хостинг-провайдера. На Tilda чекбокс согласия добавляется в настройках формы, но объединение с другими согласиями (рассылка, оферта) нужно разводить вручную — по умолчанию конструкторы делают это неправильно.
Можно ли использовать Яндекс.Метрику без согласия пользователя?
Нет. Яндекс.Метрика легальна с точки зрения требования локализации — её серверы находятся в РФ, в отличие от Google Analytics, где первичная обработка данных происходит за рубежом и подпадает под штраф 1 000 000–6 000 000 ₽. Но легальность по локализации не отменяет требование получить согласие пользователя на сбор данных: по разъяснениям Роскомнадзора cookie-файлы, включая IP-адрес и идентификаторы устройства, позволяют идентифицировать пользователя, а значит их сбор — тоже обработка персональных данных, требующая согласия до начала обработки, а не после. Технически это значит, что cookie-баннер должен появляться при первом визите и блокировать загрузку счётчика Метрики до того, как пользователь даст согласие, — сам факт, что сервис российский, эту обязанность не снимает.
Достаточно ли упомянуть cookie в политике конфиденциальности вместо отдельного баннера?
Нет. Согласие на обработку cookie нужно получить до начала обработки — то есть до того, как счётчики аналитики и рекламные виджеты загрузились и начали собирать данные о посетителе. Упоминание cookie в политике конфиденциальности информирует пользователя постфактум, но не заменяет активное согласие через баннер: это два разных основания обработки с разными требованиями по времени получения. Согласие на обработку персональных данных, введённых в форме, и согласие на cookie — тоже разные вещи, их нельзя объединить в один чекбокс или одну фразу в футере. На практике правильно настроенный cookie-баннер должен блокировать загрузку скриптов аналитики до клика пользователя, а не просто показывать уведомление параллельно с уже работающими счётчиками — именно это чаще всего проверяют при аудите сайта.
Обязательна ли политика конфиденциальности, если на сайте нет форм вообще?
Если на сайте действительно нет форм и не установлены счётчики аналитики, которые собирают данные о посетителях, формальной обработки персональных данных через сайт может не быть — и обязанность публиковать политику формально не возникает. Но на практике такое встречается редко: большинство сайтов используют хотя бы один счётчик аналитики вроде Яндекс.Метрики для оценки посещаемости, а сам факт его загрузки уже означает сбор данных о поведении посетителей, включая IP-адрес, — то есть обработку, требующую политики и согласия. Отсутствие политики конфиденциальности при уже идущей обработке — отдельное нарушение по ч. 3 ст. 13.11 КоАП, от 10 000 ₽ для ИП и от 30 000 ₽ для юрлица. Прежде чем полагаться на «у меня нет форм», стоит проверить сайт на наличие счётчиков — это самая частая причина, по которой формально статичная страница всё равно обрабатывает данные.
Что делать, если хостинг зарубежный, а домен .ru?
Доменная зона не имеет отношения к требованию локализации — важно физическое расположение сервера, где хранится и обрабатывается база данных сайта: CRM, база клиентов, форма заявок. Зарубежный хостинг с доменом .ru всё равно нарушает требование локализации, если на сайте обрабатываются персональные данные россиян, — домен .ru не гарантирует, что сервер физически находится в России, это два независимых параметра. Российские хостинг-провайдеры с дата-центрами в РФ закрывают формальное требование, но перед переносом стоит уточнить у провайдера конкретную юрисдикцию дата-центра — не все тарифы одного и того же провайдера обязательно физически в России. Сам перенос обычно не требует переделки кода, если сайт не завязан на специфичные сервисы конкретного хостинга, — сводится к копированию файлов, базы данных и смене DNS-записей.
Как должен технически выглядеть правильный чекбокс?
Отдельный элемент интерфейса, не отмеченный по умолчанию — пользователь должен поставить галочку сам, активным действием, а не увидеть уже проставленную. Согласие на обработку персональных данных должно быть отдельным чекбоксом, не объединённым с согласием на рассылку, cookie или публичной офертой в одном флажке — это правило действует с 24 июня 2025 года. Рядом с чекбоксом нужна прямая ссылка на политику обработки персональных данных, а не общая фраза без ссылки. И критически важный момент, который часто упускают: форма не должна отправляться без отмеченного чекбокса, причём проверка должна быть не только на фронтенде (атрибут required в HTML), но и на сервере — иначе требование легко обходится простым отключением JavaScript в браузере, и формально работающий чекбокс на практике ничего не гарантирует.
