Когда приходит атака, решает скорость реакции. Как NIS2 и DORA меняют ответственность руководства

За невыполнение мер безопасности или несообщение о киберинцидентах чешским компаниям грозит штраф до 250 миллионов крон или 2 % от оборота (в зависимости от того, какая сумма выше). Ответственность за выполнение этих обязанностей несёт непосредственно руководство компании, которому могут грозить личные санкции, включая финансовые взыскания и запрет на занятие должности.

DORA ещё строже. Банкам, страховым компаниям и инвестиционным фирмам грозят штрафы до 2 % мирового оборота (или фиксированные суммы, например до 10 миллионов евро) и личные санкции для руководства до 1 миллиона евро. Она жёстко нацелена и на ключевых ИТ-поставщиков финансового сектора, для которых допускает многократные штрафы до 1 % среднего дневного мирового оборота, а также административные санкции до 5 миллионов евро.

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

На практике это означает прежде всего:

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

⇢ проверить, соответствует ли защита реальной работе и сохраняет ли целостность сервисов: понимание того, покрывает ли периметр безопасности места, где сегодня реально работают приложения, сервисы и API и откуда к ним подключаются пользователи, партнёры и поставщики, а не только исторически очерченные границы инфраструктуры.

⇢ обеспечить возможность своевременной регуляторной отчётности: единые данные, чётко определённые роли и ответственность и заранее подготовленные процедуры уведомления об инцидентах, которые могут угрожать доступности или целостности сервисов, в установленные законом сроки.

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

С NIS2 вы уже должны уметь доказать, что знаете, как управлять безопасностью

NIS2 принципиально расширяет круг организаций, которые обязаны управлять кибербезопасностью системно и доказуемо. Она касается уже не узкого круга критической инфраструктуры, а до 6 тысяч компаний в самых разных отраслях. От энергетики, транспорта и здравоохранения через логистику, производство и ритейл до цифровых услуг и ИТ-аутсорсинга. Для многих организаций это первое регулирование, которое прямо говорит им: безопасность не опция, и решать её ad hoc недостаточно.

Главное изменение по сравнению с прошлым, таким образом, не в отдельных технических мерах, а в самом подходе. NIS2 не интересует, какой инструмент вы используете, а держите ли вы управление под контролем. Больше нельзя полагаться на то, что у вас внедрены какие-то инструменты безопасности, если:

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

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

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

DORA: даже если ИТ на аутсорсе, ответственность остаётся на учреждении

DORA говорит ясно: если откажет технология, откажет и финансовое учреждение, сколько бы резервов у него ни было. Поэтому регламент ставит цифровую операционную устойчивость на один уровень с традиционным управлением рисками. Для банков, страховых и инвестиционных компаний, платёжных учреждений и их технологических партнёров это значит, что «справиться с инцидентом» уже недостаточно. Они должны уметь предотвращать риски, быстро их обнаруживать, справляться с последствиями, восстанавливать работу и весь процесс документировать для регуляторов.

На практике DORA заставляет организации привести в порядок четыре области, которые раньше часто существовали раздельно или только на бумаге:

• управление ИКТ-рисками как непрерывный процесс, а не разовый аудит,
  
  
• уведомление о серьёзных инцидентах по чётким критериям и в предписанной структуре,
  
  
• тестирование устойчивости, которое должно выявлять реальные слабые места, а не просто «закрывать обязанность»,
  
  
• управление рисками поставщиков, включая договоры, аудит, обзор зависимостей и готовые сценарии на случай отказа поставщика.

И здесь принципиальный сдвиг по сравнению с прошлым прежде всего в ответственности. Даже если часть инфраструктуры на аутсорсе или работает в облаке, полная ответственность лежит на финансовом учреждении. Аргумент вроде «это была проблема у поставщика» от ответственности не освобождает. Если у вас нет обзора, контроля и возможности вмешаться в случае инцидента безопасности, это регуляторная проблема.

Регуляции NIS2 и DORA прямо переносят ответственность за кибербезопасность с чисто операционного уровня на уровень управления организацией. Это не значит, что уставные органы берут на себя технические задачи ИТ-команд, но они отвечают за настройку, утверждение и надзор над системой управления рисками безопасности в целом.

На практике для руководства это означает прежде всего обязанность:

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

С внедрением обоих актов связаны и данные исследования IAPP Privacy Governance Report 2024, согласно которому более 80 % специалистов сообщают, что получили дополнительные задачи сверх своей обычной повестки в области защиты данных. Этот тренд подтверждает и более новый EU Digital Laws Report 2025. Примерно 32-40 % респондентов теперь отвечают за соответствие требованиям по кибербезопасности (например, NIS2).

Как выполнить эту ответственность на практике?

С приходом NIS2 и DORA архитектура безопасности становится не просто техническим выбором, а управленческим риском. То, как у вас построена безопасность, напрямую определяет, как быстро ваша организация способна действовать при инциденте: реагирует ли она автоматически или только после серии ручных вмешательств, эскалаций и согласований. Оценка регуляторов затем зависит от того, удаётся ли справиться с инцидентом за минуты или лишь тогда, когда он уже влияет на работу, клиентов и регуляторные обязанности.

Скорость реакции сегодня – фактический регуляторный параметр. Но некоторые традиционные модели безопасности, особенно основанные на управляемом вручную, жёстко очерченном периметре, здесь упираются в свои пределы.

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

В традиционном, управляемом вручную периметре реакция на инцидент обычно состояла из нескольких шагов: инцидент нужно было оценить, собрать контекст, принять решение о вмешательстве, согласовать изменение, развернуть правило и проверить влияние на работу. У каждого из этих шагов был свой владелец, часто другая команда, и между фазами возникали задержки. Но атаки внутренним процессам организации не подчиняются. DDoS-атаки сегодня – это не часовые и не дневные инциденты, многие из них длятся лишь десятки минут. Чтобы защита отвечала смыслу регулирования и защищала работу, противодействие должно произойти быстрее, чем длится сама атака. Защита, которая запускается лишь после круга эскалаций и согласований, приходит поздно, даже если технически настроена правильно.

К этому добавляются физические пределы ёмкости: как только канал перегружен, защита теряет эффективность. Распределённые облачные модели, напротив, позволяют реагировать мгновенно и останавливать атаку до того, как она поставит под угрозу доступность сервиса.

Регуляторы хотят доказательств, деклараций уже недостаточно

NIS2 и DORA интересует не только то, удалось ли остановить атаку, но и то, способна ли организация доказуемо задокументировать, что произошло, когда она отреагировала, кто принимал решения, какие шаги были предприняты и с какими последствиями. Если безопасность раздроблена между несколькими инструментами, командами и поставщиками, аудиторский след складывается с трудом и часто лишь задним числом. Единый, централизованно управляемый подход, напротив, даёт согласованные данные для внутренней оценки и регуляторной отчётности, измеримое время реакции, прослеживаемые решения и единый учёт инцидентов.

NIS2 и DORA сосредоточены на управлении рисками, инцидентами, непрерывности работы и отношениях с поставщиками. Поэтому на первый план выходят рамки, основанные на исполнимых контролях, аудитах и договорной ответственности. Например, Cloudflare указывает, что её подход к защите данных признан в 39 юрисдикциях.

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