11 сентября 2026 года в Европейском союзе начинает действовать один из ранних блоков Cyber Resilience Act: сообщения об активно эксплуатируемых уязвимостях и серьезных инцидентах безопасности. Основные требования регламента к продуктам станут полностью применяться 11 декабря 2027 года. Ошибка для бизнеса - ждать этой дальней даты и не готовить канал экстренной отчетности сейчас.
Европейская комиссия 31 июля 2026 года уточнила правила и сообщила, что единая платформа отчетности должна быть готова к 11 сентября. Регламент касается производителей продуктов с цифровыми элементами, которые выводятся на рынок ЕС. Это могут быть устройства, программы и отдельно поставляемые компоненты. Для конкретного продукта нужно сверять исключения и роль компании по тексту Regulation (EU) 2024/2847 и актуальному руководству.
Два события, которые запускают процесс
Первое - уязвимость, о которой производитель знает, что она активно эксплуатируется. Одна запись в базе CVE или теоретическая возможность атаки не равны автоматически доказанной эксплуатации. Но сигнал от клиента, исследователя, центра реагирования или собственной телеметрии нельзя оставлять в обычной очереди поддержки до еженедельного совещания.
Второе - серьезный инцидент, влияющий на безопасность продукта с цифровыми элементами. Команда должна уметь отделить сбой доступности или единичную ошибку от события, которое соответствует критериям регламента. Юрист, разработчик и специалист реагирования делают это вместе, сохраняя исходные данные и время, когда компания узнала о событии.
Часы идут от осведомленности производителя, поэтому полезно заранее определить, какое сообщение и в какой системе считается поступившим организации. Письмо на забытый адрес security@, заявка дилеру и предупреждение облачного провайдера должны иметь маршрут срочной эскалации.
Сроки 24 часа, 72 часа и финальный отчет
Европейская комиссия описывает раннее предупреждение в течение 24 часов после того, как компания узнала о событии, и основное уведомление в течение 72 часов. Для активно эксплуатируемой уязвимости финальный отчет направляется не позднее 14 дней после появления корректирующей или смягчающей меры. Для серьезного инцидента финальный отчет подается в течение месяца после 72-часового сообщения.
Первое уведомление не требует закончить расследование за сутки. Его задача - вовремя обозначить событие. Нельзя заполнять неизвестные поля догадками. Указывают подтвержденное, явно отмечают предварительную оценку и план обновления. Одновременно нельзя использовать неполноту как причину молчать до выпуска патча.
Сообщение подается один раз через CRA Single Reporting Platform. Оно адресуется CSIRT по месту основного учреждения производителя и, кроме исключительных случаев, становится доступно ENISA; затем сведения распространяются между соответствующими CSIRT государств, где продукт доступен.
Кому поручить решение
Назначьте владельца процесса и круглосуточного заместителя. Разработчик оценивает техническую сторону, служба безопасности собирает индикаторы и масштаб, продуктовая команда определяет затронутые версии, юрист проверяет применимость и формулировки, руководитель утверждает рискованные решения. Контактные данные и право отправки не должны храниться только у одного человека.
Создайте короткую матрицу: тип продукта, рынки, юридическое лицо-производитель, основной CSIRT, каналы ENISA, ответственный, резервный. Для сторонних компонентов укажите поставщика, координаты проекта и договорный срок уведомления. Если подрядчик сообщает о проблеме через пять дней, производитель не сможет выдержать свои 24 часа.
Какие данные собрать заранее
- точное название продукта, версии, модели и даты поставки;
- страны и каналы, где продукт доступен;
- контакт производителя и ответственного за безопасность;
- описание уязвимости или инцидента без неподтвержденных выводов;
- признаки эксплуатации, временная шкала и затронутые системы;
- доступные меры снижения риска и план исправления;
- оценка трансграничного влияния и уведомления клиентов.
Инвентаризация версий становится центральной. Фраза проблема в старой прошивке бесполезна, если компания не знает, какие серийные номера и клиенты получили эту прошивку. Свяжите сборки, компоненты, даты выпуска и каналы продаж. Это пригодится и для полного соответствия CRA в 2027 году.
Репетиция на одном сценарии
Проведите настольное упражнение: в пятницу в 18:20 исследователь сообщает об обходе аутентификации, а журнал одного клиента показывает похожую активность. За первые два часа команда должна подтвердить прием, сохранить доказательства, решить вопрос об эксплуатации, назначить роли и ограничить риск. До 24 часов - подготовить раннее предупреждение. До 72 - уточнить версии и масштаб.
Проверяйте не техническую красоту ответа, а задержки: кто увидел письмо, сколько искали владельца продукта, можно ли войти на платформу, кто уполномочен говорить с регулятором и клиентами. Итогом упражнения становится список конкретных исправлений с ответственными и сроками.
Чего CRA пока не требует
Старт отчетности 11 сентября 2026 года не означает, что все остальные продуктовые обязанности уже полностью применяются. Комиссия указывает полную дату 11 декабря 2027 года, а правила по уведомлению органов оценки соответствия начали действовать 11 июня 2026 года. Даты нужно разделять в документах и договорах.
Не следует считать, что иностранная компания вне риска только потому, что у нее нет офиса в ЕС. Ключевой вопрос - вывод продукта на рынок Союза и роль в цепочке. Но окончательную квалификацию делает специалист по праву ЕС на основании фактов, а не статья или чек-лист.
До 11 сентября остается мало времени. Минимально жизнеспособная готовность - это инвентарь продуктов, наблюдаемый канал приема сообщений, дежурная команда, доступ к платформе, шаблоны 24- и 72-часовых уведомлений и одна репетиция. Политика на двадцать страниц без работающей эскалации не остановит часы.