CRA incident reporting: what in-house legal must settle first

Since 11 September 2026, manufacturers of products with digital elements have had to actively report exploited vulnerabilities and severe security incidents. Germany’s Federal Office for Information Security (BSI) announced the start of these Cyber Resilience Act (CRA) reporting duties in a press release on that date. Reports are submitted through the Single Reporting Platform operated by the European Union Agency for Cybersecurity (ENISA); in Germany, CERT-Bund at the BSI is the coordinating Computer Security Incident Response Team (CSIRT) and therefore the national body that receives a report and passes it on. The BSI publishes step-by-step guidance on the reporting routes themselves. For an actively exploited vulnerability, the Regulation sets a strict clock: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days.

None of that takes long to read. In-house legal teams at product companies are uneasy this month for a different reason: a reporting duty with a short deadline is not a legal question you answer once and file away. It is an operational sequence that has to work when it begins on a Friday evening and the person who understands it is unreachable.

This article is therefore not a summary of the law. It is an operational check: four points where reporting processes actually break down, what to settle at each of them, and a 45-minute rehearsal that tends to expose the gaps faster than a policy review does.

Why the date is an operational test

In-house legal teams are trained to work a new obligation through on the merits. With a short-deadline reporting duty, the centre of gravity shifts. The substantive question (is this a reportable event?) is demanding, but it is answerable once the right people are in the room with the right facts. The difficulty sits either side of that: how the facts reach the room, who is in it, and what survives the meeting.

There is a second departure from the usual working pattern. During an incident, legal is rarely the first party involved; in most organisations it is the third or fourth. The information originates in a product team, in operations, in support, or with an external security researcher who writes to a general contact address. By the time anyone classifies it as a potentially reportable incident, time has passed. That is precisely the time that will be missing later.

The third departure concerns evidence. A report is a statement to an authority about a state of affairs at a given moment. If the picture later turns out differently, what matters is not whether the first assessment was right in hindsight, but whether the basis for it can be reconstructed. That requires somebody to be writing things down during the incident, not afterwards from memory.

The four points where reporting processes break down

1. Detection: how does legal find out that something is happening?

The most common gap is also the most mundane. Many organisations already run a technical incident process: a report arrives, a ticket opens, an on-call engineer is paged. What that flow often lacks is a trigger that brings legal in, not for every ticket, but for a defined class of them.

What helps is less a general duty to inform than a named condition. Conditions that can be expressed in technical or organisational terms include: there are indications that a vulnerability is being actively exploited; a report has arrived from outside, whether from a security researcher, a customer or an authority; a product placed on the EU market is affected; an incident will require customer communication.

Write those conditions so that an on-call engineer with no legal training can apply them. If the condition reads “inform legal about potentially reportable incidents,” the on-call engineer has already taken over the legal assessment, probably at two in the morning, without noticing.

Detection also covers a point that in-house legal teams rarely track: which inbound channels exist for external reports, and does anyone read them? A vulnerability disclosure that lands in a general contact form can sit there for days without triggering anything at all.

2. Assessment: who decides, and in what role?

“Actively exploited” and “severe” are judgements, not measurements. They require technical observation and legal classification to be read together. That is exactly why this is the point where reporting processes slip most often: it is too technical for legal on its own and too legal for the security team on its own.

The practical consequence is uncomfortably clear. If the assessment is not assigned to a role in advance, it will be made in a call with seven participants in which nobody disagrees and after which nobody can say who decided. Decisions of that kind hold up badly under later scrutiny, not because they are wrong, but because they cannot be attributed to anyone.

Settle three things in advance. First, a role that decides, and a named deputy for absences; a role means a function with a name attached, not a department. Second, the information that role needs to decide: typically a technical assessment of exploitation, the range of affected products and versions, the state of containment, and the time of first observation. Third, what applies while the picture is still incomplete. A short-deadline duty cannot accommodate a state of waiting for completeness, so you need a rule for deciding under uncertainty and a rule for correcting the assessment later.

That last point is routinely underestimated. The realistic position on day one is rarely “we do not know.” More often: “we know three things, and two of them contradict each other.”

3. Reporting: who holds the access, and do they hold it today?

This is the cheapest point to settle in advance and still the one most often left open. Access to a reporting platform that is set up during an incident is not access. Registrations need approvals, approvals need people, and people are hard to reach on a Friday evening.

Be specific. Who is registered? Is it at least two people, so that leave and illness do not become the bottleneck? Where are the credentials held so that they remain reachable during an incident, including one that affects internal systems? And has anyone walked through the reporting route once while nothing was happening, so that nobody meets the structure of the form for the first time under pressure?

Substantive preparation matters just as much. A report calls for details that are otherwise assembled in a hurry: affected products and versions, manufacturer details, contact points, a technical description, the state of mitigation. Much of that is known in advance and changes rarely. Whatever sits in a prepared template does not have to be researched during the incident.

One more organisational point: decide in advance who is informed alongside the authority, and in what order. Customer communication, insurers, the board, and business partners with contractual notification clauses all run in parallel with the regulatory report, and they compete for the same handful of people.

4. Record-keeping: what will be established later?

The fourth point only becomes important months afterwards, and it then determines how well the whole response holds up. After an incident, people ask who knew what and when, and why a particular decision was taken. It is not only a regulator who asks. It is also your own board, your clients, your insurer and, in a dispute, the other side.

What should be captured is a short list: the time of first observation and who made it; the time legal was brought in; the assessment, with its reasoning, its timestamp and the person who made it; the information that assessment rested on; the time and content of the report; and every subsequent change of view, with what prompted it.

The important part is not the list but when the recording happens. A log reconstructed afterwards from chat histories and recollection is exactly that: a reconstruction. It is better than nothing, but it carries less weight than a record created while the work was going on, in which the gaps remain visible.

In practice this means somebody needs record-keeping as their actual task during an incident, and it should not be the same person who is deciding or containing. Anyone doing both will do the writing last.

Where tooling helps, and where it does not

A boundary is worth drawing here. A platform can trigger an escalation reliably, test conditions, calculate deadlines, enforce mandatory fields and capture the sequence with timestamps. That is what process automation can contribute to an incident flow: it turns an understanding between colleagues into a sequence that still runs when nobody remembers it exists. In e!, that sequence is built in the Logic Engine as a visible decision tree, where every condition and every responsibility stays open to inspection.

What tooling cannot do is decide whether an incident is reportable. That judgement is demanding in both legal and factual terms, it depends on circumstances that cannot be fully described in advance, and it has to be attributable to a person. Any automation that obscures this point makes matters worse, because it produces a decision with no decision-maker.

The useful division of labour is straightforward. The sequence is defined in advance and runs reliably. The judgement stays with a named human being, and the reasoning is recorded.

A 45-minute rehearsal

The most effective test costs an afternoon and needs no preparation beyond a diary entry. Put the people who would actually be involved in one room: legal, security or operations, product ownership, communications.

Then describe an invented but realistic case. An external security researcher reports a vulnerability at 17:40 on a Friday, in a product version that is in use at customer sites. They write that they have indications the vulnerability is already being exploited. The message arrives at a general contact address.

Work the case through in the room and record, at each of the four points, what would genuinely happen, not what ought to happen. Who reads that address at 17:40? How long before legal hears about it? Who assesses if the responsible person is away for the weekend? Who holds the platform access? Who is writing this down?

Two or three gaps usually surface within the first twenty minutes, and they are rarely the ones people expected. More often than not it is the inbound channel or the missing second platform login rather than the legal assessment.

Repeat the rehearsal annually and after any organisational change. A reporting process does not go stale because the law moves; it goes stale because people change roles.

What is worth doing this week

Starting from nothing, you do not need a policy. Four decisions on a single page will do:

That page can be written in one meeting and covers the larger part of the exposure.

Everything else (the full policy, the alignment with contractual notification duties, the interaction with other reporting regimes) matters, but it is not what goes missing on a Friday evening.

Frequently asked questions

When exactly did CRA reporting duties for manufacturers begin?

The BSI announced on 11 September 2026 that manufacturers of products with digital elements must, from that point, actively report exploited vulnerabilities and severe security incidents. The legal basis is the Cyber Resilience Act, and reports are submitted through the ENISA Single Reporting Platform. The BSI had already flagged the approaching start of these duties on 26 June 2026, in connection with a meeting of the CRA market surveillance authorities. In practical terms this means the internal sequence needs to be dependable now, not by some later cut-off date.

Who is the reporting body in Germany?

Reports go to the Single Reporting Platform operated by the European Union Agency for Cybersecurity (ENISA). In Germany, CERT-Bund at the Federal Office for Information Security is the coordinating Computer Security Incident Response Team and therefore the national body that receives a report and passes it on. The BSI publishes step-by-step guidance on the reporting routes. What matters operationally is that platform access should be arranged in advance, and that at least two people in the organisation are able to use it so that absences do not block the sequence.

Who inside the organisation should decide whether an incident is reportable?

The decision should sit with a named role and a named deputy, not with a department and not with a committee. The terms “actively exploited” and “severe” require technical observation and legal classification to be read together, which means the deciding role has to be supplied with both: a technical assessment of exploitation, the range of affected products and versions, the state of containment, and the time of first observation. Equally important is a rule agreed in advance for deciding under uncertainty and for correcting the assessment later, because on day one of an incident the picture is usually contradictory rather than merely incomplete.

What should be documented during an incident?

Capture the time of first observation and who made it, the time legal was brought in, the assessment with its reasoning and the person who made it, the information that assessment rested on, the time and content of the report, and every later change of view together with what prompted it. The decisive factor is less the volume than the timing: a record created while the work was going on carries considerably more weight than a reconstruction assembled afterwards from chat histories and recollection. In practice it works best to assign the record-keeping to someone who is not simultaneously deciding or containing.

Does this apply to organisations that do not sell software?

The Cyber Resilience Act addresses products with digital elements, which is broader than conventional software. Connected devices and components with a software element may equally be caught. In-house legal teams should therefore not stop at “do we sell software?” but establish which of their own products contain digital elements and have been placed on the EU market. Classification in an individual case is a separate analysis, and it should not be attempted for the first time during an incident.

How can the sequence be prepared without launching a project?

With four decisions on one page: the escalation condition, phrased so that an on-call engineer with no legal training can apply it; the role that makes the assessment, with a deputy; the two people holding platform access; and the person who keeps the record during an incident. Then rehearse it once against an invented case. A rehearsal of that kind takes about 45 minutes and usually exposes two or three gaps within the first twenty, most often in the inbound channel for external reports, or in the missing second platform login.

This article reflects the position as at 16 September 2026 and is operational guidance, not legal advice.

Sources

• BSI press release of 11 September 2026 on the start of CRA reporting duties for manufacturers: https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2026/260911_CRA_Meldepflicht_Schwachstellen.html
• BSI news item of 26 June 2026 on the meeting of CRA market surveillance authorities: https://www.bsi.bund.de/DE/Service-Navi/Presse/Alle-Meldungen-News/Meldungen/2026/Treffen_CRA_Markt%C3%BCberwachungsbeh%C3%B6rden_260625.html
• Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 14: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2847
• ENISA CRA Single Reporting Platform: https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp