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 у штаті потрібен. Агентства з рекрутингу в кібербезпеці допомагають з обома варіантами: швидким контрактором зараз і постійним лідом за кілька місяців.