EU Cybersecurity Requirements: What Security Leaders Need to Operationalize

A manufacturer of connected industrial equipment finds that its build environment has been compromised. Customer data was exposed, and a tampered update has already shipped. Depending on facts the company will not yet know, that single event may be a personal data breach under GDPR, a significant incident under NIS2, and an actively exploited vulnerability that must be reported under the Cyber Resilience Act. Three instruments, three clocks, one set of facts.

This is the operational reality of EU cybersecurity law. The instruments are separate and the events they govern are not. Security leaders who read the requirements as a library of laws to comply with end up running parallel workstreams. Leaders who read them as a shared set of assurance questions about accountability, incidents, third parties and evidence end up with one model that answers all of them.

One exception to the picture is worth stating plainly. For financial entities, the Digital Operational Resilience Act (DORA) is the specialized regime, and it replaces the corresponding NIS2 obligations. A bank does not report the same incident under both.

Same event, different clocks

The Cyber Resilience Act’s reporting duties already apply, even though most of its other requirements start later. Manufacturers with products on the EU market need an operating route to ENISA and the national CSIRT now, not when the remaining obligations arrive.

The Commission has proposed a single entry point for incident reporting across NIS2, GDPR and DORA, and a longer window for GDPR breach notification. It is a proposal, not law. Plan on the current clocks. Design the incident record so that one submission route can be adopted if the proposal passes.

Accountability is where budgets move

NIS2 puts cybersecurity risk-management measures in the hands of the management body. Those bodies must approve the measures, oversee their implementation, undergo training, and can be held liable for infringements. DORA gives the management body similar responsibility for the ICT risk framework of a financial entity.

The assurance consequence is practical. If a regulator asks what the board approved, what it asked, and what it was told, the answer has to come from records. A quarterly slide with a status color does not show oversight. Minutes that record the decision, the information the board relied on, and the challenge it raised do. Security leaders should redesign board reporting around what directors must be able to evidence, not around what the security team finds easiest to present.

A directive is not a single law

NIS2 is a directive, so each Member State transposes it into national law. Transposition has been uneven. The Commission opened infringement procedures against Member States that had not completed it, and later moved to reasoned opinions for a number of them. A group operating in five Member States may face five national texts, five registration processes and five supervisors, with differences in scope, supervisory powers and reporting channels.

The design consequence is a split. Set the control baseline once, at group level. Maintain the obligation register by Member State and legal entity, with the national text, the competent authority and the reporting channel recorded for each. Review the register more often than the baseline. National law keeps moving even when the Directive does not.

Third parties: where the instruments meet

NIS2 requires supply chain security as one of its risk-management measures. DORA requires a register of information on ICT third-party arrangements and subjects critical ICT third-party providers to direct oversight. The Cyber Resilience Act places duties on manufacturers, including diligence when they integrate third-party components. A security leader does not need three inventories. One third-party register can serve all of them if it holds the service provided, its criticality, the data and systems involved, subcontractors, contractual security and notification terms, and the exit plan.

What assurance has to show

Assurance is the evidence layer that sits above the controls. For each requirement, four questions apply: who is accountable, how the control operates, how its effectiveness is tested, and what record proves it. Where a requirement calls for independent testing, such as the threat-led penetration testing DORA requires of significant financial entities, the test plan and its findings become part of the evidence.

A useful stress test is to take the most recent significant incident and try to rebuild its story from records alone. When did the organization become aware? Who classified it, and on what criteria? Who decided whether to notify, and when? What did each notice say, and who approved it? If the answers depend on recollection, the process works only while the same people stay in the same roles.

A starting position

1. Determine status per legal entity: NIS2 essential, important or out of scope; DORA financial entity or ICT third-party provider; Cyber Resilience Act manufacturer, importer or distributor; GDPR controller or processor.

2. Build one incident record and one classification model whose outputs feed every notification route, with the shortest applicable clock as the internal standard.

3. Maintain one third-party register structured to satisfy NIS2, DORA and the Cyber Resilience Act together.

4. Rebuild board reporting around the evidence directors need to show oversight.

There is a trade-off in who owns each piece. Central ownership gives consistency and a single view for the board. Local ownership gives accuracy on national rules and a clear answer for each supervisor. Most groups need both: a central assurance function that sets the model and tests it, and local owners who answer to their own regulators.

Sources

1. European Commission: Commission calls on 23 Member States to fully transpose the NIS2 Directive – Start of infringement procedures; the later reasoned opinions are on the Commission’s infringement pages.

2. EUR-Lex: NIS2 Directive, DORA, Cyber Resilience Act and GDPR – Primary texts for management body duties, supply chain measures and reporting timelines.

3. Austrian Financial Market Authority: DORA ICT-related incidents – Initial, intermediate and final report timings.

4. Hunton Andrews Kurth: EU Digital Omnibus introduces a single reporting point for cybersecurity incidents – Proposal status; not adopted law.

5. European Commission: Cyber Resilience Act – Reporting obligations and implementation guidance.