Как проверить сайт по 152-ФЗ: технический чек-лист

Начните проверку с одной заявки: какую форму видит посетитель, что происходит после её отправки и где сотрудник получает обращение. Ссылка на политику объясняет только часть этого пути. Остальные сведения придётся сопоставить с настройками и обработчиком. Чек-лист помогает собрать такую карту и отделить наблюдаемую проблему от вопроса, для которого пока нет подтверждения.

Этот чек-лист помогает собрать технические факты. Он не определяет законность деятельности компании целиком. Правовую квалификацию конкретного процесса, документы и обязанности оператора следует проверить с профильным специалистом. Источники сверены 8 октября 2026 года.

Подготовьте безопасную проверку

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

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

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

A. Что проверяется публично

Пункт	Как посмотреть	Какое доказательство сохранить
Политика открывается	Перейти по ссылке без авторизации	URL, дата, код ответа, заголовок документа
Документы доступны до действия	Найти ссылки рядом с формой	Скриншот формы и точный адрес каждой ссылки
Согласие выделено отдельно	Посмотреть текст и механизм подтверждения	Наблюдение об интерфейсе; правовой вывод оставить юристу
Выбор пользователя сохраняется корректно	Сравнить первый визит и повторное открытие настроек	Сценарий и состояния интерфейса
Аналитика следует принятому выбору	На стенде сравнить запросы до выбора, при отказе и разрешении	Имена получателей и типы запросов без пользовательских идентификаторов
Нет данных в адресной строке	Проверить URL страниц и проектируемый способ отправки	Имена параметров, без значений личных данных
Внешние включения учтены	Посмотреть подключённые скрипты, iframe, виджеты	Домен, назначение, страница, способ подключения
Документ читается с телефона	Открыть ссылки и проверить масштабирование	Скриншот и описание проблемы доступности

Отметьте, использует ли форма согласие как выбранное основание. Если да, проверьте исходное состояние управляющего элемента и понятность действия. Требование отдельного оформления согласия содержится в статье 9 152-ФЗ; конкретная форма подтверждения зависит от сценария. Чекбокс — технический способ реализации, а не универсальное основание обработки.

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

B. Что проверяется с доступом владельца

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

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

Доступ предоставляется в минимальном объёме. Для проверки часто достаточно демонстрации экрана и обезличенного примера настройки. Не передавайте аудитору базу заявок только потому, что её легко выгрузить.

C. Что требует юридической оценки

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

При сборе через интернет оператор обязан опубликовать политику и сведения о реализуемых требованиях к защите на страницах, через которые собираются данные, и обеспечить доступ к ним по части 2 статьи 18.1. Проверка ссылки подтверждает доступность, но не полноту содержания. Уведомление рассматривается по статье 22, а местонахождение баз при сборе — по части 5 статьи 18. Эти вопросы не закрываются оценкой «галочка есть».

Типичные ошибки и порядок исправления

Наблюдение	Первый следующий шаг	Как проверить исправление
Ссылка на документ ведёт в 404	Восстановить доступ к утверждённому документу	Открыть без входа с обеих версий сайта
Баннер скрывается, а счётчик работает независимо от выбора	Разобрать все точки подключения	На стенде сравнить три состояния и повторный визит
Согласие объединено с принятием других документов	Согласовать разделение с юристом	Сверить новый интерфейс и доказательство получения
У формы два незадокументированных получателя	Подтвердить необходимость каждой передачи	Сопоставить настройки с маршрутом и тестом
Удаление в CRM оставляет копию в CMS	Описать все хранилища	Провести согласованный тест удаления синтетической записи

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

Оформите результат так, чтобы другой человек мог его повторить

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

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

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