Требования к реагированию на инциденты в сравнении по стандартам
Реагирование на инциденты — одна из пяти тем, которые требует каждый стандарт. Планы похожи; сроки уведомлений — нет. Вот как они соотносятся.
В этом материале рассматриваются 11 фреймворков, которые ControlMapping сопоставил на момент написания. С тех пор DORA, CPS 234, Cyber Essentials были добавлены 2026-10-27; их страницы и матрица покрытия уже включают их.
Реагирование на инциденты входит в общее ядро: каждый стандарт, который мы сопоставляем, его требует. Базовое требование одинаково везде: план, люди, которые знают свои роли, и способность обнаружить, сдержать, восстановить и извлечь уроки. Различия — в тестировании и, прежде всего, в том, кому и как быстро нужно сообщить.
Кто что требует
| Стандарт | Реагирование на инциденты | Связь |
|---|---|---|
| NIST CSF 2.0 | RS.MA-01RS.MA-02RS.MA-03RS.MA-04ID.IM-04 | Определение темы |
| ISO 27001 | A.5.24A.5.25A.5.26 | Соответствия |
| CIS v8.1 | CIS 17.1CIS 17.4CIS 17.5CIS 17.7CIS 17.9 | Соответствия |
| SOC 2 | CC7.4CC7.3 | Редакционные материалы |
| PCI DSS | 12.10.112.10.312.10.212.10.4 | Соответствия |
| CMMC | IR.L2-3.6.1IR.L2-3.6.3 | Соответствия |
| 800-53 | IR-4IR-8IR-2IR-3 | Соответствия |
| HIPAA | §164.308(a)(6)§164.308(a)(6)(ii) | Соответствия |
| GDPR | Art.33(1)Art.33(5) | Редакционные материалы |
| NIS2 | 3.13.5 | Соответствия |
| Essential Eight | ISM-1819 | Редакционные материалы |
Полные подробности и обоснование каждой связи: Реагирование на инциденты по фреймворкам →
План
Каждый стандарт ожидает документированной способности реагировать на инциденты: планирование, оценку и реагирование на инциденты по ISO 27001 (A.5.24–A.5.26), оценку инцидентов и реагирование на них по SOC 2 (CC7.3, CC7.4), план реагирования на инциденты по PCI DSS (12.10.1), обработку инцидентов по CMMC (IR.L2-3.6.1), процедуры реагирования на инциденты безопасности по HIPAA (§164.308(a)(6)) и политику обработки инцидентов и реагирования по NIS2 (пункты 3.1 и 3.5). Содержание согласовано: роли, уровни серьёзности, эскалация, локализация, устранение последствий, восстановление и извлечённые уроки.
Тестирование
PCI DSS — единственный стандарт с фиксированной периодичностью: проверка и тестирование плана не реже одного раза в год (12.10.2) и обучение людей, которые его выполняют (12.10.4). CMMC и SP 800-53 требуют тестирования способности (IR.L2-3.6.3, IR-3) с периодичностью, которую определяете вы. CIS предполагает регулярные учения (17.7). ISO 27001 и SOC 2 ожидают доказательств того, что план работает, но график не задают; обычный ответ — ежегодные настольные учения (tabletop).
Сроки уведомлений
Здесь стандарты действительно различаются:
| Стандарт | Кому сообщать | Срок |
|---|---|---|
| NIS2 | CSIRT или компетентный орган | Предварительное уведомление в течение 24 часов; уведомление о инциденте в течение 72 часов; итоговый отчёт в течение одного месяца |
| GDPR | Надзорный орган (нарушения безопасности персональных данных) | В течение 72 часов с момента, когда стало известно о нарушении (статья 33) |
| GDPR | Затронутые лица, если риск для них высок | Без неоправданной задержки (статья 34) |
| CMMC / DFARS | Министерство обороны США | В течение 72 часов по положению DFARS 252.204-7012 |
| HIPAA | Затронутые лица (Правило об уведомлении о нарушениях) | Без необоснованной задержки, не позднее 60 дней |
| PCI DSS | Платёжные системы и эквайрер | Согласно процедурам каждой платёжной системы (12.10.1) |
| ISO 27001, SOC 2 | Нормативного срока нет | Срок определяют ваш план и договоры |
Один инцидент может запустить сразу несколько таймеров. Атака программ-вымогателей на облачного провайдера в ЕС, который хранит персональные данные и обрабатывает платежи по картам, может в течение одного часа запустить процессы по NIS2, GDPR и платёжным системам.
Главные выводы
- Каждый стандарт требует плана реагирования на инциденты; содержание согласовано.
- Сроки уведомлений резко различаются: от 24 часов по NIS2 до 60 дней по HIPAA.
- Один инцидент может запустить несколько таймеров; ими должен управлять один координатор.
Что делать
- Напишите один план, который отвечает самым строгим требованиям к содержанию, и составьте список всех обязанностей по уведомлению, которые на вас распространяются, с указанием срока, адресата и ответственного.
- Определите, кто оценивает существенность. Таймер NIS2 на 24 часа начинается с момента, когда вы узнали о существенном инциденте; решение не может ждать понедельника.
- Тестируйте план не реже одного раза в год (правило PCI — хороший ориентир), включая сценарий во внерабочее время.
- Ведите учёт всех инцидентов и нарушений, уведомлены о них или нет: GDPR этого требует (статья 33(5)), и любой аудитор об этом спросит.
Страница темы «Реагирование на инциденты» содержит каждое требование с источником; тема «Уведомления» посвящена уведомлению. Наше руководство по NIS2 подробнее описывает процедуру уведомления.
Вопросы
Какие сроки уведомления об инцидентах установлены NIS2?
Предварительное уведомление в течение 24 часов с момента, как стало известно о существенном инциденте, уведомление об инциденте в течение 72 часов и итоговый отчёт в течение одного месяца.
Как часто нужно тестировать план реагирования на инциденты?
PCI DSS требует проверки и тестирования не реже одного раза в год (12.10.2). CMMC и SP 800-53 требуют тестирования способности реагирования на инциденты (IR.L2-3.6.3, IR-3). ISO 27001 и SOC 2 ожидают тестирования, но периодичность оставляют на ваше усмотрение.
Устанавливает ли ISO 27001 срок уведомления об инцидентах?
Нет. ISO 27001 требует управления инцидентами, включая внутреннее уведомление о событиях и реагирование на них, но нормативного срока уведомления регулятора не устанавливает. Сроки определяются законом (NIS2, GDPR), договорами и отраслевыми правилами.
Данные на 2026-10-27: цифры в этой публикации рассчитаны по текущей таблице соответствий и обновляются при её изменении. Соответствия связь установлена опубликованной таблицей соответствий (NIST, ENISA, CIS, PCI SSC) · Редакционные материалы Суждение ControlMapping там, где таблицы соответствий не существует; причина указана · есть только общий результат CSF 2.0: стоит проверить, но это не сопоставление · Нет сопоставления в наших данных в наших данных ничего не сопоставлено; часто это новая работа, но проверьте примечания о покрытии. Не является консультацией по соответствию.
Связанные публикации
Аналитика · 2026-10-27APRA CPS 234 и ISO 27001: что охватывает ваша СУИБ и что добавляет APRAСУИБ по ISO 27001 охватывает почти каждый пункт стандарта CPS 234 от APRA, однако APRA добавляет обязанности совета директоров, гарантии в отношении третьих сторон и жёсткие сроки уведомления.
Аналитика · 2026-10-27Cyber Essentials и Essential Eight: сравнение базовых наборов мерCyber Essentials в Великобритании и Essential Eight в Австралии нацелены на одни и те же распространённые атаки, но охватывают разные области. Что совпадает, что нет и почему.
Аналитика · 2026-10-27DORA и NIS2: что уже покрывает программа NIS2DORA и NIS2 во многом совпадают по мерам безопасности, но DORA добавляет реестр, условия договоров и тестирование на основе угроз. Статья за статьёй: что переносится.