Если компания внедряет ISO 27001, одной профилактики уже недостаточно. Даже при сильных мерах защиты информации остаются ошибки сотрудников, сбои, уязвимости, проблемы у подрядчиков, фишинг, неудачные изменения и реальные атаки. Поэтому зрелая СУИБ — система управления информационной безопасностью — должна не только снижать вероятность инцидентов, но и обеспечивать понятный, быстрый и управляемый ответ, когда что-то уже произошло. ISO/IEC 27001:2022 остается действующей базовой версией стандарта, а в 2024 году к ней было выпущено Amendment 1 по climate action, то есть сама логика стандарта сейчас рассматривается именно в редакции 2022 + Amendment 1:2024.
Для бизнеса это важно не только ради сертификации ISO 27001. Управление инцидентами напрямую влияет на простои, потери данных, отношения с клиентами, выполнение SLA, репутацию и способность компании быстро восстановить процессы. На практике именно качество реакции на инцидент часто показывает зрелость СУИБ лучше, чем красиво оформленные политики.
В логике актуального ISO/IEC 27002 тема инцидентов раскрыта не одной общей фразой, а набором отдельных мер: планирование и подготовка к управлению инцидентами, оценка и принятие решений по событиям, реагирование на инциденты, извлечение уроков и сбор доказательств. Это хороший ориентир для компаний, которые хотят выстроить не формальную процедуру, а рабочий процесс.
Что такое инцидент информационной безопасности простыми словами
Инцидент информационной безопасности — это ситуация, которая уже нарушает или реально угрожает конфиденциальности, целостности или доступности информации и требует реакции компании. Событие информационной безопасности — понятие шире: это может быть, например, необычная авторизация, срабатывание антивируса, попытка доступа, массовая рассылка писем или ошибка в журнале. Не каждое событие становится инцидентом, но любой серьезный инцидент обычно начинается с одного или нескольких событий, которые нужно вовремя заметить и правильно оценить. Такой подход согласуется с процессной логикой ISO/IEC 27035, где отдельно выделяются подготовка, обнаружение, сообщение, оценка и реагирование.
Проще говоря, инцидент — это уже не просто “что-то странное случилось”, а ситуация, для которой компании нужно принять решение: локализовать, расследовать, уведомить заинтересованные стороны, восстановить работу и не допустить повторения. Именно поэтому хорошая система управления инцидентами всегда включает не только обнаружение, но и критерии эскалации.
Почему управление инцидентами важно в ISO 27001
Требования ISO 27001 построены вокруг риск-ориентированного подхода. Это означает, что организация должна не только определить риски и выбрать меры защиты, но и уметь действовать, когда контроль не сработал полностью или риск все же реализовался. Инциденты в этой логике — не “исключение из системы”, а один из источников данных для улучшения СУИБ.
В зрелой СУИБ процесс управления инцидентами связан с оценкой рисков информационной безопасности, ролями и ответственностью, внутренними коммуникациями, корректирующими действиями, мониторингом и анализом результативности. Поэтому на аудите ISO 27001 обычно смотрят не только наличие регламента, но и то, понимают ли сотрудники, как сообщать об инциденте, ведутся ли записи, есть ли разбор причин и влияют ли инциденты на пересмотр рисков и мер защиты.
Какие инциденты рассматриваются в рамках ISO 27001
На практике речь идет не только о “кибератаках” в узком смысле. В процесс обычно попадают утечки данных, несанкционированный доступ, заражение вредоносным ПО, компрометация учетных записей, удаление или повреждение данных, ошибки сотрудников, сбои в облачной инфраструктуре, нарушения со стороны поставщиков, потеря устройств, неправильная настройка прав доступа, массовый фишинг и неудачные изменения в системах. Такой широкий охват соответствует подходу ISO/IEC 27001 и ISO/IEC 27002, где информационная безопасность рассматривается не только как ИТ-защита, а как управление рисками для бизнес-информации и процессов.
Хороший практический вопрос здесь звучит так: “Что в нашей компании действительно может привести к потере данных, остановке сервиса, нарушению обязательств перед клиентом или ущербу для бизнеса?” Если процесс инцидентов отвечает именно на этот вопрос, он полезен. Если он описывает только работу SOC или антивируса, он слишком узкий.
Как управление инцидентами связано с СУИБ
Управление инцидентами не должно жить отдельно от остальной системы. Оно связано с областью применения СУИБ, контекстом организации, оценкой рисков, приложением A ISO 27001, Statement of Applicability и операционными процедурами. В актуальной структуре ISO/IEC 27002 incident management разбит на отдельные контрольные области именно потому, что это не один шаг, а целый цикл: подготовка, оценка, реакция, извлечение уроков и работа с доказательствами.
Для компании это означает простую вещь: нельзя написать процедуру “реагирование на инциденты” и считать тему закрытой. Нужны еще роли, каналы сообщения, критерии серьезности, формы регистрации, сценарии эскалации, связь с рисками, а иногда и правила взаимодействия с подрядчиками, юристами, HR и руководством. Если часть инфраструктуры или процессов вынесена вовне, полезно учитывать и межорганизационную координацию, что отдельно отражено в ISO/IEC 27035-4:2024.
Какие цели у процесса управления инцидентами
У зрелого процесса обычно пять практических целей:
- быстро выявить и зафиксировать инцидент;
- правильно оценить его серьезность и влияние на бизнес;
- ограничить последствия и восстановить работу;
- понять причины и устранить их;
- снизить вероятность повторения.
Именно такой цикл соответствует общей логике ISO/IEC 27035-1:2023 и ISO/IEC 27035-2:2023, где incident management рассматривается как структурированный подход к подготовке, обнаружению, сообщению, оценке, реагированию и извлечению уроков.
Если в компании выполняются только первые два шага — “обнаружили и потушили” — процесс остается незрелым. С точки зрения ISO 27001 ценность появляется тогда, когда инцидент дает материал для улучшения СУИБ.
Какие роли и ответственность нужны
Одна из самых частых ошибок — считать, что инциденты касаются только ИТ или ИБ. На практике роли обычно распределяются шире. Сотрудники и пользователи должны уметь заметить и сообщить о подозрительной ситуации. ИТ и ИБ — провести первичную оценку, локализацию и координацию. Владельцы процессов — оценить бизнес-последствия. Руководство — участвовать в эскалации по серьезным случаям. Юристы, HR, комплаенс и PR могут подключаться, если есть утечка, дисциплинарный аспект, договорные обязательства или риск публичного кризиса.
В небольшой компании один человек может совмещать несколько ролей. В крупной — роли обычно разводятся. Важно не количество участников, а то, чтобы было заранее понятно: кто принимает сообщение, кто принимает решение о классификации, кто координирует response, кто фиксирует записи и кто закрывает инцидент.
Как организовать выявление и регистрацию инцидентов
Процесс начинает работать только тогда, когда сотруднику понятно, куда именно сообщать о проблеме. У компании должен быть простой канал сообщения: service desk, специальный mailbox, форма, телефон, внутренний чат, SIEM-триггер или комбинация этих вариантов. Главное — чтобы сообщение не зависело от памяти конкретного специалиста и не терялось в переписках.
Минимальная регистрация обычно включает дату и время, источник сообщения, краткое описание, затронутый актив или процесс, первые признаки влияния, принятые срочные меры, ответственного и текущий статус. Этого уже достаточно, чтобы процесс был управляемым и пригодным для аудита. Для более зрелого уровня добавляют классификацию, корневую причину, оценку ущерба, решения по уведомлениям и ссылки на корректирующие действия.
Как классифицировать инциденты по степени серьезности
Классификация нужна не ради красивой таблицы, а чтобы компания не тратила одинаковое внимание на все случаи подряд. Обычно используют критерии масштаба, влияния на критичные данные или сервисы, срочности, регуляторных последствий, вовлеченности клиента или поставщика и вероятности повторения.
Например, один неверный клик пользователя и компрометация корпоративной почты — это уже разные уровни реагирования. Потерянный ноутбук без чувствительных данных и остановка прод-сервиса для клиентов — тоже. Чем яснее критерии серьезности, тем меньше споров во время реального инцидента и тем выше скорость реакции.
Как должен работать процесс реагирования
Практически процесс реагирования обычно выглядит так: получение сообщения → первичная оценка → классификация → локализация → анализ → устранение причины или техническое восстановление → проверка восстановления → закрытие → lessons learned. Такая последовательность хорошо совпадает с логикой ISO/IEC 27035 и с тем, как в ISO/IEC 27002 разделены planning, assessment, response и learning.
Важно, чтобы у компании были заранее определены действия для типовых сценариев: фишинг, компрометация учетной записи, утечка данных, вредоносное ПО, отказ сервиса, ошибка доступа, проблема у облачного провайдера. Это не обязательно должны быть сложные playbook-документы на десятки страниц. Для многих компаний достаточно коротких и понятных runbook-инструкций с контактами, шагами изоляции и правилами эскалации.
Как расследовать причины инцидента
Незрелый подход — убрать симптомы и на этом остановиться. Зрелый — понять, почему инцидент вообще стал возможен. Причина может быть в отсутствии многофакторной аутентификации, плохом управлении доступом, неудачном изменении, слабом обучении персонала, пробеле в договоре с поставщиком или в неактуальном SoA.
Полезно разбирать не только техническую причину, но и системную: какой процесс сработал слабо, кто не получил информацию вовремя, какая мера защиты была отсутствующей или неэффективной. Именно такие выводы потом превращаются в корректирующие действия и улучшения СУИБ.
Какие документы и записи обычно нужны
Обычно компании нужны: политика или регламент по incident management, роли и схема эскалации, критерии классификации, форма карточки инцидента, журнал инцидентов, шаблон расследования, шаблон post-incident review, правила хранения доказательств и связь с реестром рисков и корректирующими действиями. Такой набор хорошо ложится на требования ISO 27001 и практические ориентиры ISO/IEC 27002 и ISO/IEC 27035.
Отдельно стоит выделить доказательства. В актуальном ISO/IEC 27002 среди мер incident management есть и контроль по collection of evidence. Это особенно важно, если инцидент может привести к спору с поставщиком, дисциплинарным мерам, юридическим действиям или внешнему расследованию.
Как управление инцидентами связано с рисками, SoA и корректирующими действиями
Инцидент не должен “умирать” в журнале. Его результаты нужно использовать для пересмотра оценки рисков информационной безопасности, корректировки мер защиты, обновления Statement of Applicability и планов обработки рисков. Если произошла компрометация аккаунта, это повод пересмотреть не только сам кейс, но и зрелость контроля доступа, осведомленность пользователей, процессы offboarding и требования к поставщикам почтовых сервисов.
Именно здесь видно, работает ли СУИБ как система. Если инциденты повторяются, а реестр рисков и SoA остаются без изменений, значит организация реагирует симптоматически. Если после серьезного инцидента меняются критерии, меры, инструкции и обучение, значит система развивается.
Что обычно проверяют на аудите ISO 27001
Аудитор обычно смотрит на шесть вещей: есть ли определенный процесс; понятны ли роли; умеют ли сотрудники сообщать об инцидентах; ведутся ли записи; есть ли разбор причин и lessons learned; влияет ли процесс на риски и улучшения. В логике актуального ISO/IEC 27002 и ISO/IEC 27035 это как раз ключевые элементы зрелого incident management.
На практике слабые места видны быстро. Если сотрудники не знают, что считать инцидентом, нет критериев серьезности, карточки пустые, расследования поверхностные, а однотипные случаи повторяются, процесс выглядит формальным. И наоборот: даже простая, но дисциплинированная система обычно производит хорошее впечатление на аудите.
Типовые ошибки и слабые места
Чаще всего компании:
- путают события и инциденты;
- не назначают владельца процесса;
- не дают сотрудникам понятный канал сообщения;
- ведут учет только крупных случаев, игнорируя повторяющиеся “мелочи”;
- устраняют последствия, но не анализируют причины;
- не связывают инциденты с рисками и корректирующими действиями;
- не тренируют персонал;
- не готовят сценарии для типовых ситуаций.
Почти все эти ошибки приводят к одному результату: компания реагирует хаотично, а не управляемо. Именно против этого и направлены практики ISO/IEC 27035 и controls по incident management в ISO/IEC 27002.
Практические рекомендации
Начать можно без большой бюрократии. Для большинства компаний уже полезно сделать пять вещей: определить роли, утвердить простой канал сообщения, ввести карточку регистрации, согласовать критерии серьезности и назначить короткий post-incident review после значимых случаев. Это даст реальную управляемость даже до глубокой автоматизации.
Следующий уровень зрелости — связать incident management с обучением, метриками и рисками. Хорошие показатели здесь: время до обнаружения, время до локализации, время до восстановления, доля повторных инцидентов, доля кейсов с определенной корневой причиной и процент выполненных corrective actions. Это не обязательный “универсальный набор”, но такие метрики хорошо показывают, приносит ли процесс пользу бизнесу.
Итоги
Управление инцидентами информационной безопасности по ISO 27001 — это не формальная процедура и не приложение к ИТ-поддержке. Это важный элемент зрелой СУИБ, который помогает компании быстрее замечать нарушения, уменьшать ущерб, извлекать уроки и улучшать меры защиты информации. Логика актуальных ISO/IEC 27001, ISO/IEC 27002 и серии ISO/IEC 27035 прямо поддерживает именно такой подход: подготовка, оценка, реагирование, обучение на инцидентах и системное улучшение.
Полезные сервисы и ресурсы по сертификации ISO
Планируете пройти сертификацию по ГОСТ Р ИСО/МЭК 27001 или другим стандартам? Отправьте одну заявку и получите до 5 коммерческих предложений за 1 раз только от аккредитованных ФСА органов по сертификации.
📢 Подписывайтесь на наш Telegram-канал с новостями и статьями по ISO;
💬 Присоединяйтесь к чату специалистов по системам менеджмента;
💰 Рассчитайте примерную стоимость сертификации в нашем онлайн-калькуляторе;
🗺️ Найдите орган по сертификации в нашем реестре — по стандарту или прямо на карте.
Планируете пройти сертификацию по ГОСТ Р ИСО/МЭК 27001 или другим стандартам? Отправьте одну заявку и получите до 5 коммерческих предложений за 1 раз только от аккредитованных ФСА органов по сертификации.
📢 Подписывайтесь на наш Telegram-канал с новостями и статьями по ISO;
💬 Присоединяйтесь к чату специалистов по системам менеджмента;
💰 Рассчитайте примерную стоимость сертификации в нашем онлайн-калькуляторе;
🗺️ Найдите орган по сертификации в нашем реестре — по стандарту или прямо на карте.