Можно ли хранить персональные данные в Google Таблицах и облаке

Клиентская база в Google Таблице удобна: заходишь с любого устройства, видишь историю правок, ничего не надо администрировать. Но сама таблица физически лежит на серверах Google за пределами России. И как только в ней появляются фамилии, телефоны и email клиентов, вопрос «можно ли хранить персональные данные в Google Таблицах» из технического превращается в правовой. Ниже разберём, что именно требует закон о локализации, чем база в облаке отличается от подгрузки шрифта и как перенести данные, чтобы снять риск.

Почему персональные данные в Google Таблицах попадают под закон

Как только вы записываете в таблицу имя, телефон или email конкретного человека, вы обрабатываете персональные данные и становитесь оператором по 152-ФЗ. Обработка это не только сбор: сюда входят запись, систематизация, хранение, обновление. Именно этим Google Sheets и Google Drive и занимаются с вашей базой.

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

Здесь важно не спутать две разные ситуации, которые внешне выглядят одинаково («используется зарубежный сервис Google»), а по закону противоположны.

Первая ситуация: на сайте подключены Google Fonts, Google-карта или другой внешний ресурс. При загрузке страницы он получает от браузера посетителя технические данные, например IP-адрес, чтобы отдать файл шрифта. За границу уходят технические сведения о запросе, а заполненных человеком контактов среди них нет. Сам по себе такой обмен состава локализации не образует.

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

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

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

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

Это требование появилось не вчера. Его ввёл 242-ФЗ, и оно действует с 1 сентября 2015 года. За прошедшие годы норма правилась, последние изменения затронули её в 2025 году, но суть осталась прежней: первичная обработка данных граждан РФ привязана к серверам внутри страны.

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

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

Для микро-бизнеса вывод простой: если база клиентов живёт только в Google Таблице или Google Drive, первичного хранения в России нет вообще, и вопрос локализации встаёт в полный рост.

Какие данные критичны, а какие нет

Не всякая таблица в облаке создаёт проблему. Всё решает содержимое.

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

Обезличенные или чисто технические записи, из которых нельзя понять, о ком речь, состава не образуют. Сюда относятся, например, сводная таблица «выручка по дням», справочник товаров, обезличенная статистика без привязки к личности.

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

Посмотрим на примере. Небольшая студия ведёт в Google Таблице лист «Клиенты» с колонками «Имя», «Телефон», «Услуга», «Дата». Это персональные данные граждан, лежащие в первичной базе за рубежом, ровно тот случай, который норма и ограничивает. А соседний лист «Загрузка по неделям» с числами заказов без имён под правило не подпадает: по нему конкретного человека не вычислить. Один файл, а статуса два, потому что закон смотрит на содержание, а не на название документа.

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

Размер штрафа за нарушение локализации

За невыполнение обязанности хранить данные россиян в базах на территории России предусмотрен отдельный состав в КоАП, часть 8 статьи 13.11. Это самостоятельное нарушение, не то же самое, что отсутствие политики конфиденциальности или сбор данных без основания.

Вилка по типам лиц выглядит так.

За повторное нарушение по части 9 той же статьи суммы выше: для юрлиц от 6 000 000 до 18 000 000 ₽.

Несколько оговорок, чтобы читать таблицу правильно.

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

Штраф считается один раз на оператора за сам факт нарушения локализации и не умножается на число зарубежных сервисов. Если база лежит и в Google Sheets, и в стороннем облаке, состав всё равно один.

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

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

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

Самопроверку удобно вести по слоям, от очевидного к скрытому.

1. Пройдите по рабочим инструментам. Где фактически лежит база клиентов: Google Sheets, Google Drive, Notion, Airtable, зарубежная CRM, почтовый ящик с перепиской? Всё, что размещено на иностранных серверах и содержит контакты клиентов, это кандидат на перенос.

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

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

1. Отделите технику от содержания. Подключённый на сайте зарубежный шрифт, карта или CDN получают только IP посетителя и к истории с базой клиентов отношения не имеют. Силы стоит тратить на реальные хранилища контактов, а техническую подгрузку без содержания можно спокойно пропустить.

Обойти все страницы и интеграции руками трудно, а проблему обычно создают как раз скрытые сервисы-приёмники данных. Увидеть их разом проще автоматически. На странице проверки сайта по правилу локализации 242-ФЗ сканер находит внешние сервисы, в которые уходят данные с сайта, и показывает, где заявки утекают в зарубежную инфраструктуру. Аудит всех ваших внутренних таблиц он не заменит, но подскажет, с какого сервиса начинать разбор.

Как перенести базу и снять риск

Задача в том, чтобы выстроить приоритет: первичная база в России, зарубежные сервисы вторичны и подключены по правилам. Полностью отказываться от Google для этого не нужно.

Определите первичное хранилище на территории России. Подойдёт российская CRM, база на российском хостинге или таблица на сервере в РФ. Главное, чтобы именно сюда данные попадали первыми и именно здесь жили постоянно.

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

Разберитесь с существующей таблицей. Данные, уже лежащие в Google Sheets, перенесите в российскую базу, а зарубежную копию либо уберите, либо оставьте только как вторичную и при соблюдении режима трансграничной передачи по статье 12, а не по умолчанию.

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

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

Частые вопросы

Можно ли вообще пользоваться Google Таблицами в работе? Да, для данных, которые не являются персональными: расчёты, справочники, обезличенная статистика. Ограничение касается первичной базы с контактами клиентов, а не таблиц как инструмента.

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

Подключённый на сайте Google-шрифт это тоже нарушение локализации? Обычно нет. Шрифт или карта получают технические данные вроде IP-адреса, заполненных клиентом контактов среди них нет. Состав возникает там, где за границу уходят сами персональные данные из базы. Техническая подгрузка его не образует.

Штрафуют ли самозанятых так же, как компании? Нет. Для самозанятого действует вилка для физлиц по части 8 статьи 13.11, миллионные суммы для юрлиц к нему не применяются. По статусу самозанятый не приравнивается ни к ИП, ни к компании.

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

Коротко

База клиентов в Google Таблицах или зарубежном облаке означает, что первичное хранение персональных данных граждан России идёт за пределами страны, а это прямо пересекается с правилом локализации из части 5 статьи 18 152-ФЗ, действующим с 2015 года. В отличие от подгрузки шрифта, где уходят только технические данные, здесь за границу передаются реальные контакты, поэтому состав возникает: за невыполнение локализации по части 8 статьи 13.11 КоАП предусмотрен штраф от 30 до 50 тысяч рублей для физлиц и самозанятых и от 1 до 6 миллионов для юрлиц, за повтор больше. Снять риск можно, если сделать первичным хранилищем российскую базу, а зарубежные сервисы оставить лишь вторичными и по правилам трансграничной передачи. Начать проще всего с ревизии, куда именно уходят заявки с сайта и какие внешние сервисы собирают данные клиентов.