Відповідність 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 може застосовуватися, якщо:

• програмне або апаратне забезпечення надається на ринку ЄС у межах комерційної діяльності — за плату або безоплатно;
• його передбачене призначення або обґрунтовано передбачуване використання передбачає пряме чи непряме логічне або фізичне з’єднання для передавання даних із пристроєм чи мережею;
• програмний або апаратний компонент окремо вводиться в обіг;
• рішення віддаленого опрацювання даних спроєктоване й розроблене виробником або під його відповідальністю, а без такого опрацювання продукт втрачає одну зі своїх функцій;
• продукт продається під вашим найменуванням або торговельною маркою, зокрема коли розроблення чи виробництво передано підряднику;
• виробник за межами ЄС постачає продукт до ЄС через імпортера, дистриб’ютора, уповноваженого представника, маркетплейс або інший канал.

Вимоги до виробників, уповноважених представників, імпортерів, дистриб’юторів і розпорядників програмного забезпечення з відкритим вихідним кодом (open-source software stewards) відрізняються. Основні обов’язки щодо безпеки продукту, документації, оцінювання відповідності та звітування за статтею 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.