Establish that you have reliable evidence of active exploitation, or a confirmed adverse security impact, not a suspicion or an unconfirmed report. The 24-hour CRA vulnerability reporting clock starts from the moment your organisation becomes aware, so this determination needs an owner and a decision point, not an open-ended internal debate. Document the time and basis of the determination itself — this timestamp is what a regulator checks first if your 24-hour report arrives late.

Submit an early warning through the ENISA Single Reporting Platform (SRP). This first submission is deliberately thin: identify the product, state that a vulnerability is being actively exploited or that a severe incident has occurred, and list the EU Member States where the affected product is sold. You are not expected to have a root cause, a fix, or a full technical assessment at this stage. The SRP notifies ENISA and the relevant national CSIRT simultaneously through a single submission.

The platform assigns a case identifier on submission. Store it against the internal incident record — every subsequent submission (the 72-hour notification, the final report, and any follow-up requests from the CSIRT) is filed as an update to this same case, not as a new CRA vulnerability reporting case.

Submit a fuller technical notification describing the vulnerability or incident in more detail, including corrective or mitigating measures already taken or available. This is where the assessment moves from “we know this is happening” to “here is what we know about it and what we’re doing.” If the CSIRT has raised follow-up questions after the 24-hour warning, address them in this submission.

Between the 72-hour notification and the final report, the receiving CSIRT may request further information, or may delay onward dissemination of the report on justified cybersecurity grounds — for example where the vulnerability is inside a coordinated disclosure process. If that happens, the CSIRT is required to inform ENISA of the delay and its justification. You do not need to independently chase dissemination status, but you should keep responding to any direct requests.

For an actively exploited vulnerability, submit the final report within 14 days of a corrective or mitigating measure becoming available. For a severe incident, submit it within one month of the 72-hour notification. The final report should describe the vulnerability or incident, any malicious actors involved where known, how it has been or can be corrected, and what mitigating measures are in place.

There is no statutory deadline for developing the fix itself — the obligation is to report on schedule, not to have solved the underlying problem by a fixed date — but the “without undue delay” standard still applies to remediation.

Once the final report is submitted, close the internal incident record against the SRP case identifier and retain the full submission history. This record is what demonstrates compliance if the same vulnerability resurfaces in a different product line, or if a regulator later asks how the organisation typically handles CRA Article 14 events.