Закон о защите персональных данных: чек-лист проверки IT-сервиса
Штраф за нарушение требований локализации персональных данных в России составляет от 1 до 6 млн рублей.
Для IT-сервиса это не только вопрос выбора хостинга: данные могут уходить за пределы страны через аналитику, SDK мобильного приложения, скрипты на сайте и инфраструктуру подрядчиков.
Проверка соответствия требованиям 152-ФЗ начинается с карты потоков данных. Нужно установить, какие сведения собирает продукт, где хранит их, кому передаёт и на каком основании. Баннер cookie и галочка в форме эту работу не заменяют.
1. Локализация инфраструктуры: где физически хранятся данные
Федеральный закон № 152-ФЗ от 27 июля 2006 года требует размещать базы персональных данных российских пользователей на серверах в России. Важно не только место основного сервера. Персональные данные могут копироваться в резервные хранилища, систему мониторинга, службу поддержки или аналитическую платформу. Каждая такая копия расширяет поверхность риска.
Для облачного приложения недостаточно знать название провайдера и регион, выбранный в панели управления. Нужно понимать, где фактически хранятся рабочие базы и резервные копии, кто имеет административный доступ и какие дочерние сервисы задействованы в обработке. Если поставщик не раскрывает архитектуру, оператор не получает подтверждения локализации — он получает только обещание.
При аудите хранения данных пользователей в цифровом сервисе следует пройти цепочку от точки сбора до удаления:
- определить, какие поля формы, профиля и приложения относятся к персональным данным;
- установить, в каких базах, логах, бэкапах и системах поддержки они сохраняются;
- проверить физическое размещение первичной базы и копий;
- зафиксировать подрядчиков, которым доступны данные, и их роль в обработке;
- проверить, как выполняются удаление и ограничение доступа после закрытия аккаунта.
Провайдер может хранить базу в российском регионе, но отправлять диагностические события в зарубежный сервис. Это не делает локализацию автоматической. Архитектуру нужно рассматривать целиком, включая маршруты телеметрии и резервирования.
Локализация — свойство всей цепочки хранения, а не отметка о регионе в настройках облака.
Нарушение требований локализации влечёт штраф от 1 до 6 млн рублей по части 8 статьи 13.11 КоАП РФ. Для оценки риска критично не просто найти сервер, а установить, какие данные на него попадают и куда они затем копируются.
2. Согласие и политика: что видит пользователь
Правовая архитектура начинается до отправки формы. Если сервис собирает персональные данные, пользователь должен понимать, кто их обрабатывает, для каких целей и на каком основании. Согласие нельзя считать полученным только потому, что нужный текст спрятан в политике или поле уже отмечено при открытии страницы.
Чекбокс согласия не должен быть включён по умолчанию. Пользователь совершает отдельное активное действие; рядом должна быть доступна ссылка на политику конфиденциальности. Но такая конструкция сама по себе не гарантирует соответствия закону. Содержание согласия и документа должно совпадать с реальным поведением продукта.
Проверка должна сопоставить интерфейс с серверной логикой:
1. Форма сбора. Какие поля обязательны, какие необязательны, и можно ли выполнить целевое действие без избыточных сведений.
2. Текст согласия. Для каких целей собираются данные и какие операции с ними выполняются.
3. Политика конфиденциальности. Совпадают ли описанные процессы с фактическими базами, подрядчиками и сроками хранения.
4. Запись согласия. Может ли система подтвердить факт и момент активного действия пользователя.
5. Отзыв и удаление. Есть ли рабочий процесс обработки запроса, а не только контактный адрес в документе.
Отдельно нужно проверить мобильное приложение. Веб-форма может показывать ссылку на политику, а экран регистрации в приложении — собирать те же данные без сопоставимого объяснения. Аналогичная проблема возникает, когда SDK запускает сбор идентификаторов устройства раньше, чем пользователь проходит экран согласия.
Отсутствие согласия на обработку персональных данных для юридического лица может повлечь штраф от 300 тыс. до 700 тыс. рублей по части 2 статьи 13.11 КоАП РФ. Однако аудит не сводится к поиску чекбокса. Система должна собирать только то, что заявлено, и использовать это в заявленных целях.
3. Уведомление Роскомнадзора и реестр операторов
Оператор персональных данных должен уведомить Роскомнадзор о начале обработки до того, как начнёт сбор, если не действует одно из предусмотренных законом исключений. После уведомления сведения об операторе вносятся в реестр. Для IT-команды это не внешний юридический ритуал: описание обработки в уведомлении должно соответствовать реальной архитектуре продукта.
Если сервис добавил новую функцию, подключил подрядчика или начал собирать дополнительные категории данных, первоначальное описание может перестать отражать фактический процесс. Поэтому реестр и внутреннюю карту данных нужно сверять при существенных изменениях продукта, а не только при запуске.
Практический контроль можно встроить в релизный процесс. Перед выпуском новой формы, SDK или интеграции команда фиксирует:
- какие новые сведения появляются в системе;
- какая цель обработки заявлена;
- какой компонент принимает и хранит данные;
- получает ли к ним доступ подрядчик;
- требуется ли обновить документы и сведения об операторе.
Такой процесс особенно важен для SaaS, где продукт меняется постепенно. Новое поле профиля или модуль поддержки может добавить обработку, которой нет в старой политике и учётной документации. Расхождение между документами и логами не исправляется одной правкой текста: нужно привести в соответствие и интерфейс, и серверную обработку, и учёт оператора.
4. Зарубежная аналитика, cookie и трансграничная передача
Внешняя аналитика часто подключается как короткий скрипт или библиотека. После загрузки она может получать IP-адрес, идентификаторы, сведения о браузере и события внутри приложения. Поэтому оценивать нужно не название инструмента, а конкретный состав передаваемых данных, направление передачи и правовое основание.
Использование зарубежной аналитики без соблюдения требований к трансграничной передаче данных и без необходимого согласия может нарушать правила обработки. При этом отключить один счётчик недостаточно, если в продукте остаются сторонние скрипты, SDK или пиксели, выполняющие сходную функцию.
Для аудита полезно собрать реестр всех внешних компонентов:
| Компонент | Что проверить | Типичный источник риска |
|---|---|---|
| Веб-аналитика | Какие события и идентификаторы отправляются, куда и при каком согласии | Передача данных за рубеж через тег или скрипт |
| SDK мобильного приложения | Какие сведения собираются до и после согласия | Скрытая телеметрия и идентификаторы устройства |
| Сервисы поддержки | Какие данные видны оператору и где хранится переписка | Передача профиля и обращений подрядчику |
| Cookie и пиксели | Какие файлы устанавливаются и для каких целей | Сбор данных до уведомления пользователя |
| Системы мониторинга | Попадают ли персональные данные в диагностические логи | Избыточное копирование сведений в журналы |
На веб-ресурсе должно быть уведомление о сборе cookie и отдельное описание правил их обработки. Сам баннер не решает вопрос законности передачи данных стороннему сервису. Он только часть интерфейса; фактические сетевые запросы нужно проверять отдельно.
В мобильном сегменте аудит безопасности данных связан и с устройством, на котором работает продукт. Обновления операционной системы и характеристики чипсета влияют на доступные механизмы защиты, но не заменяют контроль самого приложения. При оценке платформы полезно отдельно изучить новые мобильные чипы Snapdragon 8 Elite — аппаратные функции не отвечают на вопрос, какие данные приложение отправляет на сервер.
Проверка сетевого поведения должна установить, какие домены вызываются при запуске, регистрации и использовании ключевых функций. Затем эти запросы сопоставляют с политикой, согласием и перечнем обработчиков. Если приложение отправляет событие до активного согласия, интерфейсная настройка не устраняет уже возникшую передачу.
5. Ответственность после 30 мая 2025 года
Новые нормы административной ответственности по статье 13.11 КоАП РФ вступили в силу 30 мая 2025 года. Изменения повышают цену ошибок в обработке персональных данных. Для оператора это аргумент пересмотреть не только документы, но и фактическую конфигурацию продукта: базы, интеграции, формы сбора и правила доступа.
В фактуре аудита зафиксирован срок в 10 дней для выполнения предписания Роскомнадзора об устранении нарушений. Это короткий интервал для сервиса, где неизвестно, какие компоненты передают данные и кто отвечает за сторонние интеграции. Чем позже компания строит карту потоков, тем сложнее локализовать проблему в срок.
Рабочая последовательность проверки выглядит так:
1. Инвентаризировать формы, базы, резервные копии, SDK, скрипты и подрядчиков.
2. Сопоставить реальное движение данных с политикой, согласиями и сведениями оператора.
3. Проверить локализацию первичной базы и маршруты копирования.
4. Отключить или перенастроить компоненты, передающие данные без необходимого основания.
5. Зафиксировать технические изменения и назначить владельца повторной проверки.
Это не сертификация и не гарантия отсутствия претензий. Для конкретной архитектуры могут потребоваться отдельная правовая оценка и технический аудит мер защиты. Но базовая инвентаризация быстро выявляет участки, где продукт собирает больше, чем описывает, или передаёт сведения туда, куда команда не смотрит.
Закон о защите персональных данных применяется не к документу на сайте, а к обработке как к техническому процессу. Если владелец сервиса не может показать, где находятся данные, какие компоненты их получают и на каком основании, соответствие 152-ФЗ остаётся неподтверждённым. Исправлять нужно поток данных. Формулировки в политике следуют за ним, а не наоборот.