FREE SOURCE-LINKED REFERENCE · UPDATED 19 JULY 2026
Know what the CRA report
needs before the clock starts.
ENISA now publishes the planned Single Reporting Platform fields across the 24-hour, 72-hour, and final-report stages. This field map turns that table into an operational preparation view.
ENISA's FAQ says the SRP has no API at this stage, publishes the reporting-field table in Q16, and expects the platform URL before the 11 September launch.
Verify the live FAQ ↗XObligatory
CCopied from the previous step by default, or updated
OOptional
IObligatory if the information is available
AAutomated and not visible to the submitter
Q16 FIELD READINESS MAP
Prepare ownership and evidence,
not a shadow submission form.
The codes below follow ENISA's published table. Preparation prompts are independent workflow suggestions, not official fields or legal conclusions.
| Field | Published field | 24h | 72h | Final | Preparation prompt |
|---|---|---|---|---|---|
| Common1 | Notification type (vulnerability / incident) | X | C | C | Agree the occurrence-routing owner and preserve the decision basis. |
| Common2 | Notification level (24h / 72h / final) | X | X | X | Map each stage to an approver and a submission handoff. |
| Common3–6 | Reporting times and reporter | A | A | A | Prepare the authorised reporter and EU Login path; the platform supplies these fields. |
| Common7 | Manufacturer or open-source software steward | X | C | C | Keep the legal name and role source available to the reporting team. |
| Common8 | Product | X | C | C | Maintain an unambiguous product and version identifier. |
| Common9 | Product type (default / important / critical) | O | C | C | Record the classification owner and rationale; do not guess during an incident. |
| Common10 | Product category (CRA Annex III / IV, when relevant) | O | C | C | Link the approved category decision and its review date. |
| Common11 | Member States where product is available | I | C | C | Keep a current market list with a named source of truth. |
| Common12 | Title | X | C | C | Use a neutral internal naming convention that avoids unsupported conclusions. |
| Vulnerabilityv13–v14 | CVE ID and EUVD ID | O | C | C | Define who checks identifiers and how pending IDs are recorded. |
| Vulnerabilityv15–v17 | General information; nature of vulnerability and exploit | O | X | C | Prepare concise technical summaries with evidence references and confidence labels. |
| Vulnerabilityv18 | Corrective or mitigating measures taken | O | X | C | Log actions, owners, timestamps, approvals, and validation evidence. |
| Vulnerabilityv19 | Measures users can take | O | X | C | Pre-assign customer communication and technical review owners. |
| Vulnerabilityv20 | Considered sensitivity of information | O | I | C | Document the security-review path; do not place sensitive case data in this page. |
| Vulnerabilityv21 | Date corrective or mitigating measure became available | O | O | X | Capture the actual availability event; it anchors the vulnerability final-report timing. |
| Vulnerabilityv22–v24 | Full description, severity, and impact | O | O | X | Maintain an evidence-backed analysis template and qualified review path. |
| Vulnerabilityv25 | Malicious actor exploiting the vulnerability | O | O | I | Preserve attribution confidence and sources; avoid unsupported attribution. |
| Vulnerabilityv26 | Security update / corrective-measure details | O | O | X | Link release, distribution, validation, and user-notice evidence. |
| Incidenti13 | Incident suspected to involve unlawful or malicious acts | X | C | C | Define the escalation path for a cautious, evidence-based first assessment. |
| Incidenti14–i17 | Nature, detection time, occurrence time, and initial assessment | O | X | C | Preserve source timestamps, uncertainty, affected functions, and assessment owner. |
| Incidenti18 | Corrective or mitigating measures taken | O | X | C | Capture containment and recovery actions with owners and evidence. |
| Incidenti19 | Measures users can take | O | X | C | Prepare a reviewed user-action message and distribution owner. |
| Incidenti20 | Considered sensitivity of information | O | I | C | Route sensitive details through approved security and legal handling. |
| Incidenti21–i23 | Detailed description, severity, and impact | O | O | X | Reconcile the final narrative to evidence, scope, and approved severity criteria. |
| Incidenti24 | Threat type or likely root cause | O | O | X | Keep hypotheses distinct from validated root-cause conclusions. |
| Incidenti25 | Applied and ongoing mitigation measures | O | O | X | Retain owners, change records, verification results, and residual risk. |
SECURITY AND LEGAL BOUNDARY
Use this page before an event,
not as the event record.
- Does not determine CRA scope, reportability, awareness, exploitation, or severity
- Does not collect, store, transmit, or submit occurrence information
- Does not reproduce the live SRP interface or guarantee its final implementation
- Does not replace approved incident handling, legal advice, a CSIRT, ENISA, or the live platform
FROM FIELD MAP TO REHEARSAL
Run the handoffs before the first real 24-hour window.
Build a private stage brief from the published fields, then move to the complete offline drill room for owners, evidence, fictional cases, JSON portability, and a print packet.
PUBLIC EVIDENCE