On 11 September 2026, Article 14 of the Cyber Resilience Act entered into force. Many teams treated it as an isolated event: a new notification channel, a new ENISA platform, a new 24-hour deadline. That framing is incomplete. For a significant share of the organisations concerned, this article is not added to a vacuum: it is added to NIS2 and the GDPR, two regimes that are already active. A single incident can now trigger three simultaneous notification processes, with different recipients, different content and deadlines that overlap. Most GRC teams have not yet documented this combination.
Three regimes, three clocks, one team
The first regime is the CRA, Article 14. It applies to manufacturers of products with digital elements: hardware, software, embedded solutions. As soon as a manufacturer becomes aware of an actively exploited vulnerability or a serious incident affecting its product, it has 24 hours to submit an early warning to the ENISA Single Reporting Platform (SRP). The full notification follows within 72 hours. The final report is due 14 days after a fix becomes available for an actively exploited vulnerability, or within one month of the 72-hour notification for a serious incident.
The second regime is NIS2. It applies to essential and important entities: digital service providers, financial entities, healthcare establishments, infrastructure providers. In the event of a significant incident, the entity has 24 hours to send an early warning to the competent national authority (in France, the CERT-FR via the MonEspaceNIS2 portal), 72 hours for the full notification, and one month for the final report.
The third regime is the GDPR, Article 33. It applies to any controller that suffers a personal data breach. Notification to the competent supervisory authority (the French data protection authority (CNIL) in France) is due within 72 hours of becoming aware of the breach, unless the breach is "unlikely to result in a risk to the rights and freedoms of natural persons".
Who falls under all three?
The population concerned is larger than many expect. It includes in particular B2B software publishers that supply financial sector entities (subject to DORA and NIS2), HDS-certified health data hosts, cloud service providers classified as important entities under NIS2, and more generally any SaaS publisher that processes personal data of business customers at scale and whose software qualifies as a product with digital elements within the meaning of the CRA.
According to the impact assessment published by the European Commission in October 2022, the CRA covers more than 160,000 manufacturers worldwide. A significant share of them also operate as NIS2 or DORA entities and process personal data. These organisations do not have a notification problem: they have three.
An example: the financial SaaS on 14 September
A publisher of compliance software for the banking sector discovers this morning that an authentication component of its platform is subject to active exploitation. The incident has led to unauthorised access to customer data, including names, identifiers and transaction logs. The platform suffered a five-hour service interruption the previous night.
At 9:00 a.m., the three clocks start simultaneously. The CRA requires an early warning to the SRP before 9:00 a.m. the following day. NIS2 requires an early warning to the CERT-FR before 9:00 a.m. the following day. The GDPR requires notification to the CNIL before 9:00 a.m. the day after tomorrow. These deadlines do not replace one another: they stack up. The team must produce three distinct documents, for three distinct portals, with three slightly different definitions of what each must contain.
The CRA alert covers the vulnerability and the product. The NIS2 alert covers the impact on the service. The GDPR notification covers the nature and volume of the data affected, the categories of data subjects and the measures taken. This content partly overlaps but does not substitute for one another. A single document satisfies none of the three regimes.
The structural frictions
Three differences make the process hard to manage in a unified way. The first is the trigger: under the CRA, it is becoming aware of an actively exploited vulnerability; under NIS2, it is a significant incident affecting the service; under the GDPR, it is a personal data breach. These three events may occur simultaneously, as in the example above, or at different moments depending on how the incident unfolds. The same event may trigger all three at the same time, or the chain may run over several days.
The second friction is organisational. The teams handling CRA notifications are often distinct from those handling NIS2 (operational security) and the GDPR (DPO or legal team). In an incident, coordinating these three teams under pressure, with 24-hour deadlines on two of the three obligations, requires an escalation chain that many organisations have not yet formalised. ACPR inspections in 2026 identified that 35 % of inspected entities showed significant weaknesses in their ICT risk management framework, including gaps in incident detection and escalation processes. This figure illustrates the gap between documentary compliance and real operational readiness.
The third friction is post-incident follow-up. Final report deadlines differ by regime: 14 days (CRA, actively exploited vulnerability), one month (NIS2 and CRA for serious incidents), and 72 hours for the initial GDPR notification followed by a supplementary report with no fixed deadline. An organisation tracking its post-incident obligations in a single dashboard must manage at least five deliverables on distinct schedules for a single incident triggering all three regimes.
What your organisation should prepare
Four actions reduce the risk of improvisation.
The first is mapping trigger incidents. List the types of incident that, in your specific environment, can simultaneously trigger the CRA, NIS2 and the GDPR. For each type, identify the precise triggers of each regime and the deadlines that apply. This mapping is the basis for everything else.
The second is appointing a notification coordinator. This is not the person who drafts the three notifications, but the person who keeps the dashboard, checks that the three deadlines are met and coordinates the CRA, NIS2 and GDPR teams. Without this role, each team notifies within its own lane with no overview of the parallel obligations.
The third is building a common intake form. An initial assessment document, completed within the first hours of the incident, should feed the three draft notifications simultaneously. The fields overlap enough that this work need not be tripled, provided it is structured in advance.
The fourth is a simulation exercise. Run a tabletop exercise in which one incident triggers all three regimes at once. The exercise will reveal the coordination gaps that paper procedures do not show. Teams that have simulated this process, even once, arrive at a real incident with a measurable advantage. The article on the five operational pitfalls of 24-hour NIS2 notification describes the most frequent errors under that regime alone, and they apply, mutatis mutandis, to the other two.
The preparation window
The entry into force of CRA Article 14 on 11 September 2026 marks the activation of the third regime. Organisations that have treated the CRA, NIS2 and the GDPR as three separate projects now have a concrete reason to bring them together in an integrated notification process. This coordination work does not require an exceptional budget. It requires time and a decision: appoint an owner, map the cumulative scenarios, and test the process once before an incident forces improvisation.
The next time three clocks start simultaneously, your organisation will be in one of two states: it will have rehearsed this scenario, or it will discover it under real conditions.