CRA-отчётность действует с 11 сентября: кто в вашей компании отвечает за 24-часовой отчёт?

Пятница, вечер. Security researcher пишет SaaS-компании, что в её программе, которую клиенты устанавливают на свои компьютеры, нашли уязвимость. Злоумышленники уже используют её, чтобы получить доступ к компьютерам пользователей. Ещё летом такая ситуация оставалась внутренним делом компании. С 11 сентября 2026 года Cyber Resilience Act работает иначе: если продукт продаётся в ЕС, у производителя есть 24 часа, чтобы официально сообщить об этом через платформу ENISA. Сообщение подаёт конкретный человек, заранее зарегистрированный на платформе, у которого есть право самостоятельно решить, что отчёт нужен. Поэтому для большинства компаний CRA сводится к найму: такой роли в команде просто нет.

IT рекрутинговое агентство EvoTalents закрывает позиции в кибербезопасности, embedded и defense tech, поэтому мы смотрим на CRA с практической стороны. Нам важно понять, кто в компании отвечает за отчёт, какие роли для этого нужны и сколько времени займёт их найм. Ниже объясняем, что именно требует закон, почему SOC эту задачу не закрывает и каких специалистов стоит искать уже сейчас.

1. Что изменилось 11 сентября

С 11 сентября 2026 года применяется статья 14 Cyber Resilience Act. Производитель продукта с цифровыми элементами, который продаётся на рынке ЕС, обязан уведомлять регулятора в двух ситуациях.

Первая: в продукте есть уязвимость, и злоумышленники уже её используют. Речь о случаях, когда есть надёжные доказательства атаки на реальную систему, например на устройство клиента. Уязвимость, которую нашли во время внутреннего тестирования и которой никто не успел воспользоваться, сюда не относится.

Вторая: произошёл серьёзный инцидент, из-за которого пострадала безопасность самого продукта. Например, после атаки устройства клиентов перестали работать, с них утекли данные или в обновление попал вредоносный код.

На первых двух этапах сроки для обеих ситуаций одинаковые:

• раннее предупреждение (early warning): в течение 24 часов с момента, когда компания узнала об атаке или инциденте;
• уведомление (notification): в течение 72 часов, с общей информацией о том, как именно злоумышленники использовали уязвимость, и первичной оценкой;
• финальный отчёт: для уязвимости не позднее 14 дней после того, как появился патч или другой способ защиты; для серьёзного инцидента в течение месяца после 72-часового уведомления.

Все этапы подаются через Single Reporting Platform (SRP), которая заработала в тот же день. Параллельно производитель должен сообщить пользователям, которых это затронуло, и при необходимости объяснить, как защититься.

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

Основная часть CRA, в том числе требования к безопасности продукта, SBOM и обработке уязвимостей, начнёт действовать 11 декабря 2027 года. За нарушение статьи 14 предусмотрен штраф до 15 млн евро или 2,5% мирового годового оборота, в зависимости от того, какая сумма больше. Для микро- и малых компаний есть одно послабление: их не штрафуют за пропущенное 24-часовое предупреждение. 72-часовое уведомление и финальный отчёт для них так же обязательны, как для всех.

2. Кто отчитывается и куда

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

Отчёт получает координационный CSIRT страны, где находится основное предприятие (main establishment), то есть где в основном принимают решения по кибербезопасности продукта. Для компаний без такого предприятия в ЕС статья 14(7) устанавливает резервный порядок выбора. Если CSIRT выбран неправильно, уведомление могут признать недействительным, и его придётся подавать заново. Список координационных CSIRT для всех 27 стран ENISA опубликовала 4 сентября.

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

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

3. Когда запускаются часы и как выглядит подача

Разъяснения Еврокомиссии от 27 июля 2026 года описывают момент осведомлённости так: первичная оценка даёт разумную степень уверенности, что уязвимость активно используют или произошёл серьёзный инцидент. «Активно используют» значит, что есть надёжные доказательства: злоумышленник применил уязвимость в чьей-то системе без разрешения владельца.

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

Как платформа работает на практике

• Доступ через EU Login с MFA. Производитель регистрирует одного Primary Assigned Representative (AR) и до 20 Secondary AR.
• Черновики видит только тот AR, который их создал. Если AR один и он в отпуске, отчёт застрянет.
• API нет, интерфейс только на английском, отчёт заполняют вручную. Если платформа недоступна, отчёт всё равно придётся подать через неё, когда она заработает.

4. Британский контекст: PSTI уже действует, CSRB на подходе

Британский режим PSTI для потребительских устройств действует с 29 апреля 2024 года. Он запрещает универсальные пароли по умолчанию, требует опубликовать контакт для сообщений о проблемах безопасности со сроками ответа и указать минимальный период обновлений. Штраф достигает 10 млн фунтов или 4% мировой выручки.

Получается, у компании, которая соответствует PSTI, уже есть адрес, на который security researcher может написать. Кто обрабатывает эти письма, воспроизводит эксплойт и отчитывается перед регулятором в течение 24 и 72 часов, PSTI не определяет. Эти требования добавляет CRA вместе с SBOM и полным процессом обработки уязвимостей.

Cyber Security and Resilience Bill 7 сентября 2026 года прошёл рассмотрение в комитете Палаты лордов. По предварительному графику Report Stage назначена на 26 октября, и дата ещё может сдвинуться. Законопроект охватывает управляемых поставщиков услуг (MSP) под надзором ICO, дата-центры, крупных операторов управления нагрузкой и определённых критических поставщиков. Он предусматривает первичное уведомление регулятора и NCSC в течение 24 часов и полный отчёт в течение 72 часов. Штрафы за серьёзные нарушения достигают 17 млн фунтов или 4% мирового оборота. Royal Assent ожидают между концом 2026 и весной 2027 года, а большинство обязанностей появится через подзаконные акты.

Британский вендор софта или устройств, который ещё и предоставляет управляемые услуги, может оказаться сразу с двумя 24-часовыми часами: один по CRA для продуктов, другой по CSRB для сервисов.

5. Почему это задача PSIRT

SOC следит за инфраструктурой самой компании: сетью, эндпоинтами, учётными записями. Сигнал по CRA часто приходит снаружи. Это может быть письмо от security researcher, сообщение от CERT клиента, новая запись в CISA KEV или атака на встроенный компонент в устройствах, которые давно работают у клиентов. SOC эти сигналы обычно не видит.

PSIRT (Product Security Incident Response Team) работает с продуктами компании и их пользователями. FIRST описывает для PSIRT отдельный фреймворк, отличный от CSIRT, с шестью направлениями: работа со стейкхолдерами, выявление уязвимостей, триаж и анализ, исправление, раскрытие, обучение. Вакансии в этой сфере ссылаются на ISO/IEC 29147 (раскрытие уязвимостей), ISO/IEC 30111 (обработка уязвимостей), CVSS v3.1/v4 и процедуры CNA.

У крупных производителей эта функция существует давно: PSIRT в Cisco с 1995 года, в Ericsson с 2004-го, в Bosch с 2016-го. Компаниям среднего размера, которые продают устройства или софт в ЕС, чаще всего придётся строить её с нуля.

Мы рекомендуем такое распределение ответственности. Юристы и compliance отвечают за формулировки отчётов и уведомлений клиентам. Решение «подаём» принимает PSIRT lead, и его право подать отчёт без дополнительного согласования закреплено письменно.

6. Насколько компании готовы

В Европе октябрь традиционно считается месяцем кибербезопасности, и в этом году ENISA посвящает его навыкам людей. Цифры 2026 года показывают, что с людьми и процессами под CRA пока сложно:

• 66% из 843 опрошенных организаций мало или совсем не знакомы с CRA, годом ранее таких было 62%. Среди компаний из США и Канады этот показатель достигает 72%.
• 41% тех, кто знает о CRA, ещё не определили, распространяется ли он на них. Полностью выполнить требования к декабрю 2027 года рассчитывают тоже только 41%.
• В 57% микрокомпаний нет человека, ответственного за кибербезопасность. Процессы управления уязвимостями есть у 41% малых и средних компаний, SBOM используют 35%.
• 59,47% производителей потребительских IoT-устройств в мире не имеют политики раскрытия уязвимостей. Среди новых игроков рынка такая политика есть только у 16 из 68.

Спрос на рынке труда тем временем растёт. В Британии количество core cyber вакансий за 2025 год выросло на 7%, а доля бизнесов, которым не хватает базовых технических навыков, увеличилась с 49% до 57%. Лондон на первом месте по количеству вакансий. За последние полгода в Британии опубликовали 392 объявления по application security против 159 годом ранее и 790 контрактов на vulnerability management против 329. Часть этого роста может объясняться изменениями в источниках данных, но тенденция очевидна.

7. Какие роли открывать сейчас

PSIRT lead (Head of Product Security / PSIRT Manager)

Отвечает за весь процесс. Принимает решение о моменте осведомлённости, руководит триажем, подаёт отчёты в SRP и ведёт политику координированного раскрытия уязвимостей (CVD). Реже всего на рынке встречаются кандидаты, которые сочетают технический триаж с пониманием регуляторных требований и умеют спокойно разговаривать с security researchers, CSIRT и клиентами.

Product security / embedded security engineer

Воспроизводит эксплойт, оценивает влияние на конкретную версию прошивки или продукта и вместе с разработчиками готовит исправление. Для устройств и промышленных продуктов часто нужны знание IEC 62443 и опыт embedded-инженера.

Vulnerability management lead

Ведёт реестр уязвимостей, CVSS-оценки и сроки исправления, сверяет CISA KEV и threat intel с SBOM продуктов. Эту роль проще всего закрыть контрактором на переходный период.

SBOM / supply-chain security engineer

Создаёт и обновляет SBOM для всех продуктов, настраивает SCA в CI/CD-пайплайне и отслеживает сторонние компоненты, для которых действуют те же 24 часа.

Откуда приходят кандидаты

Чаще всего из трёх направлений. Инженеры SOC и CSIRT приносят скорость и опыт триажа. Пентестеры и специалисты по embedded/IoT security умеют воспроизводить эксплойты. AppSec и DevSecOps знают SBOM, SCA и пайплайн. В требованиях вакансий сейчас появляются CVSS, процессы CVE/CNA, ISO/IEC 29147/30111, SBOM-инструменты, threat modelling/TARA и рабочее знание Annex I и статьи 14 CRA.

Зарплаты и сроки

Отдельной статистики зарплат именно для PSIRT в Британии нет, поэтому ориентируемся на смежные роли. Вакансии для сеньоров в кибербезопасности в Лондоне в среднем остаются открытыми на 46 дней дольше, чем другие IT-роли, а найм часто занимает от трёх до шести месяцев. Если открыть поиск в 2027 году, конкурировать придётся со всеми производителями, которые вспомнят о дедлайне одновременно.

На переходный период можно привлечь PSIRT-as-a-service или контрактора на vulnerability management. Они закрывают мониторинг и подготовку черновиков. Юридическая обязанность и решение об осведомлённости остаются за производителем.

У всех четырёх ролей общая сложность: профиль очень узкий. Кандидат должен понимать embedded-системы на уровне кода и знать, как живёт продукт, который годами работает у клиентов. В каждой отдельной стране таких людей мало, поэтому поиск обычно идёт сразу в нескольких странах и через профильные сообщества. Как это выглядит на практике, показывает наш кейс с компанией, которую CRA касается напрямую: производителем AI-камер и IoT-систем безопасности. Мы закрывали для неё embedded-, backend- и AI-роли. Позиций PSIRT среди них не было, но кандидатов искали в тех же узких пулах.

КЕЙС EVOTALENTS: ПЯТЬ ТЕХНИЧЕСКИХ НАПРАВЛЕНИЙ ДЛЯ ПРОИЗВОДИТЕЛЯ IoT-СИСТЕМ БЕЗОПАСНОСТИ

Клиент: компания в сфере технологий безопасности, которая разрабатывает AI-камеры и IoT-системы видеонаблюдения, Украина и Польша, 50-100 сотрудников. Уровень: senior-инженеры. Формат: долгосрочное сотрудничество с 2023 года.

Ситуация

Компании нужно было масштабировать команду сразу в пяти направлениях: backend на Python/Go, embedded C/C++, инфраструктура видеостриминга, исследования LLM/AI и hardware-разработка. На каждую роль искали самостоятельных сеньоров, а кандидатов в таких нишах очень мало. Для hardware-ролей нужно было присутствие в лаборатории в Киеве. Ограничения на бронирование сотрудников и выход на польский рынок добавляли сложности.

Подход EvoTalents

• Отдельная команда рекрутеров вела все пять направлений параллельно.
• Под каждое направление своя стратегия сорсинга: прямой выход на пассивных кандидатов для senior backend, академические сети для AI/LLM, профильные площадки и инженерные митапы для embedded.
• Поиск через сообщества Python, Go, embedded и AI/ML в Украине и Польше.
• Аналитика польского рынка найма, чтобы поддержать расширение клиента.

Результат

• Закрыто 7+ позиций, сотрудничество продолжается.
• Длительность сотрудничества: больше 2,5 лет, с 2023 года.
• Пайплайн: 100-200+ кандидатов на каждую роль.
• География поиска: Украина и Польша.

Отзыв клиента: «Когда у EvoTalents что-то идёт сложно, они не сдаются. Берутся за задачу, пробуют разные подходы, открыто говорят о своих сомнениях и собирают обратную связь. В итоге мы получили лучших кандидатов».

Для производителя камер и IoT-устройств CRA означает ещё несколько ролей: PSIRT lead, embedded security engineer, vulnerability management. Кандидатов на них придётся искать в тех же узких пулах, что и embedded C/C++ инженеров: через профильные сообщества, в нескольких странах и с отдельной стратегией сорсинга под каждую роль. Что из этого компания может сделать сама за первые три месяца, рассказываем дальше.

Первые 90 дней: план для CTO и CISO

Дни 1-30: назначить ответственного

Назначьте PSIRT lead или временно исполняющего обязанности и письменно закрепите за ним право подавать отчёты. Зарегистрируйте Primary AR и как минимум двух Secondary AR в EU Login с MFA. Определите свой координационный CSIRT. Опубликуйте security.txt и CVD-политику в соответствии с ISO/IEC 29147.

Дни 31-60: подготовить процесс

Пропишите критерии осведомлённости в playbook триажа. Соберите SBOM для продуктов, которые продаются в ЕС, и настройте их сверку с CISA KEV. Подготовьте шаблоны для каждого этапа SRP и для уведомлений пользователям. Составьте карту эскалаций, на которой видны параллельные сроки по NIS2, DORA, GDPR, а позже и CSRB.

Дни 61-90: проверить на людях

Запустите круглосуточное дежурство минимум из трёх-четырёх человек: один человек не закроет 24-часовые часы в выходные. Проведите первое tabletop-учение и проверьте, получается ли собрать нужных людей за 24 часа. Откройте вакансии на постоянные роли, а на переходный период подключите контрактора или PSIRT-as-a-service.

Самые частые ошибки

Отдать отчётность SOC по умолчанию. SOC не получает писем от security researchers и не видит, что происходит с устройствами у клиентов.

Зарегистрировать одного AR. Его черновики больше никто не видит, и отпуск или болезнь останавливают подачу.

Ждать согласования юристов перед подачей. 24 часа считаются от момента осведомлённости, а не от того, когда юридический отдел прочитал письмо.

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

Забыть о продуктах, которые уже на рынке, и о сторонних компонентах. Сроки распространяются на оба случая.

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

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

FAQ

Распространяется ли CRA на британскую компанию, которая продаёт устройства или софт в ЕС?

Да. CRA определяет обязанности по рынку, на котором продаётся продукт. Британский производитель выбирает координационный CSIRT по резервному порядку из статьи 14(7), регистрирует AR в EU Login и отчитывается через SRP в те же сроки 24 и 72 часа. Если компания также предоставляет управляемые услуги, позже к этому может добавиться 24-часовая отчётность по британскому CSRB.

С какого момента считать 24 часа для CRA-отчёта?

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

Действуют ли уже штрафы за пропущенный отчёт по CRA?

Обязанность отчитываться действует с 11 сентября 2026 года. Статья 64 предусматривает до 15 млн евро или 2,5% мирового оборота за нарушение статьи 14. Часть юристов считает, что сама система штрафов формально заработает только 11 декабря 2027 года, но официального подтверждения такого толкования нет. Микро- и малые компании не штрафуют только за пропущенное 24-часовое предупреждение.

Сколько длится поиск PSIRT lead и сколько он стоит в Лондоне?

Найм сеньоров в кибербезопасности в Британии часто занимает от трёх до шести месяцев. Отдельной зарплатной статистики для PSIRT нет. Ближайшие ориентиры: медиана application security в Лондоне £100 000, медиана CSIRT в Британии около £90 000. Лиды, которые сочетают технический триаж и регуляторный опыт, обычно стоят больше медианы.

Можно ли закрыть PSIRT аутсорсом или через staffing?

Частично. PSIRT-as-a-service и контракторы на vulnerability management закрывают мониторинг, триаж и подготовку черновиков на переходный период. Решение об осведомлённости и юридическая ответственность за отчёт остаются за производителем, поэтому PSIRT lead в штате нужен. Агентства по рекрутингу в кибербезопасности помогают с обоими вариантами: быстрым контрактором сейчас и постоянным лидом через несколько месяцев.