REPORTING UNDER ARTICLE 14

Two obligations, two cascades, one article

Article 14 of Regulation (EU) 2024/2847 applies from 11 September 2026 (Article 71(2)) and places two separate reporting obligations on manufacturers. The first covers every actively exploited vulnerability contained in a product with digital elements that the manufacturer becomes aware of (Article 14(1)). The second covers every severe incident having an impact on the security of the product that the manufacturer becomes aware of (Article 14(3)). Both notifications go simultaneously to the CSIRT designated as coordinator and to ENISA, via the single reporting platform established under Article 16.

The difference between them is not a formality. Each obligation has its own trigger, its own report content and, above all, its own starting points for the deadlines. The most common mistake we see in preparation is a process written as a single chain of four deadlines — 24 hours, 72 hours, 14 days, one month. That is not how the regulation is built. There are two parallel cascades of three reports each, and the last report in each is counted from something different.

Alongside mandatory reporting there is voluntary reporting under Article 15, which has a different regime and different consequences, and informing users under Article 14(8), which is done in addition to reporting to the authorities, not instead of it. This page follows the sequence: first whether an obligation has arisen at all, then the deadlines, then the content of the reports and who receives them, and finally what happens to a notification once it has been sent.

One thing is worth saying up front. Articles 14 to 17 do not govern the relationship to other reporting obligations that may, in a particular case, apply to the same event under other legislation. So it does not automatically follow that one notification settles everything — any overlap has to be assessed separately, according to what your organisation is bound by.

• The vulnerability cascade (Article 14(2)) — early warning notification within 24 hours, vulnerability notification within 72 hours, final report no later than 14 days after a corrective or mitigating measure becomes available.
• The severe incident cascade (Article 14(4)) — early warning notification within 24 hours, incident notification within 72 hours, final report no later than one month after the 72-hour notification was submitted.
• The intermediate report is not a fourth step. Under Article 14(6) it is requested, where necessary, by the CSIRT designated as coordinator that initially received the notification, and it concerns relevant status updates. It has no fixed deadline and is not submitted unless requested.
• Informing users (Article 14(8)) is a separate obligation alongside reporting to the authorities. The manufacturer informs the impacted users, and where appropriate all users, where possible in a structured, machine-readable format.
• Voluntary reporting (Article 15) is open to manufacturers and to anyone else, including for matters that do not trigger mandatory reporting — a near miss, for example.
• Open-source software stewards have a narrower obligation: Article 14(1) applies to them to the extent that they are involved in the development of products with digital elements, and Article 14(3) and (8) to the extent that severe incidents affect the network and information systems they provide for the development of such products (Article 24(3)).

The penalty framework sits in Article 64 and we do not go into it here — it belongs to enforcement, not to the procedure. What matters more for planning: both 24-hour clocks start when the manufacturer becomes aware, including on a Friday evening. A process that assumes the decision will be taken at Monday's meeting fails at the very first step.

Decision one: is the vulnerability actively exploited?

The Regulation works with three graded terms and mandatory reporting is triggered only by the last of them. A vulnerability is a weakness, susceptibility or flaw of a product that can be exploited by a cyber threat (Article 3, point 40). An exploitable vulnerability is one that has the potential to be effectively exploited by an adversary under practical operational conditions (Article 3, point 41). And an actively exploited vulnerability is one for which there is reliable evidence that a malicious actor has exploited it in a system without the permission of the system owner (Article 3, point 42).

Only the third category triggers the obligation under Article 14(1). In practice this means that routine CVE handling does not create a reporting duty — not a high severity score, not a working proof of concept, not even the fact that the vulnerability can be reliably exploited in your lab. All of those are reasons to fix quickly, not reasons to report.

Two elements of the definition need to be read separately. The first is reliable evidence of actual exploitation — not suspicion, not prediction, not a statistical model. The second is the absence of the system owner's permission, the wording that keeps authorised penetration testing, and your own exploitability checks in a test environment, outside the definition.

At the same time, nothing says the evidence has to come from outside or from a public source. If the manufacturer holds reliable evidence of exploitation from its own telemetry or from incident response at a customer, the obligation arises at that moment — and the 24-hour clock runs from there, not from the day the vulnerability appears on some public list.

• What does not trigger the obligation — a published CVE with no evidence of exploitation, a high severity score, a publicly available proof of concept, the result of your own exploitability test, scanner output, or an exploit-probability score.
• What does trigger it — reliable evidence that a malicious actor has actually exploited the vulnerability in your product, in a system whose owner gave no permission for it. The Regulation does not prescribe where that evidence comes from.
• Authorised pentesting falls outside the definition — testing with the system owner's consent does not meet the condition “without permission of the system owner”. A pentest finding is an input to remediation, not grounds for reporting.
• The decision needs an owner. Judging whether the evidence is reliable is expert judgement under time pressure. Who makes that call in your company, and who can make it outside working hours, is settled in advance, not during the first event.
• Record the moment you became aware and what documented it. It is the starting point for both deadlines and the only record that will show afterwards that you met them.
• Track components as well as the product — a vulnerability in a third-party library that is part of your product is a vulnerability contained in your product. Without a view of what the product is made of, you will not make that link in time.

Uncertainty is the normal state here: the first information is usually incomplete and the decision comes before the analysis is finished. That is exactly why the regulation has a three-step structure — the early warning carries little detail and is refined by the later reports. Once a team gets used to that sequence, it stops waiting for a certainty that nobody has in the first hours.

Decision two: is the incident severe?

The second obligation rests on two layers of definitions. An incident having an impact on the security of the product with digital elements means an incident that negatively affects, or is capable of negatively affecting, the ability of the product to protect the availability, authenticity, integrity or confidentiality of data or functions (Article 3, point 44). The term incident itself is taken from Article 6, point 6, of Directive (EU) 2022/2555, i.e. from NIS2 (Article 3, point 43).

Only a severe incident is reported, and the severity threshold is in Article 14(5). It is met if at least one of two alternative conditions applies. Under point (a), the incident negatively affects or is capable of negatively affecting the ability of the product to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions. Under point (b), the incident has led or is capable of leading to the introduction or execution of malicious code in the product or in the network and information systems of a user of that product.

Put the two texts side by side and the difference between the general definition in Article 3, point 44, and the threshold in Article 14(5)(a) comes down to a single phrase: the threshold speaks of sensitive or important data or functions, the general definition of data or functions without that narrowing. Not every incident having an impact on the security of the product is therefore severe and reportable — and conversely, anyone who conflates the two provisions will end up reporting everything, or nothing.

Condition (b) is written differently from (a): it does not turn on the sensitivity of data but on malicious code, and it expressly covers malicious code in the network and information systems of a user of the product. Anyone shipping updates or signed artefacts should read it carefully, with an eye on how their product reaches the customer.

• Two conditions, one is enough. The conditions in Article 14(5)(a) and (b) are alternatives. There is no point weighing them together — once one is met, the incident is severe.
• Settle “sensitive or important” in advance. The Regulation does not elaborate the term at the threshold, so the answer has to come from your product: which data and which functions carry its security. This is work for a quiet afternoon, not for the first hour of an event.
• Distinguish an incident at your company from one affecting the product. What Article 14(3) covers is an incident having an impact on the security of the product, not every security event in the manufacturer's corporate infrastructure.
• “Capable of negatively affecting” is part of the definition — both texts also cover potential impact. The argument that nothing has been proven does not by itself rule out severity.
• The link to users. Condition (b) expressly covers the network and information systems of a user of the product, not only the product itself.
• Record the decision even when you do not report. A note of why the event did not meet the severity threshold, and who assessed it, is the only thing that will show years later that the decision was a deliberate one.

In practice it helps to prepare two or three model situations typical for your product and to decide in advance which side of the threshold they fall on. Not for the paperwork — so that in a live event the discussion is about the facts, not about interpretation.

Deadlines: two parallel cascades, not one chain

This is where most of the confusion arises, so it is worth reading slowly. For an actively exploited vulnerability, Article 14(2) requires an early warning notification without undue delay and in any event within 24 hours of the manufacturer becoming aware of the vulnerability; a vulnerability notification without undue delay and in any event within 72 hours of that same moment; and a final report no later than 14 days after a corrective or mitigating measure becomes available.

That last deadline is the crucial one and is often misread. The 14 days do not run from the discovery of the vulnerability, nor from the 72-hour notification, but from the availability of the fix or mitigation. Until a measure is available, no final report is due — and once it is available, the clock starts regardless of how much time has passed since the beginning.

For a severe incident the start looks the same and the end is different. Under Article 14(4), the early warning notification is submitted without undue delay and in any event within 24 hours of the manufacturer becoming aware of the incident, the incident notification within 72 hours of that same moment, and the final report within one month of submitting the 72-hour notification under point (b). The starting point of the last deadline is therefore different from the vulnerability cascade: it follows your own earlier report.

Two things follow that are worth writing into the process in capitals. The 14-day deadline does not apply to incidents. The one-month deadline does not apply to vulnerabilities. Merge the two into a single table of four dates and sooner or later you will file a final report late — or close out a case early when the fix is not yet finished.

One more aside on how the deadlines are worded. The first two steps of both cascades are written as “without undue delay and in any event within” a given time, the final report as “no later than”. In both cases the upper limit is a ceiling, not a target. If you know enough after six hours, there is no reason to wait until the twenty-fourth.

• Vulnerability, step 1 — early warning notification within 24 hours of the manufacturer becoming aware (Article 14(2)(a)).
• Vulnerability, step 2 — vulnerability notification within 72 hours of the manufacturer becoming aware (Article 14(2)(b)). It is submitted unless the relevant information has already been provided.
• Vulnerability, step 3 — final report within 14 days of the availability of a corrective or mitigating measure (Article 14(2)(c)).
• Incident, step 1 — early warning notification within 24 hours of the manufacturer becoming aware (Article 14(4)(a)).
• Incident, step 2 — incident notification within 72 hours of the manufacturer becoming aware (Article 14(4)(b)).
• Incident, step 3 — final report within one month of submitting the 72-hour notification under point (b) (Article 14(4)(c)).
• Intermediate report — no fixed deadline, only at the request of the CSIRT designated as coordinator that initially received the notification, and only on relevant status updates (Article 14(6)).

The practical consequence for tooling: your records need two different timestamps. For a vulnerability, the moment the manufacturer became aware and the moment a corrective or mitigating measure became available. For an incident, the moment the manufacturer became aware and the time the 72-hour notification was sent. Without that second timestamp you cannot work out when the final report is due.

What goes into which report

The content of each report is set out in Article 14 itself. The Regulation has no annex devoted to reporting — its eight annexes cover other things, from the essential cybersecurity requirements through the categories of important and critical products to the content of the technical documentation and the conformity assessment procedures. Anyone looking for a form in an annex is looking in vain.

For the early warning the difference between the two cascades is small but concrete. For an actively exploited vulnerability, the manufacturer indicates in the early warning, where applicable, the Member States on the territory of which it has made the product available to the best of its knowledge (Article 14(2)(a)). For a severe incident, the early warning must include at least whether the incident is suspected of being caused by unlawful or malicious acts, and, where applicable, the Member States concerned (Article 14(4)(a)). That mandatory element is absent from the vulnerability warning.

The 72-hour notification for a vulnerability consists of general information, as available, about the product concerned, about the general nature of the exploit and of the vulnerability, together with information on any corrective or mitigating measures taken and on measures that users can take; and, where applicable, how sensitive the manufacturer considers the notified information to be (Article 14(2)(b)). For an incident it is general information, where available, about the nature of the incident, an initial assessment of it, the corrective or mitigating measures taken and the measures that users can take, and, where applicable, how sensitive the notified information is (Article 14(4)(b)).

Indicating the level of sensitivity is not a formality. It is precisely what allows the CSIRT that initially receives the notification to delay passing it on to the other teams, which the section below covers separately. Leave that field empty and you lose a tool the regulation offers for exactly these sensitive cases.

The final reports each have three mandatory elements, set by the regulation as a minimum, and they differ in content. For a vulnerability: a description of the vulnerability including its severity and impact, where available information on any malicious actor that has exploited or is exploiting it, and details about the security update or other corrective measures made available to remedy it (Article 14(2)(c)(i) to (iii)). For an incident: a detailed description of the incident including its severity and impact, the type of threat or root cause that is likely to have triggered it, and the applied and ongoing mitigation measures (Article 14(4)(c)(i) to (iii)).

• Early warning — vulnerability: where applicable, the Member States on the territory of which the manufacturer has, to the best of its knowledge, made the product available.
• Early warning — incident: at least whether the incident is suspected of being caused by unlawful or malicious acts; where applicable, the Member States concerned.
• 72-hour notification — vulnerability: general information about the product, the general nature of the exploit and the vulnerability, corrective or mitigating measures taken, measures for users, and where applicable the level of sensitivity.
• 72-hour notification — incident: general information about the nature of the incident, the initial assessment, corrective or mitigating measures taken, measures for users, and where applicable the level of sensitivity.
• Final report — vulnerability: a description of the vulnerability with its severity and impact, information on the malicious actor, and details of the security updates or other corrective measures available.
• Final report — incident: a detailed description of the incident with its severity and impact, the type of threat or likely root cause, and applied and ongoing mitigation measures.
• The format and procedures may be specified further by the Commission by implementing acts under Article 14(10), in cooperation with the CSIRTs network and ENISA. The empowerment is optional — the regulation says the Commission may do so, not that it must.

Prepare the templates in advance and write them so that they can be filled in from what you actually know in the first hours. Wording such as “confirmed” or “ruled out” in the first warning is usually unsupportable; at that step the regulation does not ask for it either.

Who receives the report and how “your” CSIRT is determined

Notifications are submitted via the single reporting platform, using one of the electronic notification end-points referred to in Article 16(1). Specifically, they go through the end-point of the CSIRT designated as coordinator of the Member State where the manufacturer has its main establishment in the Union, and are simultaneously accessible to ENISA (Article 14(7)). So this is not two separate submissions to two addresses — it is a model in which you report once.

A CSIRT designated as coordinator means a CSIRT designated as coordinator pursuant to Article 12(1) of Directive (EU) 2022/2555 (Article 3, point 51). It is therefore the same body that coordinates vulnerability disclosure under NIS2 in that Member State.

A manufacturer has its main establishment in the Member State where the decisions related to the cybersecurity of its products with digital elements are predominantly taken. If no such Member State can be determined, it is the one where the manufacturer has the establishment with the highest number of employees in the Union (Article 14(7), second subparagraph). Note that the criterion is neither the registered office nor the place of development, but where cybersecurity decisions about the products are taken.

For manufacturers without a main establishment in the Union, the third subparagraph of Article 14(7) sets out a cascade of four criteria in a fixed order: the Member State of the authorised representative acting for the highest number of the manufacturer's products, then the Member State of the importer placing the highest number of products on the market, then the Member State of the distributor making the highest number of products available on the market, and finally the Member State with the highest number of users of the manufacturer's products.

The last step of the cascade comes with practical relief. Where the route is determined under point (d), that is by the highest number of users, the manufacturer may submit any subsequent notification of an actively exploited vulnerability or a severe incident to the same CSIRT to which it submitted its initial notification (Article 14(7), fourth subparagraph). There is no need to recount users before every further report.

• Determine your reporting route before you need it. Working out where decisions on the cybersecurity of your products are predominantly taken is a pointless delay in the first hours of an event.
• The main establishment test is about decisions, not org charts — what counts is where cybersecurity decisions about the products are taken, and only as a fallback the number of employees in the Union.
• Without an establishment in the Union the cascade applies in the order authorised representative, importer, distributor, number of users. The order is not a menu.
• The list of Member States where the product is made available goes into the reports where applicable, that is to the best of the manufacturer's knowledge (Article 14(2)(a) and (4)(a)). For products sold through partners this is usually the first thing missing in a live event.
• ENISA establishes the single reporting platform and manages and maintains its day-to-day operation; its architecture allows Member States and ENISA to set up their own electronic notification end-points (Article 16(1)). The platform serves mandatory notifications under Article 14(1) and (3) as well as voluntary ones under Article 15(1) and (2).
• Platform security is handled separately — ENISA takes technical, operational and organisational measures to manage the risks and notifies the CSIRTs network and the Commission without undue delay of any security incident affecting the platform (Article 16(4)). In cooperation with the CSIRTs network it provides specifications of the measures for the platform and the end-points so that vulnerabilities with no remedy available are handled under strict security protocols and on a need-to-know basis (Article 16(5)).

Two things to verify at source, because they may change over time and we therefore do not state them here: the current operational status of the single reporting platform and the registration procedure on the ENISA side, and which team is designated as coordinator in the Czech Republic and how to communicate with it. None of this changes the deadlines — the 24 hours run from the moment you become aware, not from the moment your access is sorted out.

What happens to a notification once it is sent

Sending it does not end the work, but it does stop the matter being yours alone. The CSIRT designated as coordinator that initially receives the notification disseminates it without undue delay, via the single reporting platform, to the CSIRTs designated as coordinators of the Member States on the territory of which, according to the manufacturer's information, the product has been made available (Article 16(2), first subparagraph). That is precisely why the notification names the Member States concerned.

In exceptional circumstances, in particular at the manufacturer's request and in view of the indicated level of sensitivity of the information, dissemination may be delayed on justified cybersecurity-related grounds for a period that is strictly necessary. The CSIRT must inform ENISA without undue delay of such a decision, justify the delay and state when it will disseminate the notification; ENISA may support it in applying those grounds (Article 16(2), second subparagraph).

The conditions for that delay were supplemented by Commission Delegated Regulation (EU) 2026/881 of 11 December 2025, published on 20 April 2026 under the empowerment in Article 14(9). A delay based on the nature of the information is possible only where the risks of dissemination outweigh the benefits and cannot be mitigated by protocols such as TLP or PAP, and where at least one of the four conditions in its Article 3 is also met: the manufacturer has indicated that an effective mitigating measure will be available within 72 hours; the information in the notification is sufficient for actors with limited skills to build an exploitation technique; the CSIRT is able to share parts of the notification sufficient for others to deploy mitigating measures; or the case is a coordinated vulnerability disclosure in which the CSIRT acts as a trusted intermediary.

The same Regulation also covers two situations on the recipient side. Sending a notification to a particular CSIRT may be delayed where that team has been affected by a cybersecurity incident calling into question its ability to ensure confidentiality, or where there is sufficient reason to believe that its capabilities to ensure confidentiality are insufficient — until the team informs the CSIRTs network that the capability has been restored, or evidences that the shortcomings have been remedied (Article 4). And where ENISA has informed the CSIRTs network under Article 16(4) of Regulation 2024/2847 that the platform itself has been affected by an incident, dissemination through it may be delayed until ENISA announces that its ability to ensure confidentiality has been restored (Article 5).

ENISA's access has a regime of its own. In highly exceptional circumstances — where the manufacturer states in the 72-hour notification that the vulnerability is being actively exploited and, to the best of the available information, is not being exploited in any Member State other than that of the CSIRT designated as coordinator to which it was notified; that immediate dissemination would likely result in supplying information contrary to the essential interests of that Member State; or that the vulnerability poses an imminent high cybersecurity risk stemming from further dissemination — only the information that the manufacturer has submitted a notification, general information about the product and the general nature of the exploit, and the fact that security-related grounds were provided, are made simultaneously accessible to ENISA (Article 16(2), third subparagraph). If, even on that limited basis, ENISA considers that there is a systemic risk affecting security in the internal market, it recommends that the CSIRT which initially received the notification forward the full notification to the other coordinators and to ENISA itself.

A final aside on delay concerns coordinated vulnerability disclosure. Where a CSIRT has become aware of an actively exploited vulnerability as part of a procedure under Article 12(1) of Directive (EU) 2022/2555, it may delay dissemination for the period strictly necessary until it obtains the agreement of the parties involved in the coordinated disclosure; this does not prevent manufacturers from notifying the vulnerability voluntarily (Article 16(6)).

• Delay is an option, not a duty — recital 1 of Regulation 2026/881 states expressly that the CSIRT initially receiving the notification may delay dissemination but is not obliged to do so.
• The delay conditions do not govern ENISA's access. That can be restricted only in the highly exceptional circumstances under the third subparagraph of Article 16(2) of Regulation 2024/2847, and only in relation to the 72-hour vulnerability notification under Article 14(2)(b) — recital 2 of Regulation 2026/881.
• A single Member State of supply — where the manufacturer indicates that the product is supplied only to the market of the Member State of the CSIRT initially receiving the notification, that team need not send the notification to any other (recital 7 of Regulation 2026/881).
• Market surveillance authorities are reached through the CSIRTs. On receipt of a notification, the CSIRTs designated as coordinators provide the market surveillance authorities in their Member States with the notified information necessary to fulfil their obligations under the regulation (Article 16(3)). The manufacturer therefore does not notify the surveillance authorities directly.
• Informing the public — where necessary to prevent or mitigate a severe incident, to address an ongoing incident, or where disclosure is otherwise in the public interest, the CSIRT may, after consulting the manufacturer concerned and where appropriate in cooperation with ENISA, inform the public about the incident or require the manufacturer to do so (Article 17(2)).
• Entry in the European vulnerability database — once a security update or another corrective or mitigating measure is available, ENISA adds the publicly known notified vulnerability, in agreement with the manufacturer, to the database established under Article 12(2) of Directive (EU) 2022/2555 (Article 17(5)).
• Sharing at operational level — ENISA may provide the notified information to EU-CyCLONe, established by Article 16 of Directive (EU) 2022/2555, where relevant for the coordinated management of large-scale incidents and crises (Article 17(1)).
• Notifying does not increase liability. Under Article 17(4), notifications under Article 14(1) and (3) and under Article 15(1) and (2) do not subject the notifying entity to increased liability.

The notifications received also feed an aggregate output: every 24 months ENISA prepares a technical report on emerging trends in cybersecurity risks in products with digital elements and submits it to the Cooperation Group under Article 14 of Directive (EU) 2022/2555; the first report is due within 24 months of the obligations under Article 14(1) and (3) starting to apply (Article 17(3)).

Informing users and voluntary reporting under Article 15

Reporting to the authorities is only half of the obligation. Under Article 14(8), after becoming aware of an actively exploited vulnerability or a severe incident the manufacturer informs the impacted users of the product, and where appropriate all users, about that vulnerability or incident and, where necessary, about the risk mitigation and corrective measures that users can deploy. Where possible this should be in a structured, machine-readable format that is easily automatically processable.

The provision also has a backstop. Where the manufacturer fails to inform users in a timely manner, the CSIRTs that received the notification may do so where proportionate and necessary. In other words, the message to customers does not always stay under your control — which is a good reason to have the communication part of the process ready in the same way as the formal part.

Alongside the mandatory regime there is voluntary reporting. Under Article 15(1), manufacturers and other natural or legal persons may notify the CSIRT designated as coordinator or ENISA of any vulnerability in a product with digital elements and of cyber threats that could affect its risk profile. Under paragraph 2, the same route is open for any incident having an impact on the security of the product, and for near misses that could have resulted in such an incident.

The voluntary regime has three rules worth knowing in advance. A CSIRT may prioritise the processing of mandatory notifications over voluntary ones. Where someone other than the manufacturer notifies an actively exploited vulnerability or a severe incident, the CSIRT informs the manufacturer without undue delay. And a voluntary notification must not result in additional obligations for the notifying party to which it would not otherwise have been subject (Article 15(3), (4) and (5)).

• Impacted users, or all of them — the range of addressees depends on what is necessary; the regulation provides for both (Article 14(8)).
• Machine-readable format — the requirement is worded as “where appropriate”, but it points in a direction: the message should be processable automatically on the customer's side, not merely readable by a human.
• If you do not inform in time, a CSIRT may, where proportionate and necessary. Your version of the message may not be the only one the customer sees.
• Voluntary reporting covers what the obligation does not — a vulnerability with no evidence of exploitation, a threat affecting the product's risk profile, an incident below the severity threshold, and a near miss (Article 15(1) and (2)).
• A voluntary notification creates no additional obligations for the notifying party beyond those it would otherwise have (Article 15(5)).
• Support for smaller manufacturers — the CSIRTs designated as coordinators provide helpdesk support on the reporting obligations under Article 14 to manufacturers, in particular to microenterprises and small or medium-sized enterprises (Article 17(6)).

Do not confuse customer communication with reporting. The text for the CSIRT and the text for users have a different addressee, a different purpose and a different level of detail — and in a live event they are usually written in the same hour. Who writes which is decided in advance.

Preparing for 11 September 2026: what to have ready

This section no longer describes what the regulation requires, but what works in preparation. It is our recommendation from projects, not a requirement of the legislation, and the order shifts with the type of product.

The starting point is simple: Article 14 does not add documentation work, it adds an operational capability. You can test for it with a single question — who decides at 10 p.m. on a Friday that the evidence of exploitation is reliable, and who sends the early warning within 24 hours. Most of the items below are just a pre-prepared answer to that question.

The second starting point is about data. To be able to say in the first hours which versions of the product are affected and in which Member States it has been made available, you need those records before anyone starts hunting for them. Working out what the product is made of while the 24-hour clock runs is too late — how that inventory is produced continuously at build time is covered on the secure development page in this Links section.

And third: a process nobody has tried is not a process. A dry run on a model situation takes half a day and reveals exactly the things that hurt in a live event — a missing deputy, unclear decision rights, a template that nothing can be filled into, and data nobody has at hand.

• Roles and deputies — who qualifies the event, who approves sending, who writes the text, who talks to customers, and who covers each role outside working hours.
• A determined reporting route — which Member State holds your main establishment within the meaning of Article 14(7), or which step of the cascade applies to you, with access to the end-point sorted out before you need it.
• A record of the key moments — when you became aware and what documented it, when a corrective or mitigating measure became available, and when the 72-hour notification was sent. All the deadlines in both cascades are calculated from those three timestamps, and the evidence is what defends them afterwards.
• Severity criteria decided in advance — which data and functions of your product you treat as sensitive or important within the meaning of Article 14(5)(a), with a few model situations decided as a dry run.
• A view of where the product is available — in which Member States it has been made available, including sales through partners. Without it you cannot supply the information on which dissemination to the other CSIRTs depends.
• Templates for six reports — two early warnings, two 72-hour notifications and two final reports, each with its mandatory elements under Article 14(2) and (4), plus a field for the level of sensitivity.
• Prepared user communication under Article 14(8), where possible in a machine-readable format, and clearly defined channels through which it reaches the impacted users.
• A dry run on a model situation — once with an actively exploited vulnerability, once with a severe incident, measuring the time to the first warning.

If you are building this process and want it tested before it runs for real, we will go through it with you — decision criteria, roles and availability, report templates and a dry run on a model situation. How this connects to post-release vulnerability management, and where the input data come from, is covered on the DevSecOps and secure development page in this section.

An hour-by-hour timeline from discovery to the final report

The timeline shows both cascades side by side. Only the first two steps are shared — after that the paths diverge, because for a vulnerability the last report is counted from the availability of the fix and for an incident from the submission of the 72-hour notification. The times follow Article 14 of Regulation (EU) 2024/2847; hour zero is the moment the manufacturer becomes aware.

Official sources

The statements about obligations and deadlines on this page are based on the sources below, as they stood on 9 August 2026. The page does not replace the wording of the legislation — the text in the Official Journal is what binds.