Продукты
Продукты
Menu
02
База знаний
05
Услуги
01
О нас
04
2025
Контакты
phone
e-mail:
Обучение
03
Как цифровая платформа распределила ответственность за обработку ПДн между несколькими участниками
Клиент — компания, развивающая цифровую платформу с несколькими сервисными направлениями. Для пользователя такая платформа выглядит как единый интерфейс: он заходит в один цифровой контур, выбирает нужную функцию, оставляет данные и ожидает понятного результата.
Но внутри такой модели обработка персональных данных устроена сложнее. Разные сценарии могут обслуживаться разными юридическими лицами, партнерами или внутренними командами. В одном случае данные нужны для регистрации обращения, в другом — для исполнения услуги, в третьем — для коммуникации, сопровождения или передачи информации другому участнику процесса.
13.01.2023
Именно здесь возникает ключевой вопрос по 152‑ФЗ: кто в каждом сценарии определяет цели и способы обработки, кто собирает данные, кто отвечает перед субъектом, кто размещает документы и кто фактически выступает оператором.
Если эта логика не описана, платформа начинает копить правовую неопределенность. Пользователь видит единый сервис, а внутри компании нет единой картины: кто владелец процесса, какие документы должны сопровождать конкретный сценарий, кто отвечает на запросы субъектов и кто контролирует корректность обработки.
09/07/25
Б-152
Задача
Клиент обратился с запросом на аудит цифровой платформы и распределение процессов между операторами персональных данных.
Задача была не просто проверить документы на соответствие 152‑ФЗ, а разложить платформу на конкретные пользовательские сценарии и определить, кто отвечает за обработку персональных данных в каждом из них.
Нужно было дать рекомендации по нескольким блокам:
На старте основная проблема была не в отсутствии документов как таковых. Документы существовали, но платформа развивалась быстрее, чем карта ответственности. Новые функции, партнерские сценарии и разные пользовательские пути постепенно усложнили модель обработки. В итоге общих формулировок стало недостаточно.
Задача была не просто проверить документы на соответствие 152‑ФЗ, а разложить платформу на конкретные пользовательские сценарии и определить, кто отвечает за обработку персональных данных в каждом из них.
Нужно было дать рекомендации по нескольким блокам:
- как определить оператора для каждого процесса;
- какие данные и цели обработки относятся к каждому сценарию;
- какие документы должны сопровождать обработку;
- как не смешивать ответственность разных участников;
- как объяснить пользователю, кто и зачем обрабатывает его данные;
- какие организационные меры нужны каждому оператору;
- как снизить риск противоречий при запуске новых функций.
На старте основная проблема была не в отсутствии документов как таковых. Документы существовали, но платформа развивалась быстрее, чем карта ответственности. Новые функции, партнерские сценарии и разные пользовательские пути постепенно усложнили модель обработки. В итоге общих формулировок стало недостаточно.
Вызовы
Один интерфейс скрывал несколько самостоятельных процессов
Пользовательский интерфейс объединял несколько направлений, но с точки зрения 152‑ФЗ каждое из них нужно было оценивать отдельно. Один сценарий мог предполагать сбор контактных данных, другой — передачу информации партнеру, третий — обработку данных для сервисной коммуникации или сопровождения обращения.
Если описать все единой фразой «платформа обрабатывает персональные данные пользователей», модель получится слишком размытой. Для регуляторной логики важнее другое: кто именно определяет цель обработки, кто выбирает состав данных и кто принимает решение о действиях с ними.
Именно это отличает оператора от иных участников процесса. Если роль определена неверно, дальше ошибочно выстраиваются согласия, политика, поручения, ответы субъектам и внутренние обязанности по защите персональных данных.
Если описать все единой фразой «платформа обрабатывает персональные данные пользователей», модель получится слишком размытой. Для регуляторной логики важнее другое: кто именно определяет цель обработки, кто выбирает состав данных и кто принимает решение о действиях с ними.
Именно это отличает оператора от иных участников процесса. Если роль определена неверно, дальше ошибочно выстраиваются согласия, политика, поручения, ответы субъектам и внутренние обязанности по защите персональных данных.
Документы разных участников могли расходиться между собой
В мультиоператорной модели проблема часто появляется не в одном документе, а на стыке документов. Политика одного участника описывает одну логику, пользовательская форма показывает другую, внутренний процесс работает по третьей.
Для пользователя это выглядит непрозрачно: он оставляет данные в едином интерфейсе, но не понимает, кому именно их передает и для какой цели. Для бизнеса это создает другой риск: при проверке или запросе сложно показать непротиворечивую модель ответственности.
Для пользователя это выглядит непрозрачно: он оставляет данные в едином интерфейсе, но не понимает, кому именно их передает и для какой цели. Для бизнеса это создает другой риск: при проверке или запросе сложно показать непротиворечивую модель ответственности.
Новые функции запускались быстрее, чем обновлялась карта обработки
Цифровые платформы редко остаются статичными. Добавляются новые сервисы, меняются пользовательские сценарии, подключаются партнеры, дорабатываются формы и внутренние маршруты данных.
Если при каждом изменении не проверять, кто оператор процесса и какие документы должны быть обновлены, платформа быстро получает накопленный разрыв между продуктовой реальностью и юридическим оформлением.
Если при каждом изменении не проверять, кто оператор процесса и какие документы должны быть обновлены, платформа быстро получает накопленный разрыв между продуктовой реальностью и юридическим оформлением.
«Минимизация данных» не решала проблему роли оператора
Сокращение состава данных снижает часть рисков, но не заменяет корректного распределения ответственности. Даже небольшой объем персональных данных может создать нарушение, если пользователь не понимает, кто их собирает, зачем и на каком основании.
В этом проекте важно было не просто рекомендовать собирать меньше данных, а выстроить процесс так, чтобы каждый сценарий имел владельца, цель, правовое основание и понятное внешнее объяснение.
В этом проекте важно было не просто рекомендовать собирать меньше данных, а выстроить процесс так, чтобы каждый сценарий имел владельца, цель, правовое основание и понятное внешнее объяснение.
Решение
1. Восстановили фактическую картину процессов
Команда компании Б-152 начала с интервью и анализа фактических сценариев платформы. Цель была не в том, чтобы описать платформу как единый сайт или сервис, а в том, чтобы разложить ее на отдельные процессы обработки персональных данных.
По каждому сценарию фиксировались:
Такой подход позволил перейти от общей схемы к процессной карте: стало видно, где один участник выступает оператором, где другой получает данные в самостоятельной роли, а где требуется дополнительная настройка документов и пользовательских уведомлений.
По каждому сценарию фиксировались:
- точка входа пользователя;
- действие, которое запускает обработку;
- состав собираемых данных;
- цель обработки;
- участники процесса;
- организация, которая принимает ключевые решения по обработке;
- документы, которые видит пользователь;
- внутренние документы, которые подтверждают выбранную модель.
Такой подход позволил перейти от общей схемы к процессной карте: стало видно, где один участник выступает оператором, где другой получает данные в самостоятельной роли, а где требуется дополнительная настройка документов и пользовательских уведомлений.
2. Проанализировали платформу как набор пользовательских сценариев
Следующий этап — анализ сервиса глазами пользователя. Команда прошла по ключевым сценариям: где пользователь оставляет данные, какие тексты видит, какие документы доступны, как объяснены цели обработки и есть ли ясность по тому, кто именно работает с данными.
Это важно, потому что именно внешний интерфейс часто показывает слабые места модели. Если пользовательский путь один, а операторов внутри несколько, документы и интерфейс должны помогать пользователю разобраться, а не создавать впечатление, что все данные собирает один участник без разделения целей и ответственности.
Это важно, потому что именно внешний интерфейс часто показывает слабые места модели. Если пользовательский путь один, а операторов внутри несколько, документы и интерфейс должны помогать пользователю разобраться, а не создавать впечатление, что все данные собирает один участник без разделения целей и ответственности.
3. Сопоставили документы разных участников с фактической логикой
Команда изучила предоставленную документацию и сопоставила ее с реальными процессами платформы. Проверялась не только полнота документов, но и их согласованность между собой.
В фокусе были вопросы:
В фокусе были вопросы:
- совпадают ли цели обработки в документах и интерфейсе;
- понятно ли, кто оператор в конкретном сценарии;
- нет ли смешения ролей между участниками;
- корректно ли описаны передачи персональных данных;
- есть ли у каждого оператора собственная логика выполнения обязанностей по 152‑ФЗ;
- не создают ли документы противоречий для пользователя и внутренних команд.
Если в компании похожая модель — один цифровой интерфейс, несколько участников обработки и нет полной уверенности, кто оператор в каждом сценарии, — такую задачу можно предварительно обсудить с экспертами компании Б-152.
Для этого достаточно оставить заявку и кратко описать, какие процессы нужно разобрать: пользовательские формы, партнерские сценарии, документы на сайте, распределение ролей или ответы на запросы субъектов.
4. Сформировали рекомендации по распределению ответственности
По итогам анализа команда подготовила отчет с рекомендациями по распределению процессов между операторами и корректной организации обработки каждым участником.
Отчет был построен не как общий чек-лист, а как навигационная модель: какой процесс кому принадлежит, какие документы должны его сопровождать, что нужно объяснить пользователю и какие организационные элементы нужны внутри.
Это особенно важно для платформенных сервисов. Когда запускается новая функция, команда должна не заново спорить, кто отвечает за персональные данные, а применять понятный критерий: кто определяет цель, состав данных и способ обработки в конкретном сценарии.
Отчет был построен не как общий чек-лист, а как навигационная модель: какой процесс кому принадлежит, какие документы должны его сопровождать, что нужно объяснить пользователю и какие организационные элементы нужны внутри.
Это особенно важно для платформенных сервисов. Когда запускается новая функция, команда должна не заново спорить, кто отвечает за персональные данные, а применять понятный критерий: кто определяет цель, состав данных и способ обработки в конкретном сценарии.
5. Помогли выстроить коммуникацию по внешним вопросам
В проектах с несколькими участниками обработки часто возникают вопросы, которые требуют аккуратной внешней коммуникации: куда направлять запрос, кто должен отвечать, как формулировать позицию и как не дать разные ответы от разных участников одного процесса.
Команда помогала клиенту структурировать такие вопросы и готовить более согласованную позицию. Для мультиоператорной модели это практично: единая логика коммуникации снижает риск разрозненных действий и противоречивых объяснений.
Команда помогала клиенту структурировать такие вопросы и готовить более согласованную позицию. Для мультиоператорной модели это практично: единая логика коммуникации снижает риск разрозненных действий и противоречивых объяснений.
Что было сделано
В рамках проекта команда компании Б-152 провела аудит цифровой платформы как набора процессов обработки персональных данных.
В проект вошли:
Практическая ценность проекта была в том, что клиент получил не абстрактный вывод «документы нужно обновить», а рабочую модель: как определить владельца процесса, какие документы должны сопровождать сценарий и как объяснять обработку пользователю.
В проект вошли:
- интервью с участниками процессов со стороны клиента;
- анализ платформы через пользовательские сценарии;
- выявление точек сбора и передачи персональных данных;
- анализ документации разных участников обработки;
- сопоставление документов с фактической логикой процессов;
- определение оператора для ключевых сценариев;
- рекомендации по распределению ответственности между участниками;
- рекомендации по корректной организации обработки каждым оператором;
- настройка логики внешних документов и пользовательских объяснений.
Практическая ценность проекта была в том, что клиент получил не абстрактный вывод «документы нужно обновить», а рабочую модель: как определить владельца процесса, какие документы должны сопровождать сценарий и как объяснять обработку пользователю.
Результат
Клиент получил более управляемую модель обработки персональных данных на цифровой платформе.
Во-первых, снизилась правовая неопределенность. Для ключевых сценариев стало понятно, какая организация выступает оператором, какие данные обрабатываются, с какой целью и какие документы должны подтверждать эту модель.
Во-вторых, повысилась управляемость изменений. Когда процессы распределены по владельцам и есть логика определения оператора, запуск новых функций и партнерских сценариев не приводит автоматически к накоплению противоречий в документах.
Во-третьих, улучшилась готовность к внешним вопросам. В мультиоператорной модели важно не только фактическое соответствие требованиям, но и способность объяснить его ясно, последовательно и без расхождений между участниками.
В-четвертых, платформа получила основу для дальнейшего развития. Теперь при изменении сценария можно оценивать не только продуктовую или техническую часть, но и privacy‑последствия: кто оператор, какие данные собираются, какие документы обновить и как проинформировать пользователя.
Во-первых, снизилась правовая неопределенность. Для ключевых сценариев стало понятно, какая организация выступает оператором, какие данные обрабатываются, с какой целью и какие документы должны подтверждать эту модель.
Во-вторых, повысилась управляемость изменений. Когда процессы распределены по владельцам и есть логика определения оператора, запуск новых функций и партнерских сценариев не приводит автоматически к накоплению противоречий в документах.
Во-третьих, улучшилась готовность к внешним вопросам. В мультиоператорной модели важно не только фактическое соответствие требованиям, но и способность объяснить его ясно, последовательно и без расхождений между участниками.
В-четвертых, платформа получила основу для дальнейшего развития. Теперь при изменении сценария можно оценивать не только продуктовую или техническую часть, но и privacy‑последствия: кто оператор, какие данные собираются, какие документы обновить и как проинформировать пользователя.
Что этот кейс показывает рынку
Кейс актуален для цифровых платформ, агрегаторов, маркетплейсов, экосистемных сервисов и компаний, где в одном пользовательском интерфейсе реализованы процессы нескольких организаций или направлений.
Главная ошибка в таких моделях — пытаться закрыть все одной общей политикой и универсальными формулировками. Это удобно на старте, но плохо масштабируется. Чем больше сценариев, тем выше риск, что пользовательские объяснения и фактическая модель ответственности начнут расходиться.
Вторая ошибка — считать, что минимизация данных решает проблему сама по себе. Да, избыточные данные нужно убирать. Но даже минимальный набор сведений требует понятной цели, правового основания, владельца процесса и корректного внешнего объяснения.
Третья ошибка — откладывать распределение ролей до момента проверки или конфликта. В платформенных моделях роли нужно определять при проектировании процесса, а не после запуска. Иначе потом приходится исправлять не только документы, но и интерфейс, договорную модель и внутренние маршруты данных.
Главная ошибка в таких моделях — пытаться закрыть все одной общей политикой и универсальными формулировками. Это удобно на старте, но плохо масштабируется. Чем больше сценариев, тем выше риск, что пользовательские объяснения и фактическая модель ответственности начнут расходиться.
Вторая ошибка — считать, что минимизация данных решает проблему сама по себе. Да, избыточные данные нужно убирать. Но даже минимальный набор сведений требует понятной цели, правового основания, владельца процесса и корректного внешнего объяснения.
Третья ошибка — откладывать распределение ролей до момента проверки или конфликта. В платформенных моделях роли нужно определять при проектировании процесса, а не после запуска. Иначе потом приходится исправлять не только документы, но и интерфейс, договорную модель и внутренние маршруты данных.
Вывод для рынка
В этом проекте ценность работы заключалась в том, что команда компании Б-152 помогла клиенту увидеть платформу не как единый цифровой продукт, а как совокупность процессов обработки персональных данных.
Такой взгляд меняет качество управления рисками. Когда для каждого сценария понятно, кто оператор, какие данные обрабатываются, зачем они нужны и какие документы это подтверждают, платформа становится устойчивее: проще запускать новые функции, отвечать на внешние вопросы и поддерживать соответствие 152‑ФЗ без постоянного ручного разбора каждого изменения.
Такой взгляд меняет качество управления рисками. Когда для каждого сценария понятно, кто оператор, какие данные обрабатываются, зачем они нужны и какие документы это подтверждают, платформа становится устойчивее: проще запускать новые функции, отвечать на внешние вопросы и поддерживать соответствие 152‑ФЗ без постоянного ручного разбора каждого изменения.
Для бизнеса с несколькими участниками обработки это наиболее практичный подход: не прятать сложность за общей политикой, а сделать распределение ответственности понятным для пользователя, внутренних команд и внешних проверяющих.
Ввод оборотных штрафов за утечки откладывается минимум до 1 июля 2023 года
Материалы по теме