CRA Article 14 vs DORA incident reporting: do you file twice?

What DORA Article 19 actually does

Regulation (EU) 2022/2554 (DORA) Article 19 obliges financial entities to report major ICT-related incidents to the relevant competent authority under Article 46, using the templates referred to in Article 20: an initial notification, an intermediate report when status or handling changes (with updates as needed), and a final report when root-cause analysis is done and actual impact figures replace estimates. Significant credit institutions report to the national competent authority, which immediately transmits to the ECB. Member States may also require a parallel copy to a NIS2 CSIRT — still not the CRA Single Reporting Platform.

Article 19(2) adds a voluntary channel for significant cyber threats. Article 19(3) requires client information when a major ICT-related incident hits clients' financial interests. Article 19(5) allows outsourcing of the reporting mechanics; the financial entity remains fully responsible. None of those limbs rewrite CRA manufacturer reporting.

Article 14 stays on the product / SRP track

CRA Article 14 obliges manufacturers to notify actively exploited vulnerabilities and severe incidents having an impact on the security of the product — early warning within 24 hours of becoming aware, fuller notification within 72 hours, then the final report on its own trigger — through ENISA's Single Reporting Platform to the coordinating CSIRT. That duty has applied from 11 September 2026 (Article 71(2)), including for in-scope products already on the market (Article 69(3)).

Clock detail for the CRA side lives in the reporting deadlines and becoming-aware guides. CSIRT routing: which CSIRT applies.

The trap: “DORA (or DORA-for-NIS2) covered ENISA”

Two failure modes show up in triage. First: a bank, payment institution or investment firm that also ships a connected product (app, terminal, trading client) files DORA Article 19 and skips the SRP because “financial incident reporting is already running.” Second: an ICT vendor assumes that because the customer files DORA — or because DORA can stand in for NIS2 at the financial entity — the vendor has no manufacturer Article 14 clock when an actively exploited vulnerability sits in a product it placed on the market. Entity ICT reporting and product SRP reporting are different jobs.

Neighbouring traps: parallel NIS2 (same cascade shape as CRA, still separate — and often absorbed by DORA for financial entities without touching CRA); GDPR personal-data breach clocks; AI Act Article 73 market-surveillance serious-incident filings; civil Product Liability Directive compensation claims (FAQ 2.3.1 — not an SRP substitute); and standalone SaaS outside CRA versus a shipped financial product with remote data processing inside the product.

If CRA, DORA, NIS2 and GDPR all look relevant

Run each regime's own trigger test and file to each regime's own recipient. Keep one internal timeline of what you knew and when (the evidence log), then fork the external notifications. For many financial entities, counsel may treat DORA as meeting NIS2 incident-reporting expectations (lex specialis). That still leaves CRA Article 14 on its own SRP path when a product-side AEV or severe incident is met. Confirm any equivalent-reporting claim with counsel against the current consolidated texts — do not invent a CRA exemption from a DORA/NIS2 merge.

Questions people ask

Does a DORA Article 19 major ICT-incident report satisfy CRA Article 14?

No. Article 14 does not name Regulation (EU) 2022/2554 (DORA) as an alternative route. DORA Article 19 sends major ICT-related incidents from financial entities to the relevant competent authority under Article 46 (with Article 20 templates). Article 14 sends actively exploited vulnerabilities and severe product-security incidents from manufacturers to the coordinating CSIRT and ENISA via the Single Reporting Platform. One filing does not put the report in front of the other regime.

Are the clocks the same shape as NIS2?

Only loosely. CRA Article 14 uses 24-hour early warning, 72-hour fuller notification, then a final report (14 days after a corrective or mitigating measure is available for an AEV, or one month after the 72-hour notification for a severe incident). DORA Article 19 uses initial / intermediate / final reports with timelines in Commission Delegated Regulation (EU) 2025/301 Article 5: initial as early as possible, within four hours of classifying the incident as major and no later than 24 hours from awareness; intermediate within 72 hours of the initial notification; final within one month of the intermediate (or latest updated intermediate). Matching the words “72 hours” and “final report” does not merge the calendars.

When can the same event trigger both?

When the facts independently meet both tests. CRA needs an actively exploited vulnerability in your product with digital elements, or a severe incident with impact on that product’s security, and you must be the manufacturer. DORA needs a major ICT-related incident (Articles 3 and 18 classification) at a financial entity in DORA scope. A compromised payment terminal, trading client or banking app you manufacture that also disrupts a financial entity’s ICT can trip both for the manufacturer and for the financial entity — different filers, different portals.

We already file DORA instead of NIS2 — does that cover CRA?

No. DORA can operate as lex specialis relative to NIS2 incident reporting for in-scope financial entities in many Member States, so one financial-sector filing may serve both DORA and NIS2. That consolidation stays inside the entity/ICT-resilience family. It does not rewrite CRA Article 14 or route a product AEV into ENISA’s Single Reporting Platform.

We are an ICT vendor to banks, not a financial entity — who reports what?

DORA Article 19 sits with the financial entity. If you place an in-scope product with digital elements on the Union market, you can still own CRA Article 14 as manufacturer when an AEV or severe product-security incident is met — even if you are not yourself a DORA financial entity. DORA Article 19(5) lets a financial entity outsource its DORA reporting mechanics to a third party while remaining fully responsible; that outsourcing does not transfer or cancel a separate CRA manufacturer duty on a product you ship.

When does each duty apply on the calendar?

CRA Article 14 has applied from 11 September 2026 (Article 71(2)), including for in-scope products already on the market (Article 69(3)). DORA major ICT-incident reporting under Article 19 has been live on DORA’s own application calendar (from 17 January 2025 for the core DORA package). Do not wait on a finished DORA classification file before opening an SRP case when a product-side Article 14 trigger is already met.