Две разные рамки, одна путаница: NIS2 vs DORA простыми словами
Приветствую, дорогой читатель!
Сегодня разбираем две аббревиатуры, которые в ЕС всё чаще всплывают в разговорах про облако и безопасность: NIS2 и DORA. Их постоянно путают, потому что обе про риски, инциденты, процессы и “устойчивость”. Но на деле это две разные рамки, и у них разные точки входа.
NIS2 — это директива, которая задаёт общий каркас требований по кибербезопасности для широкого набора критичных и важных секторов в ЕС. Её идея — поднять базовый уровень управления киберрисками и готовности к инцидентам у организаций, которые важны для экономики и общества.
DORA — это регламент, который нацелен именно на финансовый сектор и его цифровую операционную устойчивость: как финансовые организации (и их ключевые ИКТ-поставщики) должны выдерживать, реагировать и восстанавливаться после ИТ-сбоев и киберинцидентов. В DORA отдельно и жёстко выделен блок управления рисками третьих сторон — включая облачных провайдеров.
Почему их путают? Потому что снаружи они звучат одинаково: “киберриски”, “контроль”, “уведомления”, “поставщики”. Но если упростить до одного понятного различия:
- NIS2 чаще отвечает на вопрос: «Вы — организация из списка критичных/важных сфер. Какие меры кибербезопасности вы обязаны внедрить и как должны сообщать о значимых инцидентах?»
- DORA отвечает на вопрос: «Вы — финорганизация (или её критичный ИКТ-поставщик). Как вы обеспечиваете цифровую устойчивость, как тестируете её и как управляете зависимостями от подрядчиков и облака?»
И вот почему “облако” постоянно оказывается в центре внимания: для NIS2 это часть вашей инфраструктуры и цепочки поставок, а для DORA — часто одна из самых критичных зависимостей, которую нужно описывать, контролировать и уметь быстро обходить в случае проблем.
Дальше логично перейти к самому практичному: кого и когда это касается, какие роли появляются у провайдера и у заказчика, и почему статус одной и той же компании может отличаться в зависимости от того, в какой она цепочке и какой сектор обслуживает.
Кого это касается: scope, роли и “кто вы в этой истории”
Для начала разберём NIS2. Здесь логика простая: ЕС смотрит на отрасль и роль организации в экономике, а затем относит её к категории essential entities или important entities (по сути — разные уровни надзора и последствий).
Как правило, классификация зависит от сектора и размера (например, средние/крупные организации в перечисленных секторах), плюс есть исключения и отдельные категории, которые могут попадать в периметр иначе.
Почему это важно именно для облака: NIS2 явно рассматривает “цифровую инфраструктуру” как один из ключевых секторов, а облачные услуги часто оказываются в фокусе либо напрямую (как часть цифровой инфраструктуры), либо как критичная часть цепочки поставок для организаций из периметра.
Отдельный нюанс по срокам: NIS2 — директива, её внедряют через национальные законы. Формальный дедлайн на транспозицию был 17 октября 2024, но по странам темпы различались, поэтому в реальности требования “включались” не одинаково.
А вот DORA устроен иначе. Он не пытается охватить “всё важное” сразу — он прицельно про цифровую операционную устойчивость финансового сектора и про управление ИКТ-рисками, включая риски от внешних ИКТ-поставщиков (куда часто попадает и облако).
Здесь ключевой ориентир по срокам проще: DORA применяется с 17 января 2025.
Практический вывод для облака такой: даже если вы “не финорганизация”, но вы поставщик ИКТ-услуг для финансового сектора, DORA будет влиять на вас через требования клиентов — контракты, контроль рисков, отчётность, условия по субподрядчикам и т.д.
Если собрать всё в одну картину, дальше остаётся определить вашу роль. Вы либо провайдер, либо заказчик, либо финансовая организация, либо ИКТ-поставщик для финансового сектора. Чтобы это было проще увидеть одним взглядом, ниже — короткая таблица-ориентир.
| Ситуация | Что обычно означает по NIS2 | Что обычно означает по DORA |
| Вы облачный провайдер / цифровая инфраструктура | Можете быть в периметре NIS2 (зависит от сектора/размера/нац. транспозиции) | Для финсектора вы — ИКТ-поставщик, требования часто приходят через клиентов (контракты, контроль third-party risk) |
| Вы заказчик облака (не финсектор) | Попадаете под NIS2, если ваш сектор в списке и вы подходите по критериям | Обычно напрямую не попадаете, если вы не финорганизация |
| Вы финорганизация и используете облако | Если ваш сектор в периметре NIS2 — будут обязательства по рискам/инцидентам | DORA применяется напрямую: управление ИКТ-рисками + требования к ИКТ-поставщикам |
Дальше становится проще: когда вы понимаете “кто вы” (провайдер, заказчик, финорганизация, ИКТ-поставщик для финсектора), можно переходить к сути — что именно требуется “по содержанию”: какие блоки мер по киберрискам и устойчивости ожидаются, и где NIS2 и DORA пересекаются, а где расходятся.
Суть требований: управление рисками и операционная устойчивость
NIS2: базовые меры киберрисков и управление безопасностью
Если отбросить юридический язык, NIS2 просит от организаций из периметра одну простую вещь: управлять киберрисками как управляемым процессом, а не как “набором разрозненных мер”. Это прямо закреплено в требованиях к мерам управления рисками (risk-management measures): они должны быть пропорциональны рискам, учитывать зависимость от поставщиков и быть встроены в управление компанией, а не жить “в ИТ-углу”.
Что это значит “по сути” — какие блоки обычно ожидаются:
- Политики и процедуры управления рисками: когда у вас есть понятные правила “как мы митигируем конкретный риск”, кто за что отвечает, как принимаются решения и как это пересматривается. Включая реестр рисков.
- Инциденты: способность обнаруживать, реагировать, восстанавливаться и учиться на инцидентах (не только “потушили пожар”, но и сделали так, чтобы он не повторился).
- Непрерывность и восстановление: планы на случай сбоя, резервное копирование, восстановление, “как мы поддерживаем работу, когда что-то пошло не так”.
- Безопасность цепочки поставок: управление рисками поставщиков и подрядчиков (включая облако), потому что именно здесь часто рождаются “серые зоны” ответственности.
- Безопасная разработка и эксплуатация: практики защиты в жизненном цикле систем (обновления, управление уязвимостями, контроль изменений).
- Доступы и базовая “гигиена”: контроль привилегий, защита учётных записей, защищённые коммуникации — то, что обычно ломается первым при атаке.
На практике компании часто ориентируются на официальные разъяснения и техническое руководство ENISA, которое помогает переводить требования в конкретные меры и доказательства (“что показать аудитору/регулятору”).
DORA: пять “столпов” устойчивости и что это значит для ИКТ и облака
Если NIS2 в первую очередь про общий уровень киберуправления в важных секторах, то DORA смотрит на ИТ гораздо более “операционно”: как финансовая организация переживает сбои, атаки и провалы подрядчиков так, чтобы бизнес продолжал работать. Проще всего понимать DORA через его основные блоки (их часто описывают как “пять столпов”):
- Управление ИКТ-рисками: процессы, роли, контроль изменений, защита, обнаружение, восстановление — всё, что делает ИТ управляемым риском, а не лотереей.
- Инциденты и отчётность: что считать инцидентом, как классифицировать, как и куда сообщать, чтобы регулятор и рынок получали информацию быстро и в понятном формате.
- Тестирование цифровой устойчивости: регулярные проверки “выдержим ли мы” — не только на бумаге, но и через тесты и учения.
- Управление рисками ИКТ-третьих сторон: контракты, контроль, субподрядчики, концентрация рисков, планы выхода — особенно важно для облака.
- Информационный обмен: механизмы обмена данными об угрозах (там, где это уместно и разрешено), чтобы сектор быстрее учился на атаках.
Теперь — что это означает для облака на практике.
Для финансовой организации (заказчика) DORA почти всегда сводится к двум требованиям:
- вы должны уметь доказать, что контролируете свой ИКТ-риск (включая облако), а не “просто купили услугу”;
- вы должны управлять облаком как критичной зависимостью: знать, какие функции вынесены в облако, какие поставщики задействованы, какие есть точки отказа, и как вы из этого выходите при необходимости.
Для облачного/ИКТ-провайдера DORA чаще приходит “через клиента”, но в очень конкретной форме: расширенные требования к контрактам, прозрачности, поддержке аудита, управлению субподрядчиками и процессам инцидентов. А для отдельных крупных поставщиков есть ещё и уровень прямого надзора: DORA вводит общеевропейскую систему oversight для критичных ИКТ-поставщиков (CTPPs), где роль лид-надзора выполняют европейские надзорные органы.
Разделение ответственности: что должен обеспечить провайдер, а что обязан сделать заказчик
В NIS2 и DORA нет идеи “переложить безопасность на облако”. Есть идея управляемости: вы должны понимать, кто за что отвечает, и уметь это доказать. В облаке это почти всегда сводится к простой логике: провайдер отвечает за безопасность и устойчивость платформы, а заказчик — за безопасность и устойчивость того, что он на этой платформе построил.
Чтобы не оставлять это на уровне слов, вот таблица-ориентир. Она помогает быстро увидеть, где зона провайдера, где зона заказчика, и где чаще всего рождаются “серые зоны”:
| Область | Обычно обязан обеспечить провайдер | Обычно обязан обеспечить заказчик | Где чаще всего “серое” |
| Фундамент платформы | Физическая и базовая инфраструктурная безопасность (ЦОД, сеть, хосты/виртуализация), патчи платформенного слоя, базовая изоляция | Архитектурные решения поверх платформы: сегментация окружений, выбор регионов/зон, базовые сетевые границы, “как мы размещаем критичные компоненты” | Ожидание “платформа безопасна” – значит “всё безопасно” |
| Доступы и идентификация | Инструменты IAM, журналы, базовые механизмы безопасности платформы | Роли, MFA, минимальные права, управление пользователями и сервисными аккаунтами | Кто отвечает за компрометацию учётки и доказательства событий |
| Конфигурации сервисов | Безопасные механизмы и настройки по умолчанию (в рамках сервиса), документация и рекомендации | Публичность ресурсов, сетевые правила, шифрование, политики хранения, правильные параметры managed-сервисов | “Мы думали, что по умолчанию закрыто” |
| Устойчивость и восстановление | Устойчивость платформы, резервирование на уровне сервиса (если заявлено), процедуры и тесты провайдера | Архитектура приложения, бэкапы данных/конфигов, план восстановления, тесты восстановления | Где заканчивается SLA сервиса и начинается ответственность приложения |
| Инциденты | Реагирование на инциденты платформы, уведомления, технические детали в рамках договора | Обнаружение инцидентов в своей зоне, классификация, внутренний процесс уведомлений, взаимодействие с регулятором | Кто, когда и что сообщает; в какие сроки провайдер даёт данные |
| Цепочка поставок | Контроль собственных субподрядчиков, изменения в цепочке, прозрачность (если предусмотрено) | Оценка рисков поставщика, периодические проверки, требования к критичным поставкам | Насколько глубоко заказчик может/должен видеть субподрядчиков |
| Доказательства и соответствие | Отчёты/аттестации, описания мер, границы ответственности, audit support | Внутренние политики, риск-оценка, “доказательная база” использования облака | Что считать “достаточным доказательством” для аудита/надзора |
Облако может дать крепкий фундамент, но “готовая безопасность” сама не соберётся. Чем яснее вы разделили ответственность между платформой и своей конфигурацией, тем меньше сюрпризов в проверках и тем спокойнее живёт инфраструктура.
Договоры и third-party risk: что фиксировать в контракте и SLA
Если NIS2 и DORA — это “что должно быть обеспечено”, то контракт с облачным провайдером — это место, где вы отвечаете на вопрос: как именно это обеспечивается и чем это подтверждается. Без нормальных формулировок в договоре соответствие легко превращается в догадки: “мы думали, что так”, “они обещали устно”, “кажется, это входит в SLA”.
В контексте ЕС ключевая идея простая: облако — это часть вашей цепочки поставок, а значит риски провайдера становятся вашими рисками. Поэтому в договоре важно закрепить не только “доступность 99,9%”, но и правила контроля, прозрачности и действий в инцидентах.
Что обычно стоит зафиксировать, если говорить по сути:
Во-первых, границы ответственности и модель сервиса. Что провайдер обеспечивает на уровне платформы, а что остаётся на стороне заказчика. Это звучит очевидно, но именно отсутствие чёткой границы чаще всего ломает обсуждение после инцидента.
Во-вторых, SLA и SLO в понятных терминах. Не просто цифра доступности, а что входит в спектр оказываемых услуг, что считается простоем, как считаются минуты, какие исключения есть (плановые работы, форс-мажоры), какие есть компенсации и что они реально означают. И отдельно — важный нюанс: доступность сервиса не равна доступности вашего приложения, поэтому в договоре полезно фиксировать, какие компоненты покрываются гарантиями, а какие нет.
В-третьих, инциденты и уведомления. Даже если у вас будет отдельная глава про процесс, в договоре должно быть закреплено: какие события провайдер обязан сообщать, в какие сроки, по каким каналам, какой минимум информации предоставляется, и как обновляется статус. В регулируемой среде “мы узнали через сутки” может стать проблемой не только технической, но и юридической.
В-четвёртых, аудит и доказательства. Вопрос обычно звучит так: что вы можете показать аудитору или регулятору, чтобы подтвердить меры провайдера? Это может быть доступ к отчётам, аттестациям, описаниям мер безопасности, результатам тестов устойчивости — в том формате, который признаётся в вашей отрасли. Важно, чтобы это было не “по запросу, если получится”, а как понятное обязательство.
В-пятых, субподрядчики и цепочка поставок. Для third-party risk важно знать, кто ещё участвует в предоставлении услуги (например, в части поддержки, сетей, дата-центров), и как провайдер управляет этими зависимостями. Обычно здесь фиксируют требования к уведомлениям о существенных изменениях и правила, по которым провайдер может привлекать субподрядчиков.
В-шестых, география и данные (когда это применимо). Где обрабатываются и хранятся данные, какие есть варианты размещения, как выглядит перенос, какие ограничения и какие механизмы контроля. Даже если вы не описываете это “по стране и стойке”, важно иметь ясность, что вы покупаете: один регион, несколько регионов, возможность выбрать размещение, и как это фиксируется в договоре.
В-седьмых, exit-план. Это один из самых недооценённых пунктов, пока всё хорошо. Но в рамках DORA и вообще в логике управления рисками важно заранее понимать: как вы выходите из отношений с провайдером, как забираете данные, какие сроки, какие форматы, какие ограничения, какие обязательства по удалению данных после миграции. Иначе “выход” превращается в проект на месяцы под давлением.
Хороший контракт для NIS2/DORA — это не “толстый PDF”, а документ, который делает риски управляемыми. Он фиксирует границы ответственности, даёт доказательства, задаёт правила на инциденты и заранее продумывает самый неприятный сценарий — что делать, если с поставщиком нужно быстро расстаться.
Инциденты и отчётность: что считается инцидентом и как выстроить уведомления
В обычной жизни инцидент — это “что-то сломалось”. В регулируемой среде инцидент — это ещё и вопрос времени: когда вы узнали, как оценили масштаб и как быстро сообщили. И NIS2, и DORA как раз делают упор на то, что инциденты нельзя “держать внутри, пока разберёмся”. Должен быть процесс, который работает даже в хаосе.
Первое, что важно понять: речь идёт не о каждом предупреждении в мониторинге. Регуляторов интересуют значимые (существенные) инциденты — те, которые влияют на доступность, целостность, конфиденциальность или устойчивость услуг и могут иметь заметные последствия для клиентов, рынка или даже общества. Как именно классифицировать “значимость” — обычно задаётся рамками закона/регулятора и внутренними критериями компании, но практическая логика почти всегда одна: смотрим на масштаб, длительность, критичность затронутых функций и потенциальный ущерб.
Отсюда вытекает главная задача процесса: сделать так, чтобы в момент инцидента команда не спорила “это уже значимо или ещё нет”, а действовала по заранее понятным правилам.
На практике рабочая схема обычно строится вокруг трёх шагов.
Шаг 1: обнаружение и первичная классификация.
Вам нужен механизм, который быстро отвечает на вопрос: что произошло и насколько это похоже на “значимый” инцидент. Здесь важно заранее определить триггеры: например, массовые ошибки в критичном сервисе, длительный простой, утечка данных, компрометация учётных записей, срыв критичного процесса (оплата, расчёты, доступ к ключевым системам).
Шаг 2: запуск цепочки уведомлений.
Кто принимает решение “это инцидент”? Кто отвечает за внешнюю коммуникацию? Кто контактирует с провайдером? Кто ведёт таймлайн? У хорошего процесса эти роли назначены заранее. Потому что инцидент — это всегда момент, когда люди заняты тушением пожара, и если ещё параллельно нужно “изобрести процесс”, вы проигрываете по времени.
Шаг 3: отчётность и доказуемость.
Регуляторная логика любит факты: когда началось, когда обнаружили, какие системы затронуты, какие меры приняли, как восстанавливались, как предотвратите повтор. Поэтому важно вести хронологию действий и иметь минимальный набор данных, который можно собрать даже в стрессовой ситуации.
И здесь есть одна облачная специфика: часть информации находится у провайдера. Поэтому ваш процесс должен включать “мостик” к контрактным обязательствам: как быстро провайдер предоставляет данные по событию, по каким каналам, и кто внутри вашей команды умеет это запрашивать и интерпретировать. Иначе вы зависите от случайности: “попался ли нужный человек в поддержке”.
В итоге хороший процесс уведомлений — это не бюрократия. Это способ выиграть самое дорогое, что есть в инциденте, — время. И именно время определяет, будет ли это “неприятный сбой” или история, которая превращается в серьёзные последствия.
Дальше остаётся аккуратно завершить картину: когда вы понимаете различия NIS2 и DORA, знаете свою роль, понимаете суть требований, закрепляете ответственность в контракте и выстраиваете процесс инцидентов — регуляторные рамки перестают звучать страшно. В заключении соберём всё в простую мысль: что именно важно для облака в ЕС и как подойти к этому без паники.
Заключение
NIS2 и DORA часто звучат как “две страшные аббревиатуры про безопасность”, но по сути они про одно: киберриски и устойчивость должны быть управляемыми и доказуемыми — особенно когда вы зависите от облака и внешних поставщиков.
Если свести всё к простой картине: сначала вы понимаете, в какую рамку вы попадаете и в какой роли (провайдер, заказчик, финансовая организация, ИКТ-поставщик). Затем переводите требования из юридического языка в практику: управление рисками, устойчивость, контроль цепочки поставок. После этого фиксируете границы ответственности и обязательства в договоре и SLA, чтобы не выяснять “кто должен был” уже во время инцидента. И, наконец, выстраиваете процесс инцидентов и уведомлений так, чтобы в критический момент не терять время на споры и импровизацию.
Спасибо за внимание!
