Как аудит персональных данных превратился в перестройку юридической архитектуры федеральной лизинговой компании.
Наш клиент, федеральная лизинговая компания, развивает партнёрскую сеть и цифровые каналы. Локальный аудит персональных данных вскрыл рассинхронизацию между продуктом, договорами и требованиями 152-ФЗ. Рассказываем, как наша карта потоков данных заменила ряд согласий и убрала барьеры в воронке продаж.
В «Зарцын и партнёры» обратилась лизинговая компания, которая финансирует покупку транспорта и оборудования для бизнеса по всей России. Запрос был стандартным: обновить политики и согласия по персональным данным. Но уже на первой встрече стало ясно, что править нужно не отдельные тексты, а всю юридическую архитектуру продукта.
Вокруг основного лизингового продукта компания выстроила целую экосистему: партнёрские программы для банков, B2B-ритейлеров, франчайзинговых сетей и агентов, а также каталог из более чем 100 аккредитованных поставщиков. Всё это поддерживали собственные онлайн-формы и виджеты на сайтах многочисленных партнёров.
По данным «Эксперт РА», на 1 апреля 2023 года лизинговый портфель составлял 1,38 млрд ₽, а в сегменте оборудования для пищевой промышленности компания занимала 7-е место по объёму нового бизнеса; по оценке АКРА, за 2021–2024 годы портфель вырос более чем в семь раз. Один и тот же клиент компании мог сначала прийти за финансированием, а затем сам стать поставщиком для других клиентов — поэтому данные передавались между несколькими независимыми участниками.
Рассказываем, как наша карта потоков данных заменила ряд согласий и убрала барьеры в воронке продаж.
К моменту аудита на сайте одновременно действовали политика конфиденциальности, политика обработки и защиты персональных данных, отдельные согласия и договорные тексты. Они появлялись стихийно — каждый раз при запуске новой функции или подключении партнёра — и частично повторяли друг друга. Пользователь встречал галочки и ссылки в разных частях пути, но не понимал, какое действие от него требуется и зачем.
Команда «Зарцын и партнёры» начала не с переписывания форм, а с разбора бизнес-модели. Работа велась в связке: юрист по IT-праву и продуктовый аналитик восстанавливали фактический маршрут сведений — кто их собирает, для какой цели, кому передаёт и какую роль играет на каждом этапе.
Карта показала, что технический оператор площадки и оператор персональных данных — не всегда одно юрлицо. По п. 2 ст. 3 Федерального закона № 152-ФЗ оператором считается тот, кто определяет цели и состав обработки. Именно в этом и состоит главная задача IT-юриста — не формально назначить роли по названиям компаний, а привязать их к реальным функциям. Поэтому роль нельзя назначить участнику только потому, что сведения проходят через его интерфейс.
Карта показала, что технический оператор площадки и оператор персональных данных — не всегда одно юрлицо. По п. 2 ст. 3 Федерального закона № 152-ФЗ оператором считается тот, кто определяет цели и состав обработки. Поэтому роль нельзя назначить участнику только потому, что сведения проходят через его интерфейс.
В одних процессах цели определяла сама лизинговая компания и выступала оператором. В других самостоятельное решение принимал лизингодатель: он использовал собственные политику, согласие и основания. Там, где площадка или внешний сервис выполняли технические действия для другого оператора, применялась модель обработки по поручению.
Самый наглядный конфликт был обнаружен при проверке контрагентов по Федеральному закону № 115-ФЗ. От пользователя запрашивали отдельное согласие. Он мог отказаться или позднее отозвать его — и обязательная проверка упиралась в действие, которое по своей природе должно быть добровольным.
Обязательная по закону проверка не должна зависеть от добровольного согласия пользователя.
Мы разделили основания обработки. Согласие оставили там, где оно действительно требовалось, а обязательную проверку связали с исполнением требований закона — п. 2 ч. 1 ст. 6 152-ФЗ. Передачу во внешний сервис верификации оформили как поручение на обработку по ч. 3 той же статьи. Пользователю больше не нужно было давать отдельное подтверждение там, где обработку уже допускал закон.
Если в вашем продукте обязательные проверки зависят от добровольных согласий, а виджеты партнёров передают данные без ясной модели — стоит провести аудит.
Заказать аудит 152-ФЗ.Новый пользователь мог стать клиентом четырьмя способами: отправить заявку на лизинг, позвонить, заполнить форму на сайте или воспользоваться калькулятором-виджетом на ресурсе партнёра. Последний путь был самым экзотическим: сведения с сайта партнёра попадали прямо в базу сервиса, хотя пользователь фактически не давал своего согласия на это действие и не получал достаточно ясного объяснения, кому и зачем отправляются его данные.
Для каждого типа входа пользователей наша команда описала общую последовательность: какое уведомление видит пользователь, кому передаёт сведения, на каком основании они обрабатываются и какой документ сопровождает действие. При этом нам удалось сохранить механику получения данных через виджеты, так как это важный маркетинговый инструмент.
Ещё один нетипичный процесс возникал, когда менеджер или пользователь рекомендовал подрядчика и передавал его контакт. В этот момент сервис получал сведения о человеке, который сам ещё не взаимодействовал с площадкой и мог не знать о передаче.
Если бы компания определяла цели и состав такой обработки, на неё бы возлагались обязанности оператора, а при отсутствии подходящего правового основания возникали риски жалобы в Роскомнадзор, предписания и административной ответственности.
Аудит затронул и смежные процессы: например, для повторных продаж мы отдельно определили, когда компания может обращаться к действующему клиенту и какое основание требуется для маркетингового сообщения.
Обычно мы в «Зарцын и партнёры» проводим внедрение правовых изменений комплексно, включая активное сотрудничество с менеджментом клиента на каждом этапе переноса наших предписаний непосредственно в бизнес-процессы и программный код. В этом проекте юристы, специализирующиеся на IT и цифровых продуктах, работали в одной связке с продуктовой командой клиента — от карты потоков до финального релиза. Но клиент планировал внедрять изменения самостоятельно. Поэтому итогом стали не только политики, согласия и договорные формулировки, но и отдельные справки по внедрению.
Сначала карта реального движения сведений, затем распределение ролей и оснований, после — документы и инструкция для продуктовой команды.
Юридические тексты выпускались вместе с изменениями интерфейса, а не отдельным архивом.
Узнаете свою ситуацию? Если совпадают хотя бы три из пяти пунктов, продукт и юридическая модель, вероятно, тоже развиваются несинхронно.
Раньше заявка, в которой пользователь не давал отдельное согласие на проверку по 115-ФЗ или позднее отзывал его, выпадала из стандартного маршрута и требовала отдельной обработки. После аудита этот шаг исчез: обязательная проверка больше не зависела от добровольного действия. Каждый процесс получил понятное основание и маршрут, поэтому при подключении партнёров и внешних сервисов команде больше не приходилось заново собирать правовую модель.
Проведём аудит потоков данных, определим роли операторов и уберём лишние барьеры из воронки.
Напишите нам, и мы поможем разобраться.На платформе оператором считается тот, кто определяет цели обработки, — и это не всегда владелец сайта. Один участник может быть оператором в одном процессе и выполнять поручение в другом.
Если виджет на сайте партнёра собирает имя и телефон, это уже обработка персональных данных. Опытный юрист в сфере IT заранее определит три вещи: кто показывает уведомление, куда уходит заявка и какое правовое основание запускает обработку.
В многосторонней платформе с четырьмя каналами привлечения даже один ненужный чекбокс может снижать конверсию. Юридическая чистота и продуктовое удобство здесь не противоречат друг другу: правильно выбранное основание обработки одновременно защищает компанию и убирает барьер из воронки.
Каждая платформа уникальна. Расскажите о своей — мы покажем, где документы расходятся с продуктом.
Получить консультацию
