Тема персональных данных долго воспринималась бизнесом как формальность: где-то на сайте есть галочка «согласен», и ладно. Сегодня это уже не так. Требования к локализации данных россиян ужесточаются, штрафы выросли до ощутимых сумм, а проверки стали реальностью для обычных интернет-магазинов, а не только крупных платформ. Игнорировать вопрос стало дороже, чем закрыть его.
Эта статья — практический разбор для владельца сайта на 1С-Битрикс: что требует закон о хранении персональных данных россиян на серверах в РФ, где размещать базу и бэкапы, как правильно собирать согласия, оформить политику и что делать с внешними сервисами. Технические вопросы размещения и защиты помогает закрыть аудит и оптимизация 1С — начинается всё с понимания, где и как сейчас лежат данные. Статья носит практический, а не юридический характер: за официальным заключением обращайтесь к профильному юристу.
Коротко
- Первичная база с ПДн россиян должна физически находиться на серверах в РФ — включая бэкапы.
- У каждой формы — осознанное согласие на обработку со ссылкой на политику конфиденциальности.
- Магазин, собирающий данные покупателей, — оператор ПДн: нужны уведомление РКН и опубликованная политика.
- Внешние сервисы (аналитика, чаты, рассылки) — зона риска: нужны поручение на обработку и хранение в РФ.
О чём закон и кого касается
Базовый документ — Федеральный закон № 152-ФЗ «О персональных данных». Он определяет, кто такой оператор, что такое обработка и какие обязанности возникают у того, кто собирает данные людей. Отдельная норма (часть 5 статьи 18) вводит требование локализации: обработка ПДн граждан РФ должна вестись с использованием баз данных, расположенных в России.
Касается это практически любого коммерческого сайта, который собирает данные посетителей. Интернет-магазин, принимающий заказы, оптовый портал с личными кабинетами, даже сайт-визитка с формой обратной связи — все они становятся операторами персональных данных в тот момент, когда получают от человека имя, телефон или e-mail. Размер бизнеса значения не имеет: обязанности одинаковы и для маркетплейса, и для небольшого магазина.
Что считается персональными данными
Персональные данные — это любая информация, относящаяся к прямо или косвенно определяемому человеку. На типовом сайте это далеко не только ФИО.
- Явные данные. Имя, фамилия, телефон, e-mail, адрес доставки, дата рождения, данные компании и контактного лица в B2B.
- Косвенные идентификаторы. IP-адрес, cookie, идентификаторы устройства, история заказов, привязанные к конкретному пользователю.
- Данные из форм. Всё, что человек вводит в заказ, регистрацию, обратную связь, подписку, онлайн-консультант.
Практический вывод: точки сбора ПДн на сайте нужно инвентаризировать. Для каждой формы важно понимать, какие данные она собирает, куда они попадают и с какой целью. Именно эта карта данных станет основой и для согласий, и для политики, и для оценки рисков по внешним сервисам.
Локализация: база и бэкапы в РФ
Ядро требования простое по формулировке и коварное на практике: первичная база с персональными данными россиян должна физически размещаться на территории России. «Первичная» означает, что именно российская база — источник истины, где происходят сбор, запись, накопление и хранение.
Здесь легко упустить детали:
- Бэкапы тоже данные. Резервные копии базы с ПДн должны храниться в РФ, а не на зарубежном облаке «для надёжности».
- Реплики и логи. Копии базы, журналы с персональными данными, файлы экспорта — всё это подпадает под требование.
- Обмен с 1С. Если данные ходят между сайтом и учётной системой, обе стороны и канал должны оставаться внутри российского контура.
Где хостить сайт на 1С-Битрикс
Из требования локализации следует простой практический вывод: держите проект целиком в российском дата-центре. Это снимает сразу несколько рисков — и по хранению ПДн, и по устойчивости к недоступности зарубежных сервисов, и по скорости для российской аудитории.
При выборе площадки важны документы: хостинг должен подтверждать размещение оборудования в РФ. Для 1С-Битрикс с его требовательностью к окружению обычно берут виртуальную машину BitrixVM или совместимую конфигурацию в российском ЦОД. Как устроено такое окружение и почему оно удобно для Битрикса, мы разбирали в статье про инфраструктуру на BitrixVM. Отдельно стоит убедиться, что и почтовый сервер, и хранилище бэкапов, и сервисы обмена с 1С находятся в том же российском контуре.
Согласия на обработку в формах
Каждая форма, где посетитель оставляет данные, должна собирать согласие на их обработку. Причём согласие должно быть осознанным и подтверждаемым, а не «спрятанной» галочкой.
- Чекбокс без предзаполнения. Галочка согласия не должна стоять по умолчанию — пользователь ставит её сам.
- Ссылка на политику. Рядом с чекбоксом — ссылка на политику конфиденциальности и, при необходимости, на текст согласия.
- Понятная формулировка. Человек должен понимать, на что соглашается: кто оператор, какие данные и с какой целью обрабатываются.
- Фиксация факта. Желательно сохранять, что согласие дано, когда и с какой формы — чтобы при проверке это можно было подтвердить.
В 1С-Битрикс формы обычно строятся штатными средствами (веб-формы, компоненты заказа и регистрации), и чекбокс согласия добавляется в разметку каждой из них. Важно не забыть «тихие» точки: подписку в подвале, онлайн-консультант, всплывающие формы акций — они тоже собирают ПДн.
Политика конфиденциальности на сайте
Политика обработки персональных данных — обязательный публичный документ. Она должна быть в свободном доступе: отдельной страницей со ссылкой в подвале и рядом с каждой формой. Хорошая политика отвечает на понятные вопросы.
- Кто оператор. Реквизиты организации или ИП, контакты ответственного за обработку.
- Какие данные и зачем. Перечень собираемых ПДн и цели обработки — оформление заказа, доставка, рассылка.
- Как хранятся и защищаются. Общие принципы хранения, сроки, меры защиты.
- Права субъекта. Как человек может запросить, изменить или удалить свои данные, отозвать согласие.
Текст политики готовит юрист под конкретный бизнес, а задача разработчика — корректно опубликовать документ, связать его со всеми формами и обеспечить, чтобы ссылка была видимой, а не спрятанной в трёх кликах.
Уведомление Роскомнадзора и статус оператора
Собирая данные покупателей, бизнес становится оператором персональных данных, а оператор обязан уведомить Роскомнадзор о намерении обрабатывать ПДн (за отдельными исключениями, которые к типовому магазину обычно не относятся). Это отдельная юридическая процедура, идущая в комплекте с сайтом.
Кроме уведомления, у оператора появляется набор внутренних обязанностей: назначить ответственного за обработку, разработать документы (положение об обработке, перечень мер защиты), вести учёт. Всё это лежит в юридической плоскости, но напрямую влияет на технику: например, требование ограничить доступ к данным превращается в конкретные настройки прав на сайте и в 1С.
Внешние сервисы и передача данных
Самый частый источник нарушений — не сам сайт, а сервисы вокруг него. Каждый сторонний инструмент, которому уходят ПДн, нужно оценить отдельно.
| Сервис | Какие данные уходят | Что проверить |
|---|---|---|
| CRM / учётная система | Заказы, контакты, история | Размещение в РФ, поручение на обработку |
| E-mail и SMS-рассылки | E-mail, телефон, имя | Хранение в РФ, согласие на рассылку |
| Онлайн-чат / консультант | Имя, контакты, переписка | Где хранятся диалоги, юрисдикция |
| Веб-аналитика | IP, cookie, поведение | Обезличивание, юрисдикция сервиса |
| Платёжный шлюз | Данные плательщика | Российский провайдер, PCI DSS |
Принцип один: если сервису передаются персональные данные россиян, он должен либо хранить их в РФ, либо не получать эти данные вовсе. Зарубежные инструменты, уводящие ПДн за пределы российской базы, — прямой риск. Когда обмен данными между сайтом и внутренними системами построен через собственные интеграции и вебхуки, контролировать контур проще; о безопасной настройке таких каналов мы писали в материале про безопасность REST и вебхуков в Битрикс.
Защита данных и разграничение доступа
Локализация — только половина дела. Закон требует и защищать данные: применять организационные и технические меры, исключающие несанкционированный доступ. На практике для сайта на 1С-Битрикс это означает вполне конкретные вещи.
- Шифрование канала. HTTPS на всём сайте, особенно на страницах с формами и в личном кабинете.
- Разграничение прав. Доступ к персональным данным — только у тех сотрудников, кому он нужен по роли; в Битрикс это группы пользователей и права доступа.
- Защита админки. Сильные пароли, двухфакторная аутентификация, ограничение доступа к панели управления по адресам.
- Журналирование. Логи доступа к данным, чтобы понимать, кто и когда с ними работал.
Многие из этих мер — часть общей безопасности проекта, а не отдельная «фича под закон». Настроив их один раз, вы закрываете сразу и требования по защите ПДн, и типовые риски взлома.
Хранение и удаление: сроки и права субъекта
Персональные данные нельзя хранить бесконечно «на всякий случай». Закон говорит, что данные хранятся не дольше, чем требуется для целей обработки, после чего подлежат удалению или обезличиванию. Для магазина это означает продуманную политику жизненного цикла данных.
Также у субъекта есть права: узнать, какие данные о нём есть, потребовать их уточнения, удаления или отозвать согласие. Технически стоит заранее предусмотреть, как обрабатывать такие запросы — где искать данные человека, как их удалить из базы сайта и из связанных систем. Если данные размазаны по сайту, CRM и десятку сервисов без единой карты, выполнить запрос на удаление становится почти невозможно, а это уже нарушение.
Частые ошибки
- Бэкап за границей. Основная база в РФ, а резервные копии уходят в зарубежное облако — локализация нарушена.
- Предзаполненная галочка согласия. Согласие «по умолчанию» не считается осознанным.
- Политика спрятана. Документ есть, но ссылки на него нет ни в подвале, ни у форм.
- Забытые точки сбора. Подписка, онлайн-чат, всплывающие формы собирают ПДн без согласия.
- Внешняя аналитика без оценки. Зарубежный сервис получает IP и cookie россиян, вопрос юрисдикции не проработан.
- Нет уведомления РКН. Магазин собирает данные, но как оператор нигде не зарегистрирован.
- Данные хранятся вечно. Нет сроков и механизма удаления, запросы субъектов выполнить нечем.
Чек-лист соответствия
- Карта данных составлена. Известны все точки сбора ПДн и куда данные попадают.
- База и бэкапы в РФ. Первичная база, реплики, резервные копии и обмен с 1С — внутри российского контура.
- Согласия настроены. На каждой форме — осознанный чекбокс со ссылкой на политику, факт согласия фиксируется.
- Политика опубликована. Документ в свободном доступе, ссылки в подвале и у форм.
- Статус оператора оформлен. Подано уведомление РКН, назначен ответственный, есть внутренние документы.
- Внешние сервисы проверены. У каждого — понятная юрисдикция и поручение на обработку; рискованные заменены.
- Защита и доступ. HTTPS, разграничение прав, защита админки, журналирование настроены.
- Сроки и удаление. Определены сроки хранения и механизм выполнения запросов субъектов.
Вывод
Соблюдение требований по хранению персональных данных россиян — это не одна галочка, а связка из трёх вещей: локализация (база и бэкапы в РФ), корректный сбор согласий и опубликованная политика, а также защита данных и статус оператора. Каждый пункт по отдельности несложен, но нарушение любого из них создаёт реальный риск штрафа и блокировки.
Начните с инвентаризации — составьте карту, где и какие данные вы собираете и куда они уходят. Она сразу подсветит слабые места: зарубежный бэкап, чат непонятной юрисдикции, форму без согласия. Дальше всё превращается в понятный список задач по технике и юридике. Выстроить это заранее заметно дешевле, чем разбираться с последствиями проверки, а для российской аудитории размещение в РФ — ещё и выигрыш в скорости и стабильности.
