The first hour of a potentially reportable CRA incident
What a product security team should preserve, classify and assign before the 24-hour CRA reporting window becomes an operational problem.
What you need to know
In the first hour, do not wait for a complete root-cause analysis. Preserve the awareness time, assign one reporting owner, identify the affected product and EU market scope, classify whether you may be dealing with an actively exploited vulnerability or severe security incident, and start a staged evidence record. The CRA early-warning deadline can be at most 24 hours after awareness.
Key takeaways
- Record the awareness timestamp and the facts known at that moment before the incident narrative changes.
- Assign a single reporting owner even if multiple teams are investigating the technical issue.
- Classify the reporting path separately from root-cause analysis. Uncertainty should be recorded, not hidden.
- Begin collecting the 24-hour facts immediately while allowing the investigation to mature for the 72-hour stage.
Why is the first hour different from the rest of the investigation?
Most incident-response processes are designed to improve technical certainty over time. CRA reporting adds a second requirement: the organisation must also preserve enough information to manage a statutory timeline that begins from awareness.
That creates a predictable failure mode. Teams focus correctly on containment and diagnosis, but no one records exactly when awareness was established, which product scope was understood, or who owns the reporting decision. Hours later, the technical picture is better but the regulatory timeline is harder to reconstruct.
Step 1: preserve the awareness record
Create a short immutable note with the time, timezone, source and the facts that caused the issue to be escalated. This is not a legal conclusion about when awareness occurred. It is an operational record that lets the organisation reconstruct the timeline instead of relying on memory.
Useful source events include an internal security escalation, a customer report, a researcher disclosure, a monitoring alert that was confirmed as meaningful, or another event that caused the manufacturer to recognise the occurrence.
Step 2: name one reporting owner
The reporting owner does not need to run the technical investigation. Their job is to maintain the deadline view, coordinate the staged information set and make sure unresolved questions have an explicit owner.
This prevents the common pattern where product security assumes legal owns the notification, legal assumes incident response owns it, and incident response assumes a regulatory team will step in later.
Step 3: identify the product and market scope
Record the affected product, version or release where known, and whether the product has been made available on the Union market. Article 14 early warnings can require information about Member States where the manufacturer knows the product has been made available.
Do not spend the first hour creating a perfect market-distribution map. Record what is known and mark what still needs confirmation.
Step 4: separate the two Article 14 paths
Ask two different questions. Are you dealing with a vulnerability that is actively exploited? Or are you dealing with a severe incident having an impact on the security of the product? The evidence required to answer those questions may come from different teams.
Step 5: begin the 24-hour information packet
The early warning is deliberately earlier and lighter than the fuller 72-hour stage. Begin with the occurrence type, affected product, known market scope, a concise description of what happened and the internal awareness record. For severe incidents, Article 14 also requires at least whether unlawful or malicious acts are suspected.
At the same time, start a separate list of facts that may mature before the 72-hour notification: technical nature, initial assessment, exploitation detail, corrective or mitigating measures, user actions and sensitivity considerations.
Step 6: protect the incident response itself
Regulatory reporting should not create a second uncontrolled incident database. Keep technical evidence in the systems already approved for incident response. Your reporting preparation layer should reference or summarise what is needed for the notification rather than copy every sensitive artefact into another cloud service.
A practical first-hour checklist
- Record awareness time, timezone and source.
- Name the reporting owner and technical incident owner.
- Identify affected product, versions and known EU availability.
- Record whether the path appears to be vulnerability, severe incident or still uncertain.
- Capture the facts needed for the first reporting stage.
- Create owners for missing 72-hour information.
- Set the next reporting review before the statutory window becomes tight.
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.