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

# Локализация персональных данных: где фактически сохраняются заявки с сайта

Редакция SGI24. Техническая методика основана на проверке реальных сетевых маршрутов; юридическую квалификацию нужно делать по фактам конкретной системы. [О бюро](/company).

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

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

Проверить локализацию и маршрут данных

Что требует локализация

Часть 5 статьи 18 № 152-ФЗ устанавливает, что при сборе персональных данных граждан РФ, в том числе через интернет, запись, систематизация, накопление, хранение, уточнение и извлечение с использованием баз за пределами России не допускаются, кроме прямо названных законом случаев.

Практически оператору нужно установить:

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

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

Локализация и трансграничная передача — не одно и то же

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

Эти требования проверяются последовательно:

1. Первичная запись организована в России.
2. Дальнейшая передача имеет цель и основание.
3. До начала трансграничной передачи направлено отдельное уведомление Роскомнадзору.
4. Получены предусмотренные статьёй 12 сведения об иностранном получателе.
5. Учтены страна, решение Роскомнадзора и применимые ограничения.
6. Маршрут отражён во внутренних документах и сведениях оператора.

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

Как выглядит маршрут обычной формы

На схеме маркетинга всё кажется коротким:

text посетитель → форма → менеджер

Технический маршрут может быть длиннее:

text браузер → сервер сайта → база заявок → CRM → почта → телефония ↘ журнал ошибок ↘ аналитика ↘ резервная копия ↘ подрядчик

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

Правильная проверка строится от поля формы до последней рабочей копии.

Шаг 1. Найдите все точки сбора

Составьте перечень страниц и функций:

• обратный звонок;
• консультация;
• заказ;
• онлайн-запись;
• регистрация на мероприятие;
• приёмная комиссия;
• личный кабинет;
• чат;
• подписка;
• отзыв;
• резюме;
• загрузка документов;
• оплата.

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

Шаг 2. Зафиксируйте состав данных

Запишите видимые и технические поля. Помимо имени, телефона и почты в запрос могут попадать:

• текст обращения;
• выбранная услуга;
• дата и время записи;
• сведения о ребёнке или пациенте;
• загруженный файл;
• адрес страницы;
• рекламная метка;
• идентификатор сессии;
• сетевой адрес;
• сведения об устройстве;
• идентификатор пользователя.

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

Шаг 3. Определите первую запись

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

Проверьте:

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

Если сервис обещает «хранить в России», уточните, относится ли это к основной базе, вложениям, резервным копиям, служебным журналам и поддержке. У разных компонентов одной платформы могут быть разные условия.

Шаг 4. Пройдите все интеграции

После первичной записи данные часто передаются дальше. Карточка CRM может создавать задачу, письмо, запись звонка, счёт и событие аналитики.

Для каждой интеграции укажите:

Таблица быстро показывает «серые зоны», о которых не знают ни юрист, ни владелец сайта.

Шаг 5. Проверьте почту и мессенджеры

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

Пересылка в рабочий чат создаёт ещё одну ветку. Если сотрудник копирует заявку в личный аккаунт, организация теряет управление доступом и удалением.

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

Шаг 6. Не забудьте о журналах ошибок

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

Проверьте:

• маскирование полей;
• запрет записи паролей и токенов;
• срок хранения журналов;
• доступ разработчиков;
• регион сервиса;
• экспорт в поддержку;
• удаление при обращении субъекта.

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

Шаг 7. Разберите резервные копии

Основная база может находиться в России, а резервная копия — в другом регионе или аккаунте подрядчика. Или оператор удаляет заявку из CRM, но она остаётся в ежедневных снимках без понятного срока.

Установите:

• где создаются копии;
• кто управляет ключами и доступом;
• как долго хранятся снимки;
• можно ли восстановить отдельную запись;
• как учитывается запрос на уничтожение;
• что происходит после расторжения договора с сервисом.

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

Иностранный виджет: четыре возможных маршрута

Один и тот же внешне видимый чат может работать по-разному:

1. Браузер сразу соединяется с иностранным поставщиком и передаёт данные.
2. Виджет обращается к российскому серверу поставщика, но поддержка получает доступ из-за рубежа.
3. Сайт сначала пишет в российскую базу, затем синхронизирует данные с иностранной системой.
4. На странице загружается интерфейс, но персональные данные в него не передаются до отдельного действия.

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

Что сверить с документами

Техническая карта сопоставляется с:

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

Статья 22 № 152-ФЗ требует указывать в уведомлении наличие или отсутствие трансграничной передачи. Статья 12 предусматривает отдельное уведомление до начала такой деятельности. Если новый сервис изменил маршрут, документы и сведения оператора нужно пересмотреть.

Частые ошибки

«Сайт находится в России, значит всё выполнено»

Хостинг страницы не показывает место CRM, почты, аналитики, журналов и копий.

«Иностранный сервис используется только для аналитики»

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

«Мы не сохраняем заявки, они приходят на почту»

Почтовый ящик тоже хранит сведения и создаёт копии.

«После записи в России можно отправлять куда угодно»

Первичная локализация и дальнейшая трансграничная передача регулируются отдельно.

«Подрядчик сам отвечает за всё»

Оператор должен определить условия поручения и контролировать процесс в своей сфере ответственности. Передача технической работы не стирает обязанности оператора.

«Удалили форму — проблема закрыта»

Старые записи, почта, журналы и резервные копии продолжают существовать. Нужно завершить обработку по всему маршруту.

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

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

После этого можно принимать предметные решения:

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

Это работа на стыке сайта, договоров и ежедневных действий сотрудников. Одна правка политики не меняет маршрут пакетов и копий.

На выходе нужна карта потоков

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

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

Получить карту потоков и план исправления локализации

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

Для полной проверки сайта используйте также материал «Проверка сайта по 152-ФЗ». Подготовка сведений для реестра разобрана в статье «Уведомление Роскомнадзора».

Официальные источники

• Статья 18 № 152-ФЗ: обязанности при сборе и локализация
• Статья 12 № 152-ФЗ: трансграничная передача персональных данных
• Статья 22 № 152-ФЗ: уведомление об обработке персональных данных
• Действующая редакция Федерального закона № 152-ФЗ

Материал носит информационный характер. Выводы о конкретном сервисе принимаются после проверки его договора, инфраструктуры и фактической конфигурации.