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

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

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

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

Часть 5 статьи 18 содержит ссылки на отдельные исключения из общего правила. Их нельзя применять по аналогии или только потому, что обработка кажется общественно полезной. Для исключения требуется конкретное основание из закона и документированная связь с целью обработки.

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

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

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

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

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

Рабочая схема может выглядеть так:

Точка ввода → сервер обработки запроса → база сайта или приложения → CRM → сервис уведомлений → хранилище документов → резервная копия → аналитика и журналы.

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

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

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

Инвентаризация проводится не по отделам, а по фактическим системам. Одна и та же заявка может последовательно оказаться на сайте, в CRM, телефонии, почте, системе задач и архиве. Каждая система имеет собственное местонахождение, получателей и режим доступа.

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

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

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

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

При проверке задают вопросы:

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

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

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

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

У поставщика запрашивают:

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

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

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

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

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

Поэтому вывод оформляют двумя отдельными строками:

1. соблюдены ли требования части 5 статьи 18 при сборе;

2. возникает ли трансграничная передача и выполнен ли порядок статьи 12.

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

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

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

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

Перед запуском контролируют: