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