\u23f1 14 min Reading Time<\/p>\n
DORA has been applicable since January 2025, NIS2 transposed into German law since December 2025. For financial service providers, this means: two regulations with different deadlines, definitions, and reporting systems – but massive content overlaps. Those who address both frameworks in isolation double the effort without added value. Those who understand the synergies save millions and build an integrated compliance system that actually delivers security. This article shows where DORA and NIS2 overlap, where they differ, and what financial companies can do once instead of twice.<\/strong><\/p>\n Both DORA and NIS2 pursue the same overarching objective: strengthening cyber resilience in Europe. Both require risk management, incident reporting, penetration testing, and securing supply chains. The fundamental difference lies in scope and specificity.<\/p>\n DORA is an EU regulation that applies directly – without national transposition. It targets exclusively the financial sector: banks, insurers, securities firms, payment service providers, crypto asset service providers, and their critical ICT third-party service providers. DORA defines granular requirements for digital operational resilience, from ICT risk management to incident reporting and Threat-Led Penetration Testing (TLPT).<\/p>\n NIS2 is an EU directive that had to be transposed into national law. In Germany, this was done through the NIS-2 Implementation and Cybersecurity Strengthening Act, which came into force in December 2025. NIS2 applies across sectors to “essential” and “important” entities in 18 sectors – including the financial sector. The requirements are less granular than DORA\u2019s but cover a broader spectrum.<\/p>\n DORA is considered lex specialis over NIS2 in the financial sector. This means: Where DORA defines specific requirements, these take precedence over the more general NIS2 provisions. The NIS2 directive itself confirms this in Article 4(2) and explicitly refers to DORA as a sector-specific regulation.<\/p>\n In practice, however, this is more complicated than it sounds. The lex specialis principle does not mean NIS2 is irrelevant for financial companies. It only means DORA takes precedence where it regulates the same topics in greater detail. In areas not covered by DORA – such as supply chain security beyond ICT service providers or the security of OT systems – NIS2 continues to apply.<\/p>\n “DORA as lex specialis does not relieve financial companies of NIS2 obligations. It shifts priorities: DORA defines the ‘what’ in detail, while NIS2 fills the gaps. Those who only read DORA systematically overlook obligations.”<\/p>\n<\/div>\n For a detailed look at how BaFin reviews DORA implementation, see our article on MyBusinessFuture: DORA: BaFin Reviews Financial Institutions<\/a>.<\/p>\n The good news: About 60-70 percent of DORA and NIS2 requirements overlap in content. Those who leverage these synergies avoid massive duplication of effort. Here are the key areas where a single implementation serves both frameworks:<\/p>\n DORA (Chapter II, Articles 5-16) requires a comprehensive ICT risk management framework. NIS2 demands in Article 21 “appropriate and proportionate technical, operational, and organizational measures” for risk management. In practice: An ICT risk framework built to DORA standards automatically fulfills NIS2\u2019s risk management requirements – DORA is more detailed and stringent here.<\/p>\n \u25cf Implement once:<\/strong> ICT risk management framework according to DORA standards. This framework covers all NIS2-relevant risk management requirements.<\/p>\n \u25cf Adjust documentation:<\/strong> Supplement DORA documentation with NIS2-specific references to ensure compliance evidence holds up under both regulations.<\/p>\n Both frameworks require structured incident management. DORA defines detailed requirements for classification, reporting, and follow-up of ICT incidents in Chapter III (Articles 17-23). NIS2 mandates an “early warning system” and structured reporting in Article 23.<\/p>\n The incident management process can be built uniformly. The critical difference lies in reporting channels and deadlines – more on this in the reporting obligations section.<\/p>\n DORA requires regular penetration tests in Articles 26-27 and, for systemically important institutions, Threat-Led Penetration Testing (TLPT) under the TIBER-EU framework. NIS2 generally calls for “policies and procedures to assess the effectiveness” of security measures.<\/p>\n A DORA-compliant testing program with TLPT far exceeds NIS2\u2019s requirements. Here, the DORA implementation is fully sufficient.<\/p>\n DORA requires comprehensive ICT business continuity plans (Article 11). NIS2 demands “maintenance of operations” and crisis management (Article 21(2c)). Again, a DORA-compliant BCM program covers NIS2\u2019s requirements – DORA is more specific and stringent.<\/p>\n Despite the synergies, there are areas where DORA and NIS2 diverge substantially, requiring separate measures:<\/p>\n This is where financial service providers face the greatest operational overhead. DORA and NIS2 both require incident reporting – but to different authorities with different deadlines and formats:<\/p>\n \u25cf DORA:<\/strong> Report to the competent financial supervisory authority (in Germany: BaFin). Initial report within 24 hours of classifying an incident as “major ICT-related.” Intermediate report within 72 hours. Final report within one month. Format: EBA\/ESMA reporting forms.<\/p>\n \u25cf NIS2:<\/strong> Report to the competent national authority (in Germany: BSI). “Immediate” early warning within 24 hours. Detailed report within 72 hours. Final report within one month. Format: BSI reporting portal.<\/p>\n Although the deadlines sound similar, the reporting systems, forms, and contacts differ. Financial companies must master both reporting channels operationally. Practical tip: Create a unified internal incident report and adapt it to the respective form requirements of BaFin and BSI – instead of building two completely separate processes.<\/p>\n The management of ICT third-party service providers is the area where DORA sets the strictest and most detailed requirements of all European regulations. DORA requires:<\/p>\n \u25cf Register of Information (RoI):<\/strong> Complete documentation of all contractual agreements with ICT third-party service providers. This register must include granular details: subject matter, data locations, subcontractors, exit strategies, and dependency analyses. The deadline for the first complete RoI was Q1 2026.<\/p>\n \u25cf Criticality Assessment:<\/strong> Each ICT service provider must be assessed for its criticality to business functions. For “critical” providers, stricter requirements apply to contract design, audit rights, and exit scenarios.<\/p>\n \u25cf Concentration Risk Analysis:<\/strong> Financial companies must analyze whether they are overly dependent on individual ICT providers – a particularly relevant issue with hyperscalers (AWS, Azure, GCP).<\/p>\n NIS2 also requires “supply chain security” (Article 21(2d)), but in far less detail. For financial companies, the DORA TPRM framework is the standard that must be implemented. NIS2\u2019s requirements are included within it.<\/p>\n DORA introduces an entirely new supervisory framework in Chapter V: Critical ICT third-party service providers (such as large cloud providers) will in future be directly supervised by a “Lead Supervisory Authority” of the ESAs (EBA, ESMA, EIOPA). This element has no counterpart in NIS2 and affects financial companies indirectly – they must ensure their critical ICT service providers meet the new supervisory requirements.<\/p>\n “The Register of Information is the biggest operational challenge for many financial institutions under DORA. Those who have not systematically documented their ICT supplier relationships so far now face a mountain of catch-up work – and a deadline that has already passed.”<\/p>\n<\/div>\n Instead of treating DORA and NIS2 as two separate compliance projects, financial companies should pursue an integrated approach. The core idea: Build a single governance framework that serves both regulations, using DORA\u2019s requirements as the foundation (since they are more detailed).<\/p>\n Here\u2019s what an integrated approach looks like in practice:<\/p>\n \u25cf Step 1 – Mapping:<\/strong> Create a cross-reference matrix that assigns each DORA requirement to the corresponding NIS2 requirement. The ESAs and BSI provide mapping documents as a starting point. Identify three categories: “Covered by DORA,” “Covered by NIS2,” “Both require separate measures.”<\/p>\n \u25cf Step 2 – Unified Risk Management:<\/strong> Implement an ICT risk management framework according to DORA standards (Articles 5-16). Supplement it with NIS2-specific elements such as OT security and non-ICT-related supply chain security.<\/p>\n \u25cf Step 3 – Parallel Reporting Channels:<\/strong> Build a unified internal incident management process. Implement two parallel outputs at the end of the reporting chain: one to the BaFin reporting system (DORA) and one to the BSI reporting portal (NIS2). The internal process is identical; only the final steps differ.<\/p>\n \u25cf Step 4 – Integrated TPRM:<\/strong> Use the DORA Register of Information as the central database for all third-party risk management. Expand it to include non-ICT suppliers relevant under NIS2.<\/p>\n \u25cf Step 5 – Governance:<\/strong> Establish a single governance structure (e.g., a “Digital Resilience Committee”) responsible for both DORA and NIS2 compliance. Avoid parallel compliance teams for different regulations.<\/p>\n The DORA Register of Information (RoI) deserves special attention because it is the most labor-intensive single requirement for many institutions. The RoI must document all contractual agreements with ICT third-party service providers – including details that many companies have not previously recorded centrally:<\/p>\n \u25cf Contract Details:<\/strong> Subject matter, duration, termination periods, SLAs, liability provisions<\/p>\n \u25cf Data Locations:<\/strong> Where are data processed and stored? Which jurisdictions are affected?<\/p>\n \u25cf Subcontractor Chains:<\/strong> Which sub-service providers does the ICT provider use? Where are they located?<\/p>\n \u25cf Dependency Analysis:<\/strong> Which business functions depend on this service provider? What happens in case of failure?<\/p>\n \u25cf Exit Strategy:<\/strong> How can the service provider be replaced? Which data must be migrated?<\/p>\n Institutions that have not yet completed the RoI should prioritize pragmatically: Start with the most critical service providers (cloud providers, core banking systems, payment infrastructure) and expand gradually. BaFin has signaled that it will assess progress and methodology during the initial review – not just the final result.<\/p>\n Both DORA and NIS2 emphasize management\u2019s responsibility for cybersecurity. DORA explicitly holds the management body responsible for approving and overseeing the ICT risk management framework (Article 5(2)). NIS2 requires that management bodies approve risk management measures, monitor their implementation, and participate in cybersecurity training (Article 20).<\/p>\n Under German implementation, managing directors and board members can be held personally liable if they fail to meet their oversight obligations. The fines are substantial: up to 10 million euros or 2 percent of global annual turnover under NIS2, with comparable amounts under DORA.<\/p>\n The practical consequence: Cybersecurity is no longer an IT issue that can be delegated to the CISO. Board members and managing directors must be demonstrably involved – in decisions, approvals, and regular reviews.<\/p>\n \n“GAP assessment against both frameworks: Don\u2019t review DORA and NIS2 separately, but conduct an integrated GAP analysis.”\n<\/p><\/blockquote>\n For financial companies looking to efficiently manage the compliance double pressure, here are the concrete next steps:<\/p>\n \u25cf GAP Assessment Against Both Frameworks:<\/strong> Don\u2019t review DORA and NIS2 separately, but conduct an integrated GAP analysis. Result: A consolidated action plan instead of two.<\/p>\n \u25cf Complete the Register of Information:<\/strong> If not already done, start immediately with the top 20 ICT service providers. Don\u2019t wait for perfection – an 80% RoI that exists is better than a 100% RoI that will be ready in six months.<\/p>\n \u25cf Set Up Dual Reporting Processes:<\/strong> Implement a unified internal incident process with two outputs (BaFin + BSI). Conduct test reports before an actual incident occurs.<\/p>\n \u25cf Plan the TLPT Program:<\/strong> For systemically important institutions, Threat-Led Penetration Testing is mandatory under DORA. The effort is considerable (6-12 months per TLPT cycle) – start early with a qualified TLPT provider.<\/p>\n \u25cf Train Management:<\/strong> Board members and management must be demonstrably trained under both frameworks. Establish a joint training program that addresses DORA and NIS2 in an integrated manner.<\/p>\n \u25cf Assess Concentration Risk:<\/strong> Analyze dependencies on individual cloud providers and ICT service providers. Document multi-cloud and exit strategies.<\/p>\n \u25cf Review Contracts:<\/strong> Audit all ICT contracts against DORA requirements (audit rights, subcontractor clauses, exit provisions). Initiate renegotiations early.<\/p>\n DORA and NIS2 are not the last regulations that will impact financial companies in cybersecurity. With the EU AI Act, the Cyber Resilience Act, and the Data Act, additional frameworks are coming that will overlap and need to be considered in an integrated manner.<\/p>\n Financial institutions that now build a flexible, integrated compliance framework will more easily absorb these additional regulations than companies that treat each new law as an isolated project. The integrated approach pays off not only in the short term – it is the only scalable strategy for Europe\u2019s increasing regulatory density.<\/p>\n The supervisory authorities – BaFin and BSI – are aware of the double burden and are working on coordinated audit approaches. Nevertheless, the responsibility for efficient implementation lies with the companies themselves. Those who leverage synergies now will not only save compliance costs but build digital resilience that truly protects. For a detailed overview of NIS2 requirements, see our article NIS2 in Germany: What Companies Need to Know and Implement Now<\/a>.<\/p>\n Yes. DORA applies as lex specialis and takes precedence in case of overlaps, but NIS2 applies additionally in areas not covered by DORA. Financial companies must be familiar with both frameworks and meet their respective requirements. An integrated compliance approach avoids duplication of effort.<\/p>\n Under DORA, to the competent financial supervisory authority (BaFin) within 24 hours. Under NIS2, to the BSI, also “immediately” (in practice, within 24 hours). Both reports must be submitted in parallel – they involve different reporting systems and forms.<\/p>\n The Register of Information is a complete documentation of all contractual agreements with ICT third-party service providers under DORA. It must include details on the subject matter, data locations, subcontractors, dependencies, and exit strategies. The deadline for the first complete register was Q1 2026. Institutions that have not yet completed it should start immediately with the most critical service providers.<\/p>\n Yes, under both frameworks. DORA holds the management body responsible for approving and overseeing the ICT risk management framework. NIS2 provides for personal liability if management fails to meet its oversight obligations. Managing directors and board members must be demonstrably involved in cybersecurity decisions.<\/p>\n Through an integrated compliance approach: Build a single governance framework that serves both regulations. Use DORA\u2019s requirements as the foundation (since they are more detailed) and specifically supplement NIS2 gaps. Conduct a unified GAP analysis instead of two separate ones. Consistently leverage synergies in risk management, BCM, and testing. Avoid parallel compliance teams.<\/p>\n Header Image Source: Pexels \/ Sora Shimazaki<\/p>\n","protected":false},"excerpt":{"rendered":"\u23f1 14 min Reading Time DORA has been applicable since January 2025, NIS2 transposed into German law since December 2025. For financial service providers, this means: two regulations with different deadlines, definitions, and reporting systems – but massive content overlaps. Those who address both frameworks in isolation double the effort without added value. Those who […]","protected":false},"author":55,"featured_media":5329,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_yoast_wpseo_focuskw":"dora and nis2","_yoast_wpseo_title":"","_yoast_wpseo_metadesc":"DORA and NIS2 compliance made simple\u2014reduce risk, avoid fines, and streamline efforts for financial firms. Learn how to succeed with both now.","_yoast_wpseo_meta-robots-noindex":"","_yoast_wpseo_meta-robots-nofollow":"","_yoast_wpseo_meta-robots-adv":"","_yoast_wpseo_canonical":"","_yoast_wpseo_opengraph-title":"","_yoast_wpseo_opengraph-description":"","_yoast_wpseo_opengraph-image":"","_yoast_wpseo_opengraph-image-id":0,"_yoast_wpseo_twitter-title":"","_yoast_wpseo_twitter-description":"","_yoast_wpseo_twitter-image":"","_yoast_wpseo_twitter-image-id":0,"footnotes":""},"categories":[215,251],"tags":[],"class_list":["post-7899","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-case-studies","category-news"],"wpml_language":"en","wpml_translation_of":5311,"_links":{"self":[{"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/posts\/7899","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/users\/55"}],"replies":[{"embeddable":true,"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/comments?post=7899"}],"version-history":[{"count":5,"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/posts\/7899\/revisions"}],"predecessor-version":[{"id":11881,"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/posts\/7899\/revisions\/11881"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/media\/5329"}],"wp:attachment":[{"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/media?parent=7899"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/categories?post=7899"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/tags?post=7899"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}TL;DR<\/h2>\n
\n
Two Regulations, One Goal – But Different Paths<\/h2>\n
Lex specialis: What Does DORA\u2019s Precedence Mean?<\/h2>\n
Overlaps: What Only Needs to Be Done Once<\/h2>\n
ICT Risk Management<\/h3>\n
Incident Response and Management<\/h3>\n
Penetration Testing and Vulnerability Management<\/h3>\n
Business Continuity Management<\/h3>\n
The Critical Differences: What Must Be Done Twice<\/h2>\n
Reporting Obligations: Two Systems, Two Authorities, Different Deadlines<\/h3>\n
IT Third-Party Risk Management: DORA Goes Much Further<\/h3>\n
Supervisory Framework for Critical ICT Third-Party Service Providers<\/h3>\n
The Integrated Compliance Approach: One Framework for Both<\/h2>\n
Register of Information: The Practical Challenge<\/h2>\n
Management on the Hook: Liability Under DORA and NIS2<\/h2>\n
Practical Checklist: Managing the DORA + NIS2 Double Pressure<\/h2>\n
Outlook: Regulatory Density Continues to Increase<\/h2>\n
Frequently Asked Questions<\/h2>\n
Do financial companies have to comply with both DORA and NIS2?<\/h3>\n
To whom must security incidents be reported?<\/h3>\n
What is the Register of Information, and by when must it be completed?<\/h3>\n
Is management personally liable?<\/h3>\n
How can compliance costs for DORA and NIS2 be reduced?<\/h3>\n
Further Reading<\/h2>\n
\n
More from the MBF Media Network<\/h2>\n
\n