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

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

01 · Что считается персональными данными

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

  • Имя, телефон, email, адрес доставки.
  • История заказов и покупок, привязанная к человеку.
  • Геолокация, если по ней можно понять, где он живёт или работает.
  • Фото профиля и загруженные снимки.
  • Идентификаторы устройства в связке с аккаунтом.
Особые категории — отдельная история. Биометрия (лицо, отпечаток), данные о здоровье, вероисповедании. Для них нужно строгое отдельное согласие и усиленная защита. Если делаете приложение для клиники или используете распознавание лица — планируйте это с первого дня, а не «прикрутим потом».

02 · Сколько стоит ошибка

Штрафы пересмотрели 30 мая 2025 года, и это главная причина, почему тема поднялась в приоритетах бизнеса:

  • Обработка без согласия: для организаций 150–300 тыс ₽, при повторном нарушении 300–500 тыс ₽.
  • Утечка персональных данных: штрафы для организаций доходят до 15 млн ₽.
  • Сроки уведомлений: Роскомнадзор — в течение 24 часов с момента обнаружения, пострадавшие — в течение 10 дней.
Двадцать четыре часа — это техническое требование, а не юридическое. Уложиться в них можно только если в системе заранее есть журналы доступа: кто, когда и к каким данным обращался. Без них вы даже не поймёте, что именно утекло.

03 · Согласие: как это выглядит в интерфейсе

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

  1. Согласие в момент, когда данные реально нужны. На регистрации — на обработку, при первом заказе — на адрес, при подключении уведомлений — на них.
  2. Отдельная галочка на рекламную рассылку, по умолчанию снятая. Контакты, полученные при заказе, нельзя использовать для рекламы без отдельного согласия — это частая и дорогая ошибка.
  3. Ссылки на политику и условия — рядом, кликабельные, открываются внутри приложения.
  4. Факт согласия сохраняется в базе: кто, когда, какую версию текста принял. Иначе доказать согласие невозможно.
  5. Отзыв согласия и удаление аккаунта — доступны из приложения. Кстати, удаление аккаунта требует и Apple, так что это ещё и условие прохождения ревью — рядом с другими требованиями, о которых мы писали в разборе отказов App Store.

В проекте с картами лояльности мы отдельно делали реестр согласий в админке: владелец видит, кто и когда что подтвердил. Это ровно то, что спрашивают при проверке.

04 · Техническая сторона

  • Хранение в России. База с персональными данными российских пользователей должна находиться на серверах в РФ. Это влияет на выбор хостинга ещё до старта разработки.
  • Шифрование. Канал — по умолчанию; чувствительные поля — дополнительно в базе.
  • Разграничение прав. Менеджер видит своих клиентов, а не всю базу. Полный доступ — у единиц.
  • Журналы доступа. Кто и к чему обращался — база для расследования и для тех самых 24 часов.
  • Минимизация. Не собирайте то, что не используете. Каждое лишнее поле — это риск и обязанность его защищать.
  • Сроки хранения и удаление. Данные не должны лежать вечно «на всякий случай».

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

05 · Кто за что отвечает

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

Мы всегда проговариваем это на старте: подрядчик не может «сделать вам соответствие закону под ключ», он делает систему, которая позволяет ему соответствовать. Юридическую часть закрывает ваш юрист — и лучше на этапе технического задания, а не после релиза.

06 · Чек-лист перед релизом

  1. Выписаны все данные, которые собирает приложение, и обоснование для каждого поля.
  2. Согласия запрашиваются в момент необходимости; на рекламу — отдельная снятая галочка.
  3. Факт согласия сохраняется с датой и версией текста.
  4. Политика обработки данных опубликована и доступна из приложения и из стора.
  5. Есть удаление аккаунта и отзыв согласия.
  6. База — на серверах в России, доступы разграничены, журналы включены.
  7. Проверено, какие данные уходят во внешние сервисы.
  8. Роскомнадзор уведомлён, ответственный назначен (сторона заказчика).

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

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

Какие штрафы в 2026 году?
За обработку без согласия — 150–300 тыс ₽ для организаций, повторно 300–500 тыс ₽. За утечку — до 15 млн ₽. Размеры выросли с 30 мая 2025 года.

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

Что делать при утечке?
Уведомить Роскомнадзор за 24 часа, пострадавших — за 10 дней. Уложиться можно только при заранее включённых журналах доступа.

Что делает разработчик, а что заказчик?
Разработчик — техника: согласия, шифрование, права, журналы, хранение в РФ. Заказчик как оператор — политика, уведомление РКН, ответственный и регламенты.