УСЛУГИ КЕЙСЫ ОТЗЫВЫ ЦЕНЫ FAQ БЛОГ КОНТАКТЫ ВИДЖЕТЫ
Интернет-магазины 8 мин чтения

Персональные данные покупателей: как интернет-магазину соблюдать 152-ФЗ

Персональные данные покупателей: как интернет-магазину соблюдать 152-ФЗ

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

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

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

Какие данные интернет-магазин получает от покупателя

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

На практике данные появляются на разных этапах работы магазина:

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

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

Кто отвечает за обработку персональных данных

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

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

Оператор, обработчик и получатель данных

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

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

Какие цели обработки нужно определить заранее

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

ЦельКакие данные могут понадобитьсяПрактический результат
Оформление и исполнение заказаИмя, телефон, адрес, состав заказаПодтверждение заказа, доставка, уведомления о статусе
Работа с обращениямиИмя, контакты, содержание перепискиОтвет на вопрос, рассмотрение претензии, возврат
Бухгалтерский и обязательный учётРеквизиты и сведения, предусмотренные документамиОформление расчётов и хранение подтверждающих документов
Рекламная рассылкаЭлектронная почта или телефонОтправка предложений при наличии отдельного согласия

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

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

Как оформить согласия и документы в интернет-магазине

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

Что проверить в форме заказа

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

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

Заказ без регистрации

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

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

Локализация, хранение и доступ к базе заказов

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

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

Доступ сотрудников

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

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

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

Что делать с cookie, аналитикой и рекламными рассылками

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

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

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

Рассылки и повторные продажи

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

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

Передача данных доставке, оплате и подрядчикам

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

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

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

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

Сроки хранения, удаление и запросы покупателей

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

Сроки лучше определить по категориям:

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

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

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

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

Типичные ошибки интернет-магазинов

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

  1. Один универсальный чекбокс. В него включают заказ, рекламу, передачу всем партнёрам и использование cookie. Исправление: разделить цели и оставить обязательными только необходимые для выбранного сценария.
  2. Шаблонная политика без связи с сайтом. В документе нет фактических форм, сервисов, сроков и способов связи. Исправление: обновить текст после инвентаризации сайта, а не до неё.
  3. Лишние поля в заказе. Магазин запрашивает дату рождения, отчество или паспорт без понятной необходимости. Исправление: убрать поле либо объяснить конкретную цель и правовое основание.
  4. Общий аккаунт администратора. Невозможно установить, кто выгрузил базу или изменил заказ. Исправление: индивидуальные учётные записи, роли и журнал действий.
  5. Передача всей базы подрядчику. Для настройки одного письма выгружаются все покупатели за несколько лет. Исправление: ограничить выборку, обезличить её или использовать тестовые данные.
  6. Реклама после отказа. Отписка убирает адрес только из одного списка, а другой сервис продолжает отправку. Исправление: создать единый статус запрета на рекламные сообщения и синхронизировать системы.
  7. Форма, которая отправляет данные до согласия. Такое бывает при автоматическом сохранении полей или ошибке в сценарии JavaScript. Исправление: проверить сетевые запросы и серверную обработку, а не только внешний вид страницы.
  8. Данные в открытом доступе. Заказы, файлы выгрузок или резервные копии доступны по предсказуемой ссылке. Исправление: закрыть каталоги, проверить права, запретить индексацию служебных страниц и провести технический аудит.

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

Как проверить интернет-магазин перед запуском

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

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

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

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

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

Связь соблюдения 152-ФЗ с SEO и продажами

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

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

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

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

Нужно ли отдельное согласие для оформления заказа?

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

Можно ли отправлять рекламные письма всем бывшим покупателям?

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

Нужно ли получать согласие на телефон для доставки?

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

Что делать, если магазин работает через CRM и внешнюю доставку?

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

Нужно ли удалять данные о старых заказах?

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

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

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

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

[ RDMN ]
Нужен сайт, который приводит заявки?

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

Обсудить задачу

Похожие статьи