Персональные данные на сайте: что требует закон и как это выполнить

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

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

Закон 152-ФЗ «О персональных данных» определяет персональные данные очень широко: это любая информация, которая прямо или косвенно относится к определённому или определяемому человеку. На практике это означает, что персональными считаются не только паспортные данные, но и сочетание имени с телефоном, адрес доставки, электронная почта вида ivan.petrov@…, история заказов, привязанная к аккаунту. Даже одно поле «Телефон» в форме обратного звонка — это уже сбор персональных данных, потому что по номеру можно установить конкретного человека.

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

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

Что закон требует от владельца сайта

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

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

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

Политика обработки персональных данных: из чего она состоит

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

Обязательные разделы

• Сведения об операторе: наименование, адрес, контактный e-mail для запросов субъектов данных.
• Цели обработки — по каждой форме или процессу отдельно: обработка заказа, обратная связь, рассылка, работа личного кабинета.
• Перечень данных по каждой цели — без «и иные данные», которые размывают документ.
• Правовые основания: договор, согласие, законная обязанность.
• Третьи лица, которым передаются данные: курьерские службы, платёжный агрегатор, сервис рассылок, хостинг-провайдер.
• Сроки хранения и порядок уничтожения.
• Права субъекта и порядок обращения: как запросить сведения, исправить или удалить данные.

Типичные ошибки в политике

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

Согласие на обработку: когда нужно и как оформить

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

Практически это означает несколько правил для форм. Галочка согласия не должна стоять по умолчанию — человек ставит её сам. Рядом должна быть ссылка на текст согласия или политику, например на страницу согласия на обработку данных. Согласие на рассылку не стоит «склеивать» с согласием на обработку заказа: это две разные цели, и человек вправе выбрать только одну. Кнопка «Отправить» может быть неактивна, пока обязательное согласие не отмечено, — это проще, чем объяснять ошибку после отправки.

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

Где хранятся данные: локализация и сторонние сервисы

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

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

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

Технические меры защиты на стороне сайта

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

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

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

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

Что делать, если данные утекли

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

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

Итоги: короткий план для владельца сайта

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

Начните с карты потоков данных — она займёт час и покажет, где сайт расходится с документами. Затем пройдитесь по формам и сравните их с политикой. Если сайт только проектируется, заложите всё это в техническое задание: исправлять готовый сайт всегда дороже, чем сразу сделать правильно. А если нужна помощь с технической частью, напишите нам на [email protected] — разберём ваш сайт и предложим конкретный список доработок.