Когда европейский регулятор спрашивает не «есть ли у вас SCC», а «почему вы решили, что передача вообще допустима», спорить уже поздно. В трансграничной передаче данных риски возникают не на этапе подписания шаблонов, а раньше — в момент, когда компания неверно определяет роли, маршрут данных, применимое право и фактический доступ к информации. Именно поэтому вопрос how to assess cross border transfers для технологического бизнеса — это не формальность комплаенса, а часть стратегии выхода на международные рынки, переговоров с инвесторами и защиты продукта от регуляторных ограничений.
Для русскоязычных фаундеров, генеральных юрисконсультов и руководителей по комплаенсу проблема обычно выглядит так: инфраструктура распределена между несколькими облаками, разработка ведется в разных странах, аналитика подключена через внешние сервисы, а пользователи находятся в ЕС, США, СНГ, Латинской Америке или Азии. Формально данных касается сразу несколько режимов — от GDPR и UK GDPR до 152-ФЗ, LGPD, PIPL, CPRA и отраслевых правил. Практически это означает, что один и тот же поток данных может быть законным в одной части архитектуры и проблемным в другой.
Как оценивать трансграничные передачи данных на практике
Оценка начинается не с договора и не с чек-листа по SCC. Сначала нужно понять, что именно передается, кем, кому, из какой юрисдикции и на каком основании. Если этот фундамент не собран, любая последующая документация будет слабой.
Первая задача — картирование потоков данных. Не на уровне абстрактного «мы используем облако», а на уровне конкретных операций: сбор, хранение, удаленный доступ, резервное копирование, техподдержка, логирование, обучение моделей, антифрод, маркетинговая аналитика. Во многих проектах передача происходит даже там, где бизнес ее не замечает: например, при доступе инженеров из третьей страны к продовой среде или при отправке событий в систему мониторинга, размещенную за пределами страны сбора данных.
Дальше нужно отделить реальные трансграничные передачи от внутренних перемещений внутри одной группы компаний. Это не одно и то же. Если юридические лица разные, если есть доступ из-за рубежа, если поставщик обрабатывает данные в нескольких регионах, регулятор, скорее всего, будет смотреть на это как на передачу. Особенно под GDPR, где доступ из третьей страны сам по себе может образовывать transfer.
Шаг 1. Определите роли сторон и правовую квалификацию операции
Одна из самых частых ошибок — считать всех подряд обработчиками. В реальности в цепочке могут быть контролер, совместные контролеры, обработчик, субобработчик, независимый оператор, агент, хостинг-провайдер с ограниченным доступом и сервис, который фактически использует данные для собственных целей. От этой квалификации зависит почти все: набор договоров, объем гарантий, распределение ответственности и допустимый механизм передачи.
Например, американский SaaS-провайдер может формально предлагать DPA как обработчик, но в части телеметрии, улучшения сервиса или предотвращения злоупотреблений действовать в собственных целях. Тогда оценка должна охватывать обе роли, а не только «processor relationship». Если компания этого не замечает, в документах возникает разрыв между фактической моделью и юридическим описанием.
Шаг 2. Установите, какие законы применяются одновременно
Трансграничная передача редко анализируется только по одному закону. Если вы работаете с пользователями из ЕС, храните часть данных в России, продаете продукт в США и используете команду разработки в Армении или Казахстане, у вас может быть параллельное действие нескольких режимов. Это создает не только нагрузку по документам, но и прямые конфликты.
Характерный пример — сочетание требований GDPR к передаче в третьи страны с российскими правилами локализации персональных данных. В ряде моделей сначала требуется обеспечить первичную запись и систематизацию в России в соответствии со статьей 18.1 152-ФЗ, а уже затем анализировать дальнейшую передачу за рубеж. Аналогично в Китае вопрос может упираться не только в договорный механизм, но и в обязательность отдельной процедуры безопасности, если пороги или категория данных подпадают под PIPL и связанные акты.
Поэтому правильный вопрос не «какой механизм выбрать», а «какие обязательные условия должны быть выполнены одновременно, чтобы передача не нарушала несколько режимов сразу».
How to assess cross border transfers без ложного чувства безопасности
На практике бизнес часто ищет один универсальный ответ: подписать SCC, получить согласие, добавить пункт в политику конфиденциальности. Это создает видимость контроля, но не всегда снижает риск. После Schrems II для передачи по GDPR важен не только сам договорный механизм, но и оценка правовой среды страны получателя, а также фактических технических и организационных мер.
Если данные передаются в юрисдикцию, где государственные органы имеют широкий доступ к информации без достаточных гарантий для субъектов данных, одних SCC может быть недостаточно. Тогда требуется дополнительная оценка: какие категории данных передаются, шифруются ли они, кто владеет ключами, возможен ли доступ в открытом виде, есть ли сегментация, псевдонимизация, журналирование запросов, политика реагирования на требования органов власти.
Именно здесь юристы без технического понимания инфраструктуры часто упираются в предел своей модели. Нельзя качественно оценить передачу, если никто не разобрался, где именно лежат данные, как устроены ключи шифрования, кто имеет административный доступ, какие логи хранятся, как работают резервные копии и возможна ли репликация между регионами автоматически.
Шаг 3. Проведите оценку страны получателя и фактического риска доступа
Эта часть особенно важна для компаний, работающих через облака, подрядчиков поддержки и распределенные команды. Нужно анализировать не только текст закона, но и практическую исполнимость гарантий. Есть ли независимый судебный контроль? Может ли субъект данных обжаловать доступ? Обязан ли поставщик раскрывать факт запроса? Разрешено ли оспаривание? Насколько широко сформулированы полномочия органов?
Но и здесь нет универсального правила. Передача обезличенной телеметрии с сильной технической изоляцией оценивается иначе, чем удаленный доступ к медицинским записям, финансовым профилям или данным детей. Категория данных, объем, контекст обработки и бизнес-необходимость меняют выводы.
Шаг 4. Выберите механизм передачи, который соответствует именно вашей модели
Под GDPR это могут быть adequacy decision, SCC, BCR, исключения для отдельных ситуаций. В других режимах набор инструментов иной: где-то акцент на согласии, где-то на регистрации баз, где-то на локализации, где-то на государственном одобрении. Ошибка многих международных групп в том, что они используют один пакет документов для всех рынков, хотя правовая логика режимов различается.
Согласие, например, выглядит удобным, но редко является устойчивой опорой для масштабной и повторяющейся передачи в корпоративной инфраструктуре. Оно может быть отозвано, может не отвечать критериям добровольности в трудовых отношениях и плохо работает там, где передача необходима для постоянной операционной модели бизнеса. SCC, в свою очередь, сильнее как системный инструмент, но требуют корректного наполнения приложений, анализа законодательства страны получателя и настройки дополнительных мер.
На что регулятор смотрит в первую очередь
Регулятор обычно не начинает с тонких теоретических вопросов. Он проверяет, понимает ли компания собственные потоки данных и может ли подтвердить логику своего решения документально. Если вы не можете показать карту передач, реестр поставщиков, квалификацию ролей, основания обработки, механизм передачи и внутреннюю оценку риска, спор о нюансах почти бессмысленен.
Второй фокус — соответствие документов реальности. Если в DPA написано, что данные хранятся только в ЕС, а DevOps-команда из третьей страны имеет постоянный административный доступ, это уже зона претензий. Если политика обещает отсутствие международной передачи, а SDK отправляет события на серверы в США, проблема становится не только комплаенс-вопросом, но и вопросом недостоверного информирования субъектов.
Третий фокус — управляемость. Есть ли процесс согласования новых поставщиков? Проверяются ли subprocessor changes? Блокируется ли подключение сервисов без legal review? Что происходит при инциденте, когда выясняется, что данные ушли в неутвержденный регион? Компании с сильной позицией отличаются не идеальностью, а способностью быстро выявлять и исправлять отклонения.
Где чаще всего ошибаются технологические компании
Самые дорогие ошибки обычно неочевидны. Это не отсутствие одного документа, а несостыковка между продуктом, инфраструктурой и правовой моделью. Например, команда считает аналитику «анонимной», хотя идентификаторы устройства, IP-адреса и связка событий позволяют повторную идентификацию. Или бизнес уверен, что данные остаются в Европе, но подрядчик поддержки из третьей страны видит тикеты с персональными данными и скриншотами пользователей.
Еще одна типичная проблема — игнорирование вторичных передач. Компания подписала договор с европейским вендором, но не проверила его цепочку субобработчиков. В итоге фактическая обработка уходит дальше — в США, Индию, Израиль или Сингапур. Формально это уже другая карта риска, и ее нужно оценивать отдельно.
Если вашей команде нужно не просто «оформить бумаги», а выстроить правовую модель передачи под реальную архитектуру продукта, юристы DATA-lawyer помогают связать регуляторные требования с облачной инфраструктурой, продуктовой логикой и международной операционной моделью компании.
Хорошая оценка трансграничной передачи не тормозит рост. Она убирает правовую неопределенность там, где она дороже всего — в сделках, масштабировании и кризисных сценариях. Чем раньше вы проверите реальную картину потоков данных, тем меньше шанс, что следующий раунд инвестиций, проверка контрагента или запрос регулятора превратятся в экстренный ремонт всей архитектуры.