Локализация персональных данных: что хранить в России и как проверить процесс

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

Конюхова Евгения

Юрист по трудовому праву, эксперт по кадрам, член Национального союза кадровиков. Преподаватель курса «Защита персональных данных»

Что означает локализация в рабочем процессе

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

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

Почему домен и интерфейс ничего не доказывают

Домен .ru может обслуживаться зарубежной инфраструктурой, а иностранный продукт — хранить выбранную базу в российском дата-центре. Пользователь видит форму и бренд, но не видит конечную точку API, журнал очереди, CRM, аналитический пиксель и резервную копию. Поэтому визуальный осмотр сайта — только начало инвентаризации.

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

Разведите сбор, запись, хранение и передачу

Сбор — получение данных от субъекта или другого источника. Запись — создание их в информационной системе или базе. Хранение — сохранение в выбранном контуре. Передача — предоставление или доступ другому лицу. Эти события могут происходить почти одновременно, но для проверки их нужно разложить.

Фраза «мы ничего не передаём, сервис сам забирает» не описывает факты. Если браузер отправляет поля напрямую в сторонний endpoint, это отдельная операция. Если зарубежная поддержка входит в российскую базу, это другой сценарий. Если резервная копия уходит в иностранный регион, возникает третий. Один флажок «локализовано» скрывает различия.

Сначала определите контур данных

Составьте перечень точек сбора: формы обратной связи, регистрация, заказ, чат, личный кабинет, анкета кандидата, пропускная система, колл-центр и импортированные списки. Для каждой укажите категории субъектов, поля, цель, обязательность, источник и владельца. Не включайте реальные значения — достаточно названий полей и синтетических примеров.

Отдельно отметьте данные, которые кажутся техническими: IP-адрес, cookie-идентификатор, запись разговора, идентификатор устройства, журнал авторизации. Их квалификация зависит от контекста. Карта должна показать наличие и использование, а юридический вывод делает ответственный специалист.

Как найти точку первой записи

1. Откройте схему формы и определите endpoint отправки.
2. Проверьте серверный обработчик: сохраняет ли он запись до вызова внешнего API.
3. Посмотрите очередь и временные журналы: содержат ли они поля формы.
4. Сопоставьте время создания записи в российской базе и сторонней системе.
5. Зафиксируйте доказательства: конфигурацию, журнал теста и владельца.

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

Веб-форма: типовая скрытая развилка

Вариант A: браузер отправляет данные на российский сервер, тот создаёт запись, после чего разрешённая интеграция передаёт необходимый набор дальше. Вариант B: скрипт формы отправляет данные непосредственно зарубежному сервису, а российская CRM получает копию позже. Внешне формы одинаковы, но последовательность различается.

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

CRM, helpdesk и облачные формы

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

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

Аналитика и рекламные инструменты

Не все события аналитики содержат очевидные ФИО. Однако команда может передавать e-mail, телефон, внутренний идентификатор, параметры заказа или свободный текст. Проверьте код формирования события, а не только название поля в панели. Удаление одного видимого параметра не гарантирует, что данные не попали в URL, журнал ошибки или пользовательское свойство.

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

Резервные копии, журналы и аварийный контур

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

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

Что спросить у подрядчика

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

Ответ «соответствует 152-ФЗ» не закрывает ни один пункт. Просите факты и документы. Одновременно не требуйте раскрытия лишней информации об инфраструктуре публично: доказательства хранятся в контролируемом контуре.

Реестр восьми потоков

Как читать заполненный пример

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

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

Какие доказательства считать достаточными

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

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

Как встроить локализацию в изменения

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

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

Связь с трансграничной передачей

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

Отдельный материал о трансграничной передаче разбирает страны, получателей и уведомление. В этой статье мы останавливаемся раньше: доказываем, где и в какой последовательности создаётся и хранится запись.

Типичные ошибки проверки

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

Когда карта готова к рецензированию

Все точки сбора перечислены; поля и субъекты определены; endpoint и первая запись доказаны; основные, резервные и диагностические базы учтены; подрядчики и доступы названы; зарубежные операции отделены; для пробелов назначены действия. Синтетический тест воспроизводится другим специалистом.

Карта не должна содержать реальные персональные данные, токены и секреты. Она описывает метаданные процесса и ссылки на защищённые доказательства. Юридический вывод оформляется отдельно уполномоченным специалистом после проверки фактов.

Как перенести действующий сервис без потери контроля

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

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

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

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

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

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

От одного маршрута к системе защиты данных

Курс «Защита персональных данных: минимизируем риски» помогает связать процессы, документы, роли и меры контроля. Преподаватель — Конюхова Евгения. Статья даёт законченный реестр локализации, но не охватывает весь комплект требований и информационную безопасность.

Начните с самой важной формы и одного синтетического события. Доведите маршрут до доказанной первой записи и только затем расширяйте карту. Не пытайтесь закрыть пробел словом «облако»: у каждой операции должен быть конкретный владелец и источник.

Локализация становится проверяемой, когда компания может показать не страну бренда, а последовательность операций от сбора до первой записи, дальнейших баз, резервов и доступов по каждому потоку.

Практика вместо теории

От одного маршрута данных — к управляемому контуру защиты

Курс «Защита персональных данных: минимизируем риски» помогает связать процессы, документы и меры контроля. Преподаватель — Конюхова Евгения; по итогам обучения выдаётся Удостоверение о повышении квалификации.

Смотреть программу

Вопросы и ответы

• Российский домен означает, что данные локализованы?

  Нет. Домен не показывает endpoint формы, первую базу, журналы, резервные копии и доступы. Нужна фактическая схема и доказательства.

• Достаточно хранить копию базы в России?

  Не всегда. Существенна последовательность операций при сборе. Если первая запись создаётся за рубежом, последующая российская копия сама по себе не отвечает на вопрос.

• Можно ли использовать зарубежную CRM?

  Ответ зависит от архитектуры, ролей, операций, оснований и применимых требований. Статья не даёт универсального разрешения или запрета.

• Нужно ли включать логи и резервные копии?

  Да, если они содержат персональные данные или позволяют их обрабатывать. Их регион, состав, доступ и срок следует проверить отдельно.

• Как тестировать маршрут безопасно?

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

По теме