Why the first filing matters

The table's second column clearly exposes the problem. The legal regimes do not rename the same event; each asks a different question about the same facts. NIS2 asks whether systems were compromised. The GDPR asks whether personal data was affected. The CRA asks whether a product failed and the MDR vigilance asks whether a patient was or could have been harmed.

Four filings can each be accurate and still describe the event differently. The core facts usually do not change. A system was available or it was not; data left the environment or it did not — while the legal meaning assigned to them shifts. The regimes do not, of course, share the same reporting triggers. They do, however, align on one concept: under the Commission's July 2026 CRA guidance, a suspicious event or a third-party report does not start the clock. The manufacturer becomes aware only when, after a prompt initial assessment, it reaches a reasonable degree of certainty that a vulnerability in its product is being actively exploited or that a severe incident has compromised the product's security. That approach aligns with the EDPB's Guidelines 9/2022.

No regime gives priority to whichever notification goes first, and no rule makes one filing bind another. Confidentiality protections (NIS2 Article 23(6); CRA Article 63) guard commercial interests inside the regulatory system, not the description itself; notification does not affect or alter liability (NIS2 Article 23(1); CRA Article 17(4)), but the filing is not privileged, and its later use turns on national rules on access to file and discovery.

The first filing is the first official version of events: a timestamp and a description fixed when the facts are thinnest, inherited by everyone downstream. Once an early warning identifies ransomware on Sunday morning, a hospital arguing its Article 33 awareness arose on Thursday is arguing against a record it did not write and cannot revise. Nor are the files contained. NIS2 Article 35(1) can transfer a filing from one regulator to the data protection authority, and both regimes require notice to service recipients and users. The first description moves into customer communications, where no confidentiality exists.

The medtech boundary

CRA Article 2(2) excludes medical devices, because they already have their own security regime. In that context, the device platform answers only to MDR vigilance. But the exclusion covers only what is intended for a medical purpose under Medical Device Coordination Group guidance MDCG 2019-11 Rev. 1. Products placed on the market alongside a device can fall outside of this. The video recording device is the typical example. It records the procedure for documentation and training; it does not help perform it. As a result, it is not a medical device and falls under the CRA. The result: one organization, two regulatory identities: a medical device manufacturer on the MDR clock and a video-device manufacturer, on the CRA clock. The Commission's December 2025 proposal for Articles 87a EU MDR and 82a IVDR would probably close this gap; for now, it remains a proposal.

Three practical steps

The following measures require neither a new function nor a separate process. Two adjust procedures already in place. The third concerns a responsibility that few organizations assign: authority over the first official account of an incident.

Add a regulatory notification annex to the incident clause

Reopening every hosting, cloud or data-processing agreement is rarely realistic; adding an Annex is. The annex should require notice of the facts needed to assess NIS2, GDPR, CRA and MDR triggers, including affected systems, service interruption, personal data, product security and patient impact, within the shortest statutory window that may apply. It should also give the customer a consultation right where practicable, before any filing that describes shared facts. It should not ask the supplier to make the customer’s legal assessment or delay its own statutory filing.

When the supplier is a processor, this is not purely a matter of negotiation power. Article 28(3)(f) GDPR already obliges the processor to assist the controller in complying with Articles 33 and 34. The annex is therefore best drafted as a specification of that existing duty rather than as a new concession. It should require the parties to use a common incident vocabulary, preserve the chronology, and flow the same factual-notice obligation to subcontractors that may be first to detect the incident.

Build the four reporting trigger questions into the incident response policy

The fix is not a separate legal workflow but a small change to incident intake and escalation. At intake, and again at the 24-hour and 72-hour milestones, the person leading the incident response should be required to record, to the extent possible, whether the event affects network and information systems, personal data, product security or patient safety. Unknown should be permitted only if the assumption and owner for follow-up are properly clarified and recorded. That assessment should drive escalation to privacy, cyber assurance and IT, regulatory, product and clinical leads before the first external description is finalized. Because incident handling is part of the NIS2 risk-management framework that management bodies must approve and oversee, this classification step should belong in the board-approved incident response policy.

Appoint a first-filing owner with authority to settle the factual record

Organizations allocate notification duties by regime, but no one owns the first official account of the incident. The board-approved policy should designate a senior legal or privacy lead with authority to convene security, regulatory, product and clinical stakeholders, approve any first notification, and maintain the chronology on which all subsequent NIS2, GDPR, CRA and MDR filings will rely. That person should not decide the legal outcome in isolation; the role is to control the factual foundations, mark assumptions as provisional, ensure that shared facts are described consistently, and prevent an early operational label from becoming an unintended admission in another regulatory forum.

One limit: consultation rights yield to statutory deadlines. The contract may guarantee you can check the filing but does not guarantee that you can object to it. Nor do the four reports need to match. Both NIS2 and the GDPR assume reporting matures with the investigation (Articles 23(4), 33(4)), and there is no penalty for reporting an incident that proves not to be a breach (EDPB Guidelines 9/2022, para. 60). Regulators expect assessments to change as facts emerge; what they act on is a change no one can explain.

The reporting clocks remain separate. The Digital Omnibus would consolidate only where notifications are submitted, not what each legal regime requires, and as of mid-August 2026 it remains under Council negotiation. Decide in advance who files first and what that first filing will say.
The views expressed in this article belong solely to the author.

Search resources

Featured resources

Top 5 operational impacts of the CRA

Cybersecurity Law Key Terms

Data Security Program Cheat Sheet

Data transfer and cybersecurity laws

All IAPP resources

Filter results

Resource type

Subject

Industry

Law and regulation

Domain

How the C-Suite Should Talk About Cybersecurity

Bridging ISO 27001 to GDPR

How the C-Suite Should Talk About Cybersecurity

Four clocks, one incident: What the CRA adds to EU incident notifications

Top 12 data protection action items for global businesses