SaaSFort A German fintech in 2026 wakes up to two overlapping cybersecurity regulators. DORA (the EU Digital Operational Resilience Act) is in force since 17 January 2025 and is supervised in Germany by BaFin. NIS2 transposed into German law via the BSIG amendment is supervised by the BSI. Both regulators care about your ICT risk management; both want incident notifications; both can fine. The fintech that treats them as one project saves months; the fintech that treats them as two parallel projects burns the same months twice.
This article maps where DORA and NIS2 overlap for a BaFin-supervised B2B fintech (payment provider, banking-as-a-service, e-money institution, investment firm, insurance intermediary), where they differ, and what a 30-day pre-audit prep window should produce.
One-line definitions
| DORA | NIS2 | |
|---|---|---|
| Regulation | EU 2022/2554, Digital Operational Resilience Act | EU 2022/2555, NIS2 Directive |
| In force | 17 January 2025 (no transition for financial entities) | NIS2 transposition deadline 17 Oct 2024; Germany BSIG March 2026 |
| Primary supervisor (Germany) | BaFin (Bundesanstalt für Finanzdienstleistungsaufsicht) | BSI (Bundesamt für Sicherheit in der Informationstechnik) |
| Sectoral scope | Financial entities + their critical ICT third-party providers | 18 sectors including banking and financial market infrastructures |
| Penalty ceiling (Germany) | Up to 1% of average daily turnover per day of infringement (FinmadiG) | Up to EUR 10M or 2% global turnover (essential entities) |
Important: a German fintech is in scope of both. The two regulators sit at the same table on cyber-risk; they do not split the work neatly.
Where DORA and NIS2 overlap (substantively)
Overlap 1: ICT risk management framework
DORA Articles 5 to 16 require a comprehensive ICT risk management framework. NIS2 Article 21 lists ten cybersecurity risk-management measures. The two frameworks map heavily on the technical side: identification of risk, protection and prevention, detection, response and recovery, learning and evolving. A fintech can build ONE ICT risk management framework that satisfies both by mapping each control to both DORA Article references AND NIS2 Article 21 sub-clauses.
Overlap 2: Incident reporting
Both require incident reporting. DORA Article 19 obliges financial entities to classify and report major ICT-related incidents to the competent authority (BaFin in Germany), with timelines under Commission Delegated Regulation EU 2025/295. NIS2 Article 23 requires a 24-hour early warning, 72-hour formal notification, and 1-month final report to the national CSIRT.
The overlap is the principle (notify supervisor of significant incidents); the difference is the channel (BaFin for DORA, BSI for NIS2) and the trigger thresholds. A ransomware attack on a BaFin-supervised fintech that also processes EU personal data triggers DORA, NIS2 AND GDPR notification streams. Three filings; one underlying incident-response runbook with three notification branches.
Overlap 3: Third-party ICT risk
DORA Article 28 requires a register of all contractual arrangements with ICT third-party service providers, plus risk assessment, exit strategy, and concentration analysis. NIS2 Article 21(2)(d) requires supply-chain security including direct suppliers and service providers. Both flow into the same vendor register; DORA adds resilience-testing obligations and concentration risk that NIS2 does not explicitly demand.
Overlap 4: Resilience testing
DORA Articles 24 to 27 require digital operational resilience testing on a risk-based programme, with advanced threat-led penetration testing (TLPT) for financial entities meeting certain criteria. NIS2 Article 21(2)(f) requires policies to assess the effectiveness of risk-management measures.
The overlap is the principle; DORA is more prescriptive on TLPT depth and frequency. A fintech that runs DORA-compliant TLPT automatically satisfies NIS2 Art. 21(2)(f) for the equivalent surface.
Where they differ (so you do not miss obligations)
Difference 1: TLPT (DORA-specific depth)
DORA Article 26 introduces Threat-Led Penetration Testing as a regulated exercise for financial entities above defined thresholds. TLPT follows the TIBER-EU framework (or member-state equivalent) and requires accredited external testers. NIS2 has no equivalent prescriptive depth; a NIS2-only programme that scopes pen tests informally fails the DORA bar.
Difference 2: Concentration risk (DORA-specific)
DORA Article 29 requires financial entities to assess concentration risk where a single ICT third-party provider serves a large portion of the entity’s critical functions. NIS2 does not explicitly require concentration analysis. Most fintechs discover this as a documentation gap when DORA is applied for the first time.
Difference 3: Management-body personal liability (NIS2 + BSIG)
NIS2 Article 20 plus German BSIG §38 create personal liability for management-body members on cybersecurity oversight. DORA has equivalent governance language in Articles 5 to 6 but no equivalent personal-liability ban mechanism. Both regulations sit on the management body; the NIS2 angle bites harder personally.
Difference 4: Cross-sectoral vs sectoral
NIS2 covers 18 sectors. DORA covers only financial services. A fintech is subject to both because it sits at the intersection; a non-financial SaaS is subject only to NIS2.
Difference 5: Supervisory cadence
BaFin supervises DORA via the existing financial-supervision cadence (BaFin examiners are familiar territory for any fintech that already deals with banking supervision). BSI supervises NIS2 with a different toolkit: the BSI Meldeportal, the Prüfungsanordnung audit-order, the on-site inspection power under NIS2 Article 32. A fintech needs to be ready for both supervisors with different evidence packages.
The 30-day pre-audit prep playbook
For a German fintech entering its first DORA or NIS2 supervisory window, here is the prep sequence.
Day 1 to 5: Map your ICT risk management framework to both regulations. One framework document with two header columns: DORA Article references and NIS2 Article 21 sub-clauses. If you have a SOC 2 or ISO 27001 in place, this work is largely renaming; if you have neither, this is the largest single time investment.
Day 6 to 10: Update your third-party ICT register to DORA Article 28 schema. The DORA schema (per ITS 2024/1773) is more granular than typical vendor registers: criticality classification, location of data processing, exit strategy, concentration risk. NIS2 supply-chain documentation is a subset; DORA is the superset.
Day 11 to 15: Verify external posture across customer-facing fintech surfaces. Run an external scan on the production payment domain, customer dashboard, marketing site, partner-API subdomain. Each finding maps to BOTH DORA Article 9 ICT protection and prevention AND NIS2 Article 21(2)(b)(e)(h)(j). Free SaaSFort scan here; the scan PDF carries the dual mapping.
Day 16 to 20: Tabletop exercise the incident response runbook. DORA Article 19 plus NIS2 Article 23 plus GDPR Article 33 means three notification branches. The tabletop must exercise all three with realistic timelines. Document the tabletop minutes; both BaFin and BSI will ask for them.
Day 21 to 25: Prepare the management-body evidence pack. NIS2 Article 20 plus BSIG §38 require documented training records and risk-measure approvals from the management body. DORA Articles 5 to 6 require equivalent governance evidence. Combine into one management-body file with both header columns.
Day 26 to 30: Compile the audit-ready package. External-posture PDF (covers external surfaces under both DORA Art. 9 and NIS2 Art. 21), risk register (dual-mapped), third-party ICT register (DORA Art. 28 schema), incident response runbook with three branches, tabletop minutes, management-body training records, BSI Meldeportal registration confirmation.
Where SaaSFort fits in the dual-regulation stack
Every SaaSFort scan PDF maps external-posture findings to NIS2 Article 21 sub-clauses AND to DORA Article 9 ICT protection and prevention requirements. The same TLS configuration evidence counts for both supervisors. SaaSFort Starter at EUR 9 per month covers 1 domain with the dual mapping; Growth at EUR 19 covers 10 domains.
For DORA’s resilience-testing requirements: SaaSFort is the continuous-monitoring layer (DORA Article 9), not the TLPT layer (DORA Article 26). A fintech subject to TLPT runs both: SaaSFort continuously for the external-posture surface, plus an accredited TLPT engagement annually or biennially for the threat-led depth.
Frequently asked questions
Does BaFin verify NIS2 compliance during a DORA examination?
Technically no, but in practice BaFin examiners increasingly note NIS2 gaps as risk factors in the DORA examination report. The two supervisors share information under the German supervisory cooperation framework. Prepare both regulators’ evidence together.
My fintech has a banking licence; do DORA AND NIS2 both apply?
Yes, almost certainly. Licensed credit institutions and payment service providers under German law are DORA-scoped and typically NIS2 essential entities under Annex I (banking and financial market infrastructures). Cross-check your specific classification with legal counsel.
Can a DORA-compliant ICT risk framework substitute for NIS2 Article 21 evidence?
Largely yes on technical controls. A DORA Article 5 to 16 framework with mapped sub-references to NIS2 Article 21 sub-clauses produces the documentary evidence for both. The 20 to 30% gap is the NIS2-specific incident-reporting cadence (24h to BSI vs DORA timelines to BaFin) and the management-body training requirements under NIS2 Article 20 plus BSIG §38.
What is TIBER-EU and do I need to run it?
TIBER-EU is the threat-led penetration testing framework adopted by the European Central Bank. It is the methodology DORA Article 26 references for TLPT. Whether you must run it depends on your size and criticality classification under DORA. Smaller fintechs (below the DORA TLPT thresholds) are not required to run TIBER-EU but may run lighter pen tests under DORA’s general resilience-testing regime (Articles 24 to 25).
How do DORA penalties compare to NIS2 in Germany?
DORA penalties in Germany are framed by FinmadiG (the Financial Markets Digitalisation Act) and can reach 1% of average daily turnover per day of infringement, which becomes very large very fast. NIS2 penalties via BSIG can reach EUR 10M or 2% global turnover. The mathematics of “which is worse” depends on company size and infringement duration; both are board-level financial risks.
Does DORA add new GDPR obligations for fintechs?
No. DORA does not modify GDPR. But the DORA incident-reporting timelines and third-party register schema introduce new evidence streams that intersect with GDPR Article 33 breach notifications and Article 28 processor agreements. Build one incident runbook with three notification branches (DORA to BaFin, NIS2 to BSI, GDPR to the DPA).
Bottom line
A BaFin-supervised German fintech in 2026 lives under DORA, NIS2 and GDPR simultaneously. Treat them as one project with three notification branches, not three parallel projects. The 30-day pre-audit playbook plus an external posture grade get the technical-controls evidence in place; the legal and procedural work is mostly mapping existing documents to the right Article references.
Run a free SaaSFort scan to baseline the dual DORA + NIS2 external-posture evidence in 60 seconds. Pricing from EUR 9 per month covers continuous monthly monitoring across all fintech-customer-facing domains.
De la lectura a la acción
Escanee su dominio gratis. Primeros resultados en menos de 10 segundos — sin registro.