Хранение персональных данных на сайте: требования к серверам в России

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

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

Что именно требует закон о персональных данных

Основной принцип установлен Федеральным законом № 152-ФЗ. При сборе персональных данных граждан России оператор должен использовать базы данных, находящиеся на территории Российской Федерации. Это требование называют локализацией персональных данных.

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

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

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

Какие данные на сайте считаются персональными

Персональные данные, это любая информация, которая прямо или косвенно относится к определённому или определяемому человеку. Для сайта таким идентификатором часто становится сочетание имени и номера телефона, но перечень этим не ограничивается.

• Имя, фамилия и отчество посетителя.
• Номер телефона, адрес электронной почты и адрес доставки.
• Данные учётной записи, личного кабинета и истории обращений.
• Сведения о заказе, договоре, записи на услугу или заявке.
• IP-адрес и технические сведения, если в конкретной ситуации они позволяют связать информацию с человеком.
• Фотографии, документы, реквизиты и другие файлы, которые пользователь загружает через сайт.

Веб-форма с одним полем телефона тоже может собирать персональные данные. Количество полей не определяет обязанность компании соблюдать закон. Важны сами сведения и цель их использования.

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

Где должны находиться сервер и база данных

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

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

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

Локализация данных и трансграничная передача

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

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

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

Как составить карту движения данных

1. Выпишите все точки, где посетитель вводит или загружает информацию.
2. Для каждой формы укажите поля, цель обработки и получателя заявки.
3. Проверьте, куда данные попадают после отправки: в базу, почту, CRM, мессенджер, телефонию или таблицу.
4. Отдельно зафиксируйте внешние сервисы, скрипты, виджеты и системы аналитики.
5. Проверьте резервные копии, выгрузки менеджеров и файлы на рабочих компьютерах.
6. Для каждого участника определите роль, договор, доступ и срок хранения.

Такая карта полезнее формальной фразы «сервер находится в России». Она показывает, на каком этапе может возникнуть проблема и что именно нужно изменить.

Как выбрать российский хостинг для сайта

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

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

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

Если сайт уже работает на иностранном или непрозрачном хостинге, перенос обычно занимает от 1-3 рабочих дней для простого сайта до 1-3 недель для магазина или проекта с интеграциями. Срок зависит от объёма базы, количества доменов, почты, сертификатов, резервных копий и необходимости тестировать формы.

Что нужно настроить на самом сайте

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

Для сайта стоит проверить следующие технические настройки:

• Передача данных по защищённому соединению HTTPS.
• Разделение прав администратора, редактора и менеджера заявок.
• Сложные пароли, двухфакторная авторизация и ограничение входа в административную панель.
• Регулярные обновления CMS, плагинов, темы и серверного программного обеспечения.
• Защита формы от массовых автоматических отправок и вредоносных файлов.
• Шифрование или защищённое хранение резервных копий.
• Удаление тестовых заявок, старых выгрузок и неиспользуемых аккаунтов.
• Журналирование входов и критических действий в административной части.

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

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

Какие документы и процессы нужны бизнесу

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

Обычно проверяют наличие и актуальность следующих материалов:

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

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

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

Сайт, CRM, почта и личный кабинет: отдельные риски

Чем больше в проекте интеграций, тем выше вероятность потерять контроль над данными. Например, интернет-магазин принимает заказ на сайте, создаёт клиента в CRM, отправляет чек через платёжный сервис и передаёт адрес в службу доставки. У каждого участника должна быть понятная роль и законная цель доступа.

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

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

Типичные ошибки при хранении персональных данных

Ошибка 1. Проверяют только страну хостинга

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

Ошибка 2. Считают, что имя и телефон не являются персональными данными

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

Ошибка 3. Подключают сервисы без проверки политики обработки

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

Ошибка 4. Хранят заявки бессрочно

Старая база продолжает лежать в CMS, таблицах и почтовых ящиках, хотя бизнес уже не использует эти сведения. Нужно установить сроки хранения по целям и регулярно удалять данные, которые больше не нужны.

Ошибка 5. Оставляют общий доступ подрядчику

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

Ошибка 6. Переносят сайт без проверки форм

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

Как проверить уже работающий сайт

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

1. Соберите перечень всех форм, личных кабинетов, заказов и загрузок файлов.
2. Зафиксируйте поля каждой формы и цели их сбора.
3. Проверьте записи в базе данных и место её фактического размещения.
4. Проследите передачу заявки в CRM, почту, телефонию, чаты и внешние сервисы.
5. Проверьте домены внешних скриптов и запросы браузера при заполнении формы.
6. Проведите ревизию административных аккаунтов и прав доступа.
7. Проверьте резервные копии, их размещение и возможность восстановления.
8. Сверьте технический процесс с политикой и текстами согласий на сайте.

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

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

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

Обязательно ли размещать сайт на сервере в России?

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

Можно ли использовать иностранную CRM?

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

Достаточно ли добавить политику конфиденциальности?

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

Нужно ли переносить старые заявки на российский сервер?

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

Что делать, если сайт размещён на иностранном хостинге?

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

Кто отвечает за настройку сервера, владелец бизнеса или разработчик?

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

Что делать: короткий план

1. Перечислите все формы, заказы, личные кабинеты и загрузки файлов на сайте.
2. Составьте карту движения данных от посетителя до базы, CRM, почты и других сервисов.
3. Проверьте место размещения основной базы, резервных копий и выгрузок.
4. Выберите российскую инфраструктуру, если первичная запись происходит за пределами России.
5. Проверьте договоры с хостингом, CRM, телефонией, аналитикой и другими обработчиками.
6. Ограничьте доступы, обновите CMS и плагины, включите резервное копирование и HTTPS.
7. Удалите ненужные данные и установите понятные сроки хранения для оставшихся.
8. Обновите политику, согласия и описания целей обработки в соответствии с реальным процессом.
9. После изменений протестируйте формы, интеграции, удаление данных и восстановление из резервной копии.

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

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