# Audit 152fz

> Аудит сайта, лендинга или веб-сервиса на соответствие 152-ФЗ «О персональных данных» и смежному регулированию (локализация, трансграничная передача, уведомление РКН, cookie, рассылки). Выдаёт отчёт-чеклист со статусами по каждому требованию, ссылками на нормы, оценкой риска по ст. 13.11 КоАП и планом исправлений, который Claude может выполнить сразу. Используй этот скилл всегда, когда речь заходит о проверке сайта на 152-ФЗ, ФЗ-152, персональных данных на сайте, политике конфиденциальности или политике обработки ПДн, согласии на обработку, галочке согласия в форме, cookie-баннере, уведомлении Роскомнадзора, локализации данных в РФ, подготовке к проверке РКН, штрафах за персданные — даже если пользователь не произносит слово «аудит» и просто спрашивает «всё ли у меня по закону с формой заявки» или «нужно ли мне согласие на cookie».

- Skill: `qlasse/audit-152fz` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add qlasse/audit-152fz`
- Raw SKILL.md: https://api.skillmd.com/api/skills/qlasse/audit-152fz/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: Qlasse (https://skillmd.com/u/qlasse)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/qlasse/audit-152fz

---


# Аудит сайта на соответствие 152-ФЗ

## Что это и зачем

Владелец сайта почти всегда является оператором персональных данных — достаточно одной формы обратной связи. Практически весь риск концентрируется в вещах, которые видны снаружи: опубликована ли политика, как оформлено согласие, куда физически уходят данные из формы, подано ли уведомление в Роскомнадзор. Роскомнадзор с 2024–2025 годов сканирует сайты автоматически и приходит с предписанием на 10 рабочих дней ещё до всякой проверки, а суммы штрафов после реформы КоАП от 30.05.2025 выросли на порядок.

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

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

## Соразмерность: три формата вместо одного

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

Определи формат по запросу, прежде чем начинать:

**Разговорный ответ.** Пользователь задал вопрос, а не заказал проверку: «нужно ли мне согласие на cookie», «достаточно ли галочки», «попаду ли я на штраф». Признаки — вопросительная интонация, отсутствие файлов и URL, короткое сообщение. Отвечай в чате, без файла: что из перечисленного скорее всего в порядке, что точно проблема и почему, что нужно уточнить. Чеклист в этом случае — твой внутренний инструмент, а не структура ответа; в текст попадают только сработавшие пункты. Ориентир — до полутора-двух страниц. В конце уместно одной строкой предложить полный аудит, если пользователь даст URL или документы.

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

**Полный аудит.** Пользователь просит проверку сайта, готовится к РКН, дал доступ и документы. Здесь работает весь процесс ниже целиком и отчёт по шаблону со всеми блоками, включая ➖.

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

## С чего начать

### Шаг 1. Проверить, не устарела ли нормативная база

Прочитай `references/legal-base.md` — там даты редакций и вся фактура по нормам и штрафам. В шапке файла указано, на какую дату он актуален. **Если с этой даты прошло больше двух-трёх месяцев, сделай один-два поиска** («изменения 152-ФЗ [текущий год]», «статья 13.11 КоАП изменения») и отметь расхождения. Законодательство о ПДн меняется несколько раз в год, и отчёт со ссылкой на отменённую норму дискредитирует всю работу.

### Шаг 2. Собрать вводные

Спроси пользователя (одним коротким блоком, не по одному вопросу):

1. **URL сайта** — и есть ли закрытые разделы (личный кабинет, оформление заказа), куда нужен доступ.
2. **Документы**, если есть: политика обработки ПДн, тексты согласий, приказы, перечень ИСПДн, договоры поручения.
3. **Кто оператор**: юрлицо / ИП / физлицо, наименование, ИНН — понадобится для проверки в реестре РКН.
4. **Где хостинг и где лежат данные из форм**: хостинг-провайдер, CRM, почтовый сервис, сервис рассылок, чат.
5. **Подано ли уведомление в Роскомнадзор** и когда.

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

### Шаг 3. Собрать данные о сайте

Порядок предпочтений — от лучшего к худшему, бери первое доступное:

**А. Браузер (Claude in Chrome).** Даёт то, чего не даёт ничто другое: реальный DOM после исполнения скриптов, сетевые запросы к сторонним хостам, cookie, поведение баннера. Открой главную, страницу с формой, страницу политики. Сними исходник страницы, посмотри `read_network_requests` (куда уходят запросы) и cookie до и после взаимодействия с баннером.

**Б. WebFetch.** Читает текст политики и согласий — этого достаточно для содержательной части блоков B и C. Скрипты и cookie так не увидеть.

Не пытайся обходить ограничения фетчинга через curl, wget или python-requests — если инструменты веб-доступа не отдают страницу, честно зафиксируй, что проверить не удалось, и попроси пользователя прислать сохранённый HTML (Ctrl+S → «веб-страница полностью»).

**Разбор HTML — скриптом, не глазами.** Как только у тебя есть HTML любой страницы (сохранённый браузером или присланный пользователем), прогони его через:

```bash
python3 scripts/analyze_page.py page.html [другие.html ...] --json out.json
```

Скрипт находит формы и их поля, состояние чекбоксов (`checked` — это прямое нарушение ст. 9), ссылки на политику и согласия, сторонние скрипты/пиксели/iframe с разметкой по юрисдикции, признаки cookie-баннера. Он делает за секунду то, на что уходит десять минут чтения разметки, и не пропускает скрытый `<input type="hidden">` или счётчик, вставленный через GTM. Результат — вход для блоков C, D и E чеклиста, но не замена им: скрипт видит разметку, а квалификацию даёшь ты.

### Шаг 4. Пройти чеклист

Открой `references/checklist.md` — девять блоков, A–I, около полусотни пунктов. По каждому пункту там указано: норма, что именно смотреть, признаки нарушения и статья КоАП с суммой.

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

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

### Шаг 5. Написать отчёт

Для полного аудита и экспресс-проверки формат — в `references/report-template.md`. Его структура построена так, чтобы владелец сайта увидел главное в первые тридцать секунд, а потом смог погрузиться в детали. Для разговорного ответа шаблон не нужен: сохрани только логику «сначала вывод, потом почему, потом что делать».

## Как ставить статусы

Пять статусов, и разница между ними важнее, чем кажется:

| Статус | Когда ставить |
|---|---|
| ✅ **Соответствует** | Требование выполнено, ты это видел или подтвердил документом |
| ❌ **Нарушение** | Требование не выполнено, есть наблюдаемый признак — можно назвать статью КоАП |
| ⚠️ **Риск** | Формально не нарушено, но конструкция уязвима: спорная квалификация, серая зона, скорее всего не пройдёт проверку |
| ❓ **Не проверено** | Снаружи не видно, нужны данные от владельца — обязательно скажи, какие именно |
| ➖ **Неприменимо** | Требование не относится к этому сайту — коротко поясни, почему |

Соблазн превратить каждое ❓ в ❌ («наверняка не подали уведомление») нужно давить. Аудит с раздутым числом нарушений теряет доверие ровно в тот момент, когда владелец находит первое неверное обвинение, и дальше он не поверит и справедливым пунктам.

Приоритет считай по двум осям — размер штрафа и вероятность, что РКН это увидит при автоматическом сканировании:

- **Критично** — миллионные штрафы или то, что сканер РКН видит мгновенно: локализация (до 6 млн), отсутствие уведомления (до 300 тыс.), обработка без согласия (до 700 тыс.).
- **Высокий** — штрафы в сотни тысяч, видно при обращении гражданина или жалобе.
- **Средний** — десятки тысяч либо риск реализуется только при углублённой проверке.
- **Низкий** — гигиена, штрафом напрямую не карается, но всплывёт в предписании.

## План исправлений — главная часть отчёта

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

- **🤖 Может сделать Claude** — переписать политику, составить текст согласия, подготовить формулировки для формы, собрать данные для уведомления в РКН, написать cookie-политику. Это текстовая работа, и после сдачи отчёта уместно одной фразой предложить: «могу сразу переписать политику и тексты согласий — скажите, и сделаю».
- **👤 Требует владельца** — подать уведомление через `pd.rkn.gov.ru`, издать приказ, подписать договор поручения, подтвердить местоположение базы, принять решение об отказе от иностранного сервиса.
- **💻 Требует разработчика** — снять `checked` с чекбокса, разделить чекбоксы, внедрить cookie-баннер с блокировкой скриптов до согласия, настроить логирование согласий, перенести формы на российский бэкенд.

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

## Частые ошибки, которых стоит избегать

**Путать политику и согласие.** Это самая распространённая ошибка на российских сайтах и самая частая ошибка в аудитах. Политика (ст. 18.1 ч. 2) — односторонний документ оператора, он информирует. Согласие (ст. 9) — волеизъявление субъекта, и с 01.09.2025 оно должно быть отдельным документом, а не разделом политики или пунктом оферты. Формула «Продолжая пользоваться сайтом, вы соглашаетесь с обработкой персональных данных» не является согласием ни в каком виде: молчание и бездействие согласием не признаются прямо по тексту ч. 1 ст. 9.

**Считать, что cookie в России регулируются как в GDPR.** Отдельного «закона о cookie» в РФ нет, обязанности показывать баннер как таковой закон не устанавливает. Риск возникает иначе: если идентификатор позволяет прямо или косвенно определить субъекта, это ПДн со всеми последствиями, а если счётчик отправляет данные за рубеж — включаются локализация и трансграничная передача. Поэтому в отчёте cookie-пункты формулируй через реальное основание риска, а не через «требуется по закону» — иначе аудит будет выглядеть как переписанный GDPR-чеклист, и юрист заказчика это заметит.

**Обещать точный размер штрафа.** Санкции в ст. 13.11 КоАП даны вилками, и итог зависит от смягчающих обстоятельств, статуса лица и совокупности составов. Пиши «до 700 тыс. руб. по ч. 2 ст. 13.11 КоАП», а не «вас оштрафуют на 700 тысяч».

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

## Файлы скилла

- `references/legal-base.md` — нормы, редакции, сроки, полная таблица штрафов по ст. 13.11 КоАП. Читай в начале работы.
- `references/checklist.md` — чеклист A–I, основа проверки. Читай перед шагом 4.
- `references/report-template.md` — структура отчёта. Читай перед шагом 5.
- `scripts/analyze_page.py` — разбор сохранённого HTML: формы, чекбоксы, сторонние скрипты, cookie-баннер.