ПДн и локализация: РКН провёл тысячу проверок, а компании всё ещё путают хранение с обработкой

РКН к середине 2018 года провёл уже больше тысячи проверок по теме локализации персональных данных российских граждан. Цифра стала звучать на конференциях, и где-то в этот момент клиент, который год назад отмахивался от темы со словами «ну нас же не проверят», позвонил с вопросом: что делать с CRM на европейском SaaS.

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

Откуда путаница

152-ФЗ в части локализации (статья 18.1) говорит, что при сборе персональных данных российских граждан их запись, систематизация, накопление, хранение, уточнение и извлечение должны осуществляться с использованием баз данных на территории России. Ключевые слова здесь - не только «хранение», но и целый список операций: систематизация, накопление, уточнение, извлечение.

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

Вопрос, который многие упускают: где обрабатываются данные?

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

Некоторые SaaS-провайдеры предлагают «хранение в России» через партнёра, но при этом вся логика приложения, включая поиск и агрегацию по данным, остаётся на их стороне в ЕС. Формально база в Москве, фактически обработка - в Амстердаме.

Как выглядел проект у клиента

Клиент - торговая компания, CRM использовалась для ведения базы контактов, сделок и переписки с клиентами. Данные: имена, телефоны, email, история взаимодействий. Классика.

Мы начали с инвентаризации потоков данных, а не с разговора «куда переезжаем»:

• Откуда данные поступают в CRM. Форма на сайте, интеграция с почтой, ручной ввод менеджеров, выгрузки из 1С. Каждый из этих каналов нужно было отследить: где происходит первичная запись?
• Где данные обрабатываются внутри CRM. Какие операции выполняются на стороне SaaS-провайдера, а какие могут быть вынесены наружу.
• Какие интеграции есть у CRM. Оказалось три внешних сервиса: email-рассылки, телефония и аналитика. Все три - тоже европейские, и все три получали ПДн.
• Что хранится в резервных копиях и где они. Бэкапы делал провайдер, хранил у себя в ЕС.

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

Что выбрали

Мы рассмотрели три пути:

Российский on-premise. Разворачиваем CRM на серверах клиента или в российском ЦОД. Полный контроль, но нагрузка на ИТ-команду: обновления, доступность, резервирование - всё самостоятельно. Для компании без зрелой ИТ-службы это избыточно.

Российский SaaS-аналог. На рынке есть несколько отечественных CRM. Функциональность у части из них уступает привычному продукту, и миграция данных - отдельная история с потерями и ручной доводкой.

Российский IaaS + привычная CRM self-hosted. Арендуем VM в российском облаке, разворачиваем open-source или лицензионную CRM, которую клиент знает. Обработка данных происходит внутри этой инфраструктуры. Интеграции пересматриваются - для email-рассылок и телефонии выбирается российский провайдер.

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

Практические наблюдения

Проект подтвердил несколько вещей, которые мы стали проверять в каждом подобном случае:

• Интеграции - самая частая зона риска. Сама CRM переехала, а сервис рассылок всё ещё европейский и получает список адресов через API. Формально данные «обрабатываются» в Европе.
• SaaS-провайдеры с «хранением в России» нужно смотреть внимательно. Конкретно: где выполняется поиск по базе, где строятся отчёты, куда уходят API-запросы клиентского приложения.
• Документация на переезд нужна сразу. Если приходит проверка, нужно показать не только где хранится, но и описать все места обработки. Это уже не просто технический вопрос.

Тема локализации при таком количестве проверок перестаёт быть абстрактной. Если у вас SaaS с европейским происхождением и российская клиентская база - стоит пройтись по потокам данных и честно ответить на вопрос: где именно происходит обработка?

Помогаем разобраться в рамках аудита информационной безопасности.