ADG Оставить заявку
Блог Регуляторика 5 мин чтения

Оборотные штрафы за утечки ПДн: разбираем прецеденты лета 2025

Первые резонансные дела по оборотным штрафам в крупных компаниях - какие технические нарушения фигурируют в материалах и что это меняет в ИБ-аудите.

Контекст момента

Первые оборотные штрафы за утечки ПДн в крупных компаниях - прецедентные решения лета 2025

Летом 2025 пошли первые дела в отношении действительно крупных операторов - не малый бизнес с символическими суммами, а компании с выручкой в десятки миллиардов. Это принципиально другой разговор: когда оборотный штраф считается от оборота такого масштаба, юридическая абстракция превращается в конкретную строку в P&L. Мы в команде читали публичные материалы по этим делам - акты проверок, позиции сторон там, где они попали в открытый доступ, - и сделали несколько наблюдений, которые уже влияют на то, как мы строим ИБ-аудит у клиентов.

Какие дела имеем в виду

В открытом доступе - материалы нескольких дел, возбуждённых Роскомнадзором и дошедших до решения или хотя бы до публичной стадии разбирательства. Детали намеренно не конкретизируем: часть документов в обезличенном виде, часть - в пересказе профильных юридических изданий. Важно не «кто», а «за что именно».

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

Что фигурирует в технической части

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

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

Логи либо не вели, либо не хранили достаточно долго. Это повторяется в каждом деле. Компании не могли восстановить полную картину - кто обращался к базе, с каких адресов, в какой промежуток времени. Один из операторов представил логи за последние 7 дней: выяснилось, что утечка, судя по всему, произошла за 3 недели до обнаружения. Логов за этот период не было. Это сразу два нарушения: и невозможность расследования, и фактически принятое решение не хранить доказательную базу.

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

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

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

Что это меняет в нашей работе

Раньше в аудите ИБ мы могли услышать от клиента что-то вроде «у нас всё логируется, просто хранится 30 дней - этого же достаточно». Теперь у нас есть конкретный прецедент, где этого оказалось недостаточно. Это другой разговор.

Несколько вещей, которые мы сейчас проверяем отдельно и жёстче:

  • Срок и полнота хранения журналов - не «логи есть», а что именно пишется, откуда собирается, сколько хранится и доступно ли это для расследования спустя месяц-другой.
  • Сетевая изоляция хранилищ ПДн - сегрегация не только на уровне firewall-правил, но и в части того, кто имеет сетевой путь до базы.
  • Ролевая модель в СУБД - права на уровне схем и таблиц, а не только на уровне приложения.
  • Реестр поручений обработки - у большинства клиентов он либо неполный, либо не обновляется при смене вендоров и инструментов.
  • Техническая состоятельность обезличивания - если компания заявляет о псевдоанонимизации, смотрим на конкретный метод: обратимый или нет, есть ли ключ, где он хранится.

Мы также писали про первые судебные прецеденты в начале июля: там акцент был на процессуальной стороне. Здесь - на технической. Две стороны одной истории.

Что пока неясно

Практика ещё не устоялась. Открытые вопросы, которые нас интересуют по мере появления новых решений:

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

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

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.