Машиночитаемая политика ПДн: формат JSON-LD
С 01.09.2025 согласия на обработку ПДн оформляются отдельным документом (ФЗ-156 от 24.06.2025). Это меняет структуру политики: условия получения согласия больше нельзя смешивать с описанием обработки. JSON-LD-разметка позволяет отразить это разделение формально и однозначно. Инструкция — для юриста, который собирает или проверяет ОРД оператора и хочет привязать публичную политику к нормам ст. 9, 18.1, 22 и 22.1 ФЗ-152.
Шаг 1. Что должна содержать политика по ст. 18.1 ФЗ-152 — до разметки?
Прежде чем добавлять JSON-LD, юрист обязан убедиться, что сам текст политики соответствует ч. 2 ст. 18.1 ФЗ-152. Иначе разметка будет описывать несоответствующий документ, что при проверке РКН создаст дополнительные риски.
Обязательные разделы политики по ч. 2 ст. 18.1:
- наименование и контактные данные оператора;
- цели обработки ПДн с перечнем по каждой цели;
- правовые основания обработки (ст. 6, 10, 11 ФЗ-152);
- категории субъектов и категории обрабатываемых данных;
- порядок и сроки хранения ПДн;
- описание мер защиты по ст. 19 ФЗ-152 (организационные и технические);
- права субъектов и порядок их реализации (ст. 14–21 ФЗ-152);
- сведения о передаче данных третьим лицам и трансграничной передаче (ст. 12 ФЗ-152).
С 01.09.2025 раздел о согласиях необходимо переработать: согласие по ст. 9 ФЗ-152 (в ред. ФЗ-156 от 24.06.2025) — отдельный документ с обязательными реквизитами. Политика ссылается на форму согласия, но не заменяет её. Если ваш шаблон политики объединяет согласие и описание обработки в одном тексте — это нарушение с 01.09.2025.
Шаг 2. Как структурировать JSON-LD для политики конфиденциальности?
JSON-LD встраивается в <head> страницы с политикой тегом <script type="application/ld+json">. Основной тип — PrivacyPolicy (расширение schema.org/WebPage). На момент написания инструкции schema.org не имеет специализированного типа PrivacyPolicy с обязательными полями — используется комбинация WebPage + дополнительные поля через расширения и поле additionalType.
Минимальная структура JSON-LD для политики оператора ПДн:
"@context": "https://schema.org",
"@type": "WebPage",
"additionalType": "https://schema.org/PrivacyPolicy",
"name": "Политика обработки персональных данных",
"url": "https://example.ru/privacy/",
"datePublished": "2026-09-01",
"dateModified": "2026-09-01",
"inLanguage": "ru",
"publisher": {
"@type": "Organization",
"name": "ООО «Пример»",
"legalName": "Общество с ограниченной ответственностью «Пример»",
"url": "https://example.ru/"
},
"mentions": [
{"@type": "Legislation", "name": "ФЗ-152 «О персональных данных»",
"url": "https://www.consultant.ru/document/cons_doc_LAW_61801/"}
]
}
Поле dateModified критично: РКН при проверке оценивает актуальность политики. Если документ изменился после 01.09.2025 (новые согласия, новые цели), но дата не обновлена — это свидетельство формального, а не реального соответствия.
Юрист собирает ОРД — с чего начать?
Если вы проверяете комплект ОРД оператора и видите, что политика не обновлена после 01.09.2025 или не опубликована в открытом доступе — каждый такой факт является самостоятельным основанием для протокола по ч. 3 ст. 13.11 КоАП. У оператора нет срока на добровольное устранение после начала проверки РКН. Юристы DATUM соберут комплект из 38 документов ОРД под ключ и синхронизируют политику с актуальными требованиями ФЗ-152.
Собрать ОРД под ключОтветим за 2 часа · +7 (983) 510-38-76 · info@vitveteam.ru
Шаг 3. Какие поля JSON-LD отражают требования ст. 9 и 22 ФЗ-152?
Два ключевых нормативных требования требуют отдельного отражения в разметке: уведомление РКН по ст. 22 ФЗ-152 и порядок получения согласия по ст. 9 ФЗ-152 в редакции с 01.09.2025.
Расширенная структура с привязкой к нормам:
"@context": "https://schema.org",
"@type": "WebPage",
"additionalType": "https://schema.org/PrivacyPolicy",
"name": "Политика обработки персональных данных ООО «Пример»",
"url": "https://example.ru/privacy/",
"datePublished": "2026-09-01",
"dateModified": "2026-10-01",
"inLanguage": "ru",
"publisher": {
"@type": "Organization",
"name": "ООО «Пример»",
"legalName": "Общество с ограниченной ответственностью «Пример»",
"url": "https://example.ru/",
"contactPoint": {
"@type": "ContactPoint",
"contactType": "privacy",
"email": "dpo@example.ru"
}
},
"description": "Политика определяет порядок обработки персональных данных...",
"hasPart": [
{"@type": "WebPageElement", "name": "Правовые основания обработки",
"cssSelector": "#legal-basis"},
{"@type": "WebPageElement", "name": "Права субъектов ПДн",
"cssSelector": "#subject-rights"},
{"@type": "WebPageElement", "name": "Форма отзыва согласия",
"cssSelector": "#consent-withdrawal"}
],
"mentions": [
{"@type": "Legislation", "name": "Ст. 9 ФЗ-152 «О персональных данных»",
"url": "https://www.consultant.ru/document/cons_doc_LAW_61801/"},
{"@type": "Legislation", "name": "Ст. 18.1 ФЗ-152 «О персональных данных»",
"url": "https://www.consultant.ru/document/cons_doc_LAW_61801/"},
{"@type": "Legislation", "name": "Ст. 22 ФЗ-152 «О персональных данных»",
"url": "https://www.consultant.ru/document/cons_doc_LAW_61801/"}
]
}
Поле contactPoint с типом "privacy" позволяет автоматически идентифицировать контакт ответственного за обработку ПДн по ст. 22.1 ФЗ-152. Если оператор назначил DPO или ответственное лицо — его email или URL профиля указывается здесь. Это важно при автоматизированных проверках: отсутствие контакта в разметке совпадает с индикатором риска РКН «нет ответственного».
Поле hasPart с cssSelector позволяет прямо указать якоря разделов политики — суд или регулятор могут автоматически проверить наличие обязательных разделов по ч. 2 ст. 18.1 ФЗ-152, не читая весь текст.
Шаг 4. Как отразить в JSON-LD уведомление РКН и назначение ответственного?
Ст. 22 ФЗ-152 обязывает оператора уведомить РКН до начала обработки ПДн. Сведения из реестра операторов (pd.rkn.gov.ru) можно структурировать в разметке — это сигнал о легитимности обработки для автоматизированных систем анализа.
Ст. 22.1 ФЗ-152 требует назначить лицо, ответственное за организацию обработки ПДн. Требования к квалификации — в ч. 4 ст. 22.1. Это лицо должно быть идентифицировано публично — разметка JSON-LD является одним из способов.
"@context": "https://schema.org",
"@type": "WebPage",
"additionalType": "https://schema.org/PrivacyPolicy",
"identifier": [
{"@type": "PropertyValue",
"name": "РКН-регистрационный-номер",
"value": "77-XXXXXX-1",
"propertyID": "https://pd.rkn.gov.ru/"}
],
"author": {
"@type": "Person",
"name": "Иванов Иван Иванович",
"jobTitle": "Ответственный за организацию обработки персональных данных",
"email": "dpo@example.ru"
},
"datePublished": "2026-09-01",
"dateModified": "2026-10-01"
}
Регистрационный номер оператора в реестре РКН в поле identifier связывает публичную политику с уведомлением по ст. 22 ФЗ-152. Если оператор изменил состав обрабатываемых ПДн или цели — он обязан направить обновлённое уведомление по Приказу РКН №180. После обновления реестра — обновить identifier и dateModified в разметке.
Если оператор не стоит в реестре РКН или уведомление подано с ошибками в составе ПДн — неуведомление квалифицируется по ч. 10 ст. 13.11 КоАП: штраф 100 000 — 300 000 ₽. Неуведомление об инциденте — по ч. 11 ст. 13.11 КоАП: штраф 1 000 000 — 3 000 000 ₽. Проверьте статус уведомления до публикации политики.
Заказать аудит 152-ФЗШаг 5. Как проверить машиночитаемую политику на соответствие нормам?
После публикации политики с JSON-LD разметкой юрист проводит финальную проверку по трём параметрам: техническая валидность разметки, соответствие полей нормам ФЗ-152, синхронизация с текстом политики.
Что проверить перед финальной публикацией политики с JSON-LD
- Разметка валидна по schema.org Validator (validator.schema.org) — нет обязательных полей с ошибкой.
- Поле dateModified обновлено и совпадает с датой последнего изменения текста политики.
- Поле identifier содержит актуальный регистрационный номер из реестра pd.rkn.gov.ru.
- Поле contactPoint с типом "privacy" содержит рабочий email ответственного по ст. 22.1 ФЗ-152.
- Раздел mentions включает ссылки на все НПА, которые цитируются в тексте политики (ст. 6, 9, 18.1, 22 ФЗ-152 как минимум).
Техническая валидность — необходимое, но недостаточное условие. Основная ошибка: разметка описывает «идеальную» политику, а текст на странице — упрощённую версию без обязательных разделов. РКН при проверке читает текст, а не JSON-LD. Машиночитаемость нужна для автоматизированных инструментов, но не заменяет содержательное соответствие ч. 2 ст. 18.1 ФЗ-152.
Как применяется на практике — типовые ситуации для юриста
Ситуация 1. Оператор обновил цели обработки, не обновив политику и разметку. Компания из Центрального ФО подключила систему сквозной аналитики (осень 2025) и начала обрабатывать данные о поведении пользователей на сайте — новая цель, не отражённая в политике. Разметка JSON-LD содержала dateModified двухгодичной давности. При плановой проверке РКН инспектор сопоставил дату обновления политики с датой договора на аналитику. Расхождение стало основанием для протокола по ч. 1 ст. 13.11 КоАП. Стратегия: обновлять политику и dateModified в разметке одновременно с каждым изменением состава или целей обработки.
Ситуация 2. Ответственный по ст. 22.1 не указан в политике и не отражён в JSON-LD. Компания из Северо-Западного ФО назначила ответственного приказом, но не опубликовала его контакты в политике и не добавила contactPoint в разметку. При обращении субъекта ПДн с запросом по ст. 14 ФЗ-152 субъект не смог идентифицировать, куда направлять требование. Жалоба в РКН, внеплановая проверка, протокол по ч. 4 ст. 13.11 КоАП (40 000 — 80 000 ₽ для юрлица). Стратегия: email ответственного в поле contactPoint — обязательное поле разметки.
Ситуация 3. Форма согласия встроена в текст политики после 01.09.2025. Оператор использовал шаблон политики, в которой раздел «Согласие» содержал форму в виде флажка «Принимаю политику». После 01.09.2025 это нарушает ч. 1 ст. 9 ФЗ-152 в ред. ФЗ-156 от 24.06.2025 — согласие должно быть отдельным документом. JSON-LD в этом случае некорректно указывал hasPart с cssSelector на объединённый блок. Стратегия: разделить политику и форму согласия, исправить hasPart в разметке — указать два отдельных URL или cssSelector.
Услуги DATUM по теме
- Комплект ОРД под ключ — политика, согласия, приказы, регламенты в соответствии с ФЗ-152
- Аудит соответствия 152-ФЗ — проверка 38 позиций, включая политику и JSON-LD разметку
- DPO-аутсорсинг — функция ответственного по ст. 22.1 на абонентском обслуживании
Частые вопросы
1. Какие документы должны быть у оператора ПДн?
Минимальный комплект ОРД включает: политику обработки ПДн по ч. 2 ст. 18.1 ФЗ-152, отдельные формы согласий по ст. 9 ФЗ-152 (с 01.09.2025 — отдельный документ по ФЗ-156 от 24.06.2025), приказ о назначении ответственного по ст. 22.1 ФЗ-152, уведомление РКН по ст. 22 ФЗ-152, описание применяемых мер защиты по ст. 19 ФЗ-152, журнал учёта обращений субъектов. Отсутствие любого из этих документов создаёт самостоятельное основание для штрафа по соответствующей части ст. 13.11 КоАП.
2. Как составить политику обработки ПДн?
Политика составляется на основе ч. 2 ст. 18.1 ФЗ-152 и должна содержать: наименование оператора, цели и правовые основания обработки по каждой цели, категории субъектов и данных, сроки хранения, описание мер защиты, права субъектов и порядок их реализации. После 01.09.2025 политика не должна объединяться с формой согласия — это требование ФЗ-156 от 24.06.2025. Политику публикуют на сайте с открытым доступом и снабжают JSON-LD разметкой для машиночитаемости.
3. Кого назначить ответственным по ст. 22.1 ФЗ-152?
Оператор-юрлицо обязан назначить лицо, ответственное за организацию обработки ПДн, — приказом руководителя. Требования к квалификации установлены ч. 4 ст. 22.1 ФЗ-152. Ответственным может быть штатный сотрудник (юрист, специалист по ИБ) или внешний DPO-аутсорсер. Контактные данные ответственного публикуются в политике и указываются в поле contactPoint JSON-LD разметки. Отсутствие назначенного ответственного — индикатор риска при проверке РКН.
4. Можно ли использовать шаблон политики из интернета?
Шаблон из открытых источников не учитывает специфику конкретного оператора: состав ПДн, цели обработки, перечень третьих лиц, наличие трансграничной передачи. Большинство публичных шаблонов не обновлены под требования ФЗ-156 от 24.06.2025 и не содержат JSON-LD разметки. Использование неактуального шаблона при проверке РКН создаёт риск протокола по ч. 1 ст. 13.11 КоАП (150 000 — 300 000 ₽): политика опубликована, но не соответствует реальной обработке.
5. Какие согласия нужны после 01.09.2025?
С 01.09.2025 согласие на обработку ПДн по ч. 1 ст. 9 ФЗ-152 (в ред. ФЗ-156 от 24.06.2025) оформляется отдельным документом, не объединённым с договором, офертой, политикой или любым другим документом. Обязательные реквизиты: ФИО субъекта, контакт, наименование оператора, цель, перечень ПДн, перечень действий, срок согласия, способ отзыва. Ранее полученные согласия, соответствующие старым требованиям, переоформлять не требуется — обратная сила отсутствует. Новые согласия с 01.09.2025 — только по новой форме.
Итог
Машиночитаемая политика в формате JSON-LD — это не замена содержательного соответствия ст. 18.1 ФЗ-152, а его формализованное отражение. Корректная разметка включает: тип WebPage с additionalType PrivacyPolicy, поля dateModified, identifier с номером реестра РКН, contactPoint с email ответственного по ст. 22.1, mentions с НПА из тела политики, hasPart с якорями обязательных разделов. После 01.09.2025 политика и форма согласия — два отдельных документа; разметка должна отражать это разделение.
Юристы DATUM готовят комплект ОРД с учётом требований ФЗ-152, ФЗ-156 от 24.06.2025 и актуальной позиции РКН — включая публичную политику, JSON-LD разметку и отдельные формы согласий для каждой категории субъектов.
24 октября 2026 года