Skip to content

System Management

DORA, инциденты и риски: почему бизнесу это важно уже сейчас

DORA, інциденти та ризики

DORA (Digital Operational Resilience Act) часто воспринимают как «что-то для банков в ЕС», но смысл гораздо шире: компания должна уметь управлять ИКТ-рисками, быстро восстанавливаться после сбоев и доказывать партнёрам, что контроль работает. Для украинского бизнеса это актуально, если вы работаете с финансовыми учреждениями, обрабатываете персональные данные, предоставляете ИТ/аутсорс услуги, имеете европейских клиентов или стремитесь пройти vendor due diligence без боли.

Если совсем просто: DORA хочет видеть не формальный набор документов, а операционную устойчивость. Как техосмотр автомобиля: можно не любить процедуру, но она спасает, когда случается неприятность.

Как ISO 27005 и ISO 27035 помогают выполнять логику DORA

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

  • ISO/IEC 27005 — про риски: как оценивать, приоритезировать, назначать владельцев и контролировать выполнение.
  • ISO/IEC 27035 — про инциденты: как выявлять, реагировать, документировать, коммуницировать и делать выводы.

В паре эти стандарты закрывают «сердце» DORA: управление рисками + управление инцидентами + непрерывное улучшение.

ISO 27005 на практике: как проводится оценка рисков информационной безопасности

ISO 27005 на практиціЧтобы оценка рисков информационной безопасности не была эпизодической формальностью «для проверок», процесс должен быть системным, а результаты — понятными для принятия бизнес-решений. Практический путь выглядит так:

  1. Определить контекст
    Какие процессы критичны (продажи, производство, поддержка, бухгалтерия), какие системы их поддерживают, какой аппетит к риску приемлем.
  2. Описать активы
    Данные (базы клиентов, финансы, коммерческая тайна), инфраструктура (серверы, облако), люди и поставщики.
  3. Оценить угрозы и уязвимости
    Фишинг, ransomware, ошибки конфигураций, слабые доступы, зависимость от подрядчиков, отсутствие резервного копирования и т. п.
  4. Рассчитать риск и приоритизировать
    Вероятность × влияние (финансы, репутация, простой, юридические последствия). Важно: лучше иметь 15–30 качественно описанных рисков, чем 200 «для галочки».
  5. План обработки рисков
    Избегаем / уменьшаем / передаём / принимаем — с дедлайнами, ответственными, метриками эффективности.

Именно так появляется управляемый менеджмент рисков информационной безопасности, который можно показать руководству, партнёру или аудитору — и он будет логичным, а не «с потолка».

Список рисков кибербезопасности для организации по ISO 27005: что обычно попадает в топ

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

  • Фишинг и компрометация почты (BEC) → подмена реквизитов, мошеннические платежи, утечка переписки.
  • Ransomware и блокировка доступа к данным → простой критических сервисов, потери, восстановление из резервных копий.
  • Утечка данных из-за настроек облака или «лишних» прав доступа → штрафы, претензии клиентов, репутационные потери.
  • Риски поставщиков (SaaS, аутсорс, подрядчики) → «вас взломали через них», сбои доступности, слабые SLA.
  • Непатченные уязвимости → эксплуатация известных CVE, компрометация сервера/рабочей станции.
  • Ошибки персонала и инсайдерские инциденты → случайная публикация данных, копирование на личные носители, «человеческий фактор».
  • DDoS/отказ сервиса → недоступность сайта/кабинета/платежей, срыв обслуживания клиентов.

После составления списка важно «приземлить» каждый пункт: владелец риска, текущие контроли, пробелы, конкретные действия и KPI. Тогда реестр рисков становится инструментом управления, а не таблицей, которая пылится.

ISO 27035: как построить управляемое реагирование на инциденты

ISO 27035 превращает панику «нас атакуют!» в чёткий процесс. Минимальный набор, который реально работает в бизнесе:

1) Классификация инцидентов и правила эскалации

Что считаем инцидентом? Какие уровни критичности? Когда подключать руководство, юристов, PR или поставщика?

2) Роли и ответственность

Даже если у вас небольшая команда, должно быть понятно: кто принимает решения, кто «тушит пожар», кто коммуницирует с клиентами, кто фиксирует доказательства.

3) Журналирование, сохранение доказательств и контроль времени

Без логов и дисциплины фиксации фактов инцидент быстро превращается в «историю со слов». ISO 27035 помогает оформить это так, чтобы потом можно было разобраться — и технически, и юридически.

4) Плейбуки под наиболее вероятные сценарии

Начните с 3–5: фишинг, ransomware, утечка данных, компрометация учётной записи, недоступность сервиса. Это как аптечка: главное, чтобы была под рукой и понятной.

5) Пост-анализ и улучшения

После инцидента важно не только «восстановить», но и сделать выводы: что сломалось в процессах, какие контрмеры нужны, как обновить риски.

Подробнее о структуре процесса реагирования — на странице ISO 27035.

Как объединить ISO 27005 и ISO 27035, чтобы DORA не осталась на бумаге

Самый сильный эффект даёт цикл:
инциденты → уроки → обновление рисков → новые контроли → тренировки → меньше инцидентов.

Вот как это выглядит в реальной жизни:

  • После фишинговой атаки вы не просто сменили пароль, а повысили риск в реестре, добавили MFA, обновили обучение персонала и метрики.
  • После сбоя у поставщика вы пересмотрели SLA, резервные сценарии, процедуру переключения и критерии приемлемости простоя.
  • После утечки данных вы отработали коммуникации, доступы, DLP/логирование и сделали это частью регулярного контроля.

Так DORA становится системой привычек, а не разовым проектом.

С чего начать: короткий план на 30–60 дней

Чтобы не зависнуть в теории, можно двигаться маленькими шагами:

  • описать 5–10 критичных процессов и систем;
  • провести стартовую оценку рисков и составить реестр рисков;
  • сформировать список рисков кибербезопасности для организации по ISO 27005 с приоритетами;
  • определить команду реагирования и минимальные плейбуки по ISO 27035;
  • провести tabletop-упражнение (1–2 часа) и зафиксировать улучшения.

После этого у вас уже есть «скелет» управления — и его можно последовательно наращивать.

Украинская компания ООО «Систем Менеджмент» может помочь внедрить эти подходы так, чтобы они работали под реалии украинского бизнеса: с практическими шаблонами, обучением и фокусом на результат.