Утечки персональных данных в 2026 году: ответственность, оборотные штрафы и как снизить регуляторные риски

В одном из недавних дел апелляционный суд отменил штраф в 150 тысяч рублей, назначенный крупной компании после обнаружения базы сотрудников в открытом Телеграм-канале. Объем утечки превышал 17 миллионов строк.

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

Этот кейс важен потому, что совпал с ужесточением законодательства. В 2024—2025 годах вступили в силу поправки к КоАП и УК РФ (420-ФЗ и 421-ФЗ). Они ввели оборотные штрафы при повторных утечках и уголовную ответственность за незаконные действия с персональными данными.

Санкции стали жестче, но вместе с этим изменился и фокус. Теперь для регулятора недостаточно самого факта утечки. Вопрос в том, может ли компания показать, что у нее были внедрены обязательные меры защиты и что система реально работала.

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

В 2026 году при оценке утечки регулятор анализирует не только сам инцидент, но и действия компании до и после него. На практике ответственность усиливается в трех типовых ситуациях.

Компания нарушает порядок реагирования на инцидент

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

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

Ошибка здесь не в самом факте утечки, а в отсутствии четкого и соблюдаемого алгоритма эскалации.

Компания не может подтвердить, что меры защиты действительно применялись

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

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

Риск здесь возникает, когда документы не отражают реальную практику.

Компания не изменила процессы после первого инцидента

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

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

В таких случаях инцидент воспринимается как системная проблема.

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

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

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

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

Дополнительно сохраняется персональная ответственность должностных лиц за нарушения порядка реагирования и уведомления.

Таким образом, в одном инциденте могут сочетаться несколько факторов риска:

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

Повторный инцидент при отсутствии изменений в процессах значительно увеличивает финансовые риски.

Если начинается проверка, компании потребуется подтвердить конкретные элементы контроля.

Матрица ролей и доступов

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

Если матрица формальна или не обновляется, риск квалификации защиты как недостаточной возрастает.

Регулярный пересмотр прав доступа

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

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

Журналирование массовых операций и нетипичного доступа

Компания должна фиксировать массовые выгрузки, обращения к данным вне своей роли, нетипичное время доступа или резкий рост объема скачиваний. Эти события должны не только записываться, но и анализироваться.

Если такие события не фиксируются или не анализируются, доказать контроль над обработкой данных сложно.

Регламент эскалации инцидентов

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

Если алгоритм существует только на бумаге, ответственность усиливается за счет нарушения порядка реагирования.

Подтверждение обучения и тестирования сотрудников

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

Если такие мероприятия не проводились или не документированы, это ослабляет позицию оператора.

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

Ниже — четыре типовых действия, которые чаще всего приводят к инцидентам.

Сотрудник отправляет данные не тому адресату

В 2024 году британская полиция Уилтшира раскрыла данные более тысячи сотрудников после ошибочной рассылки файла не тому получателю. Инцидент произошел из-за неверно выбранного адресата при отправке электронной почты. Файл содержал персональные данные сотрудников.

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

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

Риск возникает в момент нажатия «Отправить».

Если в компании нет правила обязательной проверки получателя при передаче персональных данных, вероятность такой ошибки остается высокой.

Сотрудник вводит пароль на фишинговом сайте

В 2024 году атаке через фишинг подверглась компания MGM Resorts. Злоумышленники получили доступ к системам после того, как сотрудник службы поддержки прошел процедуру сброса доступа по поддельному запросу. Инцидент привел к остановке систем и утечке клиентских данных.

Атака началась с того, что сотрудник изменил параметры доступа после телефонного запроса без независимой проверки личности.

Риск возникает в момент, когда сотрудник доверяет запросу и меняет настройки доступа.

Чтобы снизить вероятность такого сценария, компания должна внедрить независимый канал подтверждения личности и запретить изменение доступа без двойной проверки.

Сотрудник выдает подрядчику доступ без ограничений

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

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

Точка риска — это решение выдать права без ограничения по сроку и роли. Чтобы не накапливать этот скрытый риск, доступ подрядчика должен быть привязан к конкретной задаче, сроку и объему данных. И пересматриваться регулярно, а не только после инцидента.

Сотрудник передает данные по запросу без проверки контекста

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

Инциденты такого типа происходят ежегодно и приводят к утечке персональных данных и финансовым потерям.

Риск возникает в момент, когда сотрудник принимает решение на основе срочности или авторитета, не сверяя запрос с внутренним процессом.

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

Утечка персональных данных чаще всего начинается не с технического сбоя, а с решения человека.

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

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

Закрепить независимый канал подтверждения

Любой запрос на передачу персональных данных или изменение доступа необходимо подтверждать через отдельный канал.

Если запрос поступил по почте — подтвердить его через систему заявок. Если поступил телефонный запрос — сверить данные через внутреннюю карточку сотрудника или клиента.

Сотрудник не должен принимать решение на основе одного источника. Наличие независимого канала снижает риск социальной инженерии и ошибочного подтверждения.

Ограничить доступы по сроку и роли

Доступ к персональным данным следует выдавать в рамках конкретной должностной роли и на определенный срок.

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

Проверять и подтверждать права доступа сотрудников

Даже корректно выданные доступы со временем становятся избыточными.

Компания должна закрепить периодический пересмотр прав доступа: например, раз в квартал или раз в полгода.

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

Вести журналирование и контролировать массовые операции

Компания должна понимать, что происходит с персональными данными внутри системы.

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

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

Вести реестр операций обработки персональных данных

Компания должна понимать, какие персональные данные она обрабатывает, где они хранятся, кто имеет к ним доступ и каков срок хранения.

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

Также в реестре фиксируется основание обработки и порядок удаления данных после истечения срока хранения.

Тренировать сотрудников с помощью имитированных атак и измерять результат

Если риск возникает в момент действия сотрудника, обучение должно быть привязано именно к этим действиям.

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

Важно не только провести обучение, но и измерять результат:

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

Без измеримости обучение остается формальностью и не влияет на уровень риска.

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

На платформе Start AWR обучение строится на реальных сценариях работы с персональными данными: сотрудники проходят интерактивные курсы и тренируются на имитированных атаках, чтобы отрабатывать правильные действия в момент принятия решения. 

Запишитесь на бесплатное демо, и наш эксперт расскажет, как Start AWR поможет вашей компании сделать риск утечек управляемым.

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

Шаг 1. Зафиксировать инцидент

Сотрудник должен немедленно передать информацию по установленному каналу эскалации.

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

Если сообщение не передано вовремя, компания рискует нарушить срок уведомления регулятора.

Шаг 2. Ограничить распространение данных

На этом этапе важно локализовать инцидент.

Необходимо:
• заблокировать скомпрометированную учетную запись;
• отозвать временные или избыточные права доступа;
• при необходимости отключить внешние интеграции;
• остановить массовую выгрузку данных.

Цель — предотвратить дальнейшее распространение информации.

Шаг 3. Оценить масштаб утечки

Компания должна определить:
• сколько субъектов персональных данных затронуто;
• какие категории данных раскрыты;
• есть ли среди них специальные категории или биометрические данные;
• продолжается ли доступ третьих лиц к информации.

Эта оценка влияет на порядок уведомления и потенциальный размер санкций.

Шаг 4. Подготовить уведомление регулятора

Если инцидент подпадает под требования закона, необходимо уведомить Роскомнадзор в установленный срок.

Уведомление должно содержать:
• описание характера утечки;
• предварительную оценку объема затронутых данных;
• меры по локализации инцидента;
• контактное лицо для взаимодействия.

При необходимости уведомляются и субъекты персональных данных.

Шаг 5. Устранить причину инцидента

После локализации важно изменить процесс, который привел к утечке.

Необходимо:
• пересмотреть права доступа;
• скорректировать алгоритм подтверждения запросов;
• обновить регламент реагирования;
• провести внеплановое обучение сотрудников.

Если причина не устранена, повторный инцидент может привести к более строгой ответственности.

Утечка персональных данных — это не только технический инцидент. Это проверка того, насколько в компании выстроены процессы реагирования.

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