152-ФЗ: Операторы ПДн в SaaS-агрегаторах мессенджеров

При использовании SaaS‑агрегатора мессенджеров в РФ по общему правилу оператором персональных данных выступает российская компания‑клиент, а агрегатор — обработчиком по договору; владелец мессенджера (например, Meta) может быть отдельным обработчиком или субобработчиком, а модель совместной ответственности возможна, если стороны совместно определяют цели и объём обработки. Требования 152 фз по локализации персональных данных и правила трансграничной передачи означают, что простая формулировка в политике «допускается передача третьим лицам и трансграничная обработка» обычно недостаточна — нужны договоры, технические меры и конкретные основания для передачи (согласие, исполнение договора и т.п.). При агрегировании переписок из сервисов, ограниченных в РФ, или при передаче через зарубежные серверы (например, через WhatsApp API) необходимо обеспечить хранение копий ПДн в РФ, контролировать субподрядчиков и документировать меры безопасности.

---

Содержание

• Кто считается оператором или обработчиком при SaaS‑агрегаторе?
• Локализация персональных данных и трансграничная передача ПДн
• Если агрегатор работает с ограниченными сервисами (Meta) или зарубежными серверами
• Юридические меры: договоры, назначение ролей, уведомления
• Технические меры: хранение в РФ, шифрование, минимизация, аудит
• Практические сценарии и пошаговые рекомендации
• Источники
• Заключение

---

Кто считается оператором или обработчиком персональных данных при использовании SaaS‑агрегатора мессенджеров?

Сначала — определение. Согласно тексту 152 фз, оператор — лицо, которое определяет цели и средства обработки персональных данных, а обработчик (исполнитель) выполняет обработку по поручению оператора; см. полный текст закона на Consultant.ru. На основе этого в реальных проектах с SaaS‑агрегаторами мессенджеров обычно складывается следующая картина:

• Российская компания‑клиент. Как правило считается оператором персональных данных, если она определяет, какие данные собираются у клиентов, с какой целью (поддержка, исполнение договора, маркетинг и т.д.) и какими способами будет осуществляться обработка. Оператор несёт основную ответственность за соблюдение 152 фз (регистрация/уведомления, реализация прав субъектов, локализация и т.д.).
• SaaS‑агрегатор. Обычно выступает обработчиком: хранит, маршрутизирует и предоставляет доступ к перепискам по инструкции оператора. При этом он обязан действовать строго по договору и техническим инструкциям оператора.
• Владелец мессенджера (например, Meta). Может быть отдельным обработчиком или субподрядчиком — если данные проходят через их сервисы (API), они фактически участвуют в обработке. Но юридическая ответственность за соблюдение требований по локализации и уведомлениям в первую очередь остаётся за оператором (российской компанией), если именно она определяет цели обработки.
• Совместная ответственность. Если агрегатор и клиент совместно определяют цели и способы обработки (например, агрегатор использует данные для собственной аналитики или коммерческих целей, а не только по поручению клиента), они могут выступать как совместные операторы и должны распределить обязанности договором (права субъектов, кто отвечает за запросы, обработку жалоб и т.п.) — это отмечено в разъяснениях Роскомнадзора и практических комментариях (РКН, Garant).

Критерии, по которым суд/регулятор определит роль:

• Кто определяет цель обработки и набор данных;
• Кто формирует политику хранения и сроки удаления;
• Использует ли лицо данные для собственных целей (монетизация, аналитика);
• Кто имеет технический доступ к содержимому сообщений и ключам шифрования.

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

---

Локализация персональных данных и трансграничная передача ПДн

Что требует закон. Статья 18 152 фз и разъяснения регуляторов устанавливают обязанность по локализации персональных данных граждан РФ: базы данных с такими ПДн должны располагаться на территории РФ; при трансграничной передаче оператор обязан обеспечить, чтобы копии данных (или необходимые для защиты данные) хранились в РФ и были доступны для исполнения обязанностей оператора (Consultant.ru; разъяснения Роскомнадзора — rkn.gov.ru). Трансграничная передача допускается, но только при наличии законных оснований (например, согласия субъекта персональных данных, необходимостью исполнения договора и т.п.) и при соблюдении условий.

Практический смысл для SaaS‑агрегатора:

• Если агрегатор или владелец мессенджера хранит или пропускает ПДн россиян только на зарубежных серверах без копий в РФ — риск нарушения 152 фз.
• Наличие общей фразы в политике конфиденциальности о том, что «передача третьим лицам и трансграничная обработка допускается», не заменяет выполнения конкретных требований: нужно законное основание, техническая возможность локализации (копии в РФ) и документальное оформление (договоры, уведомления) — на это указывают и практические комментарии по теме (Garant, Pravo.ru).

---

Если агрегатор агрегирует переписку из сервисов, доступ к которым в РФ ограничен, и/или передаёт через зарубежные серверы

Что происходит, если используется WhatsApp API или другие зарубежные сервисы (Meta, Instagram и т.д.)? Возможны три ключевых проблемы:

1. Трафик и данные фактически проходят через иностранные инфраструктуры (риск нарушения локализации).
2. Сервисы могут быть технически недоступны или заблокированы в РФ; попытки обхода (VPN, прокси) добавляют риски.
3. End‑to‑end‑шифрование и архитектура API могут ограничивать возможность агрегировать или хранить требуемые копии данных.

Можно ли «перенаправить» трафик в РФ? Регулятор обсуждает варианты проксирования и размещения копий в РФ, но на практике это требует технической реализации и согласования с владельцами сервисов; агрегатор должен обеспечить, чтобы у оператора была возможность хранить копии ПДн в российских ЦОДах и управлять доступом к ним (rkn.gov.ru, Pravo.ru).

Варианты решения:

• Использовать агрегатора, который предоставляет российский хостинг/зеркало данных и гарантирует хранение копий в РФ.
• Ограничить сбор того, что нельзя легально локализовать (например, отказаться от содержания переписки из E2E‑шифрованных каналов, хранить только метаданные).
• Получать явное согласие субъектов на трансграничную обработку и документировать основания (но согласие не снимает обязательства по локализации — копия всё равно должна быть доступна в РФ).
• Рассмотреть альтернативные каналы коммуникации, локальные мессенджеры или собственные встроенные чаты.

Риск для бизнеса: нарушение требований локализации и трансграничной обработки может привести к административным мерам (штрафы, приостановка деятельности, требования Роскомнадзора). Поэтому заранее оцените архитектуру данных и юридические риски.

---

Юридические меры: договоры, назначение ролей, уведомления, реестр операторов

Что нужно оформить юридически (минимально обязательный набор):

• Ясное назначение ролей. В договоре и внутренних политиках зафиксировать, кто является оператором, кто — обработчиком, а при совместной ответственности — документально распределить обязанности (ответы на запросы субъектов, уведомление о нарушениях, хранение данных и т.д.) (см. разъяснения РКН).
• Договор об обработке персональных данных. Обязательные пункты: предмет и цели обработки, категории обрабатываемых ПДн, сроки хранения, порядок действий при истребовании субъектов, порядок и основания трансграничной передачи, список субобработчиков, требования по безопасности, порядок уведомления о нарушениях, ответственность сторон (Consultant.ru; комментарии в Garant).
• Согласие субъектов или иные основания. Для трансграничной передачи оператор должен иметь документальное основание (согласие, исполнение договора, иные основания по закону).
• Уведомления и реестр. Оператору рекомендуется поддерживать актуальную документацию по обработкам и, при необходимости, уведомлять контролирующие органы — запрашивать разъяснения в частных случаях (см. разъяснения Роскомнадзора на rkn.gov.ru).
• Пункт о субподрядчиках. В договоре с агрегатором требуйте раскрытия списка субподрядчиков (включая инфраструктуру Meta/иных поставщиков) и возможность утверждать/отключать их.
• Права аудита. Оператор должен иметь право проводить аудиты и проверять технические и организационные меры агрегатора.
• Политика конфиденциальности и информирование субъектов. Текст для пользователей должен содержать конкретику: какие данные собираются, кому передаются, на каких основаниях и в какие страны; общая фраза про «возможную передачу» — недостаточна.

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

---

Технические меры: хранение в РФ, шифрование персональных данных, минимизация, аудит

Требуемые и рекомендуемые технические меры:

• Хранение в РФ. Наличие физически расположенных в РФ баз данных или зеркал (копий) ПДн российских граждан; подтверждение — договоры с провайдерами хостинга, топология сетей, карты потоков данных.
• Шифрование. TLS для транспорта; шифрование данных в покое. По возможности — хранение ключей и управление ими в РФ (ключи под контролем оператора). При необходимости учитывать требования к отечественным криптосредствам (ГОСТ) — см. практические рекомендации в отраслевых обзорах (Garant, Habr).
• End‑to‑end и доступ к контенту. Если используется E2E‑шифрование, агрегатор может физически не иметь доступа к содержимому; тогда нельзя требовать «локализации содержимого», и нужно пересматривать архитектуру сервиса (например, использовать бизнес‑API, дающее легальный доступ к контенту, либо хранить метаданные).
• Минимизация. Собирайте и храните только те поля ПДн, которые действительно нужны для целей обработки. Псевдонимизация и анонимизация там, где допустимо.
• Управление доступом и логирование. RBAC, MFA, аудит доступа, хранение журналов операций, регулярный мониторинг и отчётность.
• Аудиты и тесты. Регулярные пентесты, оценка уязвимостей, отчёты по соответствию. Агрегатор должен предоставлять результаты аудитов по требованию оператора.
• План реагирования на утечки. Процедуры уведомления оператора и регулятора, резервное копирование, план восстановления.

Техническая реализация должна сочетаться с договорными гарантиями: наличие хостинга в РФ — это не только пункт в договоре, а подтверждённый факт (доступ к контрактам с провайдером, информация о местах хранения, SLA).

---

Практические сценарии и пошаговые рекомендации

Короткий чек‑лист для российской компании (оператора):

• Фиксируйте в документах, что вы — оператор и какие цели обработки.
• До подключения агрегатора запросите datasheet: архитектура, список субобработчиков, локация серверов, политика сохранения данных.
• Подпишите договор об обработке ПДн с чёткими SLA по локализации, безопасности и уведомлениям о нарушениях.
• Если используется WhatsApp/Meta/API: потребуйте доказательства возможности хранения копий в РФ или откажитесь от функционала, который нельзя легально локализовать.
• Обновите политику конфиденциальности — конкретно и прозрачно (категории данных, страны передачи, правовая основа).
• Подготовьте план действий на случай блокировок/изменений доступа к зарубежным сервисам.

Чек‑лист для агрегатора:

• Выполняйте обработку только по письменной инструкции оператора, если вы обработчик.
• Предоставьте оператору технические подтверждения хранения данных в РФ (контракты с ЦОД, архитектура).
• Раскрывайте всех субподрядчиков (включая сервисы Meta) и условия их участия.
• Обеспечьте шифрование, журналирование, возможность аудитирования и своевременное уведомление об инцидентах.
• Не используйте данные для собственных целей без отдельного, оформленного соглашения.

Небольшие сценарии:

• Если агрегатор не может гарантировать локализацию содержимого (например, из‑за E2E): храните только метаданные в РФ; оговорите ограничения в договоре и в политике.
• Если требуется использование иностранного API ради бизнес‑функции: добейтесь локального зеркала и согласия субъектов; документируйте всё.

---

Источники

1. Роскомнадзор — Персональные данные
2. Текст 152‑ФЗ на Consultant.ru
3. Комментарий по SaaS и обработке ПДн — Garant
4. Практика и разборы — Habr
5. Разъяснения и новости о локализации — Pravo.ru

---

Заключение

В большинстве случаев при использовании saas агрегатора мессенджеров оператором персональных данных будет российская компания‑клиент, агрегатор — обработчиком, а владелец мессенджера (Meta) — субобработчиком либо сторонним обработчиком; модель совместной ответственности наступает при совместном определении целей и объёма обработки. Требования 152 фз и практика регулятора делают ключевой задачу локализацию персональных данных и наличие законных оснований для трансграничной передачи: простая формулировка в политике о «передаче третьим лицам» чаще всего недостаточна. Нужны оформленные договоры об обработке ПДн, подтверждённое хранение в РФ, технические меры (шифрование, минимизация, аудит) и прозрачность по субподрядчикам — иначе риски юридической и технической ответственности остаются высокими.