Инцидент информационной безопасности: что это и как реагировать по закону

В марте 2026 года НКЦКИ зафиксировал рекордное число компьютерных инцидентов на объектах КИИ. Одновременно вступил в силу приказ ФСТЭК России от 11.04.2025 № 117, который изменил правила игры для государственных информационных систем. Оборотные штрафы за утечки персональных данных действуют уже почти год. Для организаций, которые до сих пор не выстроили процесс реагирования на инциденты, времени на раскачку не осталось.

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

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

Событие, инцидент, компьютерная атака: в чём разница

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

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

Инцидент ИБ это уже другое. По ГОСТ Р 59709-2022 «Защита информации. Управление компьютерными инцидентами. Термины и определения» инцидент ИБ определяется как непредвиденное или нежелательное событие (группа событий) ИБ, которое привело (может привести) к нарушению функционирования информационного ресурса, возникновению угроз безопасности информации или нарушению требований по защите информации. Проще говоря, инцидент это событие, которое причинило реальный вред или создало реальную угрозу.

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

А компьютерная атака, согласно тому же 187-ФЗ, это целенаправленное воздействие на объекты КИИ с целью нарушить или прекратить их функционирование. Атака это действие. Инцидент это последствие. Атака может не привести к инциденту (если средства защиты сработали), а инцидент может произойти без атаки (например, из-за ошибки администратора или сбоя оборудования).

Определения из закона и практики

На практике граница между событием и инцидентом размыта. Неудачная попытка входа с перебором паролей это событие или инцидент? Если попыток было 5 и все неудачные, скорее всего событие. Если попыток было 50 000 за час с разных IP-адресов, это уже brute-force атака, и даже если она не удалась, большинство организаций классифицируют это как инцидент.

Именно поэтому в каждой организации должна быть утверждённая процедура классификации. Кто принимает решение, что событие переросло в инцидент? На основании каких критериев? Запрос «кто классифицирует событие ИБ как инцидент ИБ» часто встречается в поисковых системах. Ответ зависит от зрелости организации. В компаниях с SOC это аналитик первой или второй линии. В небольших организациях, как правило, ответственный за ИБ, назначенный в соответствии с Указом Президента РФ от 01.05.2022 № 250.

Есть ещё один нюанс. Для целей 187-ФЗ используется термин «компьютерный инцидент», а для целей 152-ФЗ и внутренних процессов чаще используют «инцидент информационной безопасности» или «инцидент ИБ». Юридически это разные понятия с разными правовыми последствиями. Утечка персональных данных это инцидент ИБ по 152-ФЗ, но не обязательно компьютерный инцидент по 187-ФЗ (если организация не является субъектом КИИ). Зато если организация субъект КИИ и произошла утечка, то уведомлять придётся и Роскомнадзор, и НКЦКИ. Подробнее об этом в следующем разделе.

Кто обязан реагировать и по каким правилам

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

Субъекты КИИ и 187-ФЗ

Федеральный закон от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» определяет субъектов КИИ [критической информационной инфраструктуры] как государственные органы, учреждения, юридические лица и ИП, которым принадлежат информационные системы, сети и АСУ в 14 сферах деятельности. Среди них здравоохранение, наука, транспорт, связь, энергетика, банковская сфера и иные сферы финансового рынка, топливно-энергетический комплекс, атомная энергия, оборонная, ракетно-космическая, горнодобывающая, металлургическая и химическая промышленность, а также государственная регистрация прав на недвижимое имущество.

На практике под 187-ФЗ подпадает почти любая крупная организация. Больница, банк, завод, оператор связи, транспортная компания. Если есть информационная система в одной из 14 сфер, организация автоматически становится субъектом КИИ. Даже если ещё не провела категорирование.

Статья 9 закона устанавливает обязанность незамедлительно информировать ФСБ России о компьютерных инцидентах через НКЦКИ [Национальный координационный центр по компьютерным инцидентам]. Сроки конкретизированы в приказе ФСБ России от 25.12.2025 № 547 (заменившем ранее действовавший приказ № 282). Для значимых объектов КИИ (ЗОКИИ) [значимый объект критической информационной инфраструктуры] информация передаётся не позднее 3 часов с момента обнаружения. Для остальных объектов КИИ срок составляет 24 часа.

Три часа. Не рабочих дней, не суток. Три астрономических часа. За это время нужно верифицировать инцидент, собрать первичную информацию и отправить её в ГосСОПКА [Государственная система обнаружения, предупреждения и ликвидации последствий компьютерных атак]. Без подготовленного плана реагирования уложиться в этот срок практически невозможно.

Перечень передаваемых сведений установлен приказом ФСБ России от 24.07.2018 № 367, а порядок обмена информацией между субъектами КИИ и НКЦКИ регулирует приказ ФСБ России от 24.07.2018 № 368.

Операторы ПДн и 152-ФЗ

Любая организация, которая обрабатывает персональные данные, подпадает под Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных». С 1 сентября 2022 года закон обязывает оператора уведомлять Роскомнадзор об утечках.

Сроки жёсткие. 24 часа на первичное уведомление о факте утечки. 72 часа на результаты внутреннего расследования. Нужно установить причину, оценить вред субъектам персональных данных и описать принятые меры. Форма уведомления электронная, через портал Роскомнадзора.

И тут важный момент. С 30 мая 2025 года (Федеральный закон от 30.11.2024 № 420-ФЗ) за несвоевременное уведомление юридическим лицам грозит штраф от 1 до 3 миллионов рублей. Но это ещё не всё. За повторные утечки введены оборотные штрафы от 1% до 3% годовой выручки, но не менее 20 миллионов и не более 500 миллионов рублей. Для компании с выручкой в миллиард это от 20 до 30 миллионов. Для крупного бизнеса суммы могут быть катастрофическими.

Финансовые организации и Банк России

Для банков и некредитных финансовых организаций (НФО) действуют дополнительные требования. С 29 марта 2025 года для кредитных организаций действует Положение Банка России от 30.01.2025 № 851-П, которое заменило ранее действовавшее Положение № 683-П. Для НФО продолжает действовать Положение № 757-П.

Банки передают информацию об инцидентах в ГосСОПКА через инфраструктуру ФинЦЕРТ [Центр мониторинга и реагирования на компьютерные атаки в кредитно-финансовой сфере Банка России]. Срок передачи составляет 3 часа с момента обнаружения. На расследование и предоставление результатов отводится 30 дней.

Тут возникает практическая сложность. Большинство крупных банков одновременно являются субъектами КИИ. А значит, они обязаны параллельно уведомлять и НКЦКИ (по 187-ФЗ), и ФинЦЕРТ (по 851-П). Формы разные, регламенты разные, сроки при этом одинаковые. На практике это означает, что у банка должна быть отлаженная процедура двойного уведомления. Иначе один из регуляторов окажется без информации.

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

С 1 марта 2026 года вступил в силу приказ ФСТЭК России от 11.04.2025 № 117. Он заменяет действовавший с 2013 года приказ № 17 и существенно расширяет сферу регулирования. Теперь требования распространяются не только на государственные информационные системы (ГИС), но и на информационные системы государственных органов, государственных унитарных предприятий и учреждений.

Приказ вводит принципиально новую модель. Вместо разовой аттестации и редких проверок теперь требуется непрерывный мониторинг защищённости и регулярная оценка состояния ИБ с передачей результатов регулятору. Операторы ГИС обязаны обеспечить обнаружение, регистрацию и реагирование на инциденты ИБ, а также взаимодействие с ГосСОПКА.

Ещё одно нововведение, которое мало кто пока учитывает. Приказ содержит требования к защите информации при использовании систем искусственного интеллекта в ГИС. Нужно определять шаблоны запросов, контролировать тематику взаимодействия с ИИ и выявлять недостоверные ответы. Для организаций, которые уже внедрили чат-ботов или ИИ-ассистентов в свои ГИС, это новая область ответственности.

Если в ГИС обрабатываются персональные данные (а это почти всегда так), дополнительно применяется приказ ФСТЭК России от 18.02.2013 № 21. При использовании СКЗИ [средства криптографической защиты информации] подключаются требования приказа ФСБ России от 18.03.2025 № 117. Важно не путать два одноимённых документа, приказы ФСТЭК и ФСБ с одинаковым номером 117, оба приняты в 2025 году, но регулируют разные вопросы. Класс СКЗИ (КС1, КС2, КС3) определяется по классу защищённости ГИС и модели угроз.

Порядок реагирования на инцидент

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

Обнаружение и первичная оценка

Всё начинается с сигнала. SIEM зафиксировал аномалию. Пользователь сообщил о подозрительном письме. Антивирус заблокировал вредоносный файл. Сотрудник обнаружил, что данные утекли в открытый доступ. Источники бывают разные, но дальше алгоритм один.

Первый шаг после получения сигнала, верификация. Действительно ли это инцидент или ложное срабатывание? На этом этапе аналитик SOC (или ответственный за ИБ в небольшой организации) проверяет контекст. Какая система затронута, какие данные, есть ли признаки целенаправленной атаки или это сбой. По результатам принимается решение о классификации и приоритете.

Здесь важна скорость. Если организация является субъектом КИИ с ЗОКИИ, у неё 3 часа на уведомление НКЦКИ. Из них первые 30-60 минут уйдут на верификацию. Остаётся 2 часа на всё остальное. Без автоматизации (IRP/SOAR) и заранее подготовленных сценариев реагирования уложиться крайне сложно.

Локализация и сбор доказательств

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

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

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

Устранение причин и восстановление

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

Восстановление это не просто «включить всё обратно». Перед возвратом системы в эксплуатацию нужно убедиться, что причина устранена, а не замаскирована. Бывают случаи, когда организация восстанавливает систему из бэкапа, а бэкап уже содержит вредоносный код, который был внедрён за недели до обнаружения инцидента.

Анализ после инцидента

Post-incident review [анализ после инцидента] это этап, который пропускают чаще всего. Инцидент закрыт, системы работают, все выдохнули. Но без разбора полётов следующий инцидент закончится точно так же.

Что анализировать. Как инцидент был обнаружен и сколько времени прошло с момента компрометации до обнаружения (dwell time). Какие меры сработали, какие нет. Были ли нарушены сроки уведомления. Что нужно изменить в процедурах, правилах SIEM, составе команды. Результаты анализа фиксируются в отчёте и используются для обновления плана реагирования.

Приказ ФСБ России от 25.12.2025 № 547 прямо предусматривает этот этап, «принятие мер по предотвращению повторного возникновения компьютерного инцидента». Это не рекомендация. Это требование.

Уведомления: кого, когда, в какой форме

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

Тип организации	Регулятор	Срок уведомления	Срок расследования	Штраф за нарушение
Субъект КИИ (ЗОКИИ)	НКЦКИ (ФСБ России)	3 часа	По приказу ФСБ № 547	Ст. 13.12.1 КоАП
Субъект КИИ (без категории)	НКЦКИ (ФСБ России)	24 часа	По приказу ФСБ № 547	Ст. 13.12.1 КоАП
Оператор ПДн (утечка)	Роскомнадзор	24 часа	72 часа	1-3 млн руб., оборотные 1-3%
Банк	ФинЦЕРТ (Банк России)	3 часа	30 дней	По 851-П
НФО	ФинЦЕРТ (Банк России)	По 757-П	По 757-П	По 757-П

Разберём подробнее по каждому регулятору.

НКЦКИ и ГосСОПКА

Субъекты КИИ уведомляют НКЦКИ через техническую инфраструктуру ГосСОПКА. Если организация подключена к ГосСОПКА напрямую, информация передаётся через защищённый канал. Если не подключена, допускается отправка по электронной почте на адрес НКЦКИ или через личный кабинет на сайте cert.gov.ru.

Сроки. Для ЗОКИИ, не позднее 3 часов с момента обнаружения инцидента. Для остальных объектов КИИ, не позднее 24 часов. В уведомлении необходимо указать дату и время обнаружения, описание инцидента, категорию и тип инцидента, затронутые ресурсы, предпринятые меры. Полный перечень сведений определён приказом ФСБ России от 24.07.2018 № 367.

Роскомнадзор при утечке ПДн

Если инцидент связан с утечкой персональных данных, оператор обязан уведомить Роскомнадзор. Независимо от того, является ли организация субъектом КИИ. Уведомление подаётся через портал pd.rkn.gov.ru.

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

С 30 мая 2025 года ставки выросли кратно. Штраф за несвоевременное уведомление для юридических лиц составляет от 1 до 3 миллионов рублей. А если утечка повторная, включаются оборотные штрафы от 1% до 3% выручки за предшествующий год, с нижней планкой 20 миллионов рублей. Для справки: до мая 2025 года штраф составлял 100-300 тысяч рублей. Разница в 10 раз.

Банк России и ФинЦЕРТ

Кредитные организации уведомляют Банк России через ФинЦЕРТ. Технически информация передаётся в автоматизированную систему обработки инцидентов (АСОИ). Срок, 3 часа с момента обнаружения инцидента. Результаты расследования необходимо передать в течение 30 дней.

НФО (страховые компании, брокеры, микрофинансовые организации) также взаимодействуют с ФинЦЕРТ, но по Положению 757-П с несколько отличающимися формами отчётности.

Если банк или НФО одновременно являются субъектами КИИ (а это типичная ситуация для крупных участников финансового рынка), то уведомления идут параллельно. НКЦКИ по линии 187-ФЗ, ФинЦЕРТ по линии Банка России. Две формы, два канала, одни и те же 3 часа. Читайте подробнее о том, как построить SOC, который справится с такой нагрузкой.

Типичные ошибки при работе с инцидентами

За годы существования ГосСОПКА, ФинЦЕРТ и практики применения 152-ФЗ накопился характерный набор ошибок. Некоторые из них совершают даже зрелые организации с выстроенными процессами ИБ.

Путают событие с инцидентом

Самая распространённая проблема. Организация фиксирует тысячи событий в SIEM, но не имеет чётких критериев эскалации. В результате либо всё подряд объявляется инцидентом (и команда тонет в ложных тревогах), либо ничего не доходит до уведомления (и реальный инцидент остаётся незамеченным). Решение простое, но требует усилий. Нужна документированная матрица классификации с конкретными пороговыми значениями.

Нарушают сроки уведомления

Три часа для ЗОКИИ, 24 часа для прочих субъектов КИИ, 24+72 для операторов ПДн. Эти сроки нарушаются постоянно. Причины разные. Долгая верификация. Бюрократия внутри организации (согласование с юристами, руководством). Отсутствие контактной информации НКЦКИ у дежурной смены. Нет шаблона уведомления. Каждая из этих причин устраняется на этапе подготовки, до того как инцидент произойдёт.

Не сохраняют доказательства

Классика. Администратор обнаруживает скомпрометированный сервер и немедленно переустанавливает операционную систему. Или перезагружает сервер, уничтожая содержимое оперативной памяти. Или чистит журналы «для порядка». В результате расследовать нечего. Причина инцидента неизвестна, виновник не установлен, а регулятору нечего показать в ответ на запрос.

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

Нет плана реагирования

Удивительно, но в 2026 году многие организации до сих пор не имеют утверждённого плана реагирования на инциденты. Даже среди субъектов КИИ. Когда инцидент происходит, начинается хаос. Кто принимает решение об изоляции? Кто звонит в НКЦКИ? Кто готовит уведомление? Кто общается со СМИ, если утечка стала публичной?

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

Что нужно подготовить заранее

План реагирования: минимальный набор

План реагирования на инциденты ИБ не должен быть стостраничным документом, который никто не читает. Достаточно практичного документа на 10-15 страниц, который каждый участник процесса может найти и прочитать за 10 минут.

Минимальный состав. Матрица классификации инцидентов (что считать инцидентом, какие уровни критичности). Контактная информация: НКЦКИ, Роскомнадзор, ФинЦЕРТ (если применимо), руководство, юристы, PR. Шаблоны уведомлений для каждого регулятора. Порядок эскалации: кто принимает решения на каждом уровне. Порядок сохранения доказательств. Порядок восстановления систем.

План должен быть протестирован. Хотя бы раз в год провести учебную тревогу (tabletop exercise). Собрать команду, зачитать сценарий инцидента, пройти по плану. Вы удивитесь, сколько пробелов обнаружится. Подробнее о построении процесса реагирования читайте в нашей экспертной статье «SOAR: автоматизация реагирования на инциденты».

Команда и роли

Реагирование на инцидент это командная работа. Даже в небольшой организации нужно заранее распределить роли. Кто координирует процесс (incident manager). Кто проводит техническое расследование. Кто готовит уведомления для регуляторов. Кто общается с руководством. Кто взаимодействует со СМИ и клиентами, если инцидент стал публичным.

В организациях с SOC роли обычно уже распределены. Но даже там возникают проблемы с эскалацией. Аналитик первой линии обнаружил подозрительную активность в 3 часа ночи. Имеет ли он полномочия изолировать сервер без согласования? Может ли он позвонить CTO и разбудить его? Эти вопросы решаются не в момент инцидента, а заранее, в плане реагирования.

Инструменты мониторинга и расследования

Без инструментов обнаружить инцидент вовремя практически невозможно. Минимальный набор для организации, подпадающей под 187-ФЗ. SIEM для сбора и корреляции событий. Средство обнаружения вторжений (IDS/IPS). Антивирусная защита на всех конечных точках. Средство анализа сетевого трафика (NTA). Если бюджет позволяет, добавить EDR для глубокого мониторинга конечных точек и IRP/SOAR для автоматизации реагирования.

Для расследования нужен другой набор. Средства форензики (снятие образов дисков, анализ памяти). Средства анализа вредоносного ПО (песочница). Доступ к киберразведке (Threat Intelligence). Система тикетов для отслеживания хода расследования. Подробнее об этом читайте в материале «SOC: когда работает, а когда нет?».

И главное. Все эти инструменты бесполезны без людей, которые умеют ими пользоваться. Управление инцидентами ИБ это не про технологии, это про процессы и компетенции.

Итоги

Инцидент ИБ это не абстрактная угроза из учебника. Это конкретная ситуация с конкретными юридическими последствиями. Штрафы за несвоевременное уведомление измеряются миллионами рублей. Оборотные штрафы за повторные утечки могут достигать сотен миллионов. Регуляторов стало больше, сроки жёстче, контроль строже.

Вот что стоит запомнить из этой статьи. Событие, инцидент и компьютерная атака это юридически разные вещи, и от правильной классификации зависит, кого и когда уведомлять. Субъекты КИИ со значимыми объектами обязаны уложиться в 3 часа. Операторы ПДн должны сообщить в Роскомнадзор за 24 часа. Банки передают данные в ФинЦЕРТ тоже за 3 часа. Организация может подпадать под несколько режимов одновременно, и тогда уведомлять нужно всех параллельно.

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