Утечки персональных данных: что делать в первые 24 часа

Что считается «утечкой ПД» по новой редакции 152-ФЗ

До 266-ФЗ операторы спорили с РКН по каждому инциденту: считать утечкой или нет. Сейчас спор закрыт. Под утечкой понимается любое событие, при котором персональные данные стали доступны лицам, не имеющим на это правового основания. Способ — не важен. Объём — не важен. Сознательность — не важна.

По факту я делю инциденты на четыре типа.

Несанкционированный доступ. Кто-то получил доступ к вашей БД, файловому хранилищу, админ-панели. Чаще всего — через украденные учётки сотрудника, уязвимость в самописном коде, скомпрометированный VPN или открытый порт MySQL/PostgreSQL без пароля. Классика жанра 2024-2026 — забытый бэкап на публичном S3-бакете без авторизации.

На прошлой неделе я разбирал кейс — у клиента утекла база на 50 тысяч email через старый бэкап, забытый на публичном S3. Они узнали через Telegram-канал «Утечки информации» — через 6 часов после публикации. РКН узнал через 3 часа после клиента. Уложиться в 24-часовой дедлайн получилось, но если бы не действовали сразу — был бы оборотный штраф.

Публикация в открытом доступе. Данные попали в публичные каналы: GitHub-репозиторий с production-конфигами, открытый Google Doc по ссылке, паблик в соцсетях, телеграм-канал «слитого». Источник может быть случайным (сотрудник запушил .env в публичный репо) или умышленным (бывший разработчик слил из обиды).

В моём опыте — три раза за два года клиенты ловили утечку через GitHub. Разработчик коммитил .env с production-учётками, репо был public, через 20 минут уже сканировали боты. Решение — pre-commit hook на проверку .env, обязательный gitleaks в CI и регулярный аудит публичных репо организации.

Продажа в даркнете. Атакующий уже скачал базу и выставил на продажу на форумах вроде RaidForums (закрыт) или их преемников. Обычно об этом узнают через сервисы мониторинга утечек — Group-IB, Bi.Zone, DLBI или открытые источники типа Have I Been Pwned. С точки зрения 152-ФЗ это полноценная утечка, неважно — продали или нет.

Потеря физического носителя. Украли ноутбук с незашифрованным диском, потерян USB-носитель с базой клиентов, сотрудник забыл документы в такси. По букве закона — это утечка с момента факта потери, даже если потом носитель нашёлся. Если диск был зашифрован полным шифрованием (BitLocker, FileVault, LUKS) и парольная фраза не скомпрометирована — РКН может зачесть это как «инцидент без утечки», но уведомлять всё равно надо.

Кто ОБЯЗАН уведомлять РКН

Все операторы персональных данных. Без исключений. Если вы хоть как-то обрабатываете ПД — вы обязаны уведомить РКН об утечке. Не важно, ИП вы или ООО, есть у вас уведомление в реестре или нет, миллион клиентов или один.

Здесь часто путают: «мы не зарегистрированы как оператор, значит не обязаны». Это в корне неверно. Обязанность операторской деятельности возникает в момент начала обработки ПД, а не в момент подачи уведомления в реестр. Если вы не подали уведомление — это отдельное нарушение (ст. 19.7 КоАП), но обязанность уведомлять об утечке от этого не исчезает.

Чаще всего «забывают про себя» три типа операторов.

Самозанятые с лендингом. Форма обратной связи на сайте + рассылка через UniSender — вы оператор ПД. При утечке базы рассылки — уведомление РКН в 24 часа. Самозанятость не освобождает.

Малые ИП без сайта. Принимаете заказы через WhatsApp, ведёте клиентскую базу в Google Sheets — вы оператор. Утечка таблицы (например, расшарили по ошибке) — уведомление РКН.

Подрядчики и фрилансеры. Разрабатываете сайты на заказ, имеете доступ к ПД заказчика — вы либо обработчик (если есть договор), либо тоже оператор. При утечке — уведомление РКН и информирование заказчика немедленно. Заказчик в этом случае уведомляет РКН от своего имени.

Подробности по подаче самого уведомления в реестр писал в отдельной статье — там пошаговый разбор формы на pd.rkn.gov.ru.

Первые 60 минут после обнаружения

Это самые важные минуты. От ваших действий здесь зависит, будет ли у вас доказательная база для общения с РКН и насколько быстро вы остановите ущерб. План — по минутам.

0-5 минут. Зафиксировать факт. Сделайте скриншот того, что вы увидели (публикация в Telegram, письмо от хакера, сообщение системы мониторинга, входящий звонок от клиента, который нашёл свои данные в паблике). Сохраните дату и время — это станет точкой отсчёта для 24-часового дедлайна. Если данные пришли по email — сохраните весь thread с заголовками.

5-15 минут. Остановить дальнейшую утечку. Это первый приоритет, важнее всего остального. Если данные продолжают вытекать прямо сейчас (открытый S3-бакет, публичный GitHub-репо, скомпрометированный API-ключ) — закрыть немедленно. Не «сначала зафиксируем, потом закроем» — закрываем сразу, фиксацию делаем параллельно.

Конкретные действия зависят от типа инцидента:

• Открытый S3/Selectel-bucket → политика на private, ротация ключей доступа;
• Утечка через украденный пароль сотрудника → блокировка учётки, принудительный logout, сброс паролей всем с тем же уровнем доступа;
• API-ключ в публичном репо → revoke ключа, ротация всех связанных секретов;
• Скомпрометированный VPN → отключение, ротация сертификатов, force re-auth всем;
• Заражённый сервер → изолировать от сети, но НЕ выключать (потеряете volatile-память).

15-30 минут. Сохранить улики. До того как «чинить» дальше — снимите образ. Это критично для последующего расследования и общения с РКН. Минимум:

# Дамп логов nginx/access за последние 30 дней
sudo cp -r /var/log/nginx /backup/incident-${INCIDENT_ID}/nginx-logs/

# Системные логи
sudo journalctl --since "30 days ago" > /backup/incident-${INCIDENT_ID}/journal.log

# Auth-логи (попытки входа)
sudo cp /var/log/auth.log* /backup/incident-${INCIDENT_ID}/

# Список активных соединений на момент инцидента
sudo netstat -tnp > /backup/incident-${INCIDENT_ID}/connections.txt
sudo ss -tnp >> /backup/incident-${INCIDENT_ID}/connections.txt

# Хэши важных файлов до изменений
sudo find /var/www -type f -exec sha256sum {} \; > /backup/incident-${INCIDENT_ID}/file-hashes.txt

# Снапшот процессов
sudo ps auxf > /backup/incident-${INCIDENT_ID}/processes.txt

# Дамп БД (если не сделан недавно)
sudo -u postgres pg_dump -Fc maindb > /backup/incident-${INCIDENT_ID}/db.dump

# Архивируем всё с подписью времени
tar -czf /backup/incident-${INCIDENT_ID}.tar.gz /backup/incident-${INCIDENT_ID}/
sha256sum /backup/incident-${INCIDENT_ID}.tar.gz > /backup/incident-${INCIDENT_ID}.sha256

Эти артефакты потом понадобятся РКН и/или ФСТЭК. Хранить как минимум 3 года.

30-45 минут. Собрать команду. Уведомить ключевых людей: руководителя, юриста (внутреннего или внешнего), DPO (если есть), технического директора, безопасника. Создать отдельный канал в Telegram/Slack с явной пометкой «инцидент-${ID}» — вся переписка по инциденту идёт там, чтобы потом был timeline для регулятора. Никаких устных переговоров без фиксации — пишите всё.

45-60 минут. Открыть инцидент-журнал. Заведите файл (Google Doc, Notion, любой) — «Инцидент №N от даты». Структура: что произошло, когда обнаружено, кто обнаружил, какие данные затронуты (предварительно), какие действия предприняты, ответственные. Дальше каждое действие — туда же с тайм-стампом. Это станет основой для отчёта в РКН.

Первые 4 часа: собрать факты для уведомления

За первый час вы остановили утечку и зафиксировали факт. Следующие 3 часа — на сбор данных, которые понадобятся для уведомления РКН. Не растягивайте, время идёт.

Что именно утекло. Категории ПД (ФИО, email, телефон, адрес, паспорт, банковские реквизиты, данные о здоровье). Чем больше категорий — тем серьёзнее инцидент. Если утекли паспортные данные или биометрия — это специальные категории, штрафы выше.

Сколько субъектов пострадало. Точное число или диапазон. Если у вас БД на 50 000 строк и непонятно, какая часть утекла, — пишите «до 50 000». Завышать не нужно, но и занижать не пытайтесь — РКН любит сверять с реальностью при проверке.

Когда произошла утечка. Не «когда обнаружили», а «когда фактически могло начаться». По логам видно: если уязвимость открытая с понедельника, а вы обнаружили в пятницу — пишите «не позже понедельника». Если точно установить нельзя — пишите так и так и обосновывайте.

Как обнаружили. Внутренний мониторинг, обращение клиента, публикация в СМИ, уведомление сторонней службы мониторинга, обращение РКН (самый плохой вариант). От источника обнаружения зависит риторика в уведомлении.

Какие меры приняты. Конкретно: закрыли бакет в 10:23, ротировали ключи в 10:35, заблокировали скомпрометированную учётку в 10:41, сменили пароли всем сотрудникам с доступом в 11:15. Точные тайм-стампы. Не «приняли меры по устранению», а «сделали то-то и то-то».

Уведомление в РКН: 12-24 часа

Подаётся через личный кабинет оператора ПД на сайте РКН (rkn.gov.ru, раздел «Электронные сервисы» → «Уведомления об инцидентах»). Если у вас есть подтверждённая учётка из реестра операторов — заходите через неё. Если нет — нужна авторизация через Госуслуги юрлица/ИП. Физлица-операторы (самозанятые) — через подтверждённую учётку Госуслуг.

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

1. Реквизиты оператора. Подтянутся автоматически из учётки. Проверьте, что ИНН и юридический адрес актуальные.

2. Дата и время обнаружения инцидента. Точное (по логам), формат — DD.MM.YYYY HH:MM. Если узнали в 09:23, а реально это случилось в 03:15 — пишите 09:23 как «обнаружение», 03:15 — отдельно в описании как «дата фактического начала».

3. Дата и время фактической утечки. Из логов. Если установить точно нельзя — пишите диапазон («с 03.05.2026 по 05.05.2026») и обосновывайте.

4. Категории субъектов ПД. Клиенты, сотрудники, поставщики, посетители сайта — каждая категория отдельно.

5. Категории ПД. Базовые (ФИО, контакты), специальные (здоровье, политические взгляды), биометрические. Перечисляйте всё, что было.

6. Количество субъектов. Точное или максимально возможное.

7. Описание инцидента. Свободная форма, 2-5 абзацев. Что произошло, как обнаружили, какой был источник угрозы (внутренняя ошибка / внешняя атака / технический сбой / действия третьих лиц). Без эмоций, фактологично.

8. Принятые меры. Подробно. Это поле РКН читает внимательнее всего — оно определяет, нужно ли назначать проверку.

9. Сведения о ходе расследования. На какой стадии находитесь, что планируете дальше, кто проводит технический аудит.

10. Сведения об уведомлении субъектов ПД. Если уже разосланы — приложите шаблон письма. Если ещё нет — укажите планируемые сроки и канал (email/СМС/звонок).

11. Контактное лицо. ФИО, должность, телефон, email — кто отвечает за инцидент. По этому контакту с вами будет связываться РКН.

Уведомление субъектов ПД: 72 часа

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

На практике — если утекли только email и имена, ущерб маловероятен (максимум — больше спама), уведомление желательно но не обязательно. Если утекли паспортные данные, банковские реквизиты, пароли — уведомление обязательно.

Как уведомлять. Канал — тот же, что использовался для связи с клиентом: email если общались по email, СМС если по СМС, личное сообщение в приложении если есть. Звонком — только в крайних случаях, плохо масштабируется и нет следа.

Что писать. Минимально:

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

Чего НЕ говорить: «ничего страшного», «риски минимальные», «вам ничего не угрожает». Это юридически рискованно — если потом окажется, что ущерб был, вы создали ложное впечатление. Лучше «мы оцениваем риски и информируем вас о ситуации».

Тон. Прямой, не извиняющийся, не паникёрский. Не «нижайше извиняемся за доставленные неудобства», а «произошла утечка, вот факты, вот что мы сделали, вот что рекомендуем вам». Профессионально.

Расследование и взаимодействие с РКН

После приёма уведомления РКН формирует ответ в течение 3-5 рабочих дней. Может пойти двумя путями.

Путь 1: запрос дополнительной информации. РКН пишет, что нужны такие-то документы (политика обработки ПД, договоры с обработчиками, акты технического расследования, доказательства принятых мер). На ответ даётся 5-10 дней. Отвечать обязательно — игнорирование увеличивает штраф и инициирует проверку.

Что обычно просят:

• Политика обработки ПД, действовавшая на момент инцидента;
• Согласия субъектов на обработку ПД (выборка по утекшим);
• Договоры с обработчиками, имевшими доступ к утекшим данным;
• Внутренние документы по безопасности (положение о доступах, инструкции);
• Технический отчёт о расследовании.

Путь 2: внеплановая проверка. Если инцидент серьёзный (более 1000 субъектов или утечка специальных категорий ПД) — РКН инициирует проверку. Уведомление приходит за 24 часа, длится 5-10 рабочих дней. По итогу — акт проверки с выявленными нарушениями и предписанием на устранение. По акту назначается штраф.

В моём опыте — если на этапе уведомления оператор сразу даёт полную картину, показывает реальные меры и не пытается «замять» — РКН чаще ограничивается перепиской без выезда. Если что-то скрывают или дают противоречивую информацию — едут.

Технический контракт-аудит

Параллельно с РКН надо разобраться, что именно произошло технически. Это нужно для двух целей: (1) предотвратить повторение, (2) дать РКН внятный отчёт о причинах.

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

Кто делает. Если у вас есть штатный безопасник или DevSecOps — он. Если нет — нанимайте внешнюю команду по форензике: Group-IB, Bi.Zone, Positive Technologies, F.A.C.C.T. Стоит от 300 тыс ₽ за быстрое расследование до 2-3 млн ₽ за глубокое с экспертизой. Это деньги, но РКН любит видеть в уведомлении строчку «технический аудит провели такие-то с лицензией ФСТЭК».

Срок — 1-4 недели. Результат — отчёт с восстановленным таймлайном, вектором атаки, scope утечки и рекомендациями. Этот отчёт прикладываете к ответу на запрос РКН.

Штрафы и оборотные санкции 2026

30 мая 2025 года вступила в силу новая редакция ст. 13.11 КоАП РФ. Штрафы выросли в десятки раз, появились оборотные санкции. Картина по 2026:

Реальные кейсы 2024-2026 (без названий компаний — обобщённо по открытым данным):

• Крупный сервис доставки еды: утечка 6,8 млн строк (имена, телефоны, адреса). Штраф около 60 тыс ₽ (по старой редакции 2022 года). Если бы это случилось в 2026 — был бы оборотный, до сотен миллионов.
• Крупный логист (СДЭК-уровня): утечка 5,6 млн строк. Штраф 100 тыс ₽ (старая редакция). По новой — порядок десятков миллионов плюс возможный оборотный за повторность.
• Медицинская сеть: утечка медицинских данных 31 млн пациентов. Штраф 60 тыс ₽ (старая). По новой за специальные категории ПД и масштаб — 15-20 млн плюс компенсации пострадавшим.
• Крупный маркетплейс (2025): утечка 200 тыс заказов с адресами. Штраф 12 млн ₽ — уже по новой редакции, без оборотных санкций (первая утечка).

Тренд понятен: с 2025 года штрафы перестали быть «копеечными» и стали реально болезненными даже для крупного бизнеса.

Что делать ДО утечки

Самые дешёвые меры — превентивные. Я в работе с клиентами вижу одну и ту же картину: 80% инцидентов — это типовые ошибки, которые закрываются за час правильной настройки. Топ-10 превентивных мер по приоритету.

1. Аудит публичных бакетов. Пройдитесь по всем S3-bucket в Yandex Cloud / Selectel / VK Cloud — закройте всё, что не должно быть публичным. Используйте инструменты типа yc cli или собственные скрипты. Запустите регулярный скан раз в неделю.
2. Аудит публичных репозиториев. Все организационные репозитории на GitHub/GitLab — настройте сканер секретов (gitleaks, trufflehog). Pre-commit hook на разработческих машинах. Уберите .env, ключи, пароли из истории git filter-repo.
3. Двухфакторка обязательна. Везде: GitHub, AWS/Yandex Cloud, админка сайта, корпоративная почта, мессенджеры. Без вариантов. По 2FA утечки через украденный пароль сокращаются на 99%.
4. Шифрование диска. BitLocker на Windows, FileVault на Mac, LUKS на Linux. На всех ноутбуках сотрудников с доступом к ПД. Включается за 10 минут, защищает в случае кражи устройства.
5. Минимальные права. Принцип least privilege. У сотрудника должен быть доступ только к тому, что нужно для работы. Регулярный пересмотр прав (раз в полгода) — обязателен.
6. Логи и мониторинг. Все обращения к БД с ПД — в лог. Подозрительные запросы (выгрузка большого объёма, доступ в нерабочее время) — алерт.
7. Регулярное обновление зависимостей. npm audit / pip-audit / cargo audit раз в неделю. Критические CVE — закрывать сразу.
8. Обучение сотрудников. Фишинговые рассылки — самый частый вектор. Обучение раз в 6 месяцев, имитация фишинга раз в квартал.
9. План реагирования на инцидент. Документ с ролями, контактами, действиями. Прогон по этому документу хотя бы раз в год.
10. Внешний аудит. Хотя бы раз в год — независимая проверка по 152-ФЗ и общей безопасности. Свежий взгляд находит то, что внутри уже примелькалось.

Частые вопросы

Если утечка маленькая — 100 контактов, можно не уведомлять?

Нет. Закон не делает исключений по объёму. 1 субъект, 100 субъектов, 100 миллионов субъектов — обязанность уведомить РКН в 24 часа одинаковая. Штраф за неуведомление по ч. 17 ст. 13.11 — от 1 млн ₽ для ЮЛ независимо от объёма утечки.

Можно ли скрыть факт утечки и не уведомлять?

Технически можно попробовать. Юридически — нет, и это очень рискованно. Сокрытие установленного факта — отягчающее обстоятельство. РКН и ФСБ имеют свои источники мониторинга: они отслеживают публикации в Telegram-каналах об утечках, паблики в даркнете, обращения граждан. Если они узнают о вашей утечке раньше вас — это сразу проверка с максимальным штрафом. Соотношение риск/польза в сокрытии плохое.

Что если узнал о своей утечке из СМИ, а не сам?

Тот же 24-часовой дедлайн, отсчёт — с момента, когда вы узнали. В уведомлении честно пишите: «об инциденте стало известно из публикации в [источник] от [дата/время]». Это нормальный сценарий, РКН не штрафует за то, что вы узнали последним — штрафует за то, что не уведомили после узнавания.

Нужно ли уведомлять иностранных клиентов?

Если они подпадают под другой правопорядок (например, GDPR для граждан ЕС) — да, дополнительно по правилам GDPR (72 часа на уведомление надзорному органу страны). Если ваши данные иностранных клиентов локализованы в РФ — основная обязанность по 152-ФЗ. На практике лучше уведомить всех затронутых пользователей независимо от гражданства — это и репутационно правильно, и снижает риски в любой юрисдикции.

Какие логи нужно сохранять заранее, чтобы было что показать РКН?

Минимум: access-логи веб-сервера (90 дней), auth-логи операционки (90 дней), логи доступа к БД (90 дней, лучше 365), логи изменений критичных файлов (постоянно), логи действий в админке (постоянно). Хранить отдельно от prod-сервера, чтобы атакующий не смог затереть. По 152-ФЗ конкретных требований к срокам нет, но РКН на практике хочет видеть минимум 30 дней истории.

Можно ли откатить уведомление в РКН, если выяснилось, что утечки не было?

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

Что если утечка из-за подрядчика?

Вы остаётесь ответственным перед РКН и субъектами. По 152-ФЗ оператор отвечает за действия обработчика — выбирали его вы. Уведомление РКН подаёте от своего имени. Параллельно — претензия подрядчику и регрессное взыскание убытков (штрафа РКН + компенсаций субъектам) по договору. Поэтому критически важно — в договоре с подрядчиком должны быть прописаны его обязанности по безопасности ПД и материальная ответственность за инциденты. Без этого — все убытки на вас.

Выводы и чек-лист «что подготовить заранее»

Утечки случаются у всех — от стартапов до Сбера. Вопрос не в том, случится у вас или нет, а в том, насколько подготовленным вы окажетесь. По факту разница между штрафом в 100 тыс ₽ и оборотным в 500 млн — это работа подготовки за месяцы до инцидента.

Чек-лист «подготовиться заранее»:

1. Создать инцидент-план с ролями, контактами, действиями. PDF в общем доступе у команды.
2. Назначить ответственного за ПД (DPO или эквивалент). Один человек, имя в политике обработки.
3. Подключить мониторинг утечек — Have I Been Pwned для домена (бесплатно), DLBI/Group-IB для глубокого мониторинга (платно).
4. Настроить логи и retention — минимум 90 дней, хранение отдельно от продакшена.
5. Включить 2FA везде и шифрование дисков на всех устройствах сотрудников.
6. Провести аудит публичных бакетов и репо — закрыть всё лишнее, поставить регулярные сканы.
7. Обновить политику обработки ПД — должна быть актуальной, с описанием категорий данных, целей, сроков, обработчиков.
8. Подать корректное уведомление в реестр операторов на pd.rkn.gov.ru, обновить если что-то менялось.
9. Установить шаблоны уведомлений — для РКН и для субъектов. Заранее, не в момент паники.
10. Раз в год — внешний аудит по 152-ФЗ. Свежий взгляд на типовые уязвимости.

Стоимость подготовки — от 50 до 500 тыс ₽ для среднего бизнеса. Стоимость одной утечки без подготовки — от 1 млн до 500 млн ₽ плюс репутационные потери. Математика очевидная.