Что закон требует от интернет-магазина: 152-ФЗ, оферта, чеки, маркировка

# Что закон требует от интернет-магазина: 152-ФЗ, оферта, чеки, маркировка

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

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

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

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

Роскомнадзор не ищет вас — он ждёт, когда на вас пожалуются

Первое, что стоит понять про контроль в этой сфере: он в подавляющем большинстве случаев реактивный, а не проактивный. Ведомство физически не может провести плановую проверку каждого из сотен тысяч интернет-магазинов в стране. У него нет ресурса ходить по сайтам и искать нарушения превентивно. Механизм работает иначе — кто-то подаёт жалобу, и только после этого запускается проверка. Жалобу может подать покупатель, которому не ответили на запрос удалить данные. Может подать конкурент, который таким образом решил создать вам проблему — да, это тоже реальная практика, и я видел такое минимум дважды. Может подать бывший сотрудник, обиженный на увольнение и знающий, что документов на сайте нет. Логика простая: пока никто не пожаловался, риск в моменте невысокий. Как только пожаловались — начинается разбирательство, и вот тогда цена вопроса резко меняется, потому что разбирают не только конкретную жалобу, а весь комплект документов и практик магазина.

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

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

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

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

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

Пакет документов, без которого магазин играет в русскую рулетку

Теперь к сути — какой набор документов реально нужен на сайте. Я говорю именно о наборе, потому что это не один документ, а несколько, и они закрывают разные риски. Первый и самый обсуждаемый — политика обработки персональных данных. Это документ, который объясняет посетителю, какие данные магазин собирает, зачем, как долго хранит и кому может передавать. Условно говоря, это ответ на вопрос «что вы делаете с моими данными», сформулированный заранее, а не придуманный в панике после жалобы. Без этого документа у оператора персональных данных попросту нет легального основания объяснить свою практику, если кто-то спросит.

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

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

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

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

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

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

152-ФЗ по-человечески: что такое персональные данные в вашем заказе

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

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

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

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

Здесь же стоит сказать про категорию данных, о которой владельцы магазинов почти никогда не задумываются заранее, — данные, которые собираются не напрямую от покупателя, а автоматически через инфраструктуру сайта. IP-адрес посетителя, данные о его устройстве и браузере, история просмотренных страниц, привязанная к идентификатору сессии, — это тоже потенциально персональные данные, если их можно соотнести с конкретным человеком, например через тот же заказ. Большинство систем аналитики и антифрод-модулей собирают такие сведения по умолчанию, и владелец магазина зачастую даже не знает, что именно и где логируется. Я советую хотя бы раз пройтись по всем модулям сайта, которые что-либо логируют, — от системы защиты от брутфорса до модуля аналитики продаж, — и честно ответить себе на вопрос, отражено ли это в политике обработки данных. Чаще всего оказывается, что отражено не всё.

Третий момент — срок хранения и право на удаление. Покупатель имеет право потребовать удаления своих данных, и магазин должен быть готов это сделать в разумный срок, а не игнорировать запрос месяцами, как это случилось в истории, с которой я начал статью. На практике это означает, что должен существовать понятный внутренний процесс: кто в компании отвечает за такие запросы, где физически хранятся данные (единая база или расползлись по десятку сервисов), как быстро можно найти и удалить запись конкретного человека. Я видел магазины, где данные клиента размазаны между базой WooCommerce, экспортами в Excel у трёх разных менеджеров, старой CRM, которую забыли выключить, и рассылочным сервисом. В такой ситуации выполнить требование об удалении технически сложно, даже если юридически вы полностью готовы это сделать. Централизация данных — это не только вопрос удобства работы, но и вопрос способности выполнить закон, когда об этом попросят.

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

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

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

Касса, чек и маркировка: там, где закон уже физически встроен в оплату

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

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

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

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

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

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

Cookie-баннеры, аналитика и та грань, где формальность становится риском

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

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

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

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

Третий момент — согласие на cookie не равнозначно согласию на обработку персональных данных в широком смысле. Это разные документы, решающие разные задачи, и подменять одно другим — распространённая, но неверная практика. Cookie-баннер информирует о технических файлах, которые сохраняются в браузере. Согласие на обработку персональных данных касается той информации, которую человек сообщает магазину напрямую — при оформлении заказа, регистрации, подписке на рассылку. Оба документа нужны, и путать их функции не стоит.

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

Если бы меня попросили расставить приоритеты, с чего начинать — будь то запуск нового магазина или наведение порядка в уже работающем, — я бы предложил такой порядок разговора с юристом. Сначала базовый пакет документов: политика обработки персональных данных, согласие, оферта, условия возврата, реквизиты, потому что без него нет ничего, на что можно сослаться в любом споре. Затем сверка того, действительно ли нужна регистрация в качестве оператора персональных данных именно для вашей схемы работы, и если нужна — оформление уведомления. Дальше проверка кассовой схемы: кто формирует чек на каждом канале оплаты, включая эквайринг, СБП и оплату по счёту для юрлиц. После этого проверка ассортимента на предмет маркировки и любых отраслевых ограничений на дистанционную торговлю. И только в последнюю очередь — cookie-баннер и приведение в порядок аналитики и виджетов, потому что это, как правило, наименее рискованная часть, если всё остальное уже закрыто. Такой порядок — не догма, юрист вполне обоснованно может предложить другую последовательность под вашу конкретную ситуацию, но как отправная точка для разговора он работает хорошо.

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

Ещё одно наблюдение напоследок, которое кажется мне важным именно с позиции директора по развитию, а не юриста. Правильно оформленные документы — это не только защита от штрафа, это ещё и элемент доверия, который покупатель считывает, даже не читая эти документы построчно. Наличие внятной страницы «Реквизиты» с реальным юридическим лицом, ссылки на политику конфиденциальности в подвале сайта, понятных условий возврата на отдельной странице — всё это работает как невидимый сигнал «здесь всё по-настоящему, а не на коленке». Я видел A/B-сравнения (не строгие научные, а практические, на реальных магазинах), где просто наличие внятной страницы с условиями возврата чуть повышало готовность оформить заказ у новых посетителей — потому что снимало один из барьеров недоверия к незнакомому магазину. То есть юридическая гигиена работает не только против рисков, но и немного на конверсию, просто эффект здесь не такой заметный, как от смены цвета кнопки, и поэтому его редко считают деньгами.

Практически то, с чем я обычно помогаю клиентам на этапе, предшествующем разговору с юристом, — это техническая база: чтобы на сайте была возможность быстро создать и разместить страницы политики обработки персональных данных, согласия, публичной оферты, условий доставки и возврата, реквизитов — и чтобы чекбокс согласия был честно непроставленным по умолчанию и вёл на актуальный текст, а не на страницу-заглушку, забытую три года назад. В COS WP Woo для этого есть модуль, который генерирует стартовый комплект таких страниц прямо в WordPress — с явной пометкой, что каждый шаблон нужно проверить у юриста и адаптировать под конкретную нишу и схему работы, прежде чем публиковать. Это не замена юридической консультации, а способ не начинать с чистого листа, когда садитесь с юристом обсуждать документы для своего магазина. Если вы ведёте магазин на WooCommerce с формами заявок, принимаете оплату через ЮKassa или Тинькофф или задумываетесь о защите персональных данных клиентов на уровне инфраструктуры — юридический слой и техническая безопасность решают разные задачи, но обе части должны работать вместе, потому что одна без другой закрывает половину риска.