Реагирование на инциденты информационной безопасности в 2026: регламент, этапы, документы

Инцидент информационной безопасности (инцидент ИБ) — событие или последовательность событий, которые привели или могли привести к нарушению конфиденциальности, целостности или доступности защищаемой информации. Для персональных данных есть отдельная обязанность: если инцидент привёл к неправомерной или случайной передаче ПДн и нарушил права субъектов, оператор уведомляет Роскомнадзор в течение 24 часов с момента выявления (ч. 3.1 ст. 21 152-ФЗ). С 30 мая 2025 года Федеральный закон № 420-ФЗ от 30.11.2024 штрафует за неуведомление: юридических лиц — на сумму от 1 до 3 млн ₽.

Что точно является инцидентом ИБ

• Утечка данных — неправомерный доступ к ПДн, КТ, технической документации третьих лиц
• Компрометация учётной записи — кража логина/пароля сотрудника, использование чужого аккаунта
• Заражение вредоносным ПО — установка трояна, шифровальщика, шпионского ПО
• Несанкционированный доступ к серверам — взлом веб-приложения, эксплуатация уязвимости
• Атака отказа в обслуживании (DDoS) с нарушением доступности критичных сервисов
• Кража физических носителей — ноутбук, USB, бумажные документы с грифом
• Социальная инженерия — фишинг, обман сотрудника с целью получить доступ
• Инсайдерская утечка — сотрудник передал данные конкуренту или в публичный доступ

Что инцидентом НЕ является

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

Классификация инцидентов по типу

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

Федеральный закон № 420-ФЗ от 30.11.2024 (поправки в КоАП РФ)

Главное нововведение 2025 года — штрафы за утечку ПДн и за неуведомление Роскомнадзора об инциденте. Сами сроки уведомления действуют с 2022 года (ч. 3.1 ст. 21 152-ФЗ, Федеральный закон от 14.07.2022 № 266-ФЗ):

• 24 часа с момента выявления — первичное уведомление с описанием инцидента, предполагаемыми причинами и объёмом скомпрометированных данных
• 72 часа — расширенное уведомление с результатами расследования, точным объёмом, мерами по минимизации последствий и плану предотвращения

За невыполнение или несвоевременное выполнение обязанности уведомить Роскомнадзор — отдельный штраф по ч. 11 ст. 13.11 КоАП РФ: для юридических лиц от 1 до 3 млн ₽. Подробнее об оборотных штрафах.

Приказ ФСТЭК России № 117 от 11.04.2025

Регулирует защиту государственных информационных систем. С 01.03.2026 заменяет Приказ №17. Включает требования к подсистеме реагирования: наличие регламента, журнал событий, обучение сотрудников, регулярные тестирования плана.

Приказ ФСТЭК России № 239 от 25.12.2017

Защита значимых объектов КИИ. Все объекты К1/К2 обязаны подключиться к ГосСОПКА через НКЦКИ и в течение 24 часов сообщать об инцидентах. Регламент реагирования — обязательный документ для аттестации.

Постановление Правительства РФ № 127 от 08.02.2018

Категорирование объектов КИИ. Для категорированных объектов реагирование становится обязательным элементом системы безопасности.

187-ФЗ от 26.07.2017

«О безопасности критической информационной инфраструктуры РФ». Закладывает основу подключения к ГосСОПКА для всех субъектов КИИ.

ГОСТ Р ИСО/МЭК 27035-1:2021

«Менеджмент инцидентов информационной безопасности». Российский аналог международного стандарта ISO/IEC 27035. Описывает 5-фазную модель управления инцидентами — общая методологическая основа для разработки внутренних регламентов.

Указ Президента РФ № 250 от 01.05.2022

Обязательное создание собственного центра реагирования (CISO + команда) для критических отраслей. Запрещено использовать иностранные SaaS-решения для обеспечения ИБ.

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

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

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

Самый важный этап — то, что делается ДО инцидента:

• Разработка регламента реагирования на инциденты ИБ — основной документ с процедурами
• Формирование группы реагирования (Incident Response Team, IRT) — CISO, ИБ-специалист, юрист, PR, IT
• Подготовка контактных списков — внутренние и внешние (РКН, ГосСОПКА, юрист, страховая)
• Настройка систем мониторинга и оповещения — SIEM, DLP, антивирус с центральной консолью
• Создание шаблонов уведомлений в РКН, в полицию, для сотрудников и СМИ
• Обучение сотрудников — какие признаки инцидента, кому сообщать
• Проведение тренировочных учений (table-top exercises) — раз в полгода

Этап 2. Обнаружение и идентификация

• Анализ сигналов от систем мониторинга (SIEM, DLP, антивирус)
• Получение сообщений от сотрудников, клиентов, контрагентов
• Внешние оповещения от ГосСОПКА, ФинЦЕРТ, поставщиков СЗИ
• Триаж — первичная оценка: это инцидент или ложное срабатывание?
• При подтверждении — создание задачи в системе и фиксация времени обнаружения (от него идёт счётчик 24 часов!)

Этап 3. Локализация (Containment)

Главная цель — остановить распространение инцидента, не дать ему расшириться:

• Изоляция скомпрометированных систем (отключение от сети, не выключение!)
• Сохранение цифровых улик — образы памяти, дампы сети, логи
• Блокировка учётных записей с признаками компрометации
• Усиление мониторинга смежных систем
• При утечке ПДн — закрытие канала утечки (отзыв доступа, отзыв ссылок)

Этап 4. Устранение (Eradication)

• Удаление вредоносного ПО, восстановление целостности систем
• Закрытие эксплуатируемых уязвимостей (патчинг, переконфигурация)
• Смена паролей, ротация ключей шифрования
• Восстановление данных из резервных копий, если они повреждены
• Проверка отсутствия закладок (rootkit, backdoor) в восстановленных системах

Этап 5. Восстановление (Recovery)

• Возвращение систем в эксплуатацию по контролируемому графику
• Усиленный мониторинг восстановленных систем в течение 1-4 недель
• Восстановление работоспособности процессов и взаимодействий с клиентами
• При утечке ПДн — уведомление субъектов ПДн о факте утечки (если масштаб значителен)

Этап 6. Анализ и улучшение (Lessons Learned)

• Сбор всей команды через 1-2 недели после инцидента
• Анализ хронологии: что сделали хорошо, где допущены ошибки
• Документирование инцидента в журнале и реестре
• Обновление регламента, моделей угроз, плана реагирования
• Корректирующие действия — закрытие системных пробелов
• Обучение сотрудников по итогам инцидента
• Финальный отчёт руководству — с конкретными мерами по предотвращению повторения

Игнорирование этапа 6 — типичная ошибка. Без анализа и улучшений организация будет постоянно сталкиваться с одними и теми же типами инцидентов.

Уведомить Роскомнадзор об инциденте с ПДн оператор обязан по ч. 3.1 ст. 21 152-ФЗ. С 30 мая 2025 года за неуведомление штрафуют по ч. 11 ст. 13.11 КоАП РФ (в ред. 420-ФЗ). Двухстадийная процедура.

Стадия 1 — Первичное уведомление (24 часа)

Срок: не позднее 24 часов с момента выявления инцидента (не возникновения!). Подача — через личный кабинет оператора в РКН или письмом на адрес РКН.

Что включить в первичное уведомление

• Полное наименование оператора, ИНН, адрес
• Дата и время обнаружения инцидента
• Краткое описание инцидента (1-3 предложения)
• Предполагаемая причина (если известна)
• Предварительная оценка объёма скомпрометированных ПДн
• Категории затронутых субъектов (клиенты, сотрудники, контрагенты)
• Предпринятые первоначальные меры по локализации
• Контактное лицо для взаимодействия с РКН (ФИО, должность, телефон, email)

На этой стадии многих данных ещё нет — это нормально. РКН ожидает факта уведомления, не финального отчёта.

Стадия 2 — Расширенное уведомление (72 часа)

Срок: не позднее 72 часов с момента выявления инцидента. К этому моменту обычно проведено внутреннее расследование.

Что добавляется во вторичном уведомлении

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

Что грозит за нарушение сроков

Шаблоны уведомлений в РКН

Типовые шаблоны первичного и вторичного уведомления по ч. 3.1 ст. 21 152-ФЗ будут в конструкторе Кибероснова Документы (ранний доступ). Также доступен бесплатный bookmarklet для автозаполнения формы РКН — автоматически заполняет поля формы из ваших настроек.

До сих пор в статье речь шла о двух режимах: 24 часа на уведомление Роскомнадзора о факте утечки и 72 часа на результаты внутреннего расследования. С 1 сентября 2026 года у части операторов добавился третий, и живёт он по другим правилам.

Обязанность ввёл Федеральный закон от 29.12.2025 № 568-ФЗ — новая часть 7 статьи 16 149-ФЗ. Порядок её исполнения установил приказ ФСБ России от 06.08.2026 № 297 (Минюст 20.08.2026, № 87923), он действует с 1 сентября 2026 года.

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

Регламент как входной билет

Порядок устроен так, что начинать приходится с документа. Взаимодействие идёт через НКЦКИ — подключением к его технической инфраструктуре (п. 1). А подключение к личному кабинету, согласно пункту 4, организуется после заключения регламента взаимодействия НКЦКИ и владельцев информационных ресурсов.

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

Что регламент закрывает

Документ определяет сроки и порядок взаимодействия сторон (п. 6), в том числе при сбоях и нарушениях защиты информации. К нему стоит подходить как к рабочему процессу, а не к подписи на бумаге: он должен отвечать на вопросы, кто в организации фиксирует инцидент, кто квалифицирует его как подлежащий передаче, у кого право отправки и что делать, если срок выпадает на выходные.

Сроков, которые регламент должен выдерживать, три, и все суточные:

Передачу подтверждает идентификатор, который НКЦКИ присваивает инциденту в личном кабинете в течение 24 часов (п. 6).

Как это ложится на обязанности оператора ПДн

Основания разные, а инцидент может быть один. Утечка персональных данных в государственном учреждении одновременно запускает уведомление Роскомнадзора по части 3.1 статьи 21 152-ФЗ и передачу информации в НКЦКИ по приказу № 297. Сроки при этом считаются независимо, каждый от своего события.

Поэтому во внутреннем регламенте реагирования разумно вести не один маршрут, а матрицу: тип события → кому сообщаем → в какой срок → кто подписывает. Иначе организация рискует закрыть один канал и пропустить другой, будучи уверенной, что «уведомили». Проверить, все ли каналы уведомления закрыты в ваших документах, помогает аудит соответствия 152-ФЗ.

Регламент реагирования на инциденты ИБ — обязательный документ для аттестации ГИС, ИСПДн уровня УЗ-1/УЗ-2, значимых объектов КИИ. Содержит 10 обязательных разделов.

10 обязательных разделов регламента

1. Общие положения — назначение, область применения, термины и определения
2. Классификация инцидентов — категории по типу, уровни критичности (низкий / средний / высокий / критический)
3. Группа реагирования (IRT) — состав, роли, ответственности, контактные данные
4. Каналы оповещения — как сотрудник сообщает об инциденте, кто получает первичное оповещение
5. Процедуры по типам инцидентов — отдельные подразделы для утечки ПДн, заражения вредоносным ПО, DDoS, инсайдерской утечки
6. Сроки уведомления внешних регуляторов — РКН (24+72 ч), ГосСОПКА (24 ч), ФСТЭК, ФинЦЕРТ — с шаблонами уведомлений
7. Порядок локализации и устранения — пошаговые действия команды на каждом этапе
8. Документирование инцидента — журнал инцидентов, формы отчётов, требования к хранению (3 года для ПДн)
9. Анализ и улучшение — порядок постмортема, корректирующих действий, обновления регламента
10. Регулярные учения — частота table-top exercises, тестирования плана восстановления

Приложения к регламенту

• Шаблон журнала инцидентов
• Шаблон уведомления в РКН (первичное и расширенное)
• Шаблон уведомления в ГосСОПКА/НКЦКИ
• Шаблон уведомления субъектов ПДн при крупной утечке
• Шаблон внутреннего отчёта об инциденте
• Контактные списки внутренних и внешних команд
• Карта эскалации (кто кому сообщает в каком сценарии)

Кто утверждает регламент

Регламент утверждается приказом руководителя организации. В крупных компаниях — заместителем по безопасности или CISO с согласованием совета директоров. Для государственных ИС — обязательное согласование с ФСТЭК (через органы по аттестации).

Частота обновления

• Регламентный пересмотр — раз в год
• Внеочередной — после каждого крупного инцидента, при изменениях в НПА (как 420-ФЗ от 30.11.2024), при существенных изменениях в инфраструктуре
• Учения — раз в полгода с проверкой актуальности регламента

Реагирование на инциденты — это сочетание документации и процессов. Кибероснова предоставляет 4 уровня поддержки.

1. Регламент реагирования: образец и конструктор

Конструктор Кибероснова Документы сейчас в разработке. В нём можно будет собрать регламент реагирования на инциденты с учётом 152-ФЗ, приказов ФСТЭК № 117 и № 239 и ГОСТ Р ИСО/МЭК 27035. В составе — журнал инцидентов, шаблоны уведомлений в РКН/ГосСОПКА/субъектам, карта эскалации.

2. Сопровождение инцидента «Под ключ»

Если инцидент уже произошёл и нужна экстренная помощь — наша команда (ИБ-аналитик + юрист + разработчик) подключается в течение 4 часов: помогает с локализацией, готовит уведомления в РКН в требуемые сроки 24+72 часа, ведёт переговоры с регулятором, сопровождает расследование. Цена индивидуальная — запрос через форму «Под ключ».

3. Bookmarklet для автозаполнения формы РКН

Бесплатный инструмент /tools/rkn-autofill автоматически заполняет поля формы уведомления в Роскомнадзоре из ваших настроек. Исключает ошибки набора. Работает с любым браузером.

4. Учения и обучение через партнёров

Регулярные table-top exercises и сценарные учения — критический элемент готовности. Привлекаем партнёров-практиков для проведения учений с реалистичными сценариями (фишинг, DDoS, инсайдерская утечка). Помогает команде отработать действия до реального инцидента.

Чем отличаемся от классических подрядчиков

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

По нашему опыту работы с компаниями в 2024-2025 годах после введения оборотных штрафов по 420-ФЗ, выделим 7 ошибок, которые встречаются чаще всего.

Ошибка 1. Реагирование без регламента

Компания узнаёт об инциденте — и начинает действовать «по ситуации». В стрессе делаются ошибки: неправильная локализация (выключают сервер, теряя цифровые улики), забывают про срок 24 часа РКН, не уведомляют ГосСОПКА, теряют логи. Регламент — это «инструкция в условиях паники».

Ошибка 2. Пропуск срока 24 часа

Самая частая ошибка после 30 мая 2025 года. Команда занята локализацией, забывает о юридической обязанности уведомить РКН. Через 25 часов срок уже нарушен: штраф по ч. 11 ст. 13.11 КоАП РФ, для юридических лиц от 1 до 3 млн ₽. Решение: автоматический таймер в SIEM/SOAR на 12 часов, чтобы дать буфер.

Ошибка 3. Выключение скомпрометированных систем

Первая реакция — выдернуть сервер из розетки. Это уничтожает дамп памяти (volatile memory) — критическую улику для криминалистов. Правильно: изоляция (отключение от сети) с сохранением работы.

Ошибка 4. Игнорирование лог-файлов

Логи перезаписываются (rotation), цифровая улика теряется. После обнаружения инцидента нужно немедленно сделать snapshot всех логов на отдельный носитель.

Ошибка 5. Уведомление СМИ до уведомления РКН

Сотрудник или PR-команда сообщает в СМИ или в Telegram о факте утечки до подачи уведомления в РКН. РКН узнаёт об инциденте из публикации раньше, чем от оператора. Срок 24 часа от этого не сдвигается, и если уведомления нет, это нарушение по ч. 11 ст. 13.11 КоАП РФ. Последовательность: РКН (24 ч) → субъекты ПДн (если масштаб большой) → СМИ (если необходимо).

Ошибка 6. Отсутствие анализа после инцидента

Инцидент устранён — команда забывает про этап 6 (Lessons Learned). Через 3-6 месяцев происходит инцидент того же типа. Постмортем — обязательная часть реагирования, не «дополнительная работа».

Ошибка 7. Регламент в столе

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

Как избежать ошибок

• Создать регламент ДО первого инцидента — не «когда понадобится»
• Установить автоматический таймер 12 часов в SIEM/SOAR для напоминания о сроке РКН
• Тренировать команду — раз в полгода table-top exercises
• Чек-лист «первые 60 минут» — на видном месте в комнате IRT
• Регулярный пересмотр и обновление регламента — раз в год