Ваши заказы лежат в зарубежной таблице или CRM? Это риск нарушения ФЗ-152: часть 5 статьи 18 требует первично записывать и хранить данные граждан России в базах на территории России. Держите базу в российском облаке, на своём сервере или в колокейшн, а зарубежные формы, CRM и таблицы замените российскими.
Какие данные покупателей вы обрабатываете и что требует локализация
Вы открыли интернет-магазин, и в первый же день форма заказа собрала имя, телефон и адрес. С этого момента вы оператор персональных данных. Статус не зависит от оборота: он возникает, когда вы сами или через подрядчика собираете, записываете и храните сведения о живых людях. Закон описывает это в ФЗ-152 «О персональных данных», где оператор прямо назван лицом, которое определяет цели и состав обработки.
В магазине таких данных больше, чем вы ожидаете. Разложим по группам, чтобы увидеть, что именно лежит в вашей базе.
- ФИО, телефон, email — контактные данные из формы заказа и личного кабинета.
- Адрес доставки, индекс, иногда этаж и код домофона.
- История заказов, состав корзин, возвраты и обращения в поддержку.
- Баланс бонусов и номер карты лояльности.
- Cookie, идентификаторы устройства и IP-адрес из аналитики и рекламных пикселей.
- Переписка в чатах, голос в записях звонков.
Отдельно про cookie. Если по ним можно найти конкретного человека, например по аккаунту или телефону, это персональные данные. Счётчик, который считает обезличенные визиты, к ним не относится, а рекламный пиксель, связывающий визит с аккаунтом, проверяйте отдельно.
Платёжные данные карты магазин обычно не видит: их принимает банк или эквайринг. Это снимает с вас часть риска, но не всю. Номер заказа, сумма и email покупателя остаются у вас, и они тоже персональные.
Теперь о главном требовании. Часть 5 статьи 18 закона обязывает записывать, систематизировать, накапливать, хранить, уточнять и извлекать персональные данные граждан России в базах на территории России. Это требование называют локализацией. Оно касается первичной записи, а не только архива: если форма сначала пишет заявку в зарубежную базу, а потом копирует в российскую, нарушение уже произошло.
Закон не запрещает иметь зарубежную копию в отдельных случаях. Но российская база должна быть первой и главной, а передача за рубеж идёт по правилам трансграничной передачи. Подробности этих правил разберём в четвёртом разделе.
Как проверить свою базу на практике? Возьмите список всех мест, где появляется покупатель, и пройдите по каждому пять вопросов.
- Где физически находится сервер, на который попадает запись при отправке формы?
- Кто владелец сервиса и в какой юрисдикции он зарегистрирован?
- Есть ли у сервиса копия данных в другой стране и кто её видит?
- Что сказано в договоре и в политике сервиса о месте хранения?
- Куда уходят уведомления: на почту и в мессенджеры, у которых свои серверы?
Ответ на первый вопрос проще проверить технически. Узнайте домен сервиса, найдите его IP через команду nslookup и сверьте страну владельца адреса в открытых базах. Метод не идеален, потому что трафик может идти через прокси или CDN. Поэтому он дополняет письменный ответ поддержки, а не заменяет его.
Полезный приём: запросите у каждого сервиса письмо с указанием дата-центров. Ответ «хранится в России» без названия площадки считайте слабым. Сильный ответ называет оператора ЦОД или российское облако и фиксируется в договоре.
Итог раздела короткий: составьте таблицу из всех систем, где лежат данные покупателей, и против каждой впишите страну хранения. Эта таблица станет основой для всего остального: выбора хостинга, уведомления Роскомнадзора и аудита автоматизации. Если нужен разбор процессов целиком, загляните в материал про аудит автоматизации бизнес-процессов.
Где хранить данные: российское облако, свой сервер или колокейшн
Представьте, что у вас склад, и вы решаете, где держать товар: арендовать место, купить помещение или поставить свои стеллажи в чужом здании. С базой покупателей та же логика. Есть три рабочих варианта, и у каждого своя доля ответственности.
Российское облако или хостинг. Вы арендуете виртуальный сервер или управляемую базу у провайдера с дата-центрами в России. Физическую безопасность, питание и сеть держит провайдер. Настройки доступов, шифрование и резервные копии остаются за вами, если вы не взяли управляемую базу.
Свой сервер. Железо стоит у вас в офисе или в подсобке. Вы контролируете всё, но платите за это временем и отказоустойчивостью. Для магазина с одним администратором такой вариант часто хуже облака: отключился свет, и заказы встали.
Колокейшн. Вы покупаете собственный сервер и размещаете его в стойке чужого дата-центра в России. Питание, охлаждение и канал даёт площадка, всё остальное на вашей стороне. Это золотая середина для тех, кому нужен контроль над железом, но не нужен свой серверный зал.
Сравним три варианта по рискам. Таблица ниже показывает, кто отвечает за каждый слой и где чаще всего случаются ошибки.
| Вариант | Что на вашей стороне | Главный риск | Кому подходит |
|---|---|---|---|
| Российское облако или VPS | Доступы, обновления, резервные копии | Забытые настройки и открытые порты | Большинству небольших магазинов |
| Собственный сервер | Всё: железо, сеть, питание, защита | Простой при сбое и нехватка специалиста | Тем, у кого есть штатный администратор |
| Колокейшн | Железо, ОС, базы, копии | Затраты на покупку и обслуживание сервера | Магазинам с высокой нагрузкой и жёсткими требованиями |
Вывод для большинства: начинайте с российского облака. Колокейшн рассматривайте, когда нагрузка или требования клиентов делают аренду тесной.
Как выбирать провайдера? Смотрите на три вещи. Первая — адреса дата-центров в договоре, а не в рекламе.
Вторая — провайдер должен быть российским юрлицом, чтобы вы могли заключить договор и получить документы для проверки. Третья — возможность настроить шифрование и копии в той же юрисдикции.
Обратите внимание на «российское облако с зарубежными корнями». Провайдер может быть зарегистрирован в России, но часть сервисов, например резервные копии или мониторинг, живёт на мощностях за границей. Спросите об этом прямо и зафиксируйте ответ письменно.
Отдельно о стоимости. Цены зависят от нагрузки, региона и тарифа, поэтому конкретных сумм здесь нет. Считайте так: сложите аренду сервера, копии, мониторинг и час работы администратора в месяц.
Для магазина, который хранит заказы и контакты без видео и больших файлов, обычно хватает самой малой конфигурации. По нашей экспертной оценке, рост расходов чаще идёт от поддержки и специалистов, а не от самого сервера.
Уровень защиты по закону тоже зависит от категории данных. Для обычных персональных данных покупателей (не специальных и не биометрических) требования мягче, чем для медицинских записей или банковских систем. Но уровень защищённости всё равно определяется в модели угроз и закрепляется приказами и техническими мерами, поэтому провайдера выбирайте с запасом.
На практике маленький магазин почти всегда выигрывает от схемы: российский VPS, на нём база и n8n для автоматизации, ежедневные копии на второй российской площадке. Подробнее про такие платформы читайте в обзоре аналогов n8n.
Куда уходят данные из Tilda, CRM, бонусной системы и Telegram
Владелец магазина на Tilda не думает о ФЗ-152, когда подключает очередную интеграцию. Он хочет, чтобы заявка с сайта пришла менеджеру. Но каждая такая «труба» может унести данные за границу, поэтому сначала нарисуйте карту потоков, а уже потом выбирайте инструменты.
Пройдём по типичной цепочке магазина на Tilda. Покупатель оставляет заявку, она попадает в разные места.
Форма Tilda. Заявка сохраняется внутри сервиса и отправляется дальше по интеграциям: на почту, в CRM, в Telegram, в таблицу. Данные в самой Tilda хранит сервис, поэтому уточните у поддержки и в документах, на каких серверах лежит база заявок. Проверяйте не слова с сайта, а ответ в письме.
Почтовый ящик. Если заявка приходит на ящик в зарубежной почте, копия данных живёт там. Для письма с ФИО и телефоном это уже трансграничная передача. Ящик на российском сервисе или на своём домене с российским хостингом такой проблемы не создаёт.
CRM. Здесь хранится главная база покупателей. Если CRM зарубежная, первичная запись идёт не туда, куда требует закон. Российская CRM с серверами в России закрывает вопрос, но не снимает обязанность проверить договор.
Бонусная система. Номера карт, баллы и история начислений связаны с телефоном. Многие магазины держат их в облачной таблице или в приложении лояльности, о хостинге которого не знают. Вносите это в карту потоков наравне с CRM.
Telegram-поддержка. Бот или группа получают текст заявки целиком. Переписка хранится на серверах мессенджера, и расположение этих серверов вы не контролируете и не можете подтвердить договором. Если в сообщения попадают ФИО, телефон и адрес, считайте канал рискованным.
Всю цепочку полезно свести в таблицу. Так сразу видно, где риск и что с ним делать.
| Узел | Что туда попадает | Риск | Что сделать |
|---|---|---|---|
| Форма Tilda | ФИО, телефон, согласие | Место хранения заявок не подтверждено | Запросить у поддержки письменный ответ |
| Почта | Полный текст заявки | Зарубежный сервер ящика | Перенести на российский сервис |
| CRM и бонусы | Профиль и история заказов | Первичная запись за рубежом | Переехать в российскую CRM |
| Telegram | Контакты и текст обращения | Серверы мессенджера вне вашего контроля | Слать только номер заказа |
Вывод: по нашей экспертной оценке, самая частая дыра в магазине — не CRM, а уведомления. Они копируют данные в удобные, но неподконтрольные каналы.
Как переделать такую цепочку? Рабочая схема выглядит так. Форма отправляет заявку на вебхук n8n, развёрнутого на российском сервере.
Там данные проверяются, записываются в российскую CRM и в базу бонусов, а в Telegram уходит короткое уведомление: «Новый заказ №1234» без контактов. Менеджер открывает карточку в CRM и видит всё остальное.
Такая схема сохраняет скорость реакции и убирает контакты покупателя из мессенджера. Менеджер получает номер заказа, а не набор сведений. Номер заказа тоже связан с человеком, поэтому уведомление не заменяет защиту CRM, а только сокращает число мест, где лежат контакты.
Проверьте и обратный поток. Когда бот поддержки получает сообщения от покупателей, вы не управляете тем, что они напишут. Поэтому в приветствии бота дайте ссылку на политику обработки и просите не присылать паспортные данные. Историю чата переносите в CRM и храните там, а не в мессенджере.
Если вы строите такую автоматизацию с нуля, пригодится материал про альтернативу Zapier на n8n. Затем повторите проверку по пяти вопросам из первого раздела для каждого нового узла, который добавили в схему.
Зарубежные сервисы и трансграничная передача: что можно и чем заменить
Что будет, если вы продолжите вести заказы в зарубежной CRM и Google Таблицах? Первичная запись данных граждан России окажется в иностранной базе, а это риск нарушения локализации. Штраф зависит от повторности, и размеры смотрите в последнем разделе.
Начнём с терминов. Трансграничная передача — это передача персональных данных на территорию иностранного государства, иностранному лицу или организации. Она не равна локализации. Локализация говорит, где должна быть первая запись.
Трансграничная передача описывает, что вы дальше делаете с данными, когда они уже лежат в России. Поэтому обе нормы работают вместе, а не заменяют друг друга.
Закон разрешает передачу за рубеж при соблюдении условий. По статье 12 ФЗ-152 оператор до начала передачи обязан уведомить Роскомнадзор и оценить, насколько получатель защищает данные. Точную редакцию статьи смотрите в тексте ФЗ-152.
Оценку проводите до подачи уведомления. Вы проверяете, какие меры принимает получатель, какие правовые нормы действуют в его стране и есть ли риск раскрытия данных. Результат оформляйте документом, который вы храните у себя и показываете по запросу.
Передача в страны, присоединившиеся к Конвенции Совета Европы о защите данных, и в страны из перечня Роскомнадзора идёт с меньшими ограничениями. Для остальных направлений Роскомнадзор вправе запретить или ограничить передачу. Точные условия сверяйте с текстом статьи 12 и перечнем на сайте ведомства.
Главная мысль: трансграничная передача не заменяет локализацию. Даже оформив уведомление, вы не можете сделать зарубежную базу первичной для граждан России. Поэтому надёжнее убрать лишние иностранные сервисы из цепочки, чем оформлять документы на каждый.
Посмотрим, что чаще всего создаёт риск. Таблица ниже сопоставляет популярные зарубежные сервисы с российскими заменами.
| Зарубежный сервис | Риск | Российская замена |
|---|---|---|
| Google Таблицы, Airtable, Notion | Заказы и контакты лежат на иностранных серверах | Яндекс 360, МойОфис, база PostgreSQL |
| HubSpot, Salesforce, Pipedrive | Первичная запись клиента за рубежом | Битрикс24, amoCRM, RetailCRM |
| Mailchimp и аналоги | Список подписчиков хранится вне России | UniSender, Sendsay |
| Google Analytics | Идентификаторы пользователей уходят за границу | Яндекс Метрика |
| Zapier, Make | Данные заявок идут через иностранный сервер | n8n на российском сервере |
Вывод: для каждого зарубежного сервиса есть российский аналог. Сроки переезда зависят от объёма базы и числа интеграций, поэтому оцените их по своей карте потоков.
Не всё нужно переносить в один день. Начните с того, где лежат контакты: CRM, рассылки, таблицы заказов. Аналитику и рекламные пиксели обработайте во вторую очередь, потому что их риск связан с cookie и идентификаторами, а не с базой клиентов.
Рекламные кабинеты и зарубежные соцсети заслуживают отдельного внимания. Если вы выгружаете туда списки покупателей для таргетинга, это передача персональных данных. Для таких выгрузок нужны законные основания и согласие людей. В идеале хешируйте данные на своей стороне и не выгружайте там, где можно обойтись без этого.
No-code платформы и интеграторы тоже входят в список. Если сценарий автоматизации крутится в зарубежном облаке, всё, что через него проходит, уходит за границу. Self-hosted n8n на российском сервере решает вопрос: данные идут с вашего сайта на ваш сервер и дальше в российские сервисы. Выбор инструментов можно сверить с материалом о российских и зарубежных аналогах n8n.
Продавцы уходят с маркетплейсов в собственные магазины. Свой магазин означает свою базу покупателей, а значит, и свою ответственность за её хранение. Как совмещать каналы, описано в статье про омниканальную торговлю.
Согласие, сроки хранения и удаление данных покупателей
Покупатель оформляет заказ, а чекбокс «Согласен с условиями» уже стоит галочкой. Выглядит удобно, но для согласия на обработку персональных данных такая форма рискованна. Оформляйте согласие отдельно от пользовательского соглашения. Действующие требования к форме и содержанию сверьте с текстом ФЗ-152.
Что это значит для формы на сайте? Нужен отдельный чекбокс, который покупатель ставит сам. Рядом ссылка на текст согласия, где указаны цели, перечень данных, срок и порядок отзыва. Предзаполненную галочку не используйте: она не доказывает, что человек согласился осознанно.
Согласие на рассылки отделяют от согласия на обработку заказа. Реклама по email и SMS требует предварительного согласия абонента по закону «О рекламе». Поставьте второй чекбокс без галочки по умолчанию и не связывайте его с оформлением заказа.
Также нужна опубликованная политика обработки персональных данных. По статье 18.1 она должна быть доступна на каждой странице, где вы собираете данные: ссылка в подвале и рядом с формой. В тексте опишите, какие данные собираете, зачем, на какой срок и куда обращаться покупателю.
Сроки хранения закон формулирует так: данные хранятся не дольше, чем этого требуют цели обработки. Конкретного числа для магазина нет. Вы выбираете срок сами, исходя из целей.
Для исполнения заказа это время до получения товара и закрытия гарантий. Для налоговой и бухгалтерской отчётности документы по заказам хранят дольше, но уже на другом основании.
На практике разделите данные на слои. В активной базе держите контакты тех, кто покупал недавно или подписан на рассылку. Бухгалтерские документы храните отдельно, по срокам из налогового и бухгалтерского законодательства. Персональные данные из неактивных профилей удаляйте или обезличивайте.
Обезличивание означает, что по данным нельзя определить человека без дополнительных сведений. Замените ФИО и телефон на идентификатор, оставьте сумму и дату для статистики. Так вы сохраняете аналитику продаж и не держите лишние персональные данные.
Как отвечать на запросы? Покупатель вправе узнать, какие данные о нём у вас есть, потребовать уточнить или удалить. Срок ответа на обращение устанавливает статья 14 закона, поэтому сверьте его с действующей редакцией. Заведите отдельный почтовый ящик для таких запросов и шаблон ответа.
Отзыв согласия запускает короткий таймер. По статье 21 оператор прекращает обработку и уничтожает данные в установленный срок, если нет другого законного основания их хранить. Если основание есть, например бухгалтерский документ, сообщите об этом покупателю.
Удалять данные надо во всех местах сразу. Покупатель просит стереть профиль, а его телефон остаётся в рассылке, в таблице курьера и в бэкапе. Поэтому карта потоков из третьего раздела нужна и здесь: по ней вы находите все копии. Сценарий в n8n получает запрос, удаляет запись в CRM, рассылке и бонусной базе, а затем пишет в журнал.
Защита данных, подрядчики и штрафы за нарушения
У магазина утекла таблица заказов, потому что администратор вышел из компании, а доступ остался. Такие случаи встречаются чаще, чем взломы. Закон требует от оператора правовых, организационных и технических мер защиты, а подробности сводятся к нескольким практическим пунктам.
Доступы и роли. Каждому сотруднику выдайте минимальный набор прав: менеджеру нужны заказы, но не выгрузка всей базы. Разработчику не нужен доступ к боевой базе. При увольнении закрывайте учётные записи в тот же день.
Шифрование. Включите HTTPS на сайте и шифрование соединения с базой. Для самой базы и резервных копий используйте шифрование на диске, а пароли храните в виде хешей.
Резервные копии. Копии делайте регулярно, храните на второй российской площадке и проверяйте восстановление. Копия с персональными данными подпадает под те же требования, что и основная база.
Журнал действий. Записывайте, кто и когда открыл, изменил или выгрузил данные. Журнал помогает при расследовании утечки и показывает проверяющим, что вы контролируете доступ.
Защита интеграций. Токены API и вебхуки прячьте в хранилище секретов, а не в тексте сценариев. Ограничьте права ключей и меняйте их при смене подрядчика. Публичный вебхук без проверки подписи позволяет подбросить в базу чужие записи.
Теперь о подрядчиках. Когда вы передаёте данные курьерской службе, call-центру, платёжной системе или разработчику, это поручение обработки по статье 6. Оно оформляется договором или условием в договоре, где указаны перечень действий, цели обработки и обязанность исполнителя соблюдать конфиденциальность и меры защиты.
Проверьте каждого подрядчика по короткому списку. Так вы увидите слабые места до подписания договора, а не после утечки.
- Есть ли в договоре пункт о поручении обработки персональных данных?
- Указаны ли цели и перечень данных, которые он получает?
- Где хранит данные и использует ли субподрядчиков?
- Что делает после окончания договора: возвращает или удаляет данные?
- Кто уведомляет вас об инцидентах?
Ответственность распределяется так: перед покупателем отвечаете вы, а перед вами — исполнитель. Поэтому в договоре закрепите его обязанность сообщать об утечках и возмещать ущерб. Разработчику магазина дайте доступ к тестовой копии без реальных данных, а на боевую допускайте по заявке и на ограниченный срок.
При утечке действуют жёсткие сроки уведомления Роскомнадзора об инциденте и о результатах внутреннего расследования. Их устанавливает часть 3.1 статьи 21 ФЗ-152, точные часы сверьте с действующей редакцией.
Подготовьте план действий заранее: кто решает, кто звонит, где лежит шаблон уведомления. Без плана эти часы уходят на споры о том, кто отвечает.
Теперь о ценах нарушений. Статья 13.11 КоАП предусматривает штрафы за несоблюдение требований закона о персональных данных (КоАП РФ). Размер зависит от части статьи, повторности нарушения и редакции кодекса. Конкретные суммы здесь не приводим: читайте редакцию на день проверки, потому что норма менялась и ответственность за утечки ужесточали.
Проверки Роскомнадзора идут по плану и по жалобам. Поводом бывает обращение покупателя, сообщение об утечке или мониторинг сайтов. Проверяющие смотрят политику обработки, согласия на формах, места хранения и договоры с подрядчиками. Если у вас есть карта потоков и документы, проверка проходит спокойнее.
Отдельный вопрос — уведомление об обработке. По статье 22 оператор обязан уведомить Роскомнадзор до начала обработки и попасть в реестр операторов. Порядок менялся, поэтому сверьтесь с действующей редакцией статьи.
Есть исключения, например данные, полученные при заключении договора и не передаваемые третьим лицам без согласия. Но интернет-магазин почти всегда использует доставку, рассылки и аналитику, поэтому исключение работает редко. Статья не заменяет юридическую консультацию: сверьте свою схему с юристом и подавайте уведомление, если сомневаетесь.
Частые вопросы
Можно ли хранить базу покупателей на зарубежном сервере по ФЗ-152?
Нет, если это первичная база данных граждан России. Часть 5 статьи 18 требует записывать, хранить и обновлять такие данные в базах на территории России. Зарубежная копия возможна только как дополнительная и только при соблюдении правил трансграничной передачи: уведомление Роскомнадзора и оценка защиты получателя. Надёжнее держать основную базу и резервные копии в России и не создавать зарубежных дублей без необходимости.
Нужно ли уведомлять Роскомнадзор, если у меня небольшой интернет-магазин?
Обычно да. Размер магазина не освобождает от обязанности. Исключение есть для данных, полученных при заключении договора с покупателем. Оно действует, только если вы не передаёте их третьим лицам без согласия и используете лишь для исполнения договора. Курьерские службы, рассылки и аналитика ломают это условие. Проверьте свою схему и при сомнениях подайте уведомление до начала обработки.
Подходят ли Google Таблицы и зарубежные CRM для хранения заказов?
Нет, если там первично записываются данные покупателей из России. Серверы этих сервисов находятся за границей, а локализация требует российской базы. Замените таблицы на Яндекс 360, МойОфис или собственную базу, а зарубежную CRM на Битрикс24, amoCRM или RetailCRM. Выгрузку для работы можно делать из российской базы, не наоборот.
Сколько времени можно хранить данные покупателей после заказа?
Закон не называет одного срока. Данные хранятся не дольше, чем нужно для цели обработки. Контакты для исполнения заказа и гарантии храните до их завершения, бухгалтерские документы — по срокам налогового и бухгалтерского законодательства. Для рассылок срок действует, пока человек не отзовёт согласие. Зафиксируйте сроки в политике обработки и настройте регулярную очистку.
Нарушает ли закон форма заявки на Tilda, если данные уходят в почту или мессенджер?
Сама форма не нарушает, но маршрут данных может. Если заявка с ФИО и телефоном приходит на зарубежную почту или в Telegram, это передача на иностранную инфраструктуру. Уточните у Tilda, где хранятся заявки, перенаправьте уведомления на российский ящик и отправляйте в мессенджер только номер заказа. Полные данные держите в российской CRM.
Что делать дальше
Нарисуйте карту потоков: список всех систем с данными покупателей и страна хранения рядом с каждой. Если в списке есть зарубежные сервисы, закажите аудит и миграцию автоматизации в российский контур. Так вы найдёте места утечки данных и перенесёте сценарии на self-hosted n8n, чтобы контакты покупателей не уходили за рубеж.
