152-ФЗ: требования к сайту, которые касаются даже лендинга с одной формой

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

Кого закон касается на самом деле

Самый живучий миф звучит так: «152-ФЗ — это про банки, операторов связи и большие компании, у которых есть отдел безопасности». Закон устроен иначе. Он оперирует понятием оператор — это тот, кто организует или ведёт обработку персональных данных. Не «крупный», не «лицензированный», не «с оборотом от». Организационно-правовая форма роли не играет: индивидуальный предприниматель с лендингом на одну страницу — такой же оператор, как федеральная сеть.

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

Достаточно, чтобы на сайте было хоть что-то из этого:

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

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

Практический минимум для обычного сайта

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

1. Политика обработки персональных данных — опубликована и доступна

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

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

2. Согласие — отдельное осознанное действие

Не годится:

• одна галочка «согласен с условиями, офертой и политикой» на всё сразу;
• предустановленная галочка;
• надпись мелким шрифтом «нажимая кнопку, вы соглашаетесь» вместо самого действия.

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

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

3. Уведомление в Роскомнадзор — до начала обработки

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

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

4. Трансграничная передача — отдельное уведомление

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

Что часто оказывается зарубежным, хотя об этом не задумываются:

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

5. База с данными граждан РФ — на территории России

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

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

6. Права человека, чьи данные вы собрали

Человек вправе узнать, какие его данные у вас есть и откуда они, потребовать уточнить неверные, удалить лишние и отозвать согласие. Отозвать согласие должно быть не сложнее, чем его дать.

Для сайта это означает рабочий канал: адрес почты в политике, который кто-то реально читает, и внутренний порядок — кто отвечает, в какой срок, кто идёт удалять строку из CRM, из почтового ящика и из той выгрузки в таблице, о которой все забыли.

7. Меры защиты — статья 19

Закон не выдаёт список «купите вот это». Статья 19 требует принимать организационные и технические меры, достаточные для защиты данных от неправомерного доступа, копирования, изменения и уничтожения. Формулировка намеренно широкая, и в этом её сложность: закрыть её одной покупкой нельзя.

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

Где безопасность сайта становится юридическим вопросом

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

Разберём цепочку на понятном примере. У вас магазин на популярной CMS. Полгода назад в плагине, который выводит форму заявки, нашли уязвимость и выпустили обновление. Обновление вы не поставили — сайт же работает, зачем трогать. Через эту уязвимость кто-то выгружает таблицу заказов: имена, телефоны, адреса доставки.

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

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

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

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

Что бывает за нарушения

Ответственность здесь не одна, а несколько разных, и смешивать их не стоит.

• Административная — статья 13.11 КоАП. Это зонтичная статья про нарушения законодательства о персональных данных, внутри неё несколько разных составов: обработка без согласия, обработка, несовместимая с заявленными целями, отсутствие опубликованной политики, невыполнение требования человека об уточнении или удалении данных. Санкции по разным составам сильно различаются и назначаются отдельно на должностное лицо и на организацию.
• Отдельно и заметно жёстче — за утечку персональных данных. Санкции в этой части существенно ужесточили в 2025 году: для юридических лиц штрафы измеряются миллионами рублей, а для повторных случаев предусмотрены оборотные штрафы, привязанные к выручке. Появилась и уголовная ответственность за незаконный оборот персональных данных. Конкретные суммы и пороги смотрите в действующей редакции КоАП — это ровно та часть, которую бессмысленно цитировать по памяти.
• Неподанное уведомление — самостоятельное нарушение и при этом самое дешёвое в устранении: подача бесплатна и занимает вечер.
• Предписания и ограничение доступа. Помимо штрафа регулятор может выдать предписание об устранении нарушения, а нарушение требования о размещении базы в России — отдельная история, по которой применялись меры вплоть до ограничения доступа к ресурсу.

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

Проверьте у себя за 15 минут

1. Политика открывается по прямой ссылке? Откройте сайт в режиме инкогнито и найдите ссылку в подвале. Если политика существует только в виде файла у юриста — считайте, что её нет.
2. Согласие отдельное? Пройдите по всем формам сайта, включая всплывающие и те, что в подвале. У каждой должен быть непредустановленный чекбокс именно про обработку персональных данных, а ссылка из него — вести на живую страницу. Рассылка — отдельным чекбоксом.
3. Уведомление подано? Это проверяется без юриста: откройте реестр операторов на сайте Роскомнадзора и поищите себя по ИНН. Если вас там нет — вот самый быстрый пункт для исправления из всего списка.
4. Где физически лежит база? Посмотрите в панели хостинга или спросите подрядчика: страна размещения сайта, CRM, почтового сервиса и резервных копий.
5. Куда уходят данные из форм? Откройте страницу с формой и посмотрите, какие сторонние скрипты на ней подключены: чат, аналитика, капча, конструктор форм, коллтрекинг. Каждый такой сервис — получатель данных, которого нужно указать в политике; если он зарубежный, добавляется уведомление о трансграничной передаче.
6. Есть ли https на страницах с формами? Проверьте, открывается ли сайт по http:// без переадресации на https://. Форма, отправляющая имя и телефон по незашифрованному каналу, — проблема и техническая, и по существу требований к защите.
7. Кто отвечает и что будет завтра? Представьте, что утром приходит письмо «удалите мои данные и пришлите подтверждение». Кто его увидит, за какой срок ответит и где будет искать эти данные? Если ответа нет — это решается за час и стоит ноль рублей.

Первые три пункта закрываются документами и одной подачей формы. Четвёртый и пятый — разговором с подрядчиком. Шестой — технический и решается за день. Седьмой не требует ничего, кроме решения.