РКН не спит - Методичка по оформлению ПД 3.0

[Sadorimatsu]

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

Было

5.1. Общие поля регистрации​

В админ-панели: admin.php?custom-user-fields/. Согласие на обработку ПДн оформляется отдельным действием от принятия Правил. Если используется сценарий Б, храните выбранные категории распространения и доказательство выбора отдельно.

• Согласие на обработку ПДн: отдельный подтверждаемый checkbox либо эквивалентный независимый механизм.
• Сценарий Б: радиокнопка/поле, определяющее общий режим публичного отображения, может использоваться для групповой автоматизации, но само по себе не решает требование индивидуального выбора категорий по ст. 10.1. Категории и запреты должны фиксироваться отдельно в соответствующем интерфейсе.
• Фиксируйте пользователя, выбранные значения, версию текста, дату и время. Не полагайтесь на то, что редактируемое поле само по себе доказывает первоначальное согласие.

Стало

5.1. Общие поля регистрации​

В админ-панели: admin.php?custom-user-fields/. Согласие на обработку ПДн оформляется отдельным действием от принятия Правил. При использовании сценария Б необходимо отдельно хранить выбранные категории распространения и доказательства выбора в БД (XenForo уже это делает).

Основные требования к полям согласия:

• Согласие на обработку ПДн - отдельный подтверждаемый механизм (checkbox или эквивалент);
• Согласие на распространение - отдельный механизм выбора (радиокнопки «Даю согласие» / «Не даю согласие»).

Варианты реализации:

• Автоматизированная система:
  • Настройка радиокнопок для выбора режима;
  • Привязка к автоматическому повышению групп;
  • Распределение пользователей между группами «Пользователи» и «Не согласных»;
  • Требуется плагин для маскировки публичных данных в группе «Не согласных».
• Ручная модерация:
  • Использование checkbox/радиокнопок для согласия на распространение;
  • Ручная проверка модератором;
  • Ручное перемещение пользователя в нужную группу при его выборе согласия или частично через радиокнопки реализовать автоматическую смену группу, остальное вручную выполнять.

Технические особенности:

• Все изменения полей автоматически фиксируются в БД;
• Для полей согласия обязательна настройка «Редактировать можно только один раз» (Для Согласия на обработку ПД, а для Согласия на распространение ПД это нужно для ручной проверки, если плагин, то не нужно ставить запрета на один раз);
• При модерации через администрацию изменение согласия возможно только через прямой запрос.

Важные примечания:

• Несмотря на автоматическое логирование в XenForo, требуется комплексная настройка механизмов согласия и их обработки.
• Необходимо обеспечить связь между выбором в поле, повышением группы и работой плагина (если есть).
• При ручной модерации контроль изменений согласия осуществляется администраторами

Было

Источник	Что проверить и описать в документах
Аккаунт	Логин, адрес электронной почты, сведения аутентификации (хеш пароля - не утверждайте алгоритм без проверки), дата регистрации, подтверждение e-mail.

Стало

Источник	Что проверить и описать в документах
Аккаунт	Логин, адрес электронной почты, сведения для аутентификации (хранится хеш пароля, алгоритм - bcrypt), дата регистрации, подтверждение e-mail.

Было

• Опубликована информация об условиях обработки и запретах (в течение 3 рабочих дней с момента получения согласия).

Стало

• Публикация условий обработки и запретов (в течение 3 рабочих дней с момента получения согласия)
  • Примечание: Это требование означает, что после получения согласия на распространение персональных данных вы обязаны публично разместить информацию о том, какие именно условия и запреты установил пользователь. Например, если пользователь разрешил публиковать только имя и фото, но запретил распространение даты рождения, эта информация должна быть доступна всем, кто получает доступ к его данным.
  • Важно понимать:
    • Публиковать нужно не само согласие, а именно выбранные пользователем условия и запреты.
    • Срок публикации - строго 3 рабочих дня.
    • Информация должна быть доступна тем, кто получает доступ к данным субъекта.
    • При изменении условий или запретов публикация обновляется в тот же срок.

Было

Отдельно проверьте до публикации

• В согласии на распространение предусмотрена возможность определить перечень данных по каждой категории; единый выбор «согласен со всем / не согласен ни с чем» требует отдельной юридической оценки и не должен считаться автоматически достаточным.
• Сведения о субъекте и операторе в согласии на распространение сверены с приказом Роскомнадзора № 18; идентификацию только по логину не называйте безусловно соответствующей приказу.
• Публичная замена имени на «Гость 123» - это замена публичного отображения, а не обязательно юридическое обезличивание, если оператор сохраняет связь с аккаунтом.
• Не заявляйте, что специальные категории данных не обрабатываются, если сайт допускает их размещение и хранение в сообщениях, медиа или профиле. Опишите фактическую обработку и порядок реагирования.

Стало

Отдельно проверьте до публикации

• В согласии на распространение для каждой категории персональных данных должен быть прописан конкретный перечень. Универсальный чекбокс «Согласен со всем», а также радиокнопки «Согласен» / «Не согласен» не могут автоматически считаться достаточным выражением воли: они требуют отдельной правовой оценки на предмет конкретности и осознанности согласия. Факт получения согласия необходимо подтверждать документально (например, через логирование в системе: фиксация времени, IP-адреса, статуса выбора пользователя).
• Сведения о субъекте и операторе сверьте с требованиями приказа Роскомнадзора № 18: идентификация только по логину не является безусловным соответствием.
• Замена имени на псевдоним (например, «Гость 123») в публичном поле - это лишь изменение отображения; если оператор сохраняет техническую связь с аккаунтом, юридическое обезличивание не достигнуто.
• Не декларируйте отсутствие обработки специальных категорий, если сайт допускает их ввод и хранение (в сообщениях, медиа, профиле): в документе следует описать фактическую практику обработки и алгоритм реагирования на такие случаи.

Позже надо будет подумать, как вписать в документах регистрацию и вход через VK и Яндекс. Если кто сделает, то поделитесь. Мне они не нужны, потому и не учитывал.
Помимо этого пока уточняю момент, как грамотно заставить подтвердить новые требования старым учёткам, по результатам сообщу варианты.

 

[Sadorimatsu]

Личная рекомендация: (Делюсь опытом и пониманием)​

Вы создаете сайт (неважно какой) и вам нужна форма регистрации, форма обратной связи, неважно какая. Любая форма это сбор данных. У вас нет документов и представления, что у вас вообще есть. Для решения, нейронка в помощь (в идеале юрист), но перед составлением документов, нужно правильно задать вопрос себе, как вы хорошо понимаете свой CMS или что там у вас... Для создания документов, нужно понимать строгий перечень задач, начну по порядку:
1. Какие формы ввода данных у вас вообще есть? (Регистрация, обратная связь, баннер/попап и пр.)
Что именно эти формы собирают? (Имя/Логин, E-mail, пароль, капча (если есть), согласие на обработку ПД (обязательно везде!), согласие на распространение ПД (если закрытый сайт, то не нужно), ознакомление с правилами сайта и политикой обработки ПД (правила вы пишите сами, а политику вам поможет нейронка составить вместе с документами на согласия).
2. У вас есть Яндекс.Метрика или может Google, кому-то она и не нужна вообще. Вам нужно понимать, это отдельная цель обработки. (Не рекомендуется в РФ использовать метрку от Google, почитайте сами почему)
3. У вас есть капча, локальная не нуждается в документальном заверении (например, вопрос-ответ), а вот от иных сервисов обязательно требуется пояснение в обработке ПД (например Яндекс.капча). И это так же является отдельной целью обработки.
4. Вам нужно решить, что могут видеть ваши гости, потому что от этого зависит форма оформление документов. Вам нужно расписать по пунктам, что видит гость, например видит логины, аватары, информацию пользователей в профиле, темы, сообщения, подписи, обложки профилей, статус активности. Для формирование документов важно это расписать для задачи.
5. Вам нужно решить как вы будете хранить свои файлы, если на сервере, то ничего делать не придется, но если облачное S3, то вам нужно будет обозначить в документах фирмы, что они отвечают за загрузку файлов, как и их хранение, куда входят те же аватары.
6. Когда со всем этим разобрались, вам нужно подать в РКН уведомление по обработке ПД, без этого вы не имете право заниматься сбором ПД на своём сайте в РФ. По закону указано, что нужно подавать уведомление до начала сбора ПД и созданные документы на сайте должны быть датированы от дня, когда начали пользователи подтверждать своё согласия и ознакомление с ними. Это важно. И все это должно фиксировать БД сайта.
7. Если у вас нет плагина на сокрытие логина, аватара и прочего, то лучше сразу ставьте сайт/форум на предмодерацию на регистрацию и вручную подтверждайте каждую регистрацию. Это вынужденная мера, если хотим всё сделать как от нас требует закон.
Это что нужно понимать каждому администратору. Если у вас на сайте нет сбора ПД, вам всё это не нужно.

• А вот если у вас уже есть сайт/форум и вам нужно внести всё это, то тут и начинаются проблемы. Вам нужно изучить структуру своей платформы, какие плагины ставили, где и какие данные у вас собираются и что и куда они передают. Не пытайтесь скрыть даже скрытый сбор от консоли, потому что РКН может потребовать вашу БД на изучение и там это будет видно, как и потребовать отчёт трафика от вашего хостера, где могут проследить передачу. Это касается и StopForumSpam.
• По возможности лучше отключить, если нет аналогов в РФ или указать в документе о такой обработке с целью защиты от ботов. Потому что сервисы, что занимаются трансграничной передачей могут доставить вам проблем, вплоть до солидных штрафов. Потому, если у вас требуется использование таких сервисов, вам нужно обязательно их расписать в документах.
• Основная проблема, это как заставить подтвердить уже зарегистрированных пользователей с новыми требованиями, то тут решаем самостоятельно, возможности есть, нужно реализовывать.
• Ну и конечно кнопки регистрации от зарубежных сервисов под строгим запретом, где законом обозначаются. Такие как Google точно под запретом.

Решил добавить в методичку краткое понимание, что к чему. Думали будет легко? А хрен вам.

 

[Vanych]

Sadorimatsu, а если есть сайт на домене например .net или .com и он зареган в России, и БД находится в России, то эту всю порнографию тоже оформлять, если есть регистрация? А если на нём нет регистраций? Оформить куки и всё? Зачем политика конфиденциальности, если регистрация закрыта и он для одного человека? И вообще, как уйти в тень от всего этого без предела, который нам учудил РКН?

 

[Vanych]

Это касается и StopForumSpam.

Приплыли. Так этот функционал по умолчанию установлен. Вы себе его отключили? Потому что не видел об этом в документах.

 

[Sadorimatsu]

а если есть сайт на домене например .net или .com и он зареган в России, и БД находится в России, то эту всю порнографию тоже оформлять, если есть регистрация?

Домен не важен, важен оператор, смотрите в чём нюанс, 152-ФЗ не смотрит на зону .ru, .com или .net. Основной критерий кто оператор и как идёт обработка. Если сайт принадлежит вам (Вы из РФ) и база стоит в России, то вы оператор ПД в понятии закона РФ. Более того, сбор данных о россиянах через сайт с БД в РФ - это как раз тот случай, когда требование локализации в 242-ФЗ у вас уже выполнено, а обязанности 152-ФЗ возникают в полном объёме. Домен в этом ни на что не влияет. Разве что в сентябре 2026 обязали идентифицировать всех владельцем в зоне ru, su, рф.

Если есть регистрация, то обязательно вам нужно сделать следующее:

• уведомление РКН о начале обработки.
• политика конфиденциальности (юридически правильно "Политика в отношении обработки персональных данных").
• чекбоксы/радиокнопки или любая форма подачи для подтверждения согласия с отдельными документами.

И да, придется оформлять всю эту порнографию, вы правильно поняли.

А если на нём нет регистраций? Оформить куки и всё?

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

• Аналитика (Такие как Яндекс.Метрика, Google Analytics и т.д.) - собирают cookie и IP. РКН считает это ПД. Читал реальный случай: что например сайт-визитка без единой формы, но с метрикой признали обработкой и обязали подать уведомление РКН. Для аналитики нужен cookie-баннер с возможностью отказа и раздел о cookie в политике. Чтобы это избежать, требуется вообще не ставить никакую аналитику. А так да, достаточно базовый баннер с куки без сторонней обработки и аналитики.
• Форма обратной связи, комментарии, чат без регистрации - даже одно поле "e-mail" делает вас оператором. Если у вас могут писать без предоставление любых ПД, то в этом случае вы не собираете и не передаете их. Это уместно, но до той поры, если кто-то сам их не напишет, тут требует проверки, потому важно не только обезличивать, но и контролировать то, что пишут... Да, аж до такого маразма дошло.
• Логи сервера с IP - формально тоже ПД в связке с другими данными; на практике большинство их хранит, но разумно ограничить срок хранения и не пихать их в публичные отчёты. От этого никуда не денешься и раз они обезличены изначально, то не несут в себе ПД.

Зачем политика конфиденциальности, если регистрация закрыта и он для одного человека?

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

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

И вообще, как уйти в тень от всего этого без предела, который нам учудил РКН?

Легальный путь "в тень" существует ровно один - не обрабатывать ПД. Статичный сайт без форм, без регистрации, без аналитики с идентификаторами и закон вас не касается вообще. Как только нужна хоть какая-то учётка или форма, проще подать одно уведомление РКН и держать простую политику, чем строить тайную инфраструктуру. Это что касается официальной части.

Если говорить неофициально, то вам нужно выйти из доменной зоны ru, su, рф (менять регистратора необязательно), вывести сервер из РФ и если ваш ресурс не на русском языке как основной, то вы выходите лишь в общин требования соблюдение ПД по системе GDPR, а там кстати не сильно отличаются от наших требований, у них даже где-то строже, но нет таких заморочек с оформлением документов т.к. у них есть определенныеы шаблоны и требования, когда у нас этого нет. Если где не прав, то поправьте.

Приплыли. Так этот функционал по умолчанию установлен. Вы себе его отключили? Потому что не видел об этом в документах.

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