Cybersecurity risk assessment: як виробнику довести комплаєнс з CRA
Для виробника цифрових продуктів, який виходить на ринок ЄС, Cyber Resilience Act (Регламент (ЄС) 2024/2847, далі – CRA) – це регуляторна рамка, що якої виробник має довести відповідність: показати, які ризики він виявив, як на них відреагував і чим це підтверджується. Центральним документом такої доказової бази є оцінка кібербезпекових ризиків (cybersecurity risk assessment).
У цій статті ми розглянемо, що саме CRA вимагає від оцінки ризиків, як її проводити, як вона вписується в технічну документацію, оцінку відповідності та маркування CE, а також що робити, поки гармонізовані стандарти ще тільки завершуються. Окремо згадаємо те, що вже діє: обов’язки зі звітності застосовуються з 11 вересня 2026 року.
Ключові дати CRA: що вже діє, а що ще попереду
CRA набув чинності 10 грудня 2024 року, але застосовується поетапно:
- з 11 червня 2026 року – положення про notified bodies (органи з оцінки відповідності);
- з 11 вересня 2026 року – обов’язки зі звітності про активно експлуатовані вразливості та серйозні інциденти (ст. 14);
- з 11 грудня 2027 року – основні вимоги до продуктів, обов’язки щодо документації та маркування CE.
На практиці це означає, що продукт, який виводитиметься на ринок ЄС після грудня 2027 року, потрібно проєктувати з урахуванням оцінки ризиків, а продукти, які перебувають на ринку сьогодні, вже підпадають під вимоги звітності.
Чому оцінка ризиків – основа доведення відповідності
CRA побудований на ризик-орієнтованому підході. Стаття 13 зобов’язує виробника провести оцінку кібербезпекових ризиків продукту та врахувати її результати на всіх етапах: планування, проєктування, розробки, виробництва, постачання й підтримки. Оцінку необхідно задокументувати, оновлювати протягом строку підтримки продукту та включити до технічної документації.
Це принципово: вимоги Додатка I до CRA не застосовуються механічно. Саме оцінка ризиків пояснює, чи застосовна конкретна вимога до продукту, і якщо так – яким чином вона реалізована. Орган ринкового нагляду, як правило, ставитиме не питання «що ви зробили», а питання «чому цього рівня захисту достатньо для вашого продукту». Фактично це і є інженерія комплаєнсу: переклад норми закону у вимоги, які можна реалізувати, перевірити й підтвердити документально.
Варто розрізняти цю оцінку з оцінкою впливу на захист даних (DPIA) за GDPR. DPIA аналізує ризики для прав і свобод людей, чиї дані обробляються, а оцінка за CRA – кібербезпекові ризики самого продукту. Об’єкти різні, хоча частину вхідних даних (карти даних, опис архітектури) можна використовувати повторно.
Що має містити cybersecurity risk assessment за CRA
Згідно зі ст. 13, оцінка повинна містити аналіз ризиків з урахуванням призначення продукту, обґрунтовано передбачуваного використання та умов експлуатації, а також строку, протягом якого продукт імовірно використовуватиметься. Крім того, вона має показати, як продукт відповідає вимогам Додатка I. Узагальнено структуру можна подати так:
| Елемент оцінки | Що документувати | Опора в CRA |
| Призначення й передбачуване використання | Функції продукту, цільові користувачі, обґрунтовано передбачувані сценарії використання | Ст. 13 |
| Умови експлуатації та активи | Операційне середовище, дані та функції, що потребують захисту, очікуваний строк використання | Ст. 13 |
| Загрози й вразливості | Джерела загроз, вектори атак, поверхня атаки, залежності від сторонніх компонентів | Додаток I, частина I |
| Застосовність вимог Додатка I | Для кожної вимоги – чи застосовна вона, як реалізована, чи є обґрунтування, якщо ні | Ст. 13, Додаток I, частина I |
| Обробка вразливостей | Як продукт і процеси виробника відповідають частині II Додатка I (SBOM, патчі, політика розкриття вразливостей) | Ст. 13, Додаток I, частина II |
| Перегляд і оновлення | Тригери перегляду оцінки протягом строку підтримки | Ст. 13 |
До вимог частини I Додатка I належать, зокрема, безпечна конфігурація за замовчуванням, захист від несанкціонованого доступу, шифрування, цілісність даних, мінімізація даних, обмеження поверхні атаки, журналювання й безпечне видалення даних. Саме за цими пунктами оцінка має показати «застосовно / не застосовно / як реалізовано».
Покрокова інструкція: як провести оцінку ризиків
CRA не нав’язує конкретної методології, тому виробник може обрати модель, яка відповідає його продукту й процесам розробки.
Практичний алгоритм виглядає так:
- Визначте роль і продукт. Переконайтеся, що ви є виробником продукту з цифровими елементами (апаратного, програмного забезпечення або його рішень з віддаленою обробкою даних) і що продукт не виключений з-під дії CRA через галузеве регулювання.
- Опишіть призначення та умови використання. Зафіксуйте, для чого продукт створений, хто ним користується, в якому середовищі працює, який орієнтовний строк використання.
- Побудуйте модель активів і поверхні атаки. Опишіть потоки даних, інтерфейси, канали оновлення, сторонні та open source компоненти.
- Ідентифікуйте загрози й оцініть ризики. Можна використати визнані підходи (наприклад, STRIDE або ISO/IEC 27005), але важливо, щоб результати були відтворюваними, а критерії оцінки – зафіксованими.
- Зіставте ризики з Додатком I. Для кожної вимоги визначте, чи вона застосовна, яким заходом реалізована та чим це можна підтвердити.
- Визначте заходи та способи верифікації. Призначте відповідальних і заплануйте тестування (наприклад, penetration testing, перевірку залежностей).
- Встановіть строк підтримки й тригери перегляду. За загальним правилом CRA строк підтримки має становити щонайменше п’ять років, якщо очікуваний строк використання продукту не коротший. Перегляд оцінки варто прив’язати до нових релізів, виявлених вразливостей, змін архітектури та суттєвих модифікацій.
- Вбудуйте результати в життєвий цикл продукту. Оцінка має впливати на backlog, вимоги до розробки та релізні рішення, а не лежати окремим документом. Це підхід інженерії безпеки: безпека закладається в систему як частина архітектури.
Технічна документація
Оцінку ризиків потрібно включити до технічної документації за ст. 31 та Додатком VII. Саме цей пакет документів орган ринкового нагляду може запросити для перевірки. Склад документації можна узагальнити так:
| Складова | Що показати | Приклади доказів |
| Опис продукту | Призначення, версії, що впливають на відповідність, інструкції для користувача | Специфікація продукту, user guide, схема архітектури |
| Проєктування, розробка та обробка вразливостей | Як продукт розроблений і як виробник працює з вразливостями | Політика secure SDLC, SBOM, політика розкриття вразливостей |
| Оцінка ризиків | Результат аналізу за ст. 13 | Звіт з оцінки ризиків, реєстр ризиків із версіями |
| Підтримка | Строк підтримки та правила надання оновлень | Support policy, публічна інформація про строк підтримки |
| Верифікація | Застосовані стандарти, результати тестів | Звіти тестування, перелік застосованих стандартів |
До документації також додається копія декларації ЄС про відповідність. Виробник має зберігати документацію та декларацію щонайменше десять років після виведення продукту на ринок або протягом строку підтримки – залежно від того, що довше. Якщо в матеріалах є комерційна таємниця (наприклад, подробиці алгоритмів чи архітектури), її варто чітко маркувати й узгодити внутрішній режим доступу ще до запиту регулятора.
Оцінка відповідності: який шлях доказування обрати
Після оцінки ризиків і підготовки документації виробник проходить процедуру оцінки відповідності. Обраний шлях залежить від категорії продукту:
| Категорія продукту | Процедура | Участь третьої сторони |
| Більшість продуктів (за замовчуванням) | Внутрішній контроль (Module A), самооцінка виробника | Не потрібна |
| Важливі продукти, клас I (Додаток III) | Module A – лише за умови повного застосування гармонізованих стандартів чи схеми сертифікації; в інших випадках – оцінка третьою стороною | Залежить від застосування стандартів |
| Важливі продукти, клас II (Додаток III) | Обов’язкова оцінка третьою стороною (EU-type examination або повне забезпечення якості) | Обов’язкова |
| Критичні продукти (Додаток IV) | Європейська схема кібербезпекової сертифікації, якщо це вимагатиме делегований акт; інакше – процедури для класу II | Так, залежно від схеми |
У разі успішного завершення процедури виробник складає декларацію ЄС про відповідність та наносить маркування CE. Для важливих продуктів, що є вільним і відкритим програмним забезпеченням, ст. 32 передбачає спрощений шлях через Module A за умови публічного доступу до технічної документації.
Гармонізовані стандарти та презумпція відповідності: що робити зараз
Продукти, що відповідають гармонізованим стандартам, опублікованим в Official Journal of the EU, користуються презумпцією відповідності в тій частині, яку ці стандарти покривають. Стандартизаційний запит Комісії (M/606) охоплює близько 41 стандарту від CEN, CENELEC та ETSI. За графіком запиту ключові горизонтальні стандарти щодо безпечної розробки та обробки вразливостей очікувалися до 30 серпня 2026 року, вертикальні – до 30 жовтня 2026 року, а решта горизонтальних – до 30 жовтня 2027 року. Актуальний статус цитування стандартів слід перевіряти в Official Journal.
Поки стандарти не процитовані, відповідність потрібно демонструвати безпосередньо за вимогами Додатка I. Чекати на них не варто: якщо оцінка ризиків, технічна документація та докази тестування вже структуровані за Додатком I, зіставлення зі стандартами згодом зводиться до аналізу прогалин, а не до перебудови всієї доказової бази.
Звітність за статтею 14: чому вона вже впливає на доказову базу
З 11 вересня 2026 року виробники зобов’язані повідомляти про активно експлуатовані вразливості та серйозні інциденти, що впливають на безпеку продукту. Повідомлення подаються через єдину платформу звітності ENISA (Single Reporting Platform) до відповідної національної CSIRT та ENISA. Строки відлічуються з моменту, коли виробник дізнався про подію:
| Етап | Термін | Зміст |
| Раннє попередження | 24 години | Факт події, за можливості – держави ЄС, де продукт доступний |
| Повідомлення | 72 години | Опис вразливості чи інциденту, характер експлуатації, вжиті або заплановані заходи |
| Підсумковий звіт | Для вразливості – 14 днів після появи виправлення чи пом’якшувального заходу; для інциденту – один місяць після повідомлення | Первинна причина, серйозність, наслідки, вжиті заходи та, за потреби, рекомендації для користувачів |
Такі строки неможливо витримати без заздалегідь налаштованого процесу.
Саме тому документація з обробки вразливостей є частиною доказової бази: вона показує, хто приймає рішення про класифікацію події, як фіксується момент «обізнаності» та як готується звіт. Якщо про подію виробник дізнався до 11 вересня 2026 року, звітувати про неї за CRA не потрібно, проте для подій після цієї дати штраф за порушення може сягати 15 млн євро або 2,5% світового річного обороту.
Повідомлення за CRA не замінює інших обов’язків щодо тієї самої події. Наприклад, якщо інцидент стосується персональних даних, діють окремі строки та вимоги Загального регламенту про захист даних (GDPR).
Сторонні компоненти та open source
Стаття 13 вимагає від виробника проявляти належну обачність щодо компонентів третіх сторін, зокрема відкритого коду, щоб вони не послаблювали кібербезпеку продукту. На практиці це означає, що SBOM (перелік програмних компонентів) потрібен не лише як технічний артефакт, а й як вхідні дані для оцінки ризиків. Доцільно поєднувати перевірку вразливостей із аудитом відповідності умовам ліцензій відкритого програмного забезпечення, адже обидва процеси спираються на ті самі дані про компоненти та їхні ліцензії з відкритим вихідним кодом.
Частину ризиків потрібно перенести у договірну площину.
Для виробників, які залучають розробників чи постачальників компонентів, це зазвичай означає такі зміни:
- у рамкових договорах (MSA) та технічних завданнях (SOW) – вимоги до безпечної розробки, передавання SBOM і підтримки документації;
- у гарантіях та запевненнях – відсутність відомих експлуатованих вразливостей на момент передання та належний процес їх усунення;
- в угоді про рівень сервісу (SLA) – строки реагування на вразливості, узгоджені з 24-годинним та 72-годинним строками звітності;
- у зобов’язаннях щодо відшкодування втрат – розподіл відповідальності, якщо недолік компонента призвів до штрафу чи претензій.
Це безпосередньо стосується й українських аутсорсингових та продуктових компаній.
Якщо ви розробляєте продукт для клієнта-виробника, ці вимоги, найімовірніше, надійдуть до вас договірним шляхом. Якщо ж продукт виводиться на ринок ЄС під вашим ім’ям, ви самі є виробником, а ваші партнери в ЄС виконують ролі імпортера чи дистриб’ютора.
Висновок
Для CRA оцінка кібербезпекових ризиків – це логічний міст між продуктом і вимогами Додатка I. Виробник, який може показати, які ризики він виявив, чому обрав саме такі заходи, як їх перевіряє та як реагує на нові вразливості, буде в сильній позиції і перед органом нагляду, і перед корпоративним клієнтом. Звітність уже діє, тож варто починати з процесів і документації, а не чекати на 2027 рік.
