Кибербезопасность и управление продуктом

Отчётный таймер EU Cyber Resilience Act запустится 11 сентября. Эстонскому производителю нужен процесс на 24 часа

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

Автор Мартин Репински25 августа 2026 года

11 сентября 2026 года начнёт применяться один из первых операционных сроков европейского Cyber Resilience Act — Регламента о киберустойчивости. Производители должны будут уведомлять об активно эксплуатируемых уязвимостях и серьёзных инцидентах, влияющих на безопасность продуктов с цифровыми элементами.

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

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

Одновременно идут два отсчёта

CRA вступил в силу 10 декабря 2024 года. Официальное резюме Европейской комиссии разделяет применение Регламента на несколько этапов:

правила уведомления органов оценки соответствия применяются с 11 июня 2026 года;
обязанности по статье 14 применяются с 11 сентября 2026 года;
основные положения CRA применяются с 11 декабря 2027 года.

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

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

Какие продукты и организации входят в контур

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

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

У импортёра, дистрибьютора, уполномоченного представителя и сопровождающего открытое ПО лица разные роли по Регламенту. ENISA указывает, что обязанности сопровождающего открытое ПО действуют в объёме, установленном статьёй 24. Поэтому роль следует фиксировать отдельно по каждому продукту, не считая слова «пользователь», «реселлер» или «open source» исчерпывающим ответом.

Последовательность уведомления измеряется часами

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

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

Официальный график состоит из трёх этапов:

Раннее предупреждение в течение 24 часов. Первичное сообщение подаётся без неоправданной задержки и в любом случае в течение 24 часов после того, как производитель узнал о событии.
Уведомление в течение 72 часов. Производитель предоставляет общую информацию и первоначальную оценку, включая доступные меры исправления или снижения риска.
Итоговый отчёт об уязвимости. Он подаётся не позднее 14 дней после появления меры исправления или снижения риска.
Итоговый отчёт о серьёзном инциденте. Он подаётся в течение одного месяца после 72-часового уведомления.

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

Августовская инструкция ENISA указывает, что представители будут использовать EU Login. Учётную запись можно создать заранее, а проверка полномочий на подачу сообщения от имени производителя проходит при использовании платформы и не должна препятствовать отправке. Практический вывод: владельца доступа и внутренние полномочия нужно определить до инцидента, хотя юридический таймер запускается только после того, как компания узнаёт о событии, подлежащем уведомлению.

Практический план готовности для эстонской продуктовой компании

1. Создать реестр продуктов и ролей

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

2. Связать мониторинг безопасности с юридическим владельцем продукта

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

3. Определить момент осведомлённости

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

4. Разделить данные для 24 и 72 часов

Раннее предупреждение не является окончательным техническим отчётом. Инструкция ENISA различает минимальную информацию на каждом этапе. Внутренние формы должны собирать сведения о продукте, типе сообщения, времени, известном влиянии, доступных мерах и данных, которые ещё проверяются.

5. Включить поставщиков и сторонние компоненты

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

6. Отрепетировать один реалистичный сценарий

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

Готовность к отчётности — часть экономики продукта

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

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

Первый срок — уже не далёкая точка соответствия в 2027 году. Это требование к реагированию на инциденты в сентябре 2026 года, измеряемое часами.

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

Основные источники

Мартин Репински