CRA PSIRT – Прийом повідомлень про вразливості, звітність протягом 24/72 годин та ланцюжок доказів | Word/PDF/Excel

Отримайте, оцініть та задокументуйте конкретну вразливість у сфері безпеки або інцидент у цифровому продукті — від першого повідомлення до фактичного повідомлення про інцидент відповідно до CRA та інформування клієнтів. Цей спеціалізований пакет для виробників продуктів із цифровими компонентами зосереджений на статті 14 CRA та Єдиній платформі повідомлень ENISA (SRP). Він не замінює комплексну оцінку ризиків відповідно до CRA, SBOM або фактичне повідомлення про інцидент регулятору.

Коротко про головне: 5 робочих документів шведською мовою, 1 керівництво для користувачів шведською мовою та 1 керівництво для користувачів англійською мовою, усі в редагуваному форматі Word (DOCX) та пошуковому форматі PDF для друку (не інтерактивні форми), а також 1 робоча книга Excel шведською мовою з 9 вкладками. Усього 15 клієнтських файлів: сім самостійних документів у двох форматах плюс один файл XLSX. Цифрове надання через ZIP-архів у майбутньому при активації.

Кому слід обирати шаблон — і коли?

Для розробників продуктів і виробників, які продають програмне забезпечення, підключене обладнання або інші продукти з цифровими компонентами на ринку ЄС і мають обробляти ознаки активного експлуатування вразливості або серйозного інциденту в сфері безпеки. Два типові випадки: повідомляч надає докази атак на конкретну версію прошивки; або виробник дізнається про інцидент, який серйозно впливає на безпеку продукту. Якщо ви звичайний дистриб’ютор, постачальник послуг з обслуговування ІТ-інфраструктури або обробляєте лише внутрішні ІТ-інциденти, можуть бути доречні інші документи та правила. Юридичний статус виробника та застосування CRA необхідно перевірити насамперед.

Файл за файлом

Робота з інструментом Excel на практиці

Робоча книга має фільтровані записи, поля статусу, зв’язки з ID та огляд на основі формул. При введенні фактичного значення UTC-часу, коли виробник дізнався про подію, що підлягає повідомленню, вона відображає орієнтовні часові межі 24 год і 72 год. Вони є максимальними технічними контрольними значеннями, а не правом на очікування: повідомляйте без зайвих зволікань. Дата підсумкового повідомлення вводиться вручну, оскільки тригери відрізняються: коли засіб стає доступним (AEV) або коли повідомлення протягом 72 год було фактично подано (SI). Реєстр розрізняє чернетку, оцінку, надіслане повідомлення та фактичне підтвердження.

Покроковий робочий процес

1. Визначте юридичного виробника, продукт, версію та відповідну роль PSIRT/SRP.
2. Записуйте джерела та докази, не зберігаючи таємниці або код експлуатації у незахищених офісних файлах.
3. Окремо оцініть AEV та SI відповідно до статті 14 CRA і задокументуйте час виявлення.
4. У разі зобов’язання: підготуйте основу та повідомте без зайвих зволікань через офіційну SRP ENISA.
5. Зберігайте фактичні ID та часові мітки подання для 24 год, 72 год і відповідного підсумкового повідомлення.
6. Задокументуйте виправний захід, постраждалих користувачів, комунікацію та перевірку після усунення інциденту.

Юридичні межі та відповідальність

Стаття 14 CRA (ЄС) 2024/2847 почала застосовуватися до виробників 11 вересня 2026 року. Обов’язок повідомлення про активно експлуатовану вразливість вимагає відповідних доказів фактичного експлуатування; номера CVE або високого рівня ризику автоматично недостатньо. Серйозний інцидент слід оцінювати відповідно до статті 14.5. Попередження слід надавати протягом 24 год, а повідомлення — протягом 72 год з моменту відповідного виявлення, без зайвих зволікань. Для AEV підсумкове повідомлення необхідно надати не пізніше ніж через 14 днів після того, як виправний або обмежувальний захід стане доступним. Для SI підсумкове повідомлення необхідно надати протягом одного місяця після фактичного повідомлення протягом 72 год. Стаття 14.8 регулює інформування постраждалих користувачів.

Необхідно безпосередньо перевіряти FAQ щодо SRP та глосарій полів ENISA під час фактичного повідомлення, оскільки поля та функції платформи оновлюються. Статус у Word або Excel ніколи не вважається поданим повідомленням. Інші основні вимоги CRA зазвичай починають застосовуватися 11 грудня 2027 року, а стаття 24.3 для відповідальних за програмне забезпечення з відкритим кодом має іншу дату початку. За необхідності може знадобитися окрема оцінка відповідно до, наприклад, NIS2, GDPR і DORA.

Відмінність від наших інших документів

Наш ширший пакет відповідності CRA включає оцінку ризиків, SBOM, вимоги безпеки та загальне повідомлення відповідно до CRA. Цей новий пакет, натомість, є спеціалізованим робочим ланцюжком для фактично отриманого повідомлення або інциденту, підтверджень SRP, доказів і інформування клієнтів.

Часті запитання

Чи про кожну вразливість у сфері безпеки потрібно повідомляти?

Ні. Стаття 14 встановлює окремі пороги для активно експлуатованих вразливостей і серйозних інцидентів. Інші вразливості можуть потребувати внутрішньої обробки, але не є автоматично обов’язковими повідомленнями відповідно до SRP.

Чи надсилає шаблон повідомлення до ENISA?

Ні. Основи готують і документують роботу; уповноважений представник повинен надіслати повідомлення через фактичну платформу SRP.

Чи можна редагувати PDF-файли?

Вони пошукові та підлягають друку, але не є інтерактивними формами для заповнення. Використовуйте файли Word для редагування.

Чи весь матеріал перекладено англійською мовою?

Ні. П’ять робочих документів і Excel — шведською мовою. Англійське керівництво пояснює, як використовуються шведські документи.

Версія, джерела та прозорість

Видання 1.0, 9 листопада 2026 року. Юридичний аналіз джерел статті 14 CRA за допомогою ШІ, інформація Комісії про повідомлення та матеріали SRP ENISA від 9 листопада 2026 року. Незалежна зовнішня юридична перевірка, перевірка регулятором або технічна сертифікація продукту не проводилися. Пакет є адміністративною підтримкою, а не гарантією відповідності.