ФЗ о защите персональных данных: статистика нарушений и штрафов

Для IT-сервиса это не абстрактный регуляторный риск: одна ошибка в доступах, интеграции или хранении резервных копий может превратить внутренний инцидент в публичное раскрытие данных и административное дело.

С 30 мая 2025 года ответственность за утечки стала существенно жестче. В отдельных случаях штраф для юридического лица достигает 15 млн рублей, а при повторном нарушении может рассчитываться как доля годовой выручки — от 1% до 3%, но не менее 20 млн и не более 500 млн рублей. С 1 сентября того же года изменился и порядок оформления согласия на обработку персональных данных: его требуется отделять от договора, оферты и других документов. Для SaaS-компаний это означает, что комплаенс больше нельзя свести к публикации политики конфиденциальности и одной галочке при регистрации.

От фиксированной санкции к цене повторного инцидента

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

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

Поправки, внесенные Федеральным законом № 420-ФЗ от 30 ноября 2024 года, вступили в силу 30 мая 2025 года. Статья 13.11 КоАП РФ получила дифференцированные штрафы за утечки и оборотную санкцию за повторное нарушение. Размер ответственности зависит, в частности, от масштаба раскрытия данных и обстоятельств нарушения.

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

У закона есть и другие составы. За обработку персональных данных без правового основания для юридических лиц предусмотрен штраф от 150 тыс. до 300 тыс. рублей. Если обработка ведется без письменного согласия в случаях, когда оно требуется, диапазон составляет 300–700 тыс. рублей. Отсутствие опубликованной политики обработки персональных данных может повлечь штраф от 30 тыс. до 60 тыс. рублей.

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

Что показывают цифры утечек

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

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

Для облачной системы поверхность атаки распределена между несколькими компонентами. Данные могут проходить через веб-приложение, API, очередь сообщений, хранилище файлов, систему аналитики, резервную копию и панель поддержки. Уязвимость не обязательно находится в основном продукте. Избыточные права сервисной учетной записи, открытый бакет, тестовая база с продуктивными данными или неотозванный ключ интеграции способны обойти защиту пользовательского интерфейса.

При разборе инцидента полезно отделять три события:

1. Несанкционированный доступ. Злоумышленник или сотрудник получил возможность читать данные, которые не должен был видеть.

2. Извлечение или копирование. Данные покинули контролируемую среду либо были собраны в выгрузку.

3. Публикация или дальнейшее использование. Информация появилась в открытом доступе, была продана или применена для атак.

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

Статистика нарушений 152-ФЗ поэтому не сводится к счетчику утекших строк. Для оператора важны обнаруживаемость инцидента, способность определить затронутые системы и данные, а также доказуемость принятых мер. Если сервис не может установить, кто обращался к хранилищу и какие выгрузки создавались, технический долг превращается в проблему управления инцидентом.

Согласие больше нельзя прятать внутри оферты

С 1 сентября 2025 года вступили в силу поправки к части 1 статьи 9 152-ФЗ, внесенные законом № 156-ФЗ от 24 июня 2025 года. Согласие на обработку персональных данных должно оформляться отдельно от договора, оферты и других документов.

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

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

Практический разбор обычно начинается с карты потока данных:

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

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

Для комплаенса персональных данных в SaaS полезно вести версионируемый реестр целей и получателей. Не как презентацию для аудита, а как рабочую карту, которую можно сопоставить с API, настройками аналитики, схемой базы и правами доступа. Без этой связки компания видит только формальное согласие, но не полный маршрут данных.

Биометрия: высокая цена ошибки

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

Биометрические данные могут обрабатываться в системах контроля доступа, подтверждения личности или удаленной идентификации. Архитектурно это создает дополнительные точки отказа: исходное изображение, векторное представление, шаблон, ключи, сервис сопоставления и журналы запросов. Компрометация такого набора отличается от утечки пароля. Пароль можно сменить; биометрический признак пользователь не может заменить по тому же принципу.

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

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

Как снизить риск в SaaS без бумажного комплаенса

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

В первую очередь стоит проверить не наличие абстрактного набора защитных средств, а связку между данными и операциями:

1. Составить карту обработки. Зафиксировать категории данных, цели, системы, интеграции, места хранения и ответственные команды. Скрытые копии обычно обнаруживаются на стыках — в аналитике, экспортах и поддержке.

2. Сократить сбор. Если продуктовая функция не зависит от поля, его наличие увеличивает поверхность утечки без технической пользы. Минимизация снижает объем потенциально раскрываемой информации.

3. Разделить доступы. Сервисные учетные записи и сотрудники не должны получать универсальный доступ ко всем данным. Права стоит привязывать к задачам, а привилегированные операции — журналировать.

4. Управлять секретами и ключами. Ключ API в репозитории или бессрочный токен интеграции превращает компрометацию одного компонента в доступ к связанным системам. Секреты должны иметь ограниченный срок и область действия.

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

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

7. Подготовить расследование заранее. Определить, какие логи сохраняются, кто имеет к ним доступ и как команда устанавливает затронутые системы. В момент инцидента проектировать аудит поздно.

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

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

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