Локализация персональных данных

Для цифровых сервисов это не абстрактная юридическая строка, а проверка всей цепочки обработки — от формы регистрации в приложении до облачной CRM и аналитического счётчика. Российский сервер «где-то в архитектуре» больше не выглядит индульгенцией.

Первичный сбор — не место для зарубежного облака

Ограничение касается записи, систематизации, накопления, хранения, уточнения и извлечения персональных данных при их сборе. В перечне каналов — сайты, интернет-магазины, личные кабинеты, мобильные приложения, формы заявок и онлайн-сервисы.

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

Ранее, как отмечает источник, норму часто трактовали как возможность параллельного внесения данных в российскую и иностранную базы. Теперь подход однозначнее: первичный контур обработки должен использовать российские базы. Удобный зарубежный SaaS не перестаёт быть зарубежным оттого, что его админка переведена на русский.

Трансграничная передача не отменена, но автоматизма больше нет

Локализация не означает полного запрета на передачу данных иностранному получателю. После первичного сбора через российскую базу такая передача возможна при соблюдении требований статьи 12 закона № 152-ФЗ. По общему правилу до её начала требуется отдельное уведомление в Роскомнадзор.

Ключевое слово здесь — «после». Российская база не легализует любой дальнейший экспорт сама по себе: нужны правовое основание и необходимые документы. Архитектура в стиле «сначала пишем всё в американское облако, а потом синхронизируем локальную копию» выглядит как попытка закрыть люк после взрыва. Для безопасника это не локализация, а следы плохого проектирования.

Особенно внимательно стоит смотреть на Google Analytics, иностранные облачные хранилища, CRM, сервисы рассылок и онлайн-чаты — инструменты, которые могут автоматически передавать сведения на иностранные серверы. В мобильных продуктах такой же аудит нужен для подключённых сервисов: важен не только договор с поставщиком, но и фактический поток данных.

Что проверить владельцу сервиса

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

Дальше по каждому сервису нужно установить:

• какие именно сведения туда поступают;
• где расположены используемые базы данных;
• предусмотрена ли передача за пределы России;
• на каком этапе происходит первичная запись и хранение;
• какие внешние CRM, аналитика, чаты, рассылки и хранилища получают данные автоматически.

Повторное нарушение требований может обернуться для организации или ИП штрафом от 6 млн до 18 млн рублей. Но денежная часть — лишь финальный симптом. Настоящая проблема обычно обнаруживается раньше: компания не знает, какие SDK, вебхуки и облачные коннекторы тянут персональные данные из её продукта.

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