Антифрод 3.0

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

Оператору предлагают запретить требовать согласие, если обязанность его получить не предусмотрена определёнными нормативными источниками. А органы власти получают полномочия определять состав данных и операции с ними для каждой цели обработки моих любимых ПД. Договоры с пользователями предлагается УВЯЗАТЬ с этими правилами.

Предлагаемая часть 2.1 статьи 18 Закона о персональных данных ЗАПРЕЩАЕТ оператору требовать согласие, если обязанность его получения не предусмотрена международным договором РФ, федеральным законом либо нормативными актами по новым частям 2.1 и 2.2 статьи 4.

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

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

Возьмём условный магазин. При оформлении заказа покупатель вводит адрес доставки и обязан согласиться на обработку данных. Компания объясняет: без адреса курьер не привезёт покупку.

Назначение адреса понятно. Но почему для этой операции требуется именно согласие, придётся разбирать отдельно. Проект сохраняет договорное основание обработки, но меняет требования к самому договору.

Я бы открыл форму заказа и посмотрел, что делает пользователь. Принимает условия покупки? Подтверждает ознакомление с документом? Разрешает дополнительную обработку? Если сайт считает всё это одной галочкой, сначала придётся восстановить смысл действия, а уже потом переписывать подпись рядом с ним.

Тут уже не всё так очевидно.

В проекте используется слово «требовать». Граница между требованием и предложением добровольно согласиться на самостоятельную дополнительную цель подробно не раскрыта. При этом тот же документ регулирует предоставление согласий и их отзыв. Вывод о запрете всех добровольных согласий с текстом не сходится.

Обязательная галочка перед оформлением заказа и отдельная подписка на рассылку устроены по-разному. В первом случае человек вынужден согласиться, чтобы двигаться дальше. Во втором может отказаться от дополнительной обработки.

Различие вполне очевидное. Понять эти «личные границы» нам ещё только предстоит. Поэтому объявлять второй вариант гарантированным исключением я бы тоже не стал: такого исключения в проекте прямо нет.

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

Теперь к нормативным актам, на которые ссылается запрет.

Проект дополняет статью 4 новыми частями 2.1 и 2.2. Федеральные органы, отвечающие за политику и нормативное регулирование в соответствующей сфере, в пределах своих полномочий принимают акты, определяющие для каждой цели состав персональных данных и операции с ними. Региональные и муниципальные органы, а также Банк России вправе принимать такие акты в пределах своих полномочий.

Формулировки различаются: для федеральных органов использовано «принимают», для второй группы — «вправе принимать». Это намекает, кто обязан, а кто просто может это делать (но захочет ли??).

Механизм охватывает обработку по пунктам 1, 5 и 7 части 1 статьи 6. В их числе согласие и договорное основание. Соответствующие акты должны проходить обязательное согласование с РКН.

Для компании появляется дополнительный шаг проверки: есть ли для конкретной цели нормативные параметры, какие сведения они охватывают и какие операции допускают.

Подумскроллить каталог целей и полей пока не получится. Поэтому что и кому разрешат, пока непонятно. Будем ждать.

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

Хорошо бы начать с тактичного вопроса: а ху… для чего место работы требуется именно при регистрации? После этого я бы проверил основание обработки и применимые правила. А если ещё и акт федерального органа появится (а если нескольких?..), поле придётся сопоставить ещё и с ним.

Проект прямо связывает согласие по пункту 1 части 1 статьи 6 с соответствием таким актам. Аналогичная привязка предусмотрена для договора. Поэтому широкий текст документа сам по себе не объяснит допустимость выбранного состава данных.

Здесь меняется последовательность работы над формой. Команда объясняет назначение сведений, юрист проверяет требования и оформление.

Регулятор, в принципе, догадался за нас, что так может получиться.

В новой редакции пункта 5 части 1 статьи 6 заключаемый с субъектом договор должен соответствовать нормативным актам по новым частям статьи 4.

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

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

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

В том же пункте проект запрещает включать в договор положения, устанавливающие случаи обработки данных несовершеннолетних, если иное не предусмотрено законодательством РФ.

Интересно, как это коснётся игровых сервисов или образовательных платформ…

В проекте есть ещё много чего «прикольного»:

Понятно, что это только проект и всё может поменяться. НО в этот раз к вопросу согласий подошли очень серьёзно (не как в 2.0) и предусмотрели систему с отраслевым регулированием обработки ПД. Поэтому, по-моему, шансы, что эти поправки примут, повыше, чем в прошлый раз.