Какие требования закон предъявляет к сайту компании

Кого это касается

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

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

Сбором данных на сайте оказывается почти любой интерактивный элемент. Полный список для обычного корпоративного сайта выглядит так:

• Форма заявки или обратной связи — имя, телефон, почта
• Подписка на рассылку — хотя бы адрес почты
• Заказ обратного звонка — номер телефона
• Онлайн-чат и виджеты мессенджеров, если в них передаётся контакт
• Личный кабинет и регистрация
• Запись на приём или бронирование времени
• Отзывы и комментарии, подписанные именем
• Отправка резюме на вакансию

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

Уведомление в Роскомнадзор

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

Этого списка больше нет. Пункты 1–6 части 2 статьи 22 утратили силу с 1 сентября 2022 года — их отменил закон 266-ФЗ от 14 июля 2022 года. В действующей редакции исключений осталось три: обработка в государственных информационных системах, созданных для защиты безопасности государства и общественного порядка; обработка исключительно без использования средств автоматизации; обработка в случаях, предусмотренных законодательством о транспортной безопасности.

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

Что указывается в уведомлении

Состав сведений задан частью 3 той же статьи. Заполнение занимает не час: половина пунктов требует решений, которых у компании обычно ещё нет.

• Наименование и адрес оператора
• Цель обработки — по каждой цели отдельно
• Описание мер по статьям 18.1 и 19, включая сведения о средствах шифрования
• Ответственный за организацию обработки и его контакты
• Дата начала обработки
• Срок или условие прекращения обработки
• Сведения о трансграничной передаче
• Место нахождения базы данных с данными граждан России
• Сведения об обеспечении безопасности по требованиям Правительства

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

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

Согласие в формах и как его оформить

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

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

• Галочка не проставлена заранее. Предзаполненный чекбокс — не однозначное согласие, потому что человек не совершал действия
• Одна цель — одно согласие. Формулировка «согласен со всем» не конкретна и не предметна
• Рассылка — отдельным согласием от обработки заявки. Это разные цели, и объединять их нельзя
• Рядом с кнопкой — ссылки на политику и на текст самого согласия, чтобы согласие было информированным
• Указан способ отзыва согласия: человек вправе его отозвать, и ему нужно знать, куда писать
• Форма не отправляется, пока галочка не поставлена — иначе согласия просто нет

Отдельный пункт — доказывание. По части 3 статьи 9 обязанность доказать, что согласие получено, лежит на операторе. На практике это означает, что факт отправки формы нужно сохранять: дата, время и та версия текста согласия, которая была показана человеку в тот момент. Если текст согласия на сайте правили трижды, а в журнале отправок лежит только «заявка принята», подтвердить получение согласия нечем.

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

Политика обработки: почему шаблон не работает

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

Формально это закрывается ссылкой в подвале. Содержательно — нет, и причина в части 1 той же статьи: политика должна определять цели, категории и перечень данных, категории субъектов, сроки хранения, порядок уничтожения и процедуры предотвращения нарушений. То есть описывать то, что действительно происходит на конкретном сайте, а не то, что в принципе бывает.

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

• В политике три цели обработки, а на сайте пять форм с разными целями
• Сроки хранения не названы или названы формулой «до достижения целей», которая ничего не ограничивает
• Передача данных третьим лицам не упомянута, хотя заявки уходят в CRM, рассылочный сервис и систему аналитики
• Ответственный за организацию обработки в политике есть, а приказа о его назначении нет
• Упомянут личный кабинет, которого на сайте не существует, — признак, что документ взят целиком у кого-то другого

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

Cookie и согласие

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

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

Практический минимум, который закрывает большинство ситуаций обычного корпоративного сайта:

• Сообщить о применении cookie заметно, а не сноской в подвале
• Разделить технические и рекламно-аналитические cookie в тексте уведомления и в политике
• Не ставить рекламные и аналитические идентификаторы до действия пользователя, если без них сайт работает
• Дать возможность отказаться и описать последствия отказа
• Перечислить в политике сервисы, которым уходят данные, — счётчики и рекламные системы в том числе

Баннер, который нельзя закрыть, не согласившись, положение не улучшает: по части 1 статьи 9 согласие даётся свободно. Конструкция «согласитесь или уходите» свободной не выглядит, и формальное наличие баннера в этом случае скорее фиксирует нарушение, чем устраняет его.

Локализация данных и иностранные сервисы

Часть 5 статьи 18 сформулирована как запрет, и это важно читать буквально: при сборе персональных данных, в том числе через интернет, запись, систематизация, накопление, хранение, уточнение и извлечение данных граждан Российской Федерации с использованием баз данных, находящихся за пределами территории Российской Федерации, не допускаются, за исключением случаев, указанных в пунктах 2, 3, 4 и 8 части 1 статьи 6.

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

На сайте это всплывает в местах, которые редко считают частью темы персональных данных:

• Форма, которая отправляет заявку напрямую в зарубежный сервис сбора заявок
• CRM или таблица, физически расположенная за пределами России
• Сервис рассылок, куда адрес почты попадает первым, минуя российскую базу
• Онлайн-чат, хранящий переписку с контактами на зарубежной площадке
• Хостинг сайта, если на нём же лежит база с заявками

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

Нарушения и штрафы

Ответственность установлена статьёй 13.11 КоАП. Действующие размеры заданы законом 420-ФЗ от 30 ноября 2024 года и применяются с 30 мая 2025 года. В таблице — суммы для юридических лиц по тем составам, которые реально касаются обычного корпоративного сайта; для граждан и должностных лиц суммы ниже и приведены в тексте статьи. Данные актуальны на 31 октября 2026 года.

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

Отдельно стоит знать, что частями 12–18 той же статьи введена ответственность за утечки, вплоть до оборотных штрафов, считаемых от выручки. К сайту-витрине с журналом заявок это обычно не относится, но относится к любому сайту, где накопился сколько-нибудь объёмный массив данных: личные кабинеты, база подписчиков, история заказов.

Чек-лист самопроверки

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

• 1. Выпишите все формы и элементы сайта, где человек оставляет о себе что-либо. Не по памяти, а пройдя сайт целиком, включая подвал и всплывающие окна
• 2. Для каждой формы назовите цель обработки своими словами. Если цель одна и та же, формы можно объединить; если разные — у них должны быть разные согласия
• 3. Выпишите, куда данные уходят после отправки: почта, CRM, мессенджер, рассылка, аналитика. Для каждого сервиса выясните, где физически хранится запись
• 4. Проверьте уведомление в Роскомнадзор: подано ли оно вообще и соответствуют ли поданные сведения текущему составу форм и целей
• 5. Откройте политику и сверьте её с результатами шагов 1–3. Расхождения исправьте в политике, а не в памяти
• 6. Проверьте формы: галочка не проставлена заранее, рассылка отделена от заявки, ссылки на политику и текст согласия на месте, способ отзыва указан
• 7. Убедитесь, что факт согласия сохраняется с датой и версией текста, а не только сама заявка
• 8. Назначьте ответственного за организацию обработки приказом, а не упоминанием в политике
• 9. Повторяйте шаги 1–3 при каждом изменении сайта: новая форма означает новую цель и, возможно, новые сведения в уведомлении

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

Это обзор требований, а не юридическая консультация: мы студия разработки и говорим о том, как требования закона ложатся на устройство сайта. Формулировки и суммы приведены по состоянию на 31 октября 2026 года со ссылками на действующие редакции; закон меняется, и перед решениями стоит сверяться с текстом статей и при необходимости с юристом.