Regulation (EU) 2024/2847
The reporting runbook, and who owns each step
From 11 September 2026, becoming aware that a vulnerability in your product is being actively exploited starts a 24-hour clock. This is the sequence that follows, in order, with the article behind each step.
No email required and nothing gated. Copy it into your wiki, put real names in the matrix, and keep it where the on-call owner will find it at 2am. Operational guidance, not legal advice.
The sequence
- T+0, the moment of awarenessArticle 14(1)
Record when you became aware, and of what
- Write down the timestamp you became aware, in UTC, and what you knew at that moment.
- Record where the knowledge came from: researcher report, telemetry, customer, public post.
- Decide, against your written trigger definition, whether this is active exploitation.
- If the answer is "probably", start the clock. You can stand down later; you cannot rewind.
The clock runs from awareness, not from confirmation. Teams lose most of the first day deciding whether the clock has started while it is already running.
- T+0 to T+1h
Get the named owner and a decision-maker in the same place
- Page the CRA reporting owner, or the backup if the owner does not answer within 15 minutes.
- Open one channel and one document. Everything from here is logged there.
- Confirm which products and versions are affected, and whether they are on the EU market.
Two parallel threads is how a 24-hour deadline becomes a 30-hour one. One channel, one owner, from the first minute.
- within 24 hoursArticle 14(2)(a)
Early warning notification of an actively exploited vulnerability
- Submit the early warning to CSIRT designated as coordinator, and ENISA.
- Say what you know and say plainly what you do not know yet. It is an early warning, not a final account.
- Log the submission time and keep whatever reference the platform returns.
Waiting for a complete picture is the most common way this deadline is missed. An incomplete early warning filed in time beats a thorough one filed late.
- within 72 hoursArticle 14(2)(b)
Vulnerability notification
- Submit the fuller notification to CSIRT designated as coordinator, and ENISA.
- Include the corrective or mitigating measures available to users, if any exist yet.
- Reconcile it against the early warning, and say what changed in your understanding.
- as soon as there is something users can act onArticle 14(8)
Inform affected users
- Tell affected users about the vulnerability and any corrective measure they can apply.
- Use a channel that reaches people who never read release notes.
- Where appropriate, say what to do in the meantime if no fix exists yet.
This duty is separate from reporting and does not wait for the final report. It is also the one your customers will judge you on.
- within 14 daysArticle 14(2)(c)
Final report
- Submit the final report to CSIRT designated as coordinator, and ENISA.
- Describe the vulnerability, its severity and impact, and the corrective measures made available.
- Attach the timeline you have been keeping since T+0.
The final report is where an undated timeline becomes visible. This is why step one is a timestamp rather than a task.
- after
Close the loop while it is fresh
- Note which step took longest and why. That is next quarter's fix.
- Update the trigger definition if the argument at T+0 was harder than it should have been.
- Keep the record. A market surveillance authority may ask later what you knew and when.
Who owns what
Four rows on purpose. A matrix nobody can hold in their head during an incident is decoration. Roles are named by function, because a company of eight and a company of eight hundred both have someone who decides and someone who talks to customers, even where that is one person wearing three hats.
| Activity | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| Deciding the clock has started | Security on-call | CRA reporting owner | Engineering lead for the affected product | Founder or exec sponsor |
| Drafting and submitting the reports | CRA reporting owner | CRA reporting owner | Legal counsel, security on-call | Founder or exec sponsor, support lead |
| Technical investigation and the fix | Engineering lead for the affected product | CTO or head of engineering | Security on-call | CRA reporting owner |
| Telling affected users | Support or customer lead | Founder or exec sponsor | CRA reporting owner, legal counsel | Whole company |
Replace the role names with real people before you need this. An unfilled matrix is the same as no matrix at 2am.
Questions
- What are the CRA reporting deadlines?
- Three, all running from awareness under Article 14(2): an early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days. The recipient is the CSIRT designated as coordinator, and ENISA.
- Who is responsible for CRA incident reporting?
- The manufacturer, and inside the manufacturer whoever is named. The responsibility matrix on this page assigns each step so the question is answered before an incident rather than during one.
- What if I do not have full information within 24 hours?
- That is the expected case, and it is why the obligation is staged. The 24-hour step is an early warning, not a complete analysis; the detail belongs in the 72-hour notification and the 14-day final report. Waiting for certainty is how the first deadline is missed.
- Does this runbook cover severe incidents?
- No. Everything here is Article 14(2), actively exploited vulnerabilities. Article 14(4) severe incidents affecting the security of the product run on different timings and we do not model them, so do not assume this sequence transfers.