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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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