Можно ли хранить персональные данные россиян на зарубежном хостинге

Нет, если на этом хостинге происходит первичная запись данных — то есть человек заполнил форму на сайте, и его имя, телефон или email впервые сохраняются именно там. Ч. 5 ст. 18 152-ФЗ требует, чтобы первичный сбор и хранение шли через базу данных на территории России. После этого часть данных можно передавать за рубеж, но уже как отдельную операцию по правилам ст. 12.

Нужна ли копия базы в России, если сайт работает на иностранном хостинге

Нужна не просто копия, а именно первичная база: сервер в РФ должен быть тем местом, куда данные попадают первыми. Схема «сайт физически на зарубежном хостинге, но формы пишут в российскую БД через API» закону не противоречит — важно, где именно происходит первая запись, а не где лежит фронтенд сайта.

Нарушает ли Google Workspace локализацию

Если Google Workspace (или другой зарубежный сервис почты/календаря) — единственное место, куда попадают персональные данные клиентов при первом контакте, формально это нарушение локализации. Если же данные сначала фиксируются в CRM на российском сервере, а в Workspace просто дублируются для удобства сотрудников, это уже вопрос трансграничной передачи, а не локализации — разные нормы и разная тяжесть.

Как проверить, где хранятся данные сайта

Три источника: техническая документация или договор с хостинг-провайдером (там указана юрисдикция дата-центра), настройки CRM/сервисов, куда пишут формы сайта (обычно в разделе «регион хранения данных» или в договоре с поставщиком), и прямой тест — отправить тестовую заявку и проверить в логах, на какой сервер она ушла первой.

Хранение персональных данных за рубежом: серверы, облака и зарубежные сервисы

Компания открывает свою CRM или почтовый сервис и видит: серверы — в Ирландии, Германии или США. Возникает вопрос — а не нарушение ли это? Ответ зависит не от факта «данные лежат за границей», а от того, что именно там лежит: первичная запись или вторичная копия. Разница определяет, грозит ли штраф до 6 000 000 ₽ за нарушение локализации или речь просто о трансграничной передаче с более мягкими требованиями.

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

Два разных вопроса: где данные, и что с ними происходит

Закон разделяет два вопроса, которые на практике часто путают:

Где происходит первичный сбор и хранение — это требование локализации (ч. 5 ст. 18 152-ФЗ). Первая база, в которую попадают данные субъекта — гражданина России, обязана физически находиться на территории РФ.
Можно ли передать данные дальше, за границу — это трансграничная передача (ст. 12 152-ФЗ). После того как данные легли в российскую базу, оператор вправе передавать их часть за рубеж — с уведомлением Роскомнадзора и с учётом характера страны-получателя.

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

Разрешённая схема: «первичка в РФ + зеркало за рубежом»

Рабочая и законная модель для бизнеса, которому по разным причинам нужна зарубежная инфраструктура:

Форма на сайте отправляет данные напрямую в базу на сервере в РФ — это происходит первым, без исключений.
Из российской базы данные (или их часть) реплицируются, экспортируются или синхронизируются в зарубежный сервис — CRM для отдела продаж, аналитическую систему, бэкап-хранилище.
На передачу оформляется отдельная процедура: уведомление в Роскомнадзор о трансграничной передаче, при необходимости — отдельное согласие субъекта, договорные гарантии с зарубежным поставщиком.

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

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

Типичные нарушения на практике

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

Google Workspace и аналогичные сервисы

Компания использует Google Workspace, Microsoft 365 или похожий облачный пакет как основную почту и CRM-подобную систему. Если заявки с сайта или контакты клиентов впервые фиксируются именно там — например, форма обратной связи отправляет письмо прямо на Gmail-адрес сотрудника, — это первичное хранение на зарубежном сервере. Формальное нарушение ч. 5 ст. 18, даже если сама компания на 100% российская и цели совершенно безобидные.

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

Зарубежный хостинг с базой данных на том же сервере

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

Решение не всегда требует полного переезда — иногда достаточно вынести базу данных на отдельный российский сервер, оставив фронтенд сайта там, где он был, и настроить запись форм через API в эту базу.

SaaS-аналитика и трекеры с формами

Виджеты обратного звонка, чат-боты, формы заявок от сторонних SaaS-сервисов — популярный источник скрытого нарушения. Виджет физически подключён к зарубежному провайдеру, и вся переписка с указанием имени и телефона хранится только у него. Проверка похожих сценариев с cookie и трекерами разобрана в статье про Google Analytics и требования 152-ФЗ — логика та же: важно, где физически лежат собранные данные, а не насколько «безобидным» кажется сервис.

Головной офис за рубежом получает выгрузки

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

Облако с «российским регионом» — не всегда решение

Крупные зарубежные облачные провайдеры (AWS, Google Cloud, Microsoft Azure) предлагают выбор региона для размещения инфраструктуры, но у большинства из них физических дата-центров на территории России нет — ближайшие доступные регионы находятся в Европе или на Ближнем Востоке. Выбор «региона поближе к России» не решает вопрос локализации: юридически значимо, что база физически находится на территории РФ, а не просто географически рядом.

Для бизнеса, которому нужна первичная база в России, реалистичные варианты — российские облачные провайдеры (VK Cloud, Yandex Cloud, SberCloud и аналогичные), либо выделенный сервер в российском дата-центре. Зарубежное облако при этом никуда не девается из архитектуры — оно просто становится вторичным звеном: туда реплицируются данные уже после того, как легли в первичную базу, и это регулируется правилами трансграничной передачи, а не локализации.

Отдельно стоит проверить CDN и защиту от DDoS — если такой сервис не просто проксирует трафик, а кеширует персонализированный контент с данными пользователей (например, страницы личного кабинета), нужно убедиться, что кеш не превращается в фактическое хранилище персональных данных на зарубежных нодах.

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

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

Куда физически попадают данные при первом контакте с пользователем — в этот сервис напрямую или в вашу базу, из которой сервис потом получает копию?
Есть ли у сервиса опция хранения данных в российском регионе или локальный аналог — иногда у крупных SaaS есть российское юрлицо или партнёр с локальным хранением именно для таких случаев.
Что произойдёт, если убрать этот сервис из цепочки — останется ли у вас первичная запись данных в России, или без него данные вообще нигде не фиксируются локально?
Прописана ли передача данных в этот сервис как отдельная процедура — уведомление РКН, при необходимости отдельное согласие, договорные гарантии с поставщиком?
Кто в компании отвечает за то, чтобы при добавлении нового сервиса эти вопросы задавались — на практике нарушения чаще всего возникают, когда новый SaaS подключает разработчик или маркетолог без согласования с тем, кто отвечает за обработку персональных данных.

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

Как проверить, где физически хранятся данные вашего сайта

Три практических шага, без специальных инструментов:

Посмотрите договор или тарифный план хостинг-провайдера. Юрисдикция дата-центра обычно указана прямо — «сервер в Нидерландах», «регион EU-West» и так далее. Для CRM и облачных сервисов та же информация — в разделе «расположение данных» или в договоре оферты.
Отправьте тестовую заявку через форму сайта и проверьте в админке или логах, куда именно она пришла первой — в базу на вашем хостинге, во внешнюю CRM, на email стороннего сервиса. Это самый надёжный способ увидеть реальный маршрут данных, а не то, что написано в документации.
Составьте список всех сервисов, куда стекаются формы сайта — CRM, рассыльщик, чат-виджет, платёжный провайдер, аналитика. По каждому определите: это первичная запись или вторичная копия уже собранных данных. Список из двух-трёх пунктов обычно закрывает 90% сайтов малого и среднего бизнеса.

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

Штрафы за нарушение локализации

Нарушение	Штраф для юрлиц
Нарушение требования локализации (ч. 8 ст. 13.11 КоАП)	до 6 000 000 ₽
Повторное нарушение	до 18 000 000 ₽
Дополнительно	суд вправе ограничить доступ к сайту по требованию РКН

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

Переезжать не всегда обязательно

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

Если бизнес уже использует зарубежный SaaS-стек, разумный порядок действий: сначала выяснить, где именно происходит первичная запись (шаги выше), и только затем решать — переносить эту точку в Россию или оформлять текущую схему через уведомление и согласие на трансграничную передачу.