Preparing a CRA Article 14 report before you open ENISA’s platform

Two of the three clocks start at the same moment: the time you became aware. The third starts later and differently for the two case types. Keep the regulation text and ENISA’s current guidance at hand; they, not a checklist, define the obligation.

Every deadline above hangs on one timestamp. Record it as soon as someone with the responsibility to act has the information — with who learned it, from which source and what exactly was known at that point. Record it even if the case later turns out not to be reportable; the record shows why.

In Attesly, an Article 14 case starts with that awareness time. The early-warning and notification deadlines are computed from it; the final-report clock appears once the corrective measure is available (exploited vulnerability) or the notification has been submitted (severe incident).

• Case owner — keeps the timeline, collects the inputs and makes sure each stage goes out on time.
• Technical lead — nature of the exploit or incident, affected products and versions, available mitigations and the fix.
• Product compliance — which products and member states are concerned, and which CSIRT coordinates.
• Management — signs off what is submitted, including a request to delay dissemination.
• Communication — what users are told, and when.

Name a deputy for every role. A 24-hour clock does not wait for someone to come back from holiday.

• The product concerned and the member states where it is made available.
• The coordinating CSIRT for the case.
• For a severe incident: whether it is suspected of being caused by unlawful or malicious acts.
• For the notification: the general nature of the exploit and of the vulnerability, or the nature of the incident with an initial assessment; corrective or mitigating measures taken; measures users can take; how sensitive you consider the information.
• If needed: a request to the CSIRT to delay dissemination under Article 16(2), with the cybersecurity-related grounds.
• After each submission: the time it was sent and the platform’s reference.

The regulation sets out the content of each stage in Article 14(2) and 14(4). Compare this list with the current text before you rely on it.

Fictional example. Northwind Robotics and its NW-200 Edge Controller are the invented demo manufacturer and product used throughout Attesly.

1. Monday 09:40: through Northwind’s public vulnerability intake page, a researcher reports that a vulnerability in a component of the NW-200 firmware is being exploited. The product security lead confirms the report and opens an Article 14 case with the awareness time 09:40.
2. The case shows the early warning due Tuesday 09:40 and the notification due Thursday 09:40. The final-report clock is not running yet.
3. The team enters the member states where the NW-200 is sold and the coordinating CSIRT, and copies the prepared submission sheet into ENISA’s platform. The early warning goes out Monday afternoon; its time and the platform reference are recorded.
4. By Wednesday the notification content is complete: nature of the exploit, measures taken, what users should do, sensitivity. It is submitted and recorded the same way.
5. The following week a firmware update is available. Recording that date starts the final-report clock: 14 days.

At every point the case record shows what was known when, who did what, and which deadline comes next.

• Does: keep the case with its awareness time and computed deadlines, hold the content fields of each stage, prepare a copy-ready ENISA submission sheet, log activity and — if members switch them on — send reminders for due case steps.
• Does not: submit anything to ENISA or a CSIRT, decide whether an event is reportable, certify products or give legal advice.

See plans and pricing, book a call or read how to keep product evidence and SBOMs current between incidents.