РКН не спит - Методичка по оформлению ПД 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 точно под запретом.

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