Аудит сайта по 152-ФЗ: что находится на самом деле

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

Я провёл несколько таких аудитов — сайтов на разных движках и на собственном коде, с доступом к исходникам и без него. И каждый раз главные находки оказывались не там, где их ждали. Ни разу не в тексте политики. Разберу, что ищется на самом деле, чтобы вы могли проверить часть этого сами и понять, что вам показывают, если аудит заказан на стороне.

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

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

Проверка, с которой всё начинается

Не с документов. С реестра операторов персональных данных.

Это самая недооценённая проверка из всех и она определяет очерёдность остальных работ. По ст.22 ч.1 уведомить регулятора нужно до начала обработки. Дальше возможны три исхода и каждый меняет картину целиком.

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

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

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

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

Какие документы обязаны быть на сайте

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

Политика в отношении обработки персональных данных — ст.18.1 ч.2. Публикуется на сайте, доступ неограниченный. Это тот единственный документ, про который знают все.

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

Текст согласия на обработку персональных данных — если обработка идёт на основании согласия (ст.9). Прямой нормы «опубликуй текст согласия» в законе нет, обязанность выводится так: согласие должно быть конкретным, предметным, информированным, сознательным и однозначным — а информированным оно не будет, если человек текста не видел. И с 1 сентября 2025 года к этому добавилось требование оформлять согласие отдельно от иных информации и документов, о нём тоже ниже.

Что обычно добавляют сверх, считая обязательным:

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

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

Документы: четыре формулировки, которые встречаются постоянно

Тексты политик кочуют из шаблона в шаблон и вместе с ними кочуют одни и те же дефекты.

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

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

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

«Оператор вправе не информировать об утрате данных». Права субъекта даны законом, а не документом оператора. Документом они и не отбираются. Для операторов-юрлиц такие положения запрещены прямой нормой — ст.18.1 ч.1 п.2.

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

Второй документ, которого почти ни у кого нет

Та самая «другая часть статьи» — это ст.18.1 ч.2, второй пункт перечня выше. Возвращаюсь к нему отдельно, потому что он заслуживает отдельного разговора.

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

Требование при этом не новое и не из свежих поправок, на которые можно списать неведение: ст.18.1 появилась в законе ещё в 2011 году, а действующая редакция ч.2 — с 2022 года. Именно она прямо говорит про страницы того самого сайта, с использованием которых собираются данные. Оговорки «являющемуся юридическим лицом» в ч.2 нет — в отличие от пунктов ч.1, о которых шла речь выше. То есть ИП это касается ровно так же.

Что в нём должно быть. Формы закон не задаёт и обязательного перечня разделов не устанавливает, поэтому содержание выводится из ст.19: правовые, организационные и технические меры, которыми оператор обеспечивает безопасность данных. На практике получается четыре блока: организационные меры (у кого есть доступ к обращениям, где живут доступы к почте и ключи от сервисов, проходят ли изменения сайта проверку до выкладки); технические меры уровня приложения (что и куда пишется, какие сроки хранения, что удаляется автоматически, как ограничивается частота обращений, чем отсекаются роботы); меры уровня транспорта и браузера (HTTPS, шифрованный канал до почтового сервера, политика безопасности содержимого, security-заголовки, контроль уязвимостей в зависимостях); и контроль — проводился ли аудит и где ведётся статус устранения находок.

Три правила, которые отличают полезный документ от вредного:

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

Чем грозит отсутствие. Отдельным составом — ч.3 ст.13.11 КоАП. Он сформулирован буквально про этот случай: невыполнение обязанности опубликовать (или иным образом обеспечить неограниченный доступ) документ о политике или сведения о реализуемых требованиях к защите данных. Обратите внимание: для него не нужны ни утечка, ни жалоба субъекта, ни выездная проверка — достаточно открыть сайт и не найти документ. Ровно тот тип нарушения, который выявляется автоматизированным мониторингом. И ИП назван в этой части отдельной категорией: сумма для него своя — ни как для должностного лица, ни как для организации.

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

Главное расхождение — не внутри документа

Самое ценное, что даёт аудит с доступом к исходному коду сайта, звучит скучно: сверка текста политики с тем, что сайт делает в действительности.

Здесь ищут расхождения вроде таких: в политике не упомянут IP-адрес посетителя, а он пишется в журнал сервера и этот журнал с IP — это тоже хранилище персональных данных. Не упомянуты третьи лица, а заявки уходят через внешний почтовый сервис — и это, как правило, квалифицируют как поручение обработки, а ст.6 ч.3 требует для него согласия субъекта и договора с обязательным составом условий: перечень данных, перечень действий, цели, конфиденциальность, требования к защите по ст.19. Ответственность перед субъектом при этом всё равно остаётся на операторе (ч.5). Назван срок хранения — но есть ли код, который по этому сроку данные действительно удаляет? Бывает — есть, бывает — срок существует только в виде фразы в документе.

Ни одно из таких расхождений не видно при чтении документа. Они видны только при сравнении документа с кодом и именно поэтому аудит, который прочитал политику и вынес вердикт, стоит недорого, но и не даёт почти ничего.

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

Формы: самое дорогое место

Возможно, это самая поучительная находка из всех и вывод у неё неожиданный.

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

А данные всё равно уходят на сервер)))

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

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

Проверяется это чтением кода, а не глазами. По внешнему виду форма ведёт себя безупречно…

Согласие, которое невозможно доказать

Ещё одна вещь, которую почти никто не закладывает заранее. Бремя доказывания согласия лежит на операторе — ст.9 ч.3.

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

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

Отдельно замечу про изменения в законе 2025 года: с 1 сентября согласие требуется оформлять отдельно от иных информации и (или) документов, которые подтверждает и (или) подписывает субъект — это ст.9 ч.1, новое предложение, добавленное 156-ФЗ. Ссылка из чекбокса на политику конфиденциальности этого требования не выполняет: политика и согласие — разные документы с разным назначением.

Формулировку часто пересказывают как «отдельно от иных согласий» — это другая норма и другой случай. «Отдельно от иных согласий» сказано в ст.10.1 про согласие на распространение персональных данных, а к обычной форме заявки оно не относится. Разница не декоративная: требование ст.9 шире, оно про «информацию и документы» вообще, то есть одной галочкой накрыть согласие на обработку и, скажем, принятие пользовательского соглашения больше нельзя. А вот что именно считать «отдельным оформлением» в интерфейсе — закон не определяет; всё, что вы прочитаете про «две галочки» или «отдельный экран» — это практика, а не цитата нормы.

Где на самом деле лежат ваши заявки

Вопрос, на который почти никто не может ответить сразу: сколько копий одной заявки существует через месяц после её отправки?

Типовой маршрут выглядит так. Человек отправил форму — запрос попал в журнал веб-сервера вместе с IP. Дальше данные легли в базу сайта. Оттуда ушло письмо на рабочую почту и осталось там навсегда, плюс копия в «Отправленных» у того, кто переслал её коллеге. Потом заявку завели в CRM. А ещё кто-то однажды выгрузил заявки за какой-то период в таблицу, чтобы посчитать конверсию и файл остался лежать на сервере.

Шесть мест. В политике описано одно.

Юридически это важно, потому что срок хранения относится не к «основной базе», а к персональным данным как таковым. Ст.21 называет сроки прямо: при достижении цели обработки данные уничтожаются в срок не более тридцати дней (ч.4), при отзыве согласия — тоже тридцать дней (ч.5), а если выявлена неправомерная обработка, то прекратить её нужно за три рабочих дня и уничтожить данные за десять (ч.3). Оговорки в частях 4 и 5 есть — иное может быть предусмотрено договором с субъектом или другим основанием обработки, но они про основание хранить дальше, а не про право не знать, где лежат данные. Если код честно чистит базу по расписанию, а те же самые данные продолжают жить в почтовом ящике и в выгрузке — срок не исполнен. Автоматическая уборка в базе при этом создаёт очень убедительную иллюзию порядка.

Три места, куда стоит посмотреть в первую очередь:

Почта. Самое частое хранилище персональных данных, о котором не думают как о хранилище. Заявки за пять лет, поиском по ящику, у нескольких сотрудников сразу.
Резервные копии. Здесь я честно скажу, что простого решения нет: выборочно удалить одну запись из архива нельзя, не сломав сам архив. Работающий подход — ограниченный срок жизни самих копий, чтобы данные в них истекали сами, а не лежали «на всякий случай» вечно.
Выгрузки на сервере. Файл zayavki.csv, оставленный в общедоступном каталоге сайта — это уже не хранение, а публикация: он отдаётся по прямой ссылке любому, кто угадает имя. Проверять это надо не глазами по FTP, а запросом по HTTP — и отдельно проверять, не лежит ли там же файл самой базы.

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

Запрос субъекта: письмо, на которое нечем ответить

Приходит письмо: «пришлите все данные, которые вы обо мне храните, а затем удалите их». Это не экзотика и не угроза — это ст.14, право на доступ.

Отвечать на такое письмо приходится содержательно. Перечень того, что оператор обязан сообщить, дан в ст.14 ч.7 и он длиннее, чем кажется: подтверждение самого факта обработки, правовые основания и цели, применяемые способы, кто имеет доступ к данным, сами данные и источник их получения, сроки хранения, порядок реализации прав, сведения о трансграничной передаче, кому обработка поручена — и отдельным пунктом информация о том, как оператор исполняет обязанности по ст.18.1, то есть те самые меры защиты из второго документа.

Срок — десять рабочих дней с момента обращения. Продлить можно, но не более чем на пять рабочих дней и только направив мотивированное уведомление с причинами (ст.14 ч.3, ст.20 ч.1). Никакого «месяца» здесь нет, а две недели — это ровно тот срок, за который нужно найти данные во всех шести местах из предыдущего раздела. Если данные подтверждённо неполны, неточны или неактуальны — на исправление даётся семь рабочих дней; столько же на уничтожение, если подтверждено, что данные получены незаконно или не нужны для заявленной цели (ст.20 ч.3).

Оговорки «являющемуся юридическим лицом» ни в ст.14, ни в ст.20 нет — к ИП это относится полностью. Составы за неисполнение отдельные: не предоставил информацию — ч.4 ст.13.11 КоАП, не уточнил и не уничтожил в срок — ч.5.

Техническая часть здесь звучит скучно, но именно она решает: исполнимость — это процедура, а не строчка в политике. Проверять надо четыре вещи.

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

И встречная оговорка, чтобы не переусердствовать: закон требует и от самого запроса вполне конкретных реквизитов — номер документа, удостоверяющего личность, сведения, подтверждающие участие в отношениях с оператором, подпись (ст.14 ч.3). Удалять чужие данные по анонимному письму «удалите всё про Иванова» нельзя: так вы исполните не право субъекта, а чужую атаку.

Утечка: двадцать четыре часа

Последний сюжет, который в аудитах всплывает крайне редко — а норме уже несколько лет.

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

Три важные детали:

Часы считаются от момента выявления и выявить может не оператор. В норме прямо сказано: с момента выявления инцидента оператором, уполномоченным органом «или иным заинтересованным лицом». То есть отсчёт может начаться от чужого обнаружения — а вы об этом узнаете не первым.
Норма не новая. Она введена в 2022 году и действует с 1 сентября 2022 года. Оговорки про юридическое лицо в ней нет — обязательства ИП такие же.
А вот ответственность здесь устроена наоборот привычному. Состав за неуведомление — ч.11 ст.13.11 КоАП, она появилась позже и действует с 30 мая 2025 года. И по примечанию к статье индивидуальные предприниматели отвечают по этой части как юридические лица — примечание распространяет такое приравнивание на части с 8 по 18 и в этот диапазон попадает ч.11. То есть обычная поправка «ИП отвечает мягче, как должностное лицо», верная для документарных нарушений, именно здесь не работает.

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

Иностранные сервисы: они не одинаковы

Технически это один класс — запросы на зарубежные хосты. Юридически они очень разные и смешивать их нельзя: слабый пункт утянет за собой в бездну сильные.

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

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

Чего в честном аудите быть не должно

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

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

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

Что можно проверить самому за вечер

Семь пунктов, не требующих ни разработчика, ни юриста:

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

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

Если хотите понять, как обстоят дела на вашем сайте — напишите, посмотрим. Техническую часть я разбираю сам, а по текстам документов скажу честно — здесь нужен юрист (ваш или привлеченный, с опытом работы в сфере законодательства о защите персональных данных). Обращайтесь, решим вашу задачу!