Как интернет-магазинам, приложениям и играм соблюдать 152‑ФЗ?

В 2026 году интернет‑сервис — это не «сайт с формой», а фабрика данных: аккаунты, устройства, поведение, платежи, геолокация, игровые профили. Почти любое действие пользователя оставляет цифровой след, который во многих случаях становится персональными данными (ПДн) и попадает под действие 152‑ФЗ. Основа устойчивого комплаенса проста: четко разделите, что вы обрабатываете для исполнения договора (личный кабинет, доставка), а что — только по отдельному согласию (маркетинг, рекламный трекинг, часть cookie).

Введение — почему тема актуальна именно сейчас

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

Финансовые риски реальны: по ст. 13.11 КоАП РФ штрафы для юрлиц по отдельным составам могут достигать миллионов рублей. Для ряда нарушений в действующей редакции встречаются вилки вплоть до 6–18 млн рублей за грубые нарушения отдельных требований (в зависимости от состава). К этому добавляются затраты на расследование инцидента, остановку маркетинга, падение доверия и отток аудитории.

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

Почему интернет‑сервис — это оператор данных под прицелом? (обработка персональных данных интернет-сервисами)

Интернет‑сервис почти всегда является оператором: он определяет цели и способы обработки, собирает данные через интерфейсы и API, а затем передает их в аналитику, поддержку, CRM и подрядчикам.

Важно помнить: «техническая» информация часто становится юридически значимой. IP‑адреса, идентификаторы устройств, cookies, события (клики, просмотры) могут позволять прямо или косвенно идентифицировать пользователя — значит, это потенциальные ПДн с точки зрения 152‑ФЗ.

Пользователь = субъект ПДн. Его телефон, почта и даже никнейм — это уже персональные данные

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

На практике ПДн в сервисе часто включают:

• Email, телефон, ID аккаунта, логин, никнейм (если их можно связать с человеком).

• Адрес доставки и история заказов (это «биография потребления», которая легко деанонимизирует).

• Device ID, cookies, рекламные идентификаторы, события поведения (особенно в связке с аккаунтом).

• Тикеты поддержки и записи звонков.

Важно! Чем больше связок между «анонимными» событиями и аккаунтом, тем меньше «анонимности» и тем больше обязанностей оператора.

Законные основания: договор vs. согласие

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

Регистрация в личном кабинете: данные для исполнения договора

Если пользователь сам создает ЛК, оформляет заказ, подписку или игровой аккаунт, часть данных обрабатывается для заключения и исполнения договора — это легитимное основание по ст. 6 152‑ФЗ. Здесь важна «необходимость»: вы берете только то, без чего договор не работает (логин, контакт для восстановления, адрес для доставки, история транзакций для поддержки).

Практичный критерий для продукта:
Ответьте на вопрос «Если убрать это поле, сервис не сможет оказать оплачиваемую/заказанную услугу?»
Если да — вероятно, это договор. Если нет — вероятно, нужно иное основание (часто — согласие).

Маркетинг, профилирование, часть аналитики: обычно только по согласию

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

Здесь подключается ФЗ «О рекламе»: распространение рекламы по сетям электросвязи допускается только при предварительном согласии адресата, а обязанность доказать наличие согласия лежит на рекламораспространителе. Кроме того, по требованию пользователя рассылка должна быть прекращена немедленно.

Важно! Согласие «на всё» внутри оферты — слабая позиция. Лучшая практика — раздельные переключатели: «сервисные уведомления» (по договору) и «рекламные сообщения» (по согласию).

Статья 18 152‑ФЗ: обязанности при сборе данных (и локализация)

Ст. 18 152‑ФЗ — это «операционная инструкция» для digital‑команд. Если данные получены не от субъекта, оператор до начала обработки должен сообщить ему: кто оператор, цель и правовое основание обработки, перечень данных, круг предполагаемых пользователей, права субъекта и источник получения. При сборе через интернет оператор обязан обеспечить запись, систематизацию, накопление, хранение, уточнение и извлечение ПДн граждан РФ с использованием баз данных на территории РФ (за исключением оговоренных законом случаев).

Три кита digital‑данных: Сайты, Приложения, Игры

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

Веб‑сайт и личный кабинет: эпоха cookie (политика конфиденциальности сайта, согласие на cookie)

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

Как разделить cookie по смыслу (и снизить риски):

• Технические (строго необходимые): сессия, авторизация, корзина.

• Аналитические: метрики, продуктовая аналитика, A/B‑тесты.

• Рекламные: ретаргетинг, look‑alike, внешние пиксели/теги.

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

Практическая рекомендация: Пример текста для cookie‑попапа

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

Мобильное приложение: что скрывается за запросом доступа? (152-ФЗ и мобильное приложение)

В iOS/Android «пермишены» выглядят как техническая мелочь, но юридически это часто сбор ПДн и даже специальных категорий данных (например, точная геолокация). Разрешение в ОС — это не всегда согласие в смысле 152‑ФЗ: правовая логика должна быть описана в политике и UX, а цель — конкретизирована.

Список «опасных» разрешений, которые почти всегда нужно обосновывать особенно строго:

• Контакты (зачем вам чужие номера, если субъект — один пользователь).

• Геолокация (точная/фоновая).

• Микрофон и камера (особенно в фоне).

• Фото/медиа‑библиотека (доступ ко всем фото vs выбор одного файла).

• Доступ к Bluetooth/локальной сети (может раскрывать окружение пользователя).

Как сделать правильно (на языке продукта):

• Запрашивать доступ в момент использования функции, а не при первом запуске.

• Давать «честное» объяснение в экранчике перед системным поп‑апом.

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

Онлайн‑игры и виртуальные миры: данные как игровой актив (данные игрового аккаунта)

В играх ПДн — это не только платежи. Это профиль, ник, друзья, инвентарь, достижения, статистика матчей, переписка в чате. Часть данных публична (ник в рейтинге), часть — приватна (история покупок, привязка телефона, IP‑логи).

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

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

Специальные категории: геолокация, платежные данные и публичные сведения

«Разрешите доступ к геопозиции»: когда это правомерно?

Геолокация — один из самых чувствительных видов данных в digital: она раскрывает привычки, маршруты, места проживания и работы. Важно разделять:

• Разовая геолокация (например, показать ближайший пункт выдачи).

• Фоновая геолокация (когда приложение «следит» постоянно).

• Точная геолокация (с высокой точностью, часто через GPS).

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

Финансовые данные и история покупок: не просто цифры, а портрет клиента

Для e‑commerce критичны: состав заказа, частота покупок, возвраты, адреса доставки, предпочтения. Это «портрет» человека, который ценен злоумышленникам и опасен при утечке.

При этом не все финансовые данные одинаковы:

• История заказов у магазина — это ПДн, за которые магазин отвечает.

• Данные банковской карты (номер, срок, CVV) — отдельный риск‑класс.

Интернет‑магазины и платежи: агрегатор vs хранение карт

Ключевой момент архитектуры: если вы используете платежного агрегатора и не получаете полные реквизиты карты (номер, срок, CVV), то эти данные обрабатывает агрегатор в своей зоне ответственности. Тогда ваша задача — корректно описать это в документах, маршрутизации данных и политике (кто оператор чего, кто обработчик, какие данные вы реально видите).

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

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

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

• Парсинг профилей «на всякий случай».

• Обогащение анкеты данными из соцсетей без уведомления.

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

Ст. 18 152‑ФЗ прямо описывает обязанности, когда данные получены не от субъекта: до начала обработки нужно раскрыть ему ключевую информацию, включая источник получения. Это означает: если вы «подтянули» данные из внешнего источника, у вас должен быть сценарий уведомления и правовое основание.

Техническая защита: не только документы, но и код

Юридические документы не спасают, если в production-среде происходит утечка через API или пароли хранятся «как есть». С точки зрения практики проверок и инцидентов, сильный аргумент — показать, что вы применяете разумные технические меры и принцип privacy by design.

Критичный минимум для любого сервиса:

• Шифрование трафика по SSL/TLS (HTTPS везде, HSTS, актуальные шифры).

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

• Регулярные обновления зависимостей и патч‑менеджмент (особенно для CMS, SDK аналитики, SDK пушей).

• Сегментация баз: отдельно учетные данные, отдельно профили, отдельно платежные токены/идентификаторы.

• Логи доступа и мониторинг аномалий (массовые выгрузки, перебор паролей).

• Пентесты и баг‑баунти (по мере роста масштаба).

Кейс (реалистичный):

В результате уязвимости в API многопользовательского проекта утекла база с логинами, хэшами паролей и email‑адресами 2 млн игроков. Данные попали на форум, затем начались атаки на аккаунты через подбор паролей и фишинг. Компания потратила месяцы на сброс паролей, поддержку и антифрод, а также столкнулась с жалобами пользователей и проверкой.

Политика конфиденциальности и не только: три документа для безопасности (политика конфиденциальности сайта)

В digital юридические документы должны отражать реальную архитектуру данных. Если политика утверждает «мы не передаем третьим лицам», а у вас стоят трекеры и внешние SDK, это не просто ошибка — это риск обвинений в недостоверном информировании.

Три базовых документа:

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

2. Пользовательское соглашение / оферта: правила сервиса и договорные цели обработки (аккаунт, доставка, подписка).

3. Cookie‑баннер + cookie‑политика: категории, цели, как отозвать согласие и изменить настройки.

Чем политика отличается от пользовательского соглашения

Политика — про ПДн и прозрачность обработки. Оферта — про условия сервиса и обязательства сторон. Их связь важна: договорные сценарии обработки должны быть описаны согласованно, чтобы основание по ст. 6 152‑ФЗ «исполнение договора» выглядело логично и проверяемо.

Где и как размещать документы

Минимум:

• Ссылка на политику на каждой странице сайта (футер) и внутри экранов регистрации/оформления заказа.

• В приложении: в магазине приложений (ссылка), в онбординге, в настройках, и отдельная ссылка перед регистрацией.

• Куки-баннер со ссылкой на политику (подробное пояснение и рекомендации).

Права пользователя в один клик: отписка, удаление, выгрузка

Права субъекта ПДн — это не «вкладка в политике», а реальные UX‑сценарии. Самый токсичный триггер жалоб — когда пользователь хочет уйти, а сервис не дает ему этого сделать.

Право на удаление аккаунта («право на забвение») — как реализовать технически

Технический минимум для «удалить аккаунт»:

• Кнопка в профиле, а не только письмо в поддержку.

• Понятный статус: «заявка принята», «аккаунт будет удален через N дней».

• Разделение данных: то, что можно удалить сразу, и то, что нужно хранить по закону (например, бухгалтерские/налоговые следы сделки).

Конфликт «удалить» vs «хранить 5 лет»

В e‑commerce часто возникает конфликт: пользователь просит удалить историю заказов, а бизнес обязан хранить сведения о сделках для налогового учета и защиты в спорах. Решение — не «отказать», а объяснить:

• что именно будет удалено (профиль, маркетинговые согласия, токены устройств),

• что будет сохранено и почему (минимально необходимый «след» операции),

• и как ограничите доступ (архивный контур, доступ на основе ролей).

Отзыв согласия на маркетинг — кнопка «Отписаться» обязана работать

По ст. 18 Закона о рекламе рассылка допустима только при предварительном согласии, а по требованию адресата должна быть прекращена немедленно. Поэтому «отписка» — это не дизайн‑элемент, а юридический предохранитель: одна ссылка, один клик, без логина и без «введите пароль».

Перенос данных (data portability) — насколько применимо в РФ

В РФ нет прямого аналога обязанности portability из GDPR, но запросы пользователей на выгрузку данных становятся нормой. Практически это полезно и бизнесу: снижает конфликтность, упрощает поддержку и показывает зрелость privacy‑культуры.

Цифровые риски: от штрафа РКН до блокировки сервиса (Роскомнадзор и онлайн-сервисы)

Главные цифровые риски 2026 года:

• Утечки из‑за уязвимостей и ошибок в настройках доступа.

• Жалобы пользователей на навязчивую рекламу или невозможность удалить аккаунт.

• «Серые» интеграции трекеров, когда данные уходят третьим сторонам без корректного информирования.

• Юридические последствия по ст. 13.11 КоАП РФ, включая крупные штрафные вилки по отдельным составам.

История из практики:

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

Важно! В digital репутация ломается быстро: после утечки пользователи уходят «в один тап», а восстановление доверия занимает месяцы.

Чек‑лист для запуска и аудита интернет‑сервиса

Ниже — пошаговый план из 12 пунктов, который подходит стартапу и зрелой IT‑компании.

1. Опишите карту данных: что собираете, откуда, куда передаете, где храните, какие сроки.

2. Разделите основания по ст. 6 152‑ФЗ: договорные сценарии vs согласия (маркетинг/трекинг).

3. Проверьте выполнение ст. 18 152‑ФЗ: уведомления, прозрачность, работа с данными, полученными не от субъекта.

4. Проведите ревизию SDK и трекеров: кто получает данные, какие события уходят, есть ли возможность отключения.

5. Настройте cookie‑баннер: категории, отказ, настройки, хранение выбора, отзыв.

6. Разведите «сервисные» сообщения и «рекламные»; на рекламу соберите отдельное согласие и обеспечьте отписку.

7. Для мобильных: сверяйте пермишены с целями, запрашивайте доступ по месту, делайте альтернативы.

8. Для e‑commerce: определите, кто оператор платежных данных (агрегатор vs вы), и отразите это в документах и архитектуре.

9. Внедрите технический минимум: TLS, хэши паролей, сегментация, логи, мониторинг, обновления.

10. Сделайте UX прав субъектов: удалить аккаунт, отозвать согласия, запросить доступ/исправление.

11. Подготовьте инцидент‑план: кто реагирует на утечку, как фиксируете, как уведомляете пользователей и регулятора (по необходимости).

12. Проведите «privacy‑ревью» перед каждым крупным релизом: новые поля, новые интеграции, новые цели.

Тренды 2026: Privacy by Design, метавселенные и искусственный интеллект

Privacy by design становится конкурентным преимуществом: пользователи выбирают сервисы, где приватность встроена в продукт, а не «приклеена» политикой. Это означает: минимизация данных, выключенные по умолчанию рекламные трекеры, короткие сроки хранения, прозрачные настройки.

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

Заключение

Соблюдение 152‑ФЗ для интернет‑сервисов в 2026 году — это архитектура: правильно выбранные основания по ст. 6, прозрачный сбор по ст. 18, раздельные согласия на маркетинг и трекинг, и техническая защита, которая соответствует реальным угрозам. В новой цифровой реальности запуск сервиса без продуманной политики данных — это не «ускорение time‑to‑market», а прямые бизнес‑риски: штрафы, потери аудитории и блокировки интеграций. А зрелый privacy‑подход, наоборот, укрепляет доверие и повышает LTV — потому что пользователи начинают ценить не только удобство, но и уважение к приватности.