Swiss financial institutions operating in EU markets are now simultaneously subject to DORA (Digital Operational Resilience Act, effective January 2025), NIS2 obligations through EU-market subsidiary structures, and FINMA's own operational resilience requirements under Rundschreiben 2023/1. Each regime uses different vocabulary, organises requirements differently, and defines incident classification thresholds independently. The practical result is that many compliance and security teams run three parallel assessment processes, generate three sets of control evidence, and answer three sets of auditor questions — for what are, in most cases, substantially overlapping controls. NIST CSF 2.0 and CIS Controls v8 provide a shared control vocabulary that maps to all three frameworks and can dramatically reduce this duplication, but only if the mapping is built deliberately, not assumed.
Understanding the Control Overlap
DORA's five pillars — ICT risk management, incident reporting, operational resilience testing, third-party ICT risk, and threat intelligence sharing — cover the same substantive ground as NIS2's ten Article 21 measures, which include risk management policies, incident handling, business continuity, supply chain security, vulnerability disclosure, asset management, access control, cryptography, HR security, and awareness training. FINMA RS 2023/1 adds Swiss-specific requirements for operational risk governance, ICT risk, cyber resilience, third-party oversight, and direct incident notification to FINMA.
The overlap is not marginal. DORA Articles 6 through 16, which cover ICT risk management framework requirements, address the same controls as NIS2 Article 21 and FINMA RS 2023/1's ICT risk sections: asset inventories, classification, protection measures, detection capabilities, response procedures, and recovery plans. A financial institution that has built a mature ICT risk management programme satisfying DORA is, in the control layer, already 80 to 90 percent compliant with NIS2 and FINMA's equivalent requirements. The compliance cost is not in the controls — it is in the documentation, the mapping, and the assessment processes that treat each framework as independent when they are not.
Third-party risk requirements represent the most acute example. DORA Chapter V requires a detailed ICT third-party risk management framework including contractual requirements, a register of arrangements, and enhanced oversight of critical third-party providers. NIS2 Article 21(2)(d) requires supply chain security measures including assessment of third-party security posture. FINMA RS 2023/1 mandates outsourcing risk management and IT service provider oversight. In most Swiss financial institutions, these three requirements produce three separate vendor assessment questionnaires, three separate contractual addendum templates, and three separate audit processes — for the same set of suppliers.
Why NIST CSF 2.0 and CIS Controls Work as the Unifying Layer
NIST CSF 2.0, published in February 2024, provides six core functions: Govern, Identify, Protect, Detect, Respond, and Recover. The new Govern function — absent in CSF 1.1 — explicitly addresses cybersecurity risk governance, policy, roles, and supply chain risk management. This addition makes CSF 2.0 the first version of the framework with direct, structured coverage of the governance chapters that dominate DORA and NIS2's compliance requirements. DORA's ICT governance obligations (Articles 5-15) map cleanly to CSF 2.0's Govern function; NIS2's Article 21 management accountability requirements map to the same function from a different regulatory angle.
CIS Controls v8 provides the implementation layer beneath the framework. Its 18 controls, grouped into Implementation Groups (IG1, IG2, IG3), translate CSF 2.0's abstract functions into specific, auditable safeguards. IG2 — designed for organisations with dedicated security staff and moderate risk profiles — is the appropriate baseline for most Swiss financial institutions and maps directly to DORA's proportionality principle, which scales requirements to the size and risk profile of the entity.
The critical operational value is that CIS Benchmarks — consensus hardening guides for operating systems, databases, cloud platforms, and applications — serve as technical evidence for multiple regulatory requirements simultaneously. A hardened Windows Server configuration verified against the CIS Microsoft Windows Server Benchmark satisfies DORA's ICT hardening requirements under Article 9, NIS2's Article 21(2)(h) cryptography and access control obligations, and FINMA RS 2023/1's ICT security baseline — from a single assessment artefact.
Building the Mapping in Practice
The unification exercise follows four steps. The first is a DORA gap analysis using CSF 2.0 as the control reference: for each DORA article, identify the corresponding CSF 2.0 function and category, then document current control maturity against that category. This produces a DORA compliance position expressed in CSF 2.0 language.
The second step runs NIS2 Article 21 requirements against the same CSF 2.0 mapping. Because DORA and NIS2 address substantially the same control domains, most of the NIS2 mapping will already be satisfied by the DORA assessment. The incremental work is identifying the NIS2 obligations that DORA does not cover — primarily awareness and training requirements under Article 21(2)(g) and HR security measures under Article 21(2)(i), which DORA treats less prescriptively.
The third step layers FINMA RS 2023/1. Most FINMA requirements are already covered by the DORA/NIS2 mapping. The incremental FINMA-specific obligations are primarily procedural: direct notification to FINMA using FINMA's own incident reporting template, documentation in German or French for examination by FINMA inspectors, and specific outsourcing notification requirements when engaging critical IT service providers. These are documentation and process requirements, not control gaps.
The fourth step adopts CIS Controls v8 safeguards as the implementation-level evidence layer beneath the CSF 2.0 mapping. Each CIS safeguard is tagged with the DORA article, NIS2 provision, and FINMA section it satisfies. The result is a single control inventory with explicit regulatory traceability: one control, multiple regulatory citations, one assessment cycle, three compliance positions.
Third-Party Risk: The Highest-Value Unification Target
Third-party risk is where the duplication problem is most expensive and where unified framework mapping delivers the most immediate return. CSF 2.0's Govern function includes the GV.SC (Supply Chain Risk Management) category, which covers third-party identification, risk assessment, contractual requirements, and ongoing monitoring. CIS Control 15 (Service Provider Management) provides implementation-level safeguards for the same domain.
A single third-party risk register keyed to CSF 2.0 GV.SC and CIS Control 15 can serve as the primary evidence source for DORA Chapter V, NIS2 Article 21(2)(d), and FINMA's outsourcing framework simultaneously. The register captures vendor name, service criticality classification, contractual security requirements, assessment results, and monitoring status — information required by all three frameworks. The only framework-specific additions are DORA's requirement to maintain a formal register of ICT third-party arrangements (Article 28(3)) and FINMA's notification requirement for material IT outsourcing arrangements. Both are additions to the same data set, not parallel data sets.
◆ Key Takeaway
The compliance duplication problem across DORA, NIS2, and FINMA is primarily a documentation problem, not a control problem. Most Swiss financial institutions already operate the required controls. NIST CSF 2.0 provides the common language to express those controls across all three frameworks; CIS Controls v8 provides the implementation evidence. The investment is in building the mapping once — not in remediating controls that are already in place.
- Adopt NIST CSF 2.0 as your organisation's primary control reference vocabulary before your next audit cycle — all three frameworks map to its six functions, eliminating the need to maintain framework-specific control inventories in parallel.
- Prioritise the CSF 2.0 Govern function first: DORA's ICT governance chapter and NIS2's Article 21 management accountability obligations overlap at approximately 80 percent — completing this mapping produces dual-framework coverage immediately from a single body of work.
- Build a single third-party risk register keyed to CSF 2.0 GV.SC and CIS Control 15; use it as the primary evidence source for DORA Chapter V, NIS2 Article 21(2)(d), and FINMA outsourcing oversight requirements — add DORA's Article 28(3) formal register and FINMA's notification trigger as documented fields within the same register.
- Adopt CIS Benchmarks as the technical hardening standard for all infrastructure tiers: every CIS Benchmark maps to CSF 2.0 Protect functions and simultaneously satisfies DORA ICT risk hardening requirements and NIS2 Article 21(2)(h) — a single hardening assessment serves three auditors.
- Determine your CIS Implementation Group level (IG1, IG2, or IG3) based on organisational size and risk profile — IG2 is the appropriate baseline for most Swiss financial institutions and aligns with DORA's proportionality principle, providing a defensible scoping rationale for regulatory examination.
- Run a residual gap analysis after the CSF 2.0 mapping to identify FINMA-specific procedural requirements not covered by DORA or NIS2: FINMA-format incident reports, German/French documentation requirements for examinations, and material outsourcing notification thresholds are the primary incremental items.
- Document the regulatory traceability in your GRC platform with explicit cross-references — one control entry, multiple regulatory citations — so that auditors from FINMA, EU competent authorities, and external assessors can verify compliance from a single source of truth rather than requesting separate evidence packages.
The EU's regulatory environment for financial institutions will continue to accumulate new requirements rather than shed old ones. The Digital Omnibus will streamline incident reporting portals; it will not harmonise the substantive control requirements of DORA, NIS2, and national frameworks like FINMA's. Swiss financial institutions that build their compliance architecture on a durable common framework — NIST CSF 2.0 anchored by CIS Controls — will be positioned to absorb new regulatory requirements as overlays rather than rebuilding their control library from scratch each time a new obligation arrives. The efficiency gain is real, material, and available now. It requires deliberate investment in the mapping layer, and that investment should happen before the next audit cycle begins.