Подготвено с помощта на AI. Източниците са проверени към Материалът е обща информация; конкретният случай изисква отделна правна преценка.
Българска компания продава собствено приложение или свързано устройство под своя марка. Екипът научава, че уязвимост в продукта вече се използва при атаки. Може ли да изчака пълния технически анализ, преди да уведоми компетентните органи?
За обхванатите производители задълженията за докладване по Cyber Resilience Act (CRA) се прилагат от 11 септември 2026 г. Основните продуктови изисквания започват да се прилагат от 11 декември 2027 г. Двете дати се отнасят до различни задължения.
Кои продукти и фирми попадат в обхвата?
Регламент (ЕС) 2024/2847 обхваща продукти с цифрови елементи, предоставяни на пазара на ЕС, чието предназначение или разумно предвидима употреба включва пряка или непряка връзка с устройство или мрежа. Това може да включва хардуер, инсталирано приложение, програма за изтегляне и отделно предлагани компоненти.
Ролята „производител“ не е запазена за фабрика. Тя може да принадлежи на фирма, която разработва или възлага разработката на софтуер и го предлага под собственото си име или марка. Възложителят и изпълнителят трябва да установят ролите си по действителния модел, а не само според заглавието на договора.
Чистата облачна услуга или обикновеният сайт не попадат автоматично в този режим. Решение за дистанционна обработка на данни може да е част от продукта, когато е разработено от производителя или под неговата отговорност и без него продуктът не може да изпълнява една от функциите си. Затова приложение със свързан облачен компонент изисква преглед на цялата архитектура.
Има специални изключения за определени продукти и за свободен софтуер с отворен код, разработван или предоставян извън търговска дейност. „Безплатен“ и „отворен код“ не означават сами по себе си, че всяка търговска употреба е изключена. За организациите, които поддържат софтуер с отворен код по специалния режим, срокът за задълженията по чл. 24, пар. 3 е 11 декември 2027 г.
Какво се докладва още сега?
Чл. 14 урежда докладването от производителя на активно експлоатирани уязвимости и тежки инциденти, засягащи сигурността на продукта. Всяка открита техническа слабост не е автоматично активно експлоатирана уязвимост. Нужна е проверка на фактите и критериите за съответното събитие.
Задължението за докладване обхваща и продукти в приложното поле, пуснати на пазара преди 11 декември 2027 г. Съгласно насоките на Комисията то може да продължи и след края на периода на поддръжка. Датата на първата продажба не е достатъчно основание да отхвърлите сигнала като „стар продукт“.
Обхватът и процедурите по CRA са отделни от уведомяването за нарушение на сигурността на личните данни по GDPR и от други приложими режими. При един инцидент проверете всяко относимо задължение; уведомяване по един режим не замества автоматично всички останали.
Какви са сроковете?
- До 24 часа от узнаването: ранно предупреждение за подлежащо на докладване събитие.
- До 72 часа от узнаването: уведомление с предвидената по-подробна информация.
- При активно експлоатирана уязвимост: окончателен доклад до 14 дни след предоставянето на коригираща мярка.
- При тежък инцидент: окончателен доклад до един месец след подаването на уведомлението в 72-часовия срок.
Това са различни начални моменти. Не броете автоматично всички срокове от датата на атаката или от деня, в който програмистът е завършил поправката. Процедурата трябва да установява кога фирмата е узнала за събитието, какво е било известно тогава и кой взема решението за докладване. Прилагат се и изискванията за действие без неоправдано забавяне.
Подаването е през единната платформа на ENISA, с адресиране към съответния координиращ CSIRT и ENISA по предвидения ред. Платформата работи от 11 септември 2026 г. Подгответе организационния достъп и отговорните лица преди инцидент; публичният адрес за контакт с поддръжката не е заместител на официалното подаване.
Планът трябва да включва и своевременно информиране на засегнатите потребители, а когато е подходящо — на всички потребители, за уязвимостта или инцидента и необходимите защитни действия. Официалното докладване и комуникацията към клиентите са свързани, но различни задачи.
Какво трябва да уредите с разработчика и доставчиците?
В договорите опишете кой приема сигнали, кой анализира засегнатите версии, как се съобщават инциденти между страните и кой подготвя корекцията и информацията към потребителите. Вътрешните срокове трябва да оставят реално време за законовите уведомления. Уговорка „доставчикът отговаря за всичко“ не прехвърля автоматично публичноправното задължение на производителя.
Включете достъп до необходимата техническа документация, информация за външни компоненти, условия за поддръжка и действия при прекратяване на договора. Проверете дали фирмата може да реагира, ако основният изпълнител е недостъпен. Правната и техническата работа трябва да се планират съвместно.
Какво да подготвите за 2027 г.?
След проверка на обхвата направете план за оценяване на рисковете, сигурност при разработване, обработване на уязвимости, поддръжка, техническа документация и приложимата процедура за оценяване на съответствието. Конкретните изисквания зависят от продукта и категорията му. Не приемайте, че един общ документ или готов сертификат решава целия режим.
Практично начало е списък с продуктите, версиите, ролите във веригата, държавите на предлагане и контактите при инцидент. За всяка група отбележете какво вече е приложимо и какво предстои. Отделно проверете плана за инциденти с лични данни.
Официални източници и консултация
Проверени са разясненията на Европейската комисия за докладването, официалните въпроси и отговори и насоките от 27 юли 2026 г. с приложението към тях. Насоките са помощ за прилагането на регламента и нямат самостоятелна задължителна сила.
За договорен преглед и консултация за приложимия режим опишете продукта, начина на продажба и участниците в разработката. Първоначалното запитване не изисква изпращане на изходен код, ключове или подробности за непубликувана уязвимост.