Оборотные штрафы за утечки ПДн: разбираем прецеденты лета 2025
Первые резонансные дела по оборотным штрафам в крупных компаниях - какие технические нарушения фигурируют в материалах и что это меняет в ИБ-аудите.
Первые оборотные штрафы за утечки ПДн в крупных компаниях - прецедентные решения лета 2025
Летом 2025 пошли первые дела в отношении действительно крупных операторов - не малый бизнес с символическими суммами, а компании с выручкой в десятки миллиардов. Это принципиально другой разговор: когда оборотный штраф считается от оборота такого масштаба, юридическая абстракция превращается в конкретную строку в P&L. Мы в команде читали публичные материалы по этим делам - акты проверок, позиции сторон там, где они попали в открытый доступ, - и сделали несколько наблюдений, которые уже влияют на то, как мы строим ИБ-аудит у клиентов.
Какие дела имеем в виду
В открытом доступе - материалы нескольких дел, возбуждённых Роскомнадзором и дошедших до решения или хотя бы до публичной стадии разбирательства. Детали намеренно не конкретизируем: часть документов в обезличенном виде, часть - в пересказе профильных юридических изданий. Важно не «кто», а «за что именно».
Общее между делами - утечка данных клиентов либо сотрудников в значимом объёме, проверка РКН, зафиксированные нарушения технического и организационного характера, возбуждение дела об административном правонарушении по статьям, предусматривающим оборотный штраф.
Что фигурирует в технической части
Это самое интересное. В материалах проверок регулятор описывает конкретные технические факты, которые стали основанием для квалификации нарушения. Паттерны повторяются.
Отсутствие сегрегации баз с ПДн от других систем. В нескольких случаях база с персональными данными клиентов находилась в той же VLAN или на том же хосте, что и системы без чувствительных данных. Компрометация смежного компонента дала доступ ко всей базе. Регулятор прямо указывает на это как на нарушение требований к защите - отсутствие технических мер, ограничивающих распространение данных при инциденте.
Логи либо не вели, либо не хранили достаточно долго. Это повторяется в каждом деле. Компании не могли восстановить полную картину - кто обращался к базе, с каких адресов, в какой промежуток времени. Один из операторов представил логи за последние 7 дней: выяснилось, что утечка, судя по всему, произошла за 3 недели до обнаружения. Логов за этот период не было. Это сразу два нарушения: и невозможность расследования, и фактически принятое решение не хранить доказательную базу.
Доступ к ПДн без ролевой модели. В одном из дел около двух десятков сотрудников имели широкий доступ к таблицам с данными клиентов - включая тех, чьи функции вообще не предполагали работы с ними. Принцип минимальных привилегий в базе данных не реализован. Регулятор трактует это как отсутствие «организационных и технических мер по ограничению доступа».
Передача ПДн третьей стороне без надлежащего поручения. Один из кейсов - данные уходили в аналитический инструмент SaaS-вендора. Договора с поручением обработки, соответствующего 152-ФЗ, не было. Вендор - иностранный, данные физически оказались вне российской юрисдикции. Это отдельный состав поверх основного нарушения.
Псевдоанонимизация вместо реальной. Любопытный технический момент: в одном деле компания заявляла, что данные были «обезличены». При разборе оказалось, что использовалась обратимая замена идентификатора на другой - то есть при наличии таблицы соответствия данные тривиально деанонимизируются. Регулятор не принял это как меру защиты.
Что это меняет в нашей работе
Раньше в аудите ИБ мы могли услышать от клиента что-то вроде «у нас всё логируется, просто хранится 30 дней - этого же достаточно». Теперь у нас есть конкретный прецедент, где этого оказалось недостаточно. Это другой разговор.
Несколько вещей, которые мы сейчас проверяем отдельно и жёстче:
- Срок и полнота хранения журналов - не «логи есть», а что именно пишется, откуда собирается, сколько хранится и доступно ли это для расследования спустя месяц-другой.
- Сетевая изоляция хранилищ ПДн - сегрегация не только на уровне firewall-правил, но и в части того, кто имеет сетевой путь до базы.
- Ролевая модель в СУБД - права на уровне схем и таблиц, а не только на уровне приложения.
- Реестр поручений обработки - у большинства клиентов он либо неполный, либо не обновляется при смене вендоров и инструментов.
- Техническая состоятельность обезличивания - если компания заявляет о псевдоанонимизации, смотрим на конкретный метод: обратимый или нет, есть ли ключ, где он хранится.
Мы также писали про первые судебные прецеденты в начале июля: там акцент был на процессуальной стороне. Здесь - на технической. Две стороны одной истории.
Что пока неясно
Практика ещё не устоялась. Открытые вопросы, которые нас интересуют по мере появления новых решений:
- Как регулятор считает оборот в холдинговых структурах, где оператор ПДн - дочерняя компания с небольшой выручкой, а данные фактически принадлежат группе.
- Какой вес имеет добровольное раскрытие и полнота уведомления при определении размера штрафа у крупных операторов - у малых компаний смягчение работало, масштабируется ли это.
- Как квалифицируются цепочки подрядчиков: если SaaS-вендор передал данные субподрядчику - где заканчивается ответственность оператора.
Следим за публичными материалами и обновляем методику по мере появления новых решений. Пока картина такая: технические нарушения, которые фигурируют в прецедентных делах, - это не экзотика, это стандартный набор пробелов, который мы находим на каждом третьем-четвёртом аудите. Разница теперь в том, что цена этих пробелов стала вполне конкретной.