CRA reporting: 24-hour and 72-hour vulnerability and incident workflow

Since 11 September 2026, manufacturers covered by the CRA must report actively exploited vulnerabilities and severe incidents that have an impact on the security of products with digital elements. The early warning is due within 24 hours of becoming aware and the full notification within 72 hours.

The main operating risk is not the lack of a form. It is the lack of an agreed T0, a decision owner, backup coverage, reliable information sources and a record explaining why an event was classified in a particular way.

The reporting timeline

Stage	Deadline	What to control
Awareness	T0	timestamp, source of information and person receiving it
Early warning	within 24 h	the information required by CRA/SRP at this stage
Full notification	within 72 h	additional information on the event and impact
Final report — actively exploited vulnerability	no later than 14 days after a corrective measure is available	remediation and handling outcome
Final report — severe incident	within 1 month from the 72-hour notification	course of the incident, impact, actions and outcome

Always verify the current CRA Single Reporting Platform instructions. Operational guidance and the portal can evolve faster than the Regulation itself.

Not every vulnerability triggers Article 14 reporting

The CRA refers to an actively exploited vulnerability, not every finding produced by a scanner. Likewise, “severe incident” is a regulatory concept rather than a synonym for any security ticket marked high priority.

A good workflow separates:

detection or receipt of information;
technical triage;
regulatory-criteria assessment;
decision by an accountable person;
preparation of the notification;
submission through the proper channel;
remediation, follow-up and the final report.

Automatically labelling a finding “CRA reportable” without human approval creates both false-positive and missed-reporting risk.

Define responsibility before the clock starts

A role called “Security Team” is not enough. For each product, identify:

who receives vulnerability or incident information;
who performs technical triage;
the product owner;
who approves the regulatory classification;
who submits through the SRP;
a backup for each time-critical role;
any out-of-hours escalation route required by the product and operating model.

If one person holds several roles, record that explicitly. Small teams are workable; ambiguous ownership is not.

What to capture at T0

Create the first record before the discussion shifts to whether the event is “really severe”. At minimum, retain:

exact awareness time;
source of the information;
product and version;
reporter or detection system;
concise description of what was observed;
person who received the information;
link to the source artefact or evidence.

Without that record, several hours later the organisation may not be able to establish when the legal clock actually began.

A practical operating sequence

1. Register

Open a case and preserve the original report. Do not overwrite the source as the understanding evolves.

2. Triage

Confirm the affected product, version, technical scope, known effects and available evidence. Separate confirmed facts from hypotheses.

3. Classify

Record the reasons for and against reportability. The decision should identify the approver and approval time.

4. Submit the 24-hour warning

Prepare the early warning from the information available at that point. Do not wait for a completed root-cause analysis when the legal deadline is already running.

5. Submit the 72-hour notification

Complete the information required by the current SRP process.

6. Remediate and communicate

Connect engineering work, releases, security updates and customer communication to the same case.

7. Complete the final report

Close the workflow only when the outcome, actions, verification evidence and the required final report have been recorded.

Exercise the process before a real event

Use one realistic but hypothetical scenario and verify:

the team knows where to create the record;
T0 can be identified;
the approving person is known;
backup coverage exists;
product and log data can be collected quickly;
the submitting person has working SRP access;
the exercise leaves a decision record and improvement actions.

The role of Pulsar GRC

Pulsar can connect the incident or vulnerability to risks, actions, owners, documents, evidence, reports and decision history. The current product repository confirms capabilities around risks, tasks, documents, evidence, reporting and analysis history.

This content does not claim that Pulsar automatically sends a notification to the SRP or autonomously determines that an event is reportable under Article 14. Either capability would require a separately verified implementation and clear authorization controls.

See Pulsar GRC on an operating workflow

Sources

Sources checked: 12 September 2026.