Соответствие EU Cyber Resilience Act и готовность к отчётности по статье 14

Превратите требования Cyber Resilience Act в работающую систему безопасности продукта — от определения сферы действия и оценки киберрисков до управления уязвимостями, доказательств соответствия и 24-часовой отчётности.

Европейский регламент о киберустойчивости (Cyber Resilience Act, CRA) — Регламент (EU) 2024/2847 — устанавливает обязательные требования к кибербезопасности на протяжении жизненного цикла аппаратных и программных продуктов с цифровыми элементами, предоставляемых на рынке ЕС. Требования статьи 14 к отчётности применяются с 11 сентября 2026 года — раньше большинства остальных требований CRA.

Сроки CRA, по которым продуктовым командам нужно действовать

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

Применяется ли CRA к вашему продукту?

CRA может применяться, если:

• программное или аппаратное обеспечение предоставляется на рынке ЕС в рамках коммерческой деятельности — за плату или бесплатно;
• его предполагаемое назначение или разумно предсказуемое использование предусматривает прямое или косвенное логическое либо физическое соединение для передачи данных с устройством или сетью;
• программный или аппаратный компонент отдельно выводится на рынок;
• решение удалённой обработки данных спроектировано и разработано производителем или под его ответственностью, а без такой обработки продукт теряет одну из своих функций;
• продукт продаётся под вашим наименованием или товарным знаком, в том числе когда разработка или производство переданы подрядчику;
• производитель за пределами ЕС поставляет продукт в ЕС через импортёра, дистрибьютора, уполномоченного представителя, маркетплейс или другой канал.

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

Программное обеспечение, SaaS и удалённая обработка

Загружаемое программное обеспечение и ПО, выполняемое на устройстве пользователя, могут быть продуктами с цифровыми элементами. Веб-приложение, доступное исключительно через браузер, как правило, само по себе не является таким продуктом. Однако облачная или серверная функция может входить в регулируемый продукт в качестве решения удалённой обработки данных. Поэтому сфера действия зависит от архитектуры, ответственности производителя, назначения продукта и последствий отключения удалённой обработки, а не только от ярлыка «SaaS», «cloud» или «on-premises».

Бесплатное программное обеспечение с открытым исходным кодом

Открытая лицензия сама по себе не выводит ПО из-под действия CRA. FOSS, предоставляемое для распространения или использования в ходе коммерческой деятельности, может подпадать под регламент. Для немонетизируемого FOSS, которое не предоставляется в рамках коммерческой деятельности, действует иной режим. Юридические лица, которые систематически и длительно поддерживают разработку FOSS, предназначенного для коммерческой деятельности, и обеспечивают его жизнеспособность, могут быть распорядителями ПО с открытым исходным кодом. Отдельный разработчик не становится ответственным только потому, что внёс код в проект FOSS, который не находится под его ответственностью.

H-X документирует анализ сферы действия отдельно для каждого продукта, версии, компонента, способа поставки и роли экономического оператора. Если отраслевое законодательство ЕС может исключать или изменять применение CRA, мы фиксируем эту зависимость и согласуем вывод с юридическим консультантом заказчика.

Что CRA требует от производителей

Безопасный продукт на основе документированной оценки рисков

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

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

Управление уязвимостями на протяжении периода поддержки

Производителю нужен эффективный процесс, позволяющий:

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

Обоснованный период поддержки — не универсальные пять лет

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

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

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

Техническая документация, оценка соответствия и маркировка CE

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

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

Для большинства продуктов допускается внутренний контроль, или самооценка, по модулю A. Если основная функциональность относит продукт к важным класса I, важным класса II или критическим продуктам, применяются иные процедуры:

• для важных продуктов класса I внутренний контроль возможен только при полном применении соответствующих гармонизированных стандартов, общих спецификаций или допустимой схемы европейской сертификации кибербезопасности; иначе нужна оценка третьей стороной;
• для важных продуктов класса II и критических продуктов, как правило, нужна оценка нотифицированным органом или применимая европейская схема сертификации, если CRA разрешает её использовать;
• для важного программного обеспечения с открытым исходным кодом предусмотрены специальные правила.

H-X не является нотифицированным органом и не продаёт несуществующий «сертификат CRA». Мы готовим продукт, процессы, результаты тестирования и технический файл к применимой процедуре оценки и сопровождаем взаимодействие с нотифицированным органом, когда он требуется.

CRA Exploited Vulnerability & Incident Reporting Readiness

С 11 сентября 2026 года у продуктовой команды может быть всего 24 часа, чтобы перейти от подтверждённого события безопасности к регуляторному раннему предупреждению. Политика на бумаге или ежегодный аудит CRA эту задачу не решат. Производителю нужен действующий процесс, связывающий Product Security, PSIRT, SOC, разработку, поддержку, руководство, коммуникации и юридических консультантов.

H-X внедряет и проверяет полную операционную цепочку:

Обнаружение → проверка статуса эксплуатации → регуляторная классификация → 24-часовое раннее предупреждение → 72-часовое и последующие уведомления → доказательства устранения

О чём обязательно сообщать?

Статья 14 требует от производителей сообщать:

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

Не каждый CVE, алерт сканера или эксплуатируемая уязвимость компонента требует обязательного сообщения по статье 14. Команда должна установить наличие соответствующего компонента и версии, достижимость или иную применимость уязвимого пути, наличие уязвимости в продукте и надёжных доказательств активной эксплуатации, затрагивающей этот продукт. Там, где применяются требования CRA по управлению уязвимостями, саму уязвимость всё равно необходимо оценить и устранить, даже если порог обязательной отчётности по статье 14 не достигнут.

Когда начинается отсчёт?

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

• содержащаяся в продукте уязвимость активно эксплуатируется; или
• произошёл тяжёлый инцидент, скомпрометировавший безопасность продукта.

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

Сроки отчётности по статье 14

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

Операционный процесс, который мы внедряем

1. Обнаружить событие и открыть контролируемый кейс

Мы подключаем или описываем релевантные источники: телеметрию продукта, алерты SOC/SIEM/EDR и облачной среды, клиентскую поддержку, опубликованный контакт по безопасности, скоординированное раскрытие уязвимостей, сообщения исследователей, выводы разработчиков, SAST/SCA/DAST, пентесты, EUVD/CVE и бюллетени поставщиков, разведку угроз и заслуживающие доверия публичные сообщения.

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

2. Проверить эксплуатацию и применимость к продукту

H-X помогает команде реагирования проверить:

• затронутые продукт, модель, версию, сборку и канал поставки;
• наличие компонента и зависимости по SBOM и данным сборки;
• достижимость уязвимого кода, конфигурацию, экспозицию и компенсирующие меры;
• релевантность proof of concept и наличие надёжных доказательств злонамеренной эксплуатации;
• индикаторы компрометации, телеметрию продукта, данные заказчиков и проверенную внешнюю аналитику;
• затронутых пользователей, инсталляции и государства ЕС;
• содержится ли уязвимость в продукте, в том числе через интегрированный сторонний компонент.

Результат — подтверждённое доказательствами решение о статусе эксплуатации, а не оценка критичности, ошибочно используемая вместо правовой классификации.

3. Выполнить регуляторную классификацию

Мы проводим событие через документированное дерево решений CRA и готовим запись о решении, включающую:

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

Ответственность за регуляторное решение и подачу сообщения сохраняет производитель. H-X предоставляет доказательства по кибербезопасности, расследованию и соответствию и может поддержать уполномоченного подателя в рамках согласованного мандата.

4. Подготовить 24-часовое раннее предупреждение

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

5. Сопроводить 72-часовое уведомление, коммуникации с пользователями и итоговый отчёт

По мере расследования мы обновляем материалы события и готовим:

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

6. Сформировать доказательства устранения и закрыть кейс

Итоговый пакет может включать:

• хронологию инцидента и журнал решений;
• анализ уязвимости, эксплуатации и первопричины;
• матрицу затронутых версий и каналов поставки;
• SBOM, VEX или эквивалентные записи о применимости;
• коммиты кода, согласования изменений и сведения о сборке;
• идентификаторы подписанных пакетов, хеши и доказательства выпуска;
• результаты тестов безопасности, регрессионных и повторных проверок;
• доказательства развёртывания обновления или охвата пользователей;
• бюллетень безопасности и сообщения пользователям;
• подтверждения подачи в SRP и переписку;
• решение об остаточном риске и выводы по итогам события.

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

Результаты проекта по обеспечению готовности

Заказчик получает работающие инструменты, а не только отчёт об оценке:

• реестр продуктов и сферы действия отчётности;
• дерево решений по статье 14 и форму классификации;
• правила определения момента осведомлённости и требований к доказательствам;
• RACI и матрицу эскалации для PSIRT, SOC, разработки, юристов и руководства;
• шаблоны для 24-часового, 72-часового и итогового сообщения, а также уведомления пользователей;
• соответствие шаблонов актуальным полям ENISA SRP;
• защищённую структуру кейса и систему хранения доказательств;
• карту источников SBOM и аналитики уязвимостей;
• матрицу пересекающихся регуляторных требований;
• контакты, маршрут утверждения и playbook;
• сценарий настольного учения, тренировку с контролем времени и отчёт об улучшениях;
• приоритизированный план внедрения и, при необходимости, проверку после устранения.

Полное внедрение CRA

Процесс по статье 14 можно заказать отдельно или как часть комплексной программы CRA.

1. Сфера действия, роли и классификация продукта

Мы определяем регулируемые продукты и компоненты, решения удалённой обработки, коммерческое FOSS, роли экономических операторов, исключения, семейства продуктов, основную функциональность и категорию: обычный, важный класса I, важный класса II или критический продукт.

2. Оценка разрывов CRA и план внедрения

Мы сопоставляем требования Приложений I и II с архитектурой продукта, разработкой, управлением уязвимостями, поддержкой, информацией для пользователей и существующими мерами. Результат — доказательный реестр разрывов с ответственными, приоритетами и критериями приёмки.

3. Оценка киберрисков и архитектура

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

4. Безопасная разработка и контроль цепочки поставок

Мы встраиваем требования CRA в безопасный цикл разработки, безопасность продукта и DevOps, управление релизами, процессы SBOM/VEX, скоординированное раскрытие уязвимостей, механизм обновления и требования к поставщикам.

5. Проверка безопасности продукта

В зависимости от продукта и риска выполняем аудит безопасности исходного кода, тестирование на проникновение, анализ архитектуры, конфигурации и зависимостей, проверку механизма обновления, поддержку устранения и независимый ретест.

6. Техническая документация и готовность к оценке соответствия

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

7. Постоянные операции безопасности продукта

Соответствие CRA продолжается после выпуска. H-X может предоставлять постоянную разведку угроз, SOC как сервис, расследование инцидентов и цифровую криминалистику, триаж уязвимостей, поддержку отчётности, сопровождение доказательств, периодические учения и экспертов по безопасности или виртуального CISO.

Существенные модификации: принимайте решение до релиза

Изменение уже выведенного на рынок продукта является существенной модификацией, если оно влияет на соответствие существенным требованиям к кибербезопасности из части I Приложения I или изменяет назначение, для которого продукт оценивался.

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

Мы добавляем контрольный этап релиза, который фиксирует:

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

Надзор и штрафы

Национальные органы надзора за рынком могут запросить техническую документацию и информацию, потребовать корректирующие меры, ограничить или запретить продукт, а также распорядиться о его изъятии из обращения или отзыве. Максимальные уровни административных штрафов по CRA включают:

• до 15 миллионов евро или 2,5% совокупного мирового годового оборота за нарушение существенных требований к кибербезопасности и указанных обязанностей производителя, включая статьи 13 и 14, — для предприятия применяется большая сумма;
• до 10 миллионов евро или 2% за нарушение других обязанностей CRA;
• до 5 миллионов евро или 1% за предоставление нотифицированным органам или органам надзора неверной, неполной или вводящей в заблуждение информации.

Конкретные санкции определяются законодательством государства ЕС и обстоятельствами нарушения. Микропредприятия и малые предприятия не подвергаются административному штрафу за пропуск 24-часового срока статьи 14, а к распорядителям программного обеспечения с открытым исходным кодом административные штрафы CRA не применяются. Эти исключения не отменяют сами обязанности, полномочия надзорных органов и операционную необходимость реагировать.

Почему H-X Technologies

CRA находится на пересечении продуктовой разработки, наступательной безопасности, реагирования на инциденты и обеспечения соответствия. H-X объединяет эти компетенции в одной команде. Мы можем перевести правовое требование в архитектуру, код, облачную среду, процесс сборки, телеметрию продукта, триаж уязвимостей, тестирование и готовые к аудиту доказательства, не оставляя заказчику несвязанный набор рекомендаций.

H-X можно привлечь для отдельного проекта готовности к статье 14, полного внедрения CRA, независимого аудита соответствия требованиям безопасности, проверки устранения или постоянных управляемых операций безопасности продукта.

Начните со срока, который наступает первым

Если ваши продукты предоставляются в ЕС, подготовьте процесс статьи 14 до того, как первое подлежащее отчётности событие запустит 24-часовой отсчёт. Можно начать с одного продукта и одного сценария с контролем времени, а затем масштабировать процесс на весь портфель.

Официальные источники: текст Cyber Resilience Act · обзор CRA Еврокомиссии · руководство Еврокомиссии от 27 июля 2026 года · требования CRA к отчётности · Единая платформа отчётности ENISA

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

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

Отправьте форму ниже для заказа услуг внедрения CRA.