Cyber Resilience Act: отчётность об инцидентах стартует 11 сентября 2026

Коротко о главном

С 11 сентября 2026 года вступает в силу первый блок обязательств европейского Cyber Resilience Act (CRA): производители продуктов с цифровыми элементами обязаны сообщать об активно эксплуатируемых уязвимостях и серьёзных инцидентах в ENISA и национальный CSIRT. Дедлайны жёсткие: раннее предупреждение — за 24 часа, полное уведомление — за 72 часа, финальный отчёт — в течение 14 дней. Это касается любого, кто выводит цифровой продукт на рынок ЕС, включая команды из США и России. Если вы строите ПО на заказ для европейских клиентов — часы уже пошли.

Обязательство закреплено в статье 14 регламента и подтверждено официальной страницей Еврокомиссии и ENISA. Отчёт подаётся один раз через единую платформу Single Reporting Platform (SRP): производитель направляет уведомление в CSIRT страны своего основного присутствия, и информация одновременно уходит в ENISA. Дальше принимающий CSIRT без задержек распространяет её среди других национальных команд реагирования, на территории которых доступен продукт.

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

Что именно вступает в силу 11 сентября

CRA — это регламент ЕС о кибербезопасности продуктов с цифровыми элементами: от IoT-устройств и прошивок до операционных систем, приложений и библиотек. Большинство его требований (базовые требования к безопасности, техдокументация, маркировка CE) применяются позже — с 11 декабря 2027 года. Но обязательства по отчётности вынесены вперёд и стартуют именно 11 сентября 2026 года, потому что раннее оповещение об эксплуатируемых уязвимостях считается критичным для всей экосистемы.

Отчитываться нужно о двух категориях событий. Первое — активно эксплуатируемая уязвимость в продукте с цифровыми элементами: то есть не гипотетическая дыра, а та, которую злоумышленники уже используют. Второе — серьёзный инцидент, влияющий на безопасность продукта. Обязанность лежит на производителе (manufacturer) — том, кто выводит продукт на рынок ЕС под своим именем или брендом, независимо от того, где физически находится компания.

Три дедлайна: 24 часа, 72 часа, 14 дней

Отчётность построена как многоступенчатая, по образцу уже знакомых директив NIS2 и DORA. Сначала — раннее предупреждение (early warning) в течение 24 часов с момента, когда производитель узнал об активно эксплуатируемой уязвимости или серьёзном инциденте. Это короткое уведомление «мы знаем о проблеме», а не полный разбор.

Затем — уведомление об уязвимости или инциденте (notification) в течение 72 часов: здесь уже нужны технические детали, оценка серьёзности и, где применимо, индикаторы компрометации. Наконец — финальный отчёт. Для уязвимости это не позднее 14 дней после того, как стала доступна корректирующая мера (патч или обходное решение); для серьёзного инцидента — в течение одного месяца после уведомления. Логика в том, чтобы регуляторы и другие вендоры получили сигнал максимально рано, а полную картину — когда угроза взята под контроль.

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

Single Reporting Platform: одно окно вместо десятков

Ключевое техническое новшество — единая платформа отчётности (Single Reporting Platform, SRP), которую разворачивает ENISA. Смысл в том, чтобы производитель подавал отчёт один раз, а не рассылал его по десяткам национальных регуляторов вручную. Уведомление адресуется CSIRT страны основного присутствия и одновременно становится доступным ENISA (за исключением оговорённых исключительных обстоятельств).

По заявлению ENISA, платформа станет операционной к дедлайну 11 сентября 2026 года; функциональное и security-тестирование ведётся. Через SRP предусмотрена и добровольная отчётность — подать сигнал об уязвимости или инциденте может любое физическое или юридическое лицо, не только обязанный производитель. Порядок раскрытия информации детализируется делегированным актом, принятым 11 декабря 2025 года: распространение может быть отложено при обоснованных соображениях кибербезопасности.

Кого это касается за пределами ЕС

CRA, как и AI Act с GDPR, действует экстерриториально. Российский или американский разработчик подпадает под обязательства в тот момент, когда его продукт с цифровыми элементами доступен на рынке ЕС — через собственные продажи, дистрибьютора или интеграцию в чужой продукт. География головного офиса значения не имеет; значение имеет то, где используется продукт.

Для команд, которые поставляют SDK, библиотеки, встроенное ПО или SaaS европейским заказчикам, это означает две вещи. Во-первых, стоит уже сейчас определить, кто в цепочке считается «производителем» для конкретного продукта — вы или ваш партнёр, интегрирующий ваш компонент. Во-вторых — договорно закрепить, кто и в какие сроки уведомляет регулятора при инциденте, чтобы 24-часовой дедлайн не повис в воздухе между поставщиком и вендором.

Что это значит для команд разработки и CTO

Первое — инвентаризация. Составьте список продуктов с цифровыми элементами, которые вы выводите на рынок ЕС, и определите роль (производитель, импортёр, дистрибьютор). Без этого невозможно понять, на ком лежит обязанность по отчётности.

Второе — процесс обнаружения и эскалации. 24-часовой дедлайн выполним только при налаженном мониторинге: телеметрия эксплуатации, канал приёма сообщений об уязвимостях (coordinated vulnerability disclosure), дежурная смена и заранее прописанный runbook, кто принимает решение о нотификации. Это классическая задача выстраивания процессов ИБ, а не разовая правка документации.

Третье — не изобретайте отдельный контур под CRA. Если вы уже строите соответствие NIS2, DORA или ведёте программу управления уязвимостями, отчётность CRA логично встроить в тот же поток: единый реестр инцидентов, единые SLA на реагирование, единая ответственность. Дублирование процессов под каждый регламент — прямой путь к тому, что ни один из дедлайнов не будет выдержан.

Четвёртое — держите в уме цену вопроса. За несоблюдение базовых требований CRA регламент предусматривает штрафы до 15 млн евро или 2,5% мирового годового оборота — в зависимости от того, что больше. Отчётность — самая ранняя из обязанностей, и именно по ней регуляторы будут калибровать зрелость вендора.

Часто задаваемые вопросы

С какой даты действует отчётность по CRA? С 11 сентября 2026 года. Это первый блок обязательств регламента; остальные базовые требования применяются с 11 декабря 2027 года.

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

Какие сроки? Раннее предупреждение — за 24 часа, уведомление с деталями — за 72 часа, финальный отчёт — не позднее 14 дней после появления корректирующей меры для уязвимости или в течение месяца для серьёзного инцидента.

Куда подавать отчёт? Через единую платформу ENISA — Single Reporting Platform. Отчёт направляется в CSIRT страны основного присутствия и одновременно доступен ENISA. Подавать нужно один раз.

Касается ли это компаний из России и США? Да, если продукт доступен на рынке ЕС. Регламент применяется экстерриториально — значение имеет использование продукта в ЕС, а не место регистрации компании.

Источники

European Commission — Shaping Europe's digital future: Cyber Resilience Act — Reporting obligations, 2026 (первоисточник).

ENISA — Single Reporting Platform (SRP), 2026 (первоисточник).

Freshfields — Cyber Resilience Act reporting obligations take effect on 11 September 2026, 2026.