24-часовой репортинг по CRA: что делать российскому бизнесу в ЕС

Что произошло

11 сентября 2026 года вступили в силу обязательства по статье 14 Cyber Resilience Act (CRA), требующие от производителей «продуктов с цифровыми элементами» уведомлять об активно эксплуатируемых уязвимостях и серьёзных инцидентах в течение 24 часов. Регуляторный механизм реализован через единую платформу отчётности ENISA — Single Reporting Platform (SRP), которая стала единой точкой входа для всех уведомлений, направляемых национальным командам реагирования на компьютерные инциденты (CSIRT) и самому Агентству по кибербезопасности ЕС. Этот шаг завершает многолетний переходный период и устанавливает чёткий, юридически обязывающий стандарт для всех поставщиков, действующих на рынке ЕС, независимо от их юрисдикции.

Нововведение напрямую затрагивает российский бизнес. Если ваша компания — разработчик ПО, поставщик IoT-устройств или провайдер ИИ-решений, чьи продукты продаются в ЕС, интегрированы в европейские решения или доступны европейским пользователям, вы теперь подпадаете под юрисдикцию CRA. Обязательства распространяются как на новые, так и на уже находящиеся на рынке продукты, что исключает возможность отложить приведение процессов в соответствие. Игнорирование требований грозит не только репутационными потерями, но и административными мерами, вплоть до ограничения доступа на рынок и отзыва CE-маркировки.

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

Как это устроено

Механика репортинга: три этапа и строгие дедлайны

Статья 14 CRA устанавливает трёхуровневую систему уведомлений, каждый из которых имеет свой срок и содержание. Процесс запускается в момент, когда производитель «становится осведомлён» об активно эксплуатируемой уязвимости или серьёзном инциденте. Первым шагом является раннее предупреждение (early warning), которое необходимо подать в течение 24 часов. Оно содержит минимальный набор сведений: факт уязвимости, наименование продукта и страны, где он представлен.

В течение следующих 72 часов производитель обязан предоставить расширенное уведомление (full notification). Этот документ требует детальной технической информации, включая вектор атаки, оценку серьёзности (например, по CVSS), потенциальное влияние и уже принятые меры по смягчению последствий. Финальный этап — финальный отчёт, который подаётся в разные сроки: через 14 дней после выпуска патча для уязвимости или в течение месяца после 72-часового уведомления о серьёзном инциденте. Этот отчёт должен содержать полную картину произошедшего, включая анализ первопричин и остаточные риски.

Тип уведомления	Срок подачи	Содержание
Раннее предупреждение (Early warning)	24 часа	Факт уязвимости/инцидента, продукт, затронутые страны
Расширенное уведомление (Full notification)	72 часа	Технические детали, вектор атаки, оценка влияния, первые меры
Финальный отчёт по уязвимости	14 дней после доступности патча	Полное описание, анализ причин, статус исправления
Финальный отчёт по инциденту	1 месяц после 72-часового уведомления	Полный анализ инцидента, ущерб, долгосрочные меры

Технологическая платформа: SRP как единая точка входа

Технической основой для репортинга служит Single Reporting Platform (SRP), разработанная и поддерживаемая ENISA. Платформа работает по принципу «report once»: производитель заполняет одну форму в системе, и она автоматически маршрутизируется в компетентные органы — координатору CSIRT государства-члена, где компания имеет свою основную деятельность, а также в другие национальные CSIRT, где продукт представлен, и в ENISA. Это устраняет бюрократическую нагрузку, связанную с подачей множественных отчётов в разные страны.

Доступ к SRP осуществляется через EU Login с обязательной многофакторной аутентификацией. Компании должны назначить официального представителя (Assigned Representative), который будет нести ответственность за подачу уведомлений. По нашему опыту, процесс регистрации и настройки доступа может занять от нескольких дней до недель, поэтому его необходимо завершить заблаговременно, а не в момент инцидента. Платформа предоставляет шаблоны для каждого типа уведомления, что стандартизирует формат и снижает риск ошибки.

Применимость к ИИ-системам: двойное регулирование

ИИ-системы, поставляемые как программный продукт (например, SaaS-платформа с ИИ-функционалом) или встроенные в устройство, однозначно подпадают под определение «продукта с цифровыми элементами» и, следовательно, под требования CRA по репортингу уязвимостей. Это означает, что если в вашей нейросетевой модели или surrounding code обнаружена эксплуатируемая уязвимость (например, уязвимость в фреймворке TensorFlow, позволяющая удалённое выполнение кода), вы обязаны отчитаться в ENISA в течение 24 часов.

Однако здесь возникает важный нюанс: параллельно с CRA действует EU AI Act. Он вводит отдельные обязательства по репортингу «серьёзных инцидентов» для провайдеров ИИ-систем высокого риска (high-risk AI systems). Под инцидентом по AI Act понимается не только уязвимость безопасности, но и отказ системы, приводящий к вреду для здоровья, безопасности или фундаментальных прав граждан. Таким образом, провайдер ИИ-решения в ЕС может столкнуться с необходимостью подавать два разных отчёта: один — в ENISA по CRA (на уязвимость безопасности), второй — в национальный компетентный орган по AI Act (на вредоносный отказ модели).

Экономика комплаенса: от затрат к необходимой инвестиции

Внедрение процессов под CRA — это не просто юридическая формальность, а существенное изменение в экономике управления рисками. Ранее компании могли тратить на vulnerability management и disclosure по остаточному принципу. Теперь же необходимость иметь процессы, способные уложиться в 24-часовое окно, становится условием доступа на рынок ЕС. Это требует прямых инвестиций в несколько областей: инструменты для непрерывного мониторинга угроз и управления уязвимостями (VMT), создание и поддержание актуальных Software Bill of Materials (SBOM) для быстрой оценки затронутых компонентов, а также наём или обучение персонала (security-аналитики, юристы, PR-специалисты).

Экономический эффект от невыполнения требований перевешивает затраты на подготовку. Штрафы по CRA могут достигать значительных размеров, а косвенные убытки от блокировки продаж на рынке ЕС, отзыва CE-маркировки и утраты доверия клиентов могут оказаться фатальными для бизнеса. В типовом сценарии инцидент, не раскрытый в срок, приводит к расследованию со стороны регулятора, что парализует операционную деятельность на месяцы.

Как это выглядит на практике

Сценарий 1: Российский SaaS-вендор на рынке ЕС

Российская компания предоставляет SaaS-платформу для управления проектами с клиентами в Германии, Франции и Нидерландах. 15 сентября в 10:00 по МСК команда безопасности получает уведомление от исследователя об активно эксплуатируемой уязвимости SQL-инъекции в одном из компонентов платформы, используемом всеми клиентами. В 10:30 проводится внутреннее расследование, подтверждающее уязвимость и наличие публичного эксплойта. В 11:00 МСК (что соответствует 10:00 CET) запускается эскалационный план. Юристы и технические директора принимают решение о необходимости репортинга. В 12:00 МСК (11:00 CET), то есть через час после подтверждения, назначенный представитель вносит в SRP раннее предупреждение, указав наименование продукта и страны присутствия. В течение следующих 48 часов команда разрабатывает патч, готовит техническую информацию для расширенного уведомления и координирует действия с европейскими клиентами. Уведомление подаётся в SRP до истечения 72-часового срока.

Сценарий 2: Производитель IoT-устройств с цепочкой поставок

Российская компания производит умные розетки, которые продаются в ЕС через европейского дистрибьютора под его брендом. 20 сентября исследовательская группа публикует информацию об уязвимости нулевого дня в прошивке чипсета, используемого в партии устройств, поставленной в ЕС в прошлом квартале. Уязвимость позволяет удалённо получить контроль над устройством. Несмотря на то, что продукт продаётся под чужим брендом, обязанность по репортингу лежит на производителе — российской компании. Она немедленно уведомляет своего дистрибьютора и совместно с ним готовит уведомление для SRP. Сложность заключается в необходимости оценить точное количество затронутых устройств в разных странах и координировать выпуск обновления прошивки через инфраструктуру дистрибьютора. 24-часовой дедлайн заставляет компании иметь заранее подписанные протоколы о взаимодействии в таких ситуациях.

Сценарий 3: Провайдер ИИ-модели для финтеха

Стартап из России предоставляет европейским финтех-компаниям API-доступ к специализированной языковой модели для анализа финансовых документов. 25 сентября в ходе внутреннего аудита обнаруживается критическая уязвимость в API-шлюзе, позволяющая при специально сформированном запросе получить доступ к данным других клиентов (data leakage). Хотя утечка ещё не произошла, уязвимость классифицируется как активно эксплуатируемая, так как есть признаки её сканирования злоумышленниками. Компания подаёт раннее предупреждение в ENISA по CRA. Одновременно правовая команда оценивает, не подпадает ли потенциальный утечка данных под критерии «серьёзного инцидента» в AI Act (вред для прав и свобод граждан). Решено, что прямой угрозы физическому вреда нет, поэтому дополнительный отчёт по AI Act пока не требуется, но ситуация находится на особом контроле. Компания выпускает патч и уведомляет всех клиентов, предоставляя им инструкции по немедленному обновлению ключей API.

Что это значит для российской компании

Для российского бизнеса, имеющего операции или цепочки поставок, связанные с ЕС, вступление в силу Article 14 CRA — это фундаментальный сдвиг в парадигме управления безопасностью и комплаенсом. Если ранее соблюдение европейских норм было скорее конкурентным преимуществом, то теперь оно становится лицензией на деятельность. Санкционное давление со стороны ЕС не отменяет, а усложняет эту задачу, создавая правовую и операционную двусмысленность. Однако юрисдикция CRA распространяется на любой продукт, физически или цифровой присутствующий на рынке ЕС, независимо от санкционного статуса производителя.

Прямой российский аналог CRA, устанавливающий 24-часовое обязательное репортинг для всех коммерческих цифровых продуктов в единый государственный портал, в настоящее время отсутствует. Российское регулирование в области кибербезопасности (ФЗ-187, приказы ФСТЭК, ФСБ) носит более отраслевой характер и в основном касается критической информационной инфраструктуры и госзаказчиков. Это означает, что российским компаниям придётся выстраивать новые процессы «с нуля», ориентируясь на европейские стандарты, а не адаптировать существующие внутренние процедуры.

Влияние на бюджеты и процессы будет ощутимым. Требуется создание кросс-функциональной команды (безопасность, разработка, юристы, PR), внедрение новых инструментов (VMT, SBOM-анализаторы), а также затраты на юридическое консультирование и регистрацию на SRP. Эти инвестиции следует рассматривать не как издержки, а как неотъемлемую стоимость поддержания европейского рынка сбыта.

Аспект	До 11.09.2026	После 11.09.2026
Юридический статус репортинга	Добровольный (CVD) или разрозненный	Обязательный, унифицированный по всей ЕС
Сроки уведомления	Дни или недели, по усмотрению компании	24 часа на первичное уведомление
Ответственность	Репутационные риски	Административные штрафы, блокировка продаж, отзыв CE-маркировки
Охват продуктов	Новые продукты, по инициативе производителя	Все продукты на рынке ЕС, включая legacy
Процессы	Фрагментированные, часто не формализованные	Централизованные, с эскалационными планами и таймерами
Затраты	Низкие или нерегулярные	Постоянные инвестиции в people, process, technology

Что делать: пошагово

1. Определите охват. Проведите полный инвентарный анализ вашего продуктового портфеля и определите, какие именно продукты (ПО, устройства, ИИ-системы) подпадают под определение «продукта с цифровыми элементами» и продаются или используются в ЕС.
2. Назначьте ответственного. Учредите должность или назначьте конкретного сотрудника (например, Head of Compliance или CISO) ответственным за CRA. Этот человек будет точкой контакта для ENISA и внутренним координатором.
3. Пройдите юридическую экспертизу. Привлеките юристов, специализирующихся на европейском праве, для детального анализа CRA и подготовки внутренних политик, процедур и шаблонов уведомлений, соответствующих требованиям регламента.
4. Разработайте эскалационный план. Создайте формализованный план реагирования на инциденты с встроенными таймерами (24, 72 часа, 14 дней, 1 месяц). Чётко пропишите, кто и на каком этапе принимает решение о репортинге.
5. Внедрите технические средства. Обеспечьте возможность быстрой оценки затронутых компонентов через внедрение Software Bill of Materials (SBOM) и инструментов для управления уязвимостями (Vulnerability Management Tools).
6. Зарегистрируйтесь на SRP. Пройдите процедуру регистрации на Single Reporting Platform ENISA, настройте доступ для ответственных лиц и протестируйте процесс заполнения форм на учебном примере.
7. Проведите учения. Организуйте внутреннее учение ( tabletop exercise ), смоделировав сценарий обнаружения активно эксплуатируемой уязвимости. Проверьте, как срабатывает эскалационный план и укладываетесь ли вы в сроки.
8. Обеспечьте непрерывный мониторинг. Настройте процессы непрерывного мониторинга угроз через подписку на бюллетени безопасности, feeds от threat intelligence-провайдеров и участие в программах bug bounty.

Типичные ошибки

• Игнорирование legacy-продуктов. Ошибка считать, что CRA распространяется только на новые релизы. Обязательства охватывают все продукты, находящиеся на рынке ЕС, даже если они были выпущены несколько лет назад.
• Смешивание добровольного и обязательного раскрытия. Компания продолжает следовать своей внутренней политике Responsible Disclosure, игнорируя 24-часовой дедлайн для регуляторного уведомления, что приводит к пропуску срока и штрафам.
• Недооценка времени на принятие решения. Техническая команда быстро находит уязвимость, но решение о репортинге задерживается на уровне руководства или юристов. В итоге 24-часовое окно упускается из-за бюрократии.
• Разобщённость команд. Отдел безопасности находит уязвимость, но не информирует вовремя юристов и PR-специалистов. В результате расширенное уведомление подаётся с ошибками или не в том формате, вызывая дополнительные вопросы со стороны регулятора.
• Игнорирование перекрёстки с AI Act. Провайдер ИИ-систем отчитывается по CRA об уязвимости, но упускает из виду, что последствием инцидента стал вред, подпадающий под критерии AI Act, и получает второе нарушение.
• Расчёт на то, что санкции отменят CRA. Ошибочное предположение, что под санкционными компаниями требования ЕС не распространяются. На практике юрисдикция CRA определяется рынком сбыта, а не юрисдикцией производителя.

Как понять, что вы на верном пути

• У вас есть утверждённый и задокументированный план реагирования на инциденты, в котором есть отдельная ветка «Репортинг по CRA» с чётко прописанными сроками и ответственными.
• Вы можете в течение нескольких часов сгенерировать точный SBOM для любого вашего продукта и определить все затронутые компоненты при обнаружении уязвимости в сторонней библиотеке.
• Назначенный представитель компании успешно зарегистрирован на SRP, имеет рабочие учётные данные с MFA и доступ ко всем необходимым формам уведомлений.
• Юридический отдел и отдел безопасности совместно разработали и утвердили шаблоны раннего предупреждения, расширенного уведомления и финального отчёта.
• Вы провели как минимум одно полное учение по сценарию CRA и уложились в 24-часовой дедлайн, выявив и устранив узкие места в процессе.
• Ваш бюджет на следующий год включает статьи расходов на инструменты VMT/SBOM и на юридическую поддержку по комплаенсу в ЕС.

Вопросы, которые нам задают

Что именно считается «actively exploited»?

Это означает наличие достоверных сведений о том, что уязвимость используется злоумышленниками для атак на реальные системы. Простое теоретическое описание уязвимости или наличие Proof-of-Concept концепта без признаков его использования в дикой природе не является основанием для немедленного репортинга, но требует повышенного внимания.

Нас коснётся это, если мы продаём ПО через европейского реселлера?

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

Нужно ли сообщать об уязвимости в open-source библиотеке, которую мы используем?

Да, если эта библиотека является частью вашего коммерческого продукта, доступного на рынке ЕС. Вы обязаны отчитаться об уязвимости в составе вашего продукта, даже если первоисточник уязвимости находится в стороннем open-source проекте.

Как это согласуется с российским законодательством о гостайне?

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

Источники

• ENISA — The Cyber Resilience Act Single Reporting Platform is launched
• ENISA — Single Reporting Platform (SRP)
• EU Commission — CRA reporting obligations
• DLA Piper — The CRA’s 24-hour rule: preparing for the Cyber Resilience Act’s September 2026 reporting obligations
• Yusmp Group — Новости: Обязанности по репортингу по CRA с 11 сентября 2026
• Element — Guide to Cyber Resilience Act Article 14 reporting obligations
• H-X Technology — Mandatory CRA reporting is here
• ContinueOps — Cyber Resilience Act Timeline
• Brandefense — CRA reporting obligations: 24-hour clock explained