What timestamps and evidence should you preserve for CRA reporting?
A practical evidence checklist for awareness time, mitigations, 72-hour submission and final-report trigger dates under the CRA.
What you need to know
Preserve at least four classes of time evidence: when the manufacturer became aware of the occurrence, when the 24-hour and 72-hour submissions were actually made, when a corrective or mitigating measure became available for an actively exploited vulnerability, and when material incident facts or mitigations changed. Those timestamps drive different CRA reporting milestones and should not be reconstructed from memory later.
Key takeaways
- The 24-hour and 72-hour stages are tied to awareness, so preserve the awareness record with timezone and source.
- For severe incidents, the final-report clock runs from the actual 72-hour incident-notification submission.
- For actively exploited vulnerabilities, the final-report clock runs from when a corrective or mitigating measure becomes available.
- Keep the evidence record separate from the prose of the report so later edits do not erase the original timeline.
Why do timestamps deserve their own reporting record?
CRA reporting is not one deadline. It is a sequence with different trigger events. If a team stores only a single incident date, it can lose the evidence needed to calculate later milestones accurately.
A good operational record therefore separates event time, detection time, awareness time, submission time and mitigation availability. Those concepts may happen close together, but they are not interchangeable.
1. Preserve the awareness timestamp
Article 14 ties the early warning and fuller notification to the manufacturer becoming aware of the reportable occurrence. Preserve the timestamp, timezone and source that support your internal awareness record.
Also preserve the facts known at that moment. If the classification changes later, you can then distinguish between what the organisation knew initially and what the investigation established afterward.
2. Preserve the actual submission timestamps
Record when the 24-hour early warning was submitted and when the 72-hour notification was submitted, including the platform confirmation or another authoritative submission reference.
This matters especially for severe incidents because the final report is due within one month after submission of the 72-hour incident notification. Using the theoretical 72-hour deadline instead of the actual submission time can produce the wrong final date.
3. For vulnerabilities, record when the corrective measure becomes available
For an actively exploited vulnerability, Article 14 sets the final-report deadline no later than 14 days after a corrective or mitigating measure becomes available. That means the release or availability timestamp is a separate regulatory trigger worth preserving explicitly.
Record what became available, when, to whom and through which release mechanism. If there are multiple staged mitigations, preserve the sequence rather than overwriting the first record with the latest release state.
4. Preserve material changes in facts and mitigation
The 72-hour stage and final report can contain information that was not available at the early-warning stage. Keep a chronological record of material changes such as confirmed exploitation, revised severity, new affected versions, root-cause findings, mitigation deployment and user guidance.
What should each timestamp record contain?
- Timestamp: use an unambiguous date, time and timezone.
- Event type: awareness, submission, mitigation availability, confirmation or material change.
- Source: ticket, alert, email, release record, SRP confirmation or another internal system of record.
- Owner: the person or function responsible for the entry.
- Known facts: a short statement of what was established at that moment.
- Confidence or status: confirmed, suspected, under review or superseded.
Should the evidence log contain all incident artefacts?
No. A reporting timeline should be useful without becoming another full copy of the incident evidence set. Preserve references to the approved source systems and only copy the information needed to support the reporting workflow.
Official references
Verify against the live official sources
CRA Report is a preparation tool. Regulatory guidance and the ENISA reporting workflow can change, so final decisions and submissions should be checked against the current Regulation, Commission guidance and ENISA SRP documentation.