Утечка данных: пошаговый план действий (чек-лист)

Обновлено 08.11.2026 08:18

 

При утечке данных в первые 24 часа нужно локализовать инцидент и уведомить Роскомнадзор (если затронуты персональные данные) или НКЦКИ через ГосСОПКА (для субъектов КИИ), а в течение 72 часов - направить результаты внутреннего расследования. Пропуск срока уведомления - отдельный штраф до 3 млн рублей, сама утечка - до 20 млн, при повторении - оборотный штраф до 3% годовой выручки. Поэтому план реагирования пишут до инцидента: в момент атаки дорога каждая минута.

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

Ключевые выводы

Утечка - это не только взлом: по данным Positive Technologies, 64% успешных атак в 2025 году сопровождались утечкой конфиденциальной информации, а почти половина атак на российские компании оказалась успешной.

Сроки реагирования закреплены законом: 24 часа на первичное уведомление Роскомнадзора об утечке персональных данных и 72 часа на отчёт о результатах внутреннего расследования (ч. 3.1 ст. 21 152-ФЗ).

Для значимых объектов КИИ сроки жёстче: 3 часа на сообщение в НКЦКИ через ГосСОПКА (приказ ФСБ России от 25.12.2025 № 547).

Штрафы выросли кратно: от 3 до 20 млн рублей за утечку в зависимости от масштаба, при повторной - оборотные от 20 до 500 млн рублей (ст. 13.11 КоАП РФ).

Главные причины утечек - социальная инженерия, вредоносное ПО и незакрытые уязвимости: базовая гигиена ИБ окупается лучше любого «экзотического» решения.

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

Введение

В 2025 году Роскомнадзор зафиксировал 103 случая компрометации баз персональных данных - в открытый доступ попало около 50 млн записей. При этом, по данным Positive Technologies, 47% атак на российские компании оказались успешными и привели к нарушению деятельности - против 31% годом ранее. Утечка перестала быть «проблемой айтишников»: это вопрос непрерывности бизнеса, денег и репутации.

В этой статье я, Петухов Олег Анатольевич, руководитель компании «ЛЕГАС», разберу угрозы с трёх точек зрения - руководителя ИБ, руководителя бизнеса и специалиста по аудиту, приведу реальные инциденты и судебную практику, а главное - дам пошаговые алгоритмы: что делать в первые 24 часа, как подготовиться к проверке и как снизить риски через подрядчиков. Каждый алгоритм можно применить на практике уже сегодня.

Угрозы и меры защиты: три взгляда

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

Взгляд CISO: инцидент как процесс, а не «суббота, всё сломалось»

Для руководителя ИБ-подразделения утечка - это управляемый процесс с измеримыми метриками: временем обнаружения (MTTD), временем реагирования (MTTR), полнотой покрытия мониторингом. Опора здесь - стандарты и регламенты, а не героизм отдельных сотрудников.

Нормативная база. ГОСТ Р 59547-2021 «Информационная безопасность. Управление событиями и инцидентами информационной безопасности» задаёт цикл управления инцидентами: от выявления и регистрации до извлечения уроков. ISO/IEC 27001:2022 в пункте A.5.26 требует процедур реагирования на инциденты, а серия ISO/IEC 27035 детализирует этапы - от подготовки к реагированию до анализа последствий. NIST Cybersecurity Framework 2.0 (февраль 2024) добавил функцию Govern и ужесточил требования к восстановлению: категория RC.RP требует верифицировать целостность резервных копий до восстановления и формально объявлять об окончании восстановления.

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

Классификация источников утечек. Прежде чем защищаться, полезно понимать, откуда вообще утекают данные. В моей практике источники делятся на четыре большие группы. Первая - инсайдеры: обиженные или беспечные сотрудники, которые выносят данные на почту, мессенджеры и личные носители; по разным оценкам, на этот вектор приходится до трети всех утечек. Вторая - компрометация инфраструктуры: стилеры на рабочих станциях, подбор паролей, эксплуатация уязвимостей, фишинг. Третья - процессы и подрядчики: разработчики, аутсорсеры, службы доставки, которые получают доступ к данным, но не несут за них реальной ответственности. Четвёртая - физические носители и бумага: утерянные ноутбуки, распечатки, архивы, списанные диски без уничтожения. Разные источники требуют разных мер: DLP-системы и обучение персонала против инсайдеров, патч-менеджмент и MFA против компрометации, договорная работа против подрядчиков, регламент уничтожения носителей против «бумажных» утечек. Попытка закрыть всё одной «серебряной пулей» - типичная ошибка.

О техническом контроле инсайдеров. DLP-системы в России зрелые, и для многих компаний вопрос «ставить или нет» уже не стоит - стоит вопрос «как внедрить, чтобы не сломать процессы». Мой практический совет: начинайте с телеметрии без блокировок. Два-три месяца система работает в режиме наблюдения, вы собираете статистику реальных потоков данных и учите аналитиков. Блокирующие политики включаются точечно - на канал и категорию данных, а не на всех сразу. Такой подход снижает сопротивление персонала и, что важнее, даёт законную доказательную базу, если инцидент всё же случится: у вас будут зафиксированы и попытка выгрузки, и момент её пресечения.

Кейс из практики ЛЕГАС. На проекте в промышленной компании в Москве мы обнаружили, что служебные учётные записи администраторов гипервизора использовались для подключения из «домашних» VPN-профилей сотрудников. Формально нарушений «по паролям» не было - но в компиляции из открытых источников нашлись три пары «логин–пароль», совпадавшие с корпоративными (детали проекта не раскрываем из соображений конфиденциальности - укажем лишь отрасль и суть). Замена паролей, повсеместное включение MFA и аудит привилегий закрыли проблему за две недели. И отрицательный кейс: в другом проекте заказчик отказался от сегментации сети ради «экономии на коммутаторах» - через год руткит на файловом сервере разошёлся по всей локальной сети, и компания потеряла три дня работы.

Что сделать в первую очередь:

Внедрить централизованный сбор событий ИБ (SIEM или хотя бы агрегатор логов): это одно из направлений показателя защищённости КЗИ по методике ФСТЭК от 11.11.2025, на группу «мониторинг и реагирование» приходится 30% веса.

Включить MFA везде, где возможно, и запретить повторное использование корпоративных паролей вне периметра.

Прописать регламент реагирования с ролями и эскалацией - по структуре ГОСТ Р 59547-2021.

Проверить, кто в компании знает, куда звонить в первый час инцидента. Если ответ «никто» - это и есть главная уязвимость.

Пара слов о метриках. Считать их обязательно, но не ради отчёта: цели по MTTD и MTTR - это управленческий рычаг. Если инцидент обнаруживается за сутки, а реагирование растягивается на неделю - это сигнал о дефиците мониторинга и полномочий. Ориентир, который я даю клиентам: критический инцидент должен быть замечен за минуты-часы (автоматическое оповещение), локализован за первые часы, а полная картина - собрана в течение суток. Достигнуть этого без централизованного сбора событий и подготовленных людей невозможно, поэтому SIEM и регламент - не роскошь, а база.

Взгляд руководителя бизнеса: утечка как финансовый и юридический риск

Буду прямым: стоимость утечки определяется не размером базы, а реакцией в первые сутки. Одинаково «засветившаяся» база в 10 000 строк может обойтись компании в предупреждение от регулятора, а может - в десятки миллионов рублей штрафа и потерю клиентов. Разница - в подготовленности.

Нормативная база. С 30 мая 2025 года действуют новые штрафы за утечку персональных данных (ст. 13.11 КоАП РФ в редакции Федерального закона № 420-ФЗ). За действия, повлёкшие неправомерную передачу данных 1–10 тыс. субъектов (ч. 12), юрлицо платит 3–5 млн рублей; 10–100 тыс. субъектов (ч. 13) - 5–10 млн; свыше 100 тыс. субъектов или более 1 млн идентификаторов (ч. 14) - 10–15 млн; за утечку специальных категорий данных - состояние здоровья, религиозные взгляды, судимость и т. п. (ч. 16) - 10–15 млн. При повторном нарушении - оборотный штраф от 1 до 3% годовой выручки, но не менее 20 и не более 500 млн рублей (ч. 15). Неуведомление Роскомнадзора об утечке в 24 часа - отдельный состав: для юрлиц 1–3 млн рублей (ч. 11 ст. 13.11 КоАП). Есть и уголовная ответственность: статья 272.1 УК РФ (введена законом № 421-ФЗ от 30.11.2024) наказывает за незаконное использование и передачу персональных данных - вплоть до 10 лет лишения свободы.

Реальный инцидент. В апреле 2025 года программа-вымогатель зашифровала 15 серверов биофармацевтической компании MJ Biopharm, включая серверы с конфиденциальной информацией. Средний первоначальный выкуп у российских компаний в 2025 году - от 4 до 40 млн рублей, максимум вырос на 67% - до 400 млн. Это уже не «стоимость защиты», это размер убытков без неё.

Отдельно о страховании и репутации. Киберстрахование в России пока развито слабо, но полисы покрытия киберриск уже появились, и крупные компании ими пользуются. Важная деталь: страховщики обращают внимание на то, как организация реагировала на инцидент. Задокументированная, последовательная реакция повышает шансы на возмещение и снижает риск регуляторных санкций; молчание и попытки скрыть инцидент, наоборот, работают против вас. Репутационная составляющая часто дороже штрафа: клиент, чьи данные утекли, редко возвращается добровольно, а в B2B-сегменте вопрос «как вы храните наши данные» теперь задаётся на этапе тендера.

Кейс из практики ЛЕГАС. Прецедент, который я чаще всего пересказываю клиентам: Верховный Суд в постановлении от 21.01.2026 № 5-АД25-119-К2 подтвердил - за утечку персональных данных через подрядчика отвечает оператор. Базу сотрудников одного из министерств вёл аутсорсинговый подрядчик, его взломали хакеры - оштрафовали всё равно само ведомство. Это меняет договорную работу: положения об ответственности обработчиков в договорах (ч. 3 ст. 6 152-ФЗ) перестали быть формальностью. В Санкт-Петербурге мы помогали заказчику переработать договорную цепочку из четырнадцати контрагентов: к моменту проверки все положения об ответственности были в силе, и это дало весомый аргумент в диалоге с регулятором.

Что сделать в первую очередь:

Проверить, есть ли компания в реестре операторов персональных данных Роскомнадзора: непредставление уведомления - штраф до 300 тыс. рублей для юрлица (ч. 10 ст. 13.11 КоАП).

Назначить ответственного за информационную безопасность - не «по совместительству у юриста», а с полномочиями и ресурсами.

Провести оценку рисков и составить реестр обрабатываемых данных с категориями - это основа любых мер защиты.

Заложить бюджет не на «антивирус», а на сокращение времени обнаружения: статистика 2025 года показывает, что промедление дороже защиты на порядок.

Взгляд аудита и пентеста: утечка как следствие дефектов инфраструктуры

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

Нормативная база. Для субъектов КИИ действует приказ ФСТЭК России от 25.12.2017 № 239 «Требования по обеспечению безопасности значимых объектов критической информационной инфраструктуры» с группами мер защиты. Для государственных информационных систем и систем госорганов и госпредприятий с 1 сентября 2026 года применяются требования приказа ФСТЭК России от 11.04.2025 № 117 - он заменил документ 2007 года и распространяет требования на более широкий круг систем. Меры защиты для персональных данных - по приказу ФСТЭК России от 18.02.2013 № 21 «Состав и содержание организационных и технических мер по обеспечению безопасности персональных данных». С 11 ноября 2025 года действует обновлённая методика оценки показателя защищённости КЗИ: нормированное значение - 1,0; оценка проводится не реже одного раза в шесть месяцев, а результаты направляются в ФСТЭК.

Не забывайте про бумагу и физику. Аудиторы привычно смотрят в сторону сетей и ПО, но значительная часть утечек начинается с самой простой вещи: распечатанный документ, лежащий в открытом ящике; списанный жёсткий диск, проданный «за копейки»; пропуск, оставленный в офисе. В требованиях ФСТЭК к мерам защиты предусмотрены организационные меры по обращению с носителями информации, и это не формальность. В одном из наших аудитов в Санкт-Петербурге архив бухгалтерии складировался в подсобке без опечатывания - формально система была защищена по всем канонам, а фактически доступ к бумажным носителям имели все сотрудники этажа. Технический периметр без физического - это замок на дверях при открытом окне.

Реальный инцидент. В феврале 2025 года на российские системы госуправления пришлось 822 DDoS-атаки, самая длительная продолжалась 71 час. По данным Positive Technologies, госучреждения - главная цель вымогателей и хактивистов: на них приходится 21% всех успешных атак на организации. Для аудитора это сигнал: если инфраструктура доступна из интернета, атака - вопрос времени, а не вероятности.

Кейс из практики ЛЕГАС. На пентесте регионального оператора в Вологодской области мы за четыре дня прошли от веб-формы обратной связи до домена предприятия - через устаревшую версию CRM с известной уязвимостью, которую «планировали обновить» почти два года. По моей практике, почти в каждом втором пентесте путь нарушителя лежит через уязвимость, о которой заказчик знал. Отсюда главный совет аудируемым компаниям: не создавайте раздутый реестр уязвимостей - создайте регламент их закрытия. Это дешевле любой новой системы защиты. Точный перечень уязвимостей и их уровней опасности удобно сверять с банком данных угроз безопасности информации ФСТЭК (БДУ).

Что сделать в первую очередь:

Провести внешнюю оценку защищённости (сканирование периметра и тест на проникновение).

Внедрить регламент патч-менеджмента: критические уязвимости закрываются в согласованные сроки, а не «когда-нибудь».

Проверить сегментацию: критические системы не должны иметь прямого доступа в интернет.

Подготовиться к расчёту показателя КЗИ - оценка проводится регулярно, не реже раза в полгода.

Изменения в ландшафте угроз и регулировании

Блок актуален на дату публикации - 2 ноября 2026 года.

Регуляторная активность 2025–2026 годов беспрецедентна по плотности. С 1 сентября 2025 года заработал пакет поправок в 152-ФЗ: согласие на обработку персональных данных оформляется отдельным документом, а не пунктом договора; операторы по запросу Минцифры передают обезличенные данные в государственные информационные системы (Федеральный закон от 08.08.2024 № 233-ФЗ). Методы обезличивания закреплены приказом Роскомнадзора от 19.06.2025 № 140 и постановлением Правительства от 01.08.2025 № 1154.

В сфере КИИ реформу задал Федеральный закон от 07.04.2025 № 58-ФЗ: с 1 сентября 2025 года из субъектов КИИ исключены индивидуальные предприниматели, введены перечни типовых отраслевых объектов (правила уточнены постановлением Правительства от 07.11.2025 № 1762, сами перечни утверждены распоряжением Правительства от 26.02.2026 № 360-р), а приказом ФСТЭК № 247 от 11.07.2025 актуализирована форма сведений о результатах категорирования - теперь в ней указываются типовой отраслевой объект, доменные имена и внешние IP-адреса. Законом от 31.07.2025 № 325-ФЗ введены структурные ограничения на иностранное участие в капитале субъектов КИИ. Порядок взаимодействия с НКЦКИ определил приказ ФСБ России от 25.12.2025 № 547 (вступил в силу 30.01.2026): инцидент на значимом объекте - сообщение в НКЦКИ не позднее 3 часов; на объекте без категории и при компьютерной атаке - 24 часа; отчёт о результатах реагирования - 48 часов, а для банковской сферы дополнительно в Банк России.

Региональная специфика. Москва и Санкт-Петербург концентрируют наибольшее число операторов персональных данных: банки, ИТ-компании, e-commerce, телеком. Для них критичны новые штрафы и практика Роскомнадзора по столичным операторам. Северо-Западный федеральный округ, включая Вологодскую область, силён промышленностью и энергетикой: металлургия, химия, энергосети - здесь много объектов КИИ, и реформа категорирования по 58-ФЗ и перечню типовых объектов бьёт по региональным предприятиям особенно ощутимо. В Вологодской области мы регулярно сталкиваемся с тем, что предприятия «наследуют» старые информационные системы, категорирование которых пришлось пересматривать с нуля. В регионах, как правило, острее стоит кадровый вопрос: специалистов по ИБ меньше, и грамотно составленный чек-лист с чёткими ролями там важнее, чем в корпорациях с крупными ИБ-службами.

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

Экосистема реагирования также формализуется: в 2026 году подписан приказ ФСБ России № 161 об аккредитации центров ГосСОПКА и требованиях к ним, а НКЦКИ определены форматы представления информации о компьютерных атаках и инцидентах. Для организаций это означает простую вещь: канал уведомления о инцидентах - не «личная договорённость», а регламентированный процесс с формами и сроками, и готовиться к нему нужно заранее.

В ландшафте угроз - сдвиг в промышленный сектор: по данным центра мониторинга «Спикател», на него приходится 34% кибератак, на телеком - 26%. Доминирующая схема - двойное вымогательство: кража данных плюс шифрование. Отдельно отмечу рост атак через цепочку поставок: доля таких инцидентов в России выросла с 2% до 4%.

Чек-лист: пошаговый план действий при утечке данных

Ниже - тот самый чек-лист, который стоит распечатать, подписать у руководителя и повесить там, где его найдут без интернета. Он собран из практики реагирования и требований нормативных документов: ГОСТ Р 59547-2021, ч. 3.1 ст. 21 152-ФЗ, приказа ФСБ России № 547. Разбей его на три этапа: подготовка (до инцидента), первые 24 часа, 72 часа и после.

Этап 1. Подготовка (до инцидента)

Утвердить план реагирования на компьютерные инциденты: роли, полномочия, порядок эскалации (это один из частных показателей методики КЗИ - документ запрашивается ФСТЭК).

Составить и напечатать таблицу контактов: Роскомнадзор региона, НКЦКИ/ГосСОПКА, ФСБ, ФСТЭК, юрист, ИБ, провайдер канала.

Подготовить шаблоны: первичное уведомление в Роскомнадзор, сообщение в НКЦКИ, внутренний акт об инциденте, сообщение пострадавшим.

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

Организовать резервное копирование по правилу 3-2-1: три копии, два типа носителей, одна - офлайн. Проверять восстановление тестами, не «на глаз».

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

Назначить ответственного за связь с регуляторами и СМИ: один голос от организации, без самодеятельности сотрудников в соцсетях.

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

Этап 2. Первые 24 часа

Зафиксировать время обнаружения и кто обнаружил - с этого момента считаются все сроки.

Изолировать затронутые системы от сети, не выключая их (выключение может уничтожить оперативную память как улику).

Сохранить доказательства: копии логов, снимки памяти, сетевые дампы, скриншоты.

Направить первичное уведомление в Роскомнадзор (если затронуты ПДн) - в течение 24 часов; при признаках атаки на объект КИИ - в НКЦКИ (3 часа для значимых объектов).

Созвать рабочую группу: ИБ, юрист, ИТ, представитель руководства.

Оценить масштаб: какие данные, сколько субъектов, куда ушли, есть ли шифровальщик.

Проверить внешние интеграции: подключённые сервисы, вебхуки, ключи API - часто утечка идёт мимо основного периметра.

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

Этап 3. 72 часа и после

Провести внутреннее расследование и направить в Роскомнадзор отчёт о его результатах в течение 72 часов (ч. 3.1 ст. 21 152-ФЗ).

Направить в НКЦКИ отчёт о результатах реагирования (для значимых объектов - в течение 48 часов после завершения мероприятий).

Устранить причину: закрыть уязвимость, отозвать доступ, перестроить процесс.

Уведомить пострадавших лиц, если это необходимо, и подготовить публичное сообщение, если инцидент стал общедоступным.

Провести внеочередную оценку показателя КЗИ (она прямо предусмотрена методикой при значимом инциденте).

Разобрать инцидент и обновить план реагирования: что сработало, что нет, что добавить.

Как обнаружить утечку раньше, чем её увидит регулятор

Самая дорогая утечка - та, о которой вы узнаёте от Роскомнадзора, от журналиста или от продавца вашей же базы. Методика КЗИ и практика реагирования сходятся в одном: время обнаружения - главный резерв экономии. Вот контрольные точки, где утечка «светится» раньше всего.

Контрольные точки мониторинга

Аномалии доступа. Массовые выгрузки из баз, нетипичные запросы от учётной записи, доступ в нерабочее время - самые ранние сигналы инсайдерской утечки. Централизованный сбор событий с оповещениями по таким триггерам - требование методики КЗИ (частный показатель группы «мониторинг и реагирование»).

Компрометация учётных данных. Сервисы мониторинга утечек позволяют проверять, не «всплыли» ли корпоративные адреса в свежих дампах. Реагировать нужно на совпадение домена компании, а не на вход в аккаунт - предпринимать меры стоит до попытки входа.

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

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

Фишинг и стилеры. Проверка почтовых вложений и контроль запуска подозрительных файлов - прямое требование частных показателей КЗИ; компиляции вроде «16 млрд записей» собираются именно такими средствами.

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

Практическая часть: вопрос-ответ

Что делать в первые 24 часа после обнаружения утечки персональных данных?

Первые сутки - самое важное время, и здесь многие ошибаются, пытаясь «сначала разобраться, потом сообщить». Правильно - наоборот: уведомить регулятора в 24 часа (ч. 3.1 ст. 21 152-ФЗ), расследовать в 72 часа. Судебная практика 2026 года подтверждает: компания, которая подверглась DDoS-атаке и не сумела сразу закрыть доступ к базе двух клиентов, получила предупреждение вместо штрафа - нарушение совершено впервые, вреда нет (решение АС Кемеровской области от 19.01.2026 по делу № А27-27136/2025). Своевременное уведомление - один из главных смягчающих аргументов.

Алгоритм:

Локализовать источник утечки и изолировать затронутые системы - без уничтожения улик: снимки памяти, копии логов.

Направить первичное уведомление в Роскомнадзор через сервис на портале персональных данных - электронная форма обязательна.

Если инцидент имеет признаки компьютерной атаки на объект КИИ - параллельно сообщить в НКЦКИ через ГосСОПКА.

Создать рабочую группу расследования: ИБ, юрист, ИТ, PR.

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

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

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

Нужно ли сообщать в НКЦКИ и ГосСОПКА о каждом инциденте?

Нет, не о каждом - но «серую зону» трактуйте осторожно. По приказу ФСБ № 547 инцидент на значимом объекте КИИ информируется в НКЦКИ за 3 часа, на объекте без присвоенной категории - за 24 часа; компьютерная атака - в любом случае за 24 часа. Если система не значимая, но обрабатывает персональные данные, уведомляется Роскомнадзор, а при признаках атаки - и ГосСОПКА.

Алгоритм:

Определить, является ли организация субъектом КИИ (сферы по ст. 2 187-ФЗ).

Проверить наличие объекта в перечне типовых отраслевых объектов КИИ (распоряжение Правительства от 26.02.2026 № 360-р).

При наличии признаков инцидента - направить первичное сообщение в НКЦКИ в установленный срок.

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

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

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

Как подготовиться к проверке Роскомнадзора или ФСТЭК?

Подготовка - это доказательная база, а не «правильные ответы на вопросы». По 152-ФЗ (ст. 22, ст. 18.1, ст. 19) оператор обязан иметь уведомление в реестре, локальные акты и меры защиты по постановлению Правительства № 1119; по 187-ФЗ - модель угроз и меры по приказу ФСТЭК № 239. По моей практике проверок, регуляторы чаще всего «заваливают» компании не отсутствием технологий, а отсутствием документов о том, как эти технологии используются.

Алгоритм:

Сверить наличие актуального уведомления в реестре операторов и обновлять сведения при изменениях (в течение 15 дней следующего месяца).

Проверить комплект локальных актов: политика обработки ПДн, перечень мер по ПП № 1119, приказ о назначении ответственного.

Проверить модель угроз, согласованную с требованиями ФСТЭК, и её актуальность.

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

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

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

Рекомендация: держите «досье защищённости» в одном месте - на проверке это экономит недели.

Несколько слов о том, как устроена сама система. ГосСОПКА - государственная система обнаружения, предупреждения и ликвидации последствий компьютерных атак; взаимодействие с ней идёт через центры ГосСОПКА, а координирует их НКЦКИ ФСБ России. Госорганы обязаны подключаться к системе; субъекты КИИ и операторы, обрабатывающие ПДн, обязаны информировать НКЦКИ о компьютерных атаках и инцидентах. В 2026 году приказом ФСБ № 161 утверждён порядок аккредитации центров ГосСОПКА и требования к ним - экосистема реагирования формализуется, и вступать с ней в диалог лучше с заранее налаженного канала, а не с первого инцидента.

Как обезличить персональные данные правильно?

Обезличивание стало самостоятельным правовым режимом. Требования, методы и правила утверждены постановлением Правительства от 01.08.2025 № 1154 и приказом Роскомнадзора от 19.06.2025 № 140. Обезличенные данные могут использоваться без согласия субъекта - но только если процедура выполнена корректно, а сведения, позволяющие восстановить исходные данные, хранятся отдельно.

Алгоритм:

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

Выбрать метод из утверждённых (изменение состава, семантики, псевдонимизация, изменение идентификаторов).

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

Утвердить локальный акт о порядке обезличивания.

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

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

Рекомендация: не путайте обезличивание с шифрованием - это разные операции с разными правовыми последствиями.

Как минимизировать риск утечки через подрядчиков?

Кейсы с подрядчиками - одни из самых болезненных. Постановление ВС РФ от 21.01.2026 № 5-АД25-119-К2 прямо показало: за утечку через подрядчика отвечает оператор, вина исполнителя не освобождает от штрафа. Для субъектов КИИ требования жёстче: на значимых объектах допускается программное обеспечение из реестра отечественного ПО.

Алгоритм:

Провести инвентаризацию всех подрядчиков, имеющих доступ к данным.

Включить в договоры положения об ответственности обработчика и требования по защите (ч. 3 ст. 6 152-ФЗ).

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

Ограничить объём предоставляемых данных минимально необходимым (принцип минимизации, ст. 5 152-ФЗ).

Предусмотреть право проверки и порядок реагирования на инцидент у подрядчика.

Типовой сценарий, который я вижу регулярно: компания передаёт подрядчику базу для рассылки или интеграции, договор при этом общий («услуги ИТ»), положение о защите данных - одно предложение. Проходит год, подрядчик меняет подрядчика второго уровня, и данные уходят уже совсем не туда, откуда ждали. Лечится это тремя словами: договор, аудит, минимизация. И тем самым самым положением об ответственности - теперь его юридическая сила подтверждена позицией Верховного Суда.

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

Сравнительная таблица: требования и сроки реагирования

Субъект/система

Нормативный акт

Куда уведомлять о компьютерном инциденте

Срок первичного уведомления

Срок отчёта о расследовании

Любой оператор ПДн

152-ФЗ, ч. 3.1 ст. 21; ст. 13.11 КоАП

Роскомнадзор

24 часа

72 часа

Значимый объект КИИ

187-ФЗ; приказ ФСБ № 547; приказ ФСТЭК № 239

НКЦКИ через ГосСОПКА

3 часа

48 часов

Объект КИИ без категории

187-ФЗ; приказ ФСБ № 547

НКЦКИ через ГосСОПКА

24 часа

48 часов (о результатах реагирования)

ГИС и системы госорганов

приказ ФСТЭК № 117 от 11.04.2025

ГосСОПКА; результаты КЗИ - в ФСТЭК

по порядку ведомства

по порядку ведомства

Специальные категории ПДн при утечке

ст. 13.11 КоАП, ч. 16

Роскомнадзор

24 часа

72 часа; штраф 10–15 млн руб.

 

И последнее: заведите привычку раз в квартал перечитывать свой чек-лист глазами человека, который видит его впервые. Если половина пунктов непонятна без пояснений - чек-лист не работает, его нужно переписать. План реагирования - живой документ, а не отчётная бумага.

Ту же проверку стоит устроить и учениям: если во время учебного инцидента хоть один шаг пришлось исполнять «по памяти», а не по чек-листу, значит, документ ещё не дожил до реальности.

Частые ошибки

Попытка «разобраться самим» до уведомления регулятора. В итоге сроки пропущены - и компания получает двойной штраф: за утечку и за неуведомление. Как избежать: уведомляйте в 24 часа всегда, даже при неполноте данных.

Отсутствие печатного чек-листа реагирования. Инструкция в корпоративной вики, недоступной из-за инцидента, - это не инструкция. Как избежать: распечатанный плакат с контактами и телефонами в серверной и у руководства.

Модель угроз «под сдачу», без актуализации. Модель, написанная пять лет назад, не отражает реальные векторы атак. Как избежать: пересматривать модель минимум раз в год и при существенных изменениях инфраструктуры.

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

Экономия на резервных копиях. Без проверки целостности восстановление после шифровальщика не работает - категория RC.RP в NIST CSF 2.0 прямо требует верифицировать копии до использования. Как избежать: регулярные тестовые восстановления и офлайн-копии.

Заключение

Утечка данных в 2026 году - это не «событие», а управляемый риск с чёткими юридическими и техническими рамками. Штрафы выросли кратно, сроки реагирования сжались, а регуляторы научились находить утечки сами. Пошаговый план действий: подготовить чек-лист реагирования, назначить ответственных, отработать каналы уведомления Роскомнадзора и НКЦКИ, проверить реестр операторов и актуальность модели угроз.

Конкретное действие на сегодня: соберите рабочую группу из трёх человек - ИБ, юрист, ИТ - и за один день набросайте свой чек-лист по образцу из этой статьи. Если нужна помощь с аудитом, реагированием или подготовкой к проверке - обращайтесь в «ЛЕГАС»: утечка данных и пошаговый план действий по её предупреждению - наша ежедневная практика в Москве, Санкт-Петербурге и Вологде.

Блок автора

Петухов Олег Анатольевич - руководитель юридической компании «ЛЕГАС» (офисы в Москве, Санкт-Петербурге и Вологде), эксперт по информационной безопасности с 25-летним стажем. Специализация: информационная безопасность, защита персональных данных, безопасность КИИ, реагирование на инциденты. В «ЛЕГАС» развивает практику информационной безопасности - от аудита до правового сопровождения ИБ-проектов. Профиль автора размещён на legascom.ru.

Поделитесь статьёй с коллегами - особенно с теми, кто отвечает за ИБ или договорную работу.

Подпишитесь на legascom.ru - разбираем сложное просто.