Before any stage: facts for every notification
- Manufacturer name, spelt exactly as registered. A different spelling creates a separate manufacturer entity in the platform.
- CSIRT designated as coordinator, worked out under Article 14(7). Choosing the wrong one can get the notification invalidated. Which CSIRT do you notify?
- Date and time you became aware of the actively exploited vulnerability or severe incident, with the time zone and who decided it.
- Notification type: actively exploited vulnerability or severe incident. Actively exploited vulnerabilities and severe incidents have different tests.
- Product identification: product name, affected versions or models, and a short title for the case.
- Member States where you know the product has been made available. The regulation asks for these in the early warning where applicable, and the CSIRT uses them to decide who to pass the notification to.
- A named submitter with an active Assigned Representative account, or at least an EU Login account with MFA working. CRA Assigned Representative
Actively exploited vulnerability: stage by stage
The minimum content comes from Article 14(2) of the regulation. ENISA's FAQ adds that the vulnerability fields include, where available, the CVE ID and EUVD ID.
Early warning (within 24 hours of becoming aware)
- The shared facts above, including the Member States where the product is available.
- The CVE ID or EUVD ID if one already exists. Leave it for later if not.
- A one-paragraph holding description your team has approved.
72-hour notification (within 72 hours of becoming aware)
- General information about the product concerned.
- The general nature of the exploit and of the vulnerability.
- Corrective or mitigating measures you have taken.
- Corrective or mitigating measures users can take.
- Where applicable, how sensitive you consider the information, and whether you are asking for dissemination to be delayed under Article 16(2).
Final report (no later than 14 days after a corrective or mitigating measure is available)
- A description of the vulnerability, including its severity and impact.
- Where available, information about any malicious actor that has exploited or is exploiting it.
- Details of the security update or other corrective measures made available.
- The date and time the fix or mitigation became available, which starts this clock.
Severe incident: stage by stage
The minimum content comes from Article 14(4).
Early warning (within 24 hours of becoming aware)
- The shared facts above, including the Member States where the product is available.
- At least whether you suspect the incident was caused by unlawful or malicious acts.
72-hour notification (within 72 hours of becoming aware)
- General information about the nature of the incident.
- An initial assessment of the incident.
- Corrective or mitigating measures taken, and those users can take.
- Where applicable, how sensitive you consider the information.
Final report (within one month after the 72-hour notification)
- A detailed description of the incident, including its severity and impact.
- The type of threat or root cause that is likely to have triggered it.
- Mitigation measures applied and still ongoing.
Between the 72-hour notification and the final report, the CSIRT designated as coordinator can ask you for an intermediate report on relevant status updates (Article 14(6)). Keep a running status note so you can answer quickly.
How to use this checklist
- Turn each stage into a pre-agreed template, so the submitter pastes approved text instead of writing it under pressure. CRA Article 14 report template
- Note who owns each fact: security for the technical description, product for versions and markets, legal or compliance for sensitivity and sign-off.
- Track the three deadlines from your own awareness time. The platform's counters are reminders, not your legal deadlines. Deadline calculator
- Remember that drafts saved in the platform are visible only to the person who saved them (ENISA submission guidance).
Questions people ask
- Where is the official list of CRA SRP fields?
- ENISA's SRP Glossary. For each field it explains the meaning, the expected format and the stage it applies to, and whether it is required, optional, mandatory if available, or carried forward from an earlier stage. This checklist is a preparation aid built from the CRA text and ENISA's FAQ, not a copy of the Glossary.
- Are all SRP fields required in the 24-hour early warning?
- No. ENISA's FAQ says some fields are not required in the early warning but become required in the 72-hour notification or the final report. If you leave out mandatory data, the platform shows an error and will not submit.
- Do the fields differ for vulnerabilities and incidents?
- Yes. You choose whether the notification is an actively exploited vulnerability or a severe incident, and the fields adapt. Vulnerability fields include the CVE ID and EUVD ID where available, the nature of the exploit and any malicious actor. Incident fields include the nature of the incident and the threat or root cause likely to have triggered it.
- Can we change a notification after submitting it?
- Yes, until the final report is submitted or the notification is closed. ENISA's submission guidance says an update notifies the CSIRT designated as coordinator, ENISA and any CSIRTs that already received it. After the final report the notification can no longer be edited.
- Does the platform let us save a draft?
- Yes. A saved draft is visible only to the Assigned Representative who wrote it, so drafts are not a way to share text with colleagues. Agree the content outside the platform first.