German financial firms are no longer reading DORA and NIS-2 as two separate checklists. They are discovering they are two layers on the same governance stack.
This is not a compliance style story. It is an operating model story.
At least three structural anchors are now visible in the public material, and they point to the same point: firms that keep controls siloed by framework will fail sooner than those that unify incident, vendor, and reporting evidence.
Problem: the same risk events are being captured in different languages
The first anchor is timing and maturity around DORA information-register work. BaFin’s DORA page for information-register and notification obligations says the first 2025 reference cycle with date 31 March 2025 is complete, and that the process has moved into ongoing validation and readiness mechanics from 2 June 2025 onward through TEST/continuity pathways BaFin, 18 Jul 2025 update.
What changed in practice is simple: firms cannot treat DORA filing as a one-time submission ritual. Reporting is now a maintenance discipline, and that discipline requires internal ownership of evidence quality.
A second anchor is NIS-2 reporting topology. BSI says NIS-2 registration and reporting requirements apply from 6 Dec 2025, with registration and reporting routed through the new federal portal path at portal.bsi.bund.de, and states that this is the practical entry channel for covered entities BSI NIS-2 registration information.
That move sounds administrative, but it changes who must care. Reporting mechanics are now anchored in a national cyber-resilience channel with cross-sector implications, not only a finance-only template.
A third anchor appears in DORA ICT-risk management guidance itself: incident handling, third-party control, and operational resilience are framed as lifecycle obligations, from onboarding to recovery, not as one-time policy annexes BaFin IKT risk management page.
These anchors combine into one operational gap.
A firm can have accurate DORA records and still fail NIS-2 readiness if those records cannot be translated to the reporting channel and incident taxonomy BSI expects.
Analysis: why convergence pain appears in execution, not interpretation
The pain point is not “do we understand the law.” The harder question is “where does incident meaning live?”
DORA asks for evidence tied to ICT risk, digital concentration, and continuity obligations in the financial context. NIS-2 demands that covered entities register, report incidents, and operate through an updated national portal path. Both ask for facts. Both ask for ownership.
Yet many firms keep two internal dictionaries:
- one for DORA obligations (reporting templates, supervisory wording, test-readiness language),
- one for cyber incident operations (severity, timing, channeling, authority notifications).
The result is semantic drift.
If a critical event is “material” under one framework and “significant incident” under another, escalation pathways split. If a third-party dependency record is updated for one channel but not the other, controls appear complete in each silo yet incomplete end-to-end. If legal ownership sits in one function and data ownership sits in another, remediation timelines diverge.
The overlap is therefore structural:
- Incident taxonomies are no longer interchangeable.
- Vendor registers are no longer just procurement artifacts.
- Board accountability is no longer only about policy sign-off.
BaFin and BSI are not inventing a new legal category. They are forcing firms to make the same control stack answer to two auditors who look for different phrasing and different timing thresholds.
Under DORA-influenced flow, the firm needs to show governance, third-party concentration, and continuity controls in a disciplined record set. Under NIS-2 channeling, it also needs clear registration-linked reporting and portal-compatible incident routing.
These outcomes are only compatible if data definitions, ownership fields, and severity mapping are pre-aligned. If not, teams spend more energy translating their own reports than strengthening controls.
This is why the transition from DORA setup to DORA maintenance matters. The 2025 cycle completion statement from BaFin is not a milestone of closure. It is the start of recurring obligations becoming routine. And routine obligations become fragile when the same facts are maintained in parallel, contradictory formats.
Analysis: what is different for German financial firms in 2026
Second, the transition window is still real. The BSI page’s transition note shows overlap with MIP2 still available through 31 July 2026 and extended in parts through 31 December 2026 for certain KRITIS operators and federal authorities BSI NIS-2 portal migration notes.
Overlap sounds generous, but it is mostly execution noise.
If an organization keeps “old channel” and “new channel” teams, it doubles translation cost.
If it keeps a single evidence model with one incident taxonomy and one vendor register, overlap becomes a managed cutover instead of a compliance fire drill.
The operational implication is that convergence is not achieved by adding another governance layer. It is achieved by deleting duplicated reporting logic.
Implications: what firms should do now
Three concrete moves matter most.
First: build one incident dictionary and one dependency register that both DORA and NIS-2 teams consume.
That sounds simple, but it changes tooling requirements:
- the same criticality levels must map to both DORA readiness logic and NIS-2 reporting triggers,
- severity grading must be stable across dashboards,
- executive escalation conditions should be shared, with channel-specific routing handled by workflow rules.
Second: move from legal ownership to operational ownership.
DORA documents are strongest when risk owners, board committees, and continuity teams agree on who owns evidence quality. NIS-2 makes that ownership more visible because reporting channeling forces clear operational accountability.
Boards and senior management committees should not ask “is the filing complete?” alone.
They should ask “is the same evidence usable everywhere, and is ownership explicit at upload time?”
Third: stop treating cyber reporting as external compliance output only.
If controls are written only for examiners, firms miss the internal opportunity. A unified stack improves audit speed, shortens incident triage, and reduces contradictory executive narratives during an emergency.
DORA and NIS-2 are one story with two chapters.
And the next chapter is written by teams that can turn “incident captured” into “incident understood” before anyone asks for a second export.
The practical test is straightforward:
- does one source-of-truth event feed both the DORA evidence system and the NIS-2 portal workflow,
- do vendor records connect to incident logic,
- and do senior managers know who is accountable when evidence is requested under either framework.
If the answer is yes, firms will spend less time repackaging and more time hardening.
If the answer is no, convergence is not a policy slogan. It is a deadline.
Sources
- BaFin, DORA information-register and notification obligations page (update 18 Jul 2025): first 2025 submission with reference date 31 Mar 2025 completed; post-2025 submissions moved to ongoing validation rhythm with TEST-readiness context. https://www.bafin.de/DE/Aufsicht/DORA/Informationsregister_und_Anzeigepflichten/Informationsregister_und_Anzeigepflichten_artikel.html
- BaFin, DORA node and implementation materials https://www.bafin.de/DE/Aufsicht/DORA/DORA_node.html
- BaFin, DORA IKT risk management materials https://www.bafin.de/DE/Aufsicht/DORA/IKT_Risikomanagement/IKT_Risikomanagement_artikel.html
- BSI NIS-2 registration information page https://mip2.bsi.bund.de/en/info-nis2-registrierung/
- European Parliament/Official text: Regulation (EU) 2022/2554, Article 64 DORA applicability from 17 Jan 2025
Discussion
Sign in to join the discussion.
No comments yet. Be the first to share your thoughts.