Методология ручной проверки сайта по 152-ФЗ

Обновлено: 21 мая 2026

Почему проверка начинается с пути пользователя

Методология ручной проверки сайта по 152-ФЗ строится вокруг простого вопроса: что происходит с персональными данными пользователя от момента захода на сайт до отправки заявки, подписки, сообщения в чат или принятия cookie? Именно этот путь показывает реальные зоны риска.

На сайте могут быть корректные документы, но пользователь не видит ссылку на них до отправки формы. Может быть политика обработки персональных данных, но в ней не указаны cookie, рекламные пиксели, чат или CRM. Может быть чекбокс согласия, но он объединяет разные цели: обратную связь и рекламную рассылку. Поэтому ручная проверка сопоставляет не отдельные элементы, а всю цепочку: форма → согласие → документ → сервис → цель обработки.

Этап 1. Составляем карту точек сбора данных

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

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

На этом этапе важно не предполагать, а смотреть, что реально есть на сайте. Даже небольшая форма «Имя + телефон» уже является точкой сбора персональных данных и должна быть связана с понятным правовым основанием, текстом согласия и политикой.

Этап 2. Проверяем, что видит пользователь до отправки данных

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

Ключевые вопросы проверки:

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

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

Этап 3. Сопоставляем документы с реальным сайтом

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

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

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

Этап 4. Проверяем cookie, аналитику и внешние сервисы

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

В рамках проверки фиксируется:

• появляется ли cookie-баннер при первом посещении;
• есть ли возможность отказаться от необязательных cookie;
• какие скрипты и сервисы видны на сайте;
• описаны ли cookie и технические данные в политике;
• совпадает ли текст баннера с фактическим использованием cookie;
• не обещает ли сайт «только технические cookie», если установлены аналитические или рекламные инструменты;
• есть ли отдельная логика для рекламных целей.

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

Этап 5. Оцениваем риск и приоритет исправления

Не все замечания одинаковы по срочности. Поэтому методология должна включать приоритизацию. В отчете можно использовать три уровня:

Высокий приоритет. Данные отправляются без обязательного согласия, документы отсутствуют или ссылки не работают, цели обработки не соответствуют форме, рекламное согласие смешано с обязательным, cookie и рекламные пиксели не раскрыты.

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

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

Такая приоритизация помогает не спорить о каждом пункте, а быстро закрыть наиболее заметные риски.

Почему автосканера недостаточно

Автосканер может помочь найти отдельные признаки: наличие формы, слова «персональные данные», cookie-скрипты, ссылки на документы. Но автосканер не всегда понимает контекст. Он не проверяет, согласована ли цель формы с политикой, разделены ли разные согласия, видит ли пользователь текст до отправки, совпадает ли баннер с реальными cookie и кто должен исправить проблему.

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

Что не входит в базовую методологию проверки сайта

Базовая проверка публичной части сайта не является полной проверкой всех процессов компании. Она не заменяет:

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

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

Что получает клиент по итогам методологии

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

Отчет можно использовать как техническое задание для:

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

Вопросы и ответы

Почему проверка строится вокруг пользователя, а не вокруг документов?

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

Можно ли провести проверку без доступа в админку?

Для базовой проверки публичной части сайта доступ в админку не требуется. Проверяются видимые формы, тексты, документы, cookie-баннеры, скрипты и путь заявки. Доступы могут понадобиться только для расширенного аудита внутренних процессов или CRM.

Что считается результатом ручной проверки?

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

Как часто нужно повторять проверку?

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

Можно ли использовать методологию для самостоятельной проверки?

Да, по этой логике можно провести первичную самопроверку. Но ручной отчет полезен тем, что связывает найденные элементы в единую картину и формирует конкретный план исправлений.