152-ФЗ простыми словами: что реально требуется от небольшого сайта

MAATRIX

У вас лендинг с формой заявки, интернет-магазин с личным кабинетом или блог, где можно оставить комментарий — и рано или поздно кто-то говорит: «а вы вообще в курсе, что по 152-ФЗ...». Дальше обычно идёт тревога, гуглинг обрывков закона и ощущение, что тема слишком юридическая, чтобы разобраться самому. На практике всё проще, чем кажется: разберём человеческим языком, что закон означает для обычного небольшого сайта и что с этим реально делать — без канцелярита, без выдуманных номеров пунктов и без запугивания. > Важная оговорка. Это обзорный ознакомительный материал, написанный простым языком для владельца небольшого сайта, а не юридическая консультация. Он не разбирает закон постатейно и не покрывает все возможные ситуации — у интернет-магазина, медицинского сайта и B2B-лендинга требования могут отличаться в деталях. Для вашей конкретной ситуации — особенно если вы собираете чувствительные данные (здоровье, финансы, данные детей) или работаете с большими объёмами — обратитесь к юристу или специалисту по защите персональных данных.

Что вообще считается «обработкой персональных данных» на сайте

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

Если на вашем сайте есть хотя бы одно из следующего — вы уже обрабатываете персональные данные:

• Форма обратной связи или заявки. Посетитель ввёл имя, телефон или почту, чтобы вы ему перезвонили или прислали КП. Это уже сбор и обработка.
• Регистрация пользователей. Личный кабинет интернет-магазина, форум, доступ к закрытому контенту — везде, где заводится аккаунт с email и паролем, вы храните персональные данные.
• Email-рассылка. База подписчиков — это база персональных данных, даже если в ней только адреса почты без имён.
• Комментарии на блоге. Имя и email, которые оставляет комментатор, юридически тоже персональные данные, хотя воспринимаются как мелочь.
• Аналитика и метрики. IP-адрес, cookie-идентификаторы и поведение на сайте в строгом смысле тоже относятся к данным, которые можно связать с человеком, хотя эта часть темы обычно регулируется отдельно от «прямых» данных вроде ФИО и телефона.

Важный нюанс: закон не требует, чтобы данные были «чувствительными» (паспорт, диагноз, банковская карта), чтобы попасть под регулирование. Имя и телефон в форме заявки на лендинге — уже достаточно. Это первая и самая частая причина, по которой владельцы маленьких сайтов ошибочно решают, что их это не касается: они мысленно приравнивают «персональные данные» к «секретным данным», а это не одно и то же.

Три типичных сценария небольшого сайта

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

Форма на лендинге («оставьте заявку»). Самый простой случай с точки зрения объёма данных, но именно на нём чаще всего забывают про формальности — потому что кажется, что «это всего одна строчка контактов». По сути вы собираете имя и телефон/почту, передаёте их себе на email или в CRM, потом менеджер звонит. Обработка тут короткая, но она есть от момента отправки формы до момента, пока данные хранятся у вас (в почте, в CRM, в таблице).

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

Блог с комментариями и рассылкой. Комментаторы оставляют имя и email, подписчики рассылки — email и иногда имя. Отдельная особенность: рассылка требует явного согласия на получение писем (это, по сути, отдельный вид обработки — коммуникация с человеком по email), и это согласие стоит фиксировать отдельно от «согласия на обработку данных» при регистрации.

Во всех трёх случаях логика одна: как только на сайте появляется поле ввода, куда посетитель вписывает что-то о себе, вы становитесь стороной, которая эти данные обрабатывает — со всеми вытекающими обязанностями.

Согласие на обработку: что это значит на практике

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

• Рядом с формой (заявка, регистрация, подписка на рассылку) размещается чекбокс или текст вида «Отправляя форму, вы соглашаетесь с обработкой персональных данных в соответствии с [политикой обработки]».
• Чекбокс либо активный (пользователь сам ставит галочку — надёжнее с точки зрения доказуемости согласия), либо предзаполненный текст со ссылкой на политику, который пользователь принимает нажатием кнопки «Отправить».
• Форма не должна отправляться, если согласие не дано явно — это обычно реализуется на уровне валидации формы (нельзя нажать «Отправить», пока чекбокс не отмечен).

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

Для email-рассылок отдельно стоит держать в голове практику double opt-in — подтверждение подписки переходом по ссылке в письме. Это не столько юридическое требование, сколько защита от жалоб на спам и от того, что кто-то впишет чужой email в форму подписки; подробнее о технической стороне массовой рассылки, где эта тема пересекается с репутацией отправителя, можно почитать в статье про настройку сервера под почтовую рассылку.

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

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

Типично такой документ отвечает на несколько вопросов:

• Какие именно данные собираются (имя, телефон, email, IP-адрес, cookie и так далее — по факту того, что реально есть на сайте).
• Для каких целей они используются (обработка заказа, ответ на заявку, рассылка новостей).
• Где и как долго данные хранятся.
• Передаются ли они третьим лицам (например, службе доставки, платёжному шлюзу, сервису email-рассылок) и на каком основании.
• Как пользователь может запросить удаление своих данных или отозвать согласие.

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

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

Где физически хранятся данные российских пользователей

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

Это не значит, что весь сайт обязан находиться в РФ — сам фронтенд, статика, CDN вполне могут быть где угодно. Речь именно про базу данных, где лежат персональные данные: имена, телефоны, адреса, история заказов. Для типичного небольшого проекта это на практике означает: сервер (или хотя бы база данных) под личные кабинеты, CRM и формы должен стоять в России, даже если остальная инфраструктура — за рубежом.

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

«Меня это не коснётся» и другие частые заблуждения

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

«Это только для больших компаний». Самое частое и самое неверное убеждение. Закон о персональных данных не делает исключений по размеру бизнеса, обороту или количеству записей в базе. Формально ИП с лендингом на пять заявок в месяц и федеральный интернет-магазин с миллионами клиентов подчиняются одному и тому же закону — разница только в масштабе рисков и в том, насколько вероятно привлечь внимание регулятора. «Маленький» не означает «невидимый», особенно если кто-то из посетителей пожалуется напрямую.

«У нас же просто форма, а не база данных». Любое хранилище, где данные лежат больше одного запроса — почтовый ящик, куда падают заявки, таблица в Google Sheets, CRM, — юридически тоже база данных персональных данных. Слово «просто» здесь ничего не меняет.

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

«У нас есть SSL-сертификат, значит мы защищены по закону». HTTPS защищает канал передачи данных между браузером и сервером, это полезная и нужная мера, но она не заменяет ни согласие на обработку, ни политику, ни требования к месту хранения — это разные, независимые друг от друга требования.

«Мы всё сделаем, если придёт проверка». Реактивный подход рискован именно потому, что типичный триггер внимания — не плановая проверка, а жалоба пользователя (например, недовольного клиента, который просит удалить свои данные и не получает ответа) или инцидент вроде утечки данных. К моменту, когда «пришла проверка», обычно уже поздно наводить порядок.

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